General Master Boot Record

[Antti]

This is probably my first actual release of OSDev code. I have written a lot of code but never put it under public review. This is also like a test to see what happens if I try to do that. For me this whole publishing process is more important than the actual thing published at this time. This is important thing to mention because I do not think a release like this is worth an announcement in general but I play my "first release" card. I start with a small test that is called General Master Boot Record.

• 8086 compatible code.
• CHS and LBA disk access routines.
• Designed for real hard drives and USB sticks.
• USB emulated floppy or hard drive both work.
• Defensive programming taken very seriously.
• General code "alignment" for size-constrained area.

There is nothing special in the design itself and it is all about the implementation. If you think this license is still too restrictive (shoult not be) I can try to make it even more free. The license and my moral approval make it possible to use in proprietary software.

General Master Boot Record

Comments?

[Octocontrabass]

Comments?

Is there any particular reason you're overriding the assembler's optimizations? Most of your overrides have no effect at all, and a few of them make your code larger.

There are a few other space-wasters in your code, such as a far jump when CS is already a known value, and a CS segment override when the default segment has the same value as CS, an instruction that operates on AX when it could get the same result operating on AL, and an "add" that could be an "inc".

Your code for LBA to CHS conversion doesn't handle more than 256 cylinders. A setup where this matters would be rare, but it's a potential issue.

[Antti]

Is there any particular reason you're overriding the assembler's optimizations? Most of your overrides have no effect at all, and a few of them make your code larger.

This is a very valid question. Every instruction is thought-out when it comes to length and all those longer instructions are used just because their longer lengths. If you look at the binary code, you will see a few patterns that make it like thoroughly signed by me. This is just how it is.

a few other space-wasters in your code, such as a far jump when CS is already a known value, and a CS segment override when the default segment has the same value as CS.

That CS override is a bit unelegant but please note that the next instructions are very space inefficient too. There is a lot of room to make some small changes (and possible bug fixes that are usually just a very few bytes) without collapsing the overall binary structure of this sector.

Your code for LBA to CHS conversion doesn't handle more than 256 cylinders.

This was a design choice and should probably be mentioned on the feature list. Please note that it does handle it: an error message with very defined behavior.

Thank you very much for your comments. Any bugs?

[Antti]

My previous reply could be interpreted so that there is a tone of underestimation but I really try to avoid giving that impression. I take all the feedback seriously, listen to users (it does not matter whether there actually are users or not) and support all the software I release unless specifically announced otherwise.

The stylistic notes were very valid but I am not sure there existed an answer that rationalized the way things were implemented in a way that makes controversy disappear altogether. May I give an example? After releasing the first version, I started to think about tiny improvements for the next "merge window" if there were bugs that make it necassary to release the next version in the first place.

For the next version there will be two things on my list:

• Clear the boot partition signature area in the buffer before making the read calls.
• Clear register cx before getting the drive geometry. This will catch the error if the call does not modify it.

Both of these changes fit well in the code and take advantage of these so called "reserved" bytes, i.e. space inefficient instructions.

However, let's imagine a situation that someone actually started using the first release I made. Do I release an updated version every day and make it very confusing, e.g. was the first version useless and do I have to update my installer that embedded the code in it?

The current version has the exact same bytes than the first released version. It has no bugs as far as I know (and I asked for checking if someone else finds ones) and I think there should be a threshold so new versions are not released without good reasons. Of course, I will implement the things listed above but it would be good to have those changes in the same "merge window" so that there will be only a few different versions in use.

Please note that all this is just theoretical thinking but small things may scale to bigger things as far attitude is concerned.


EDIT: Of course this was not marked as "stable" but that is just because I am just learning this process...

[sandras]

Antti,

I find your approach interesting (in a very good way) and inspiring. Keep doing what you do. I personally hope to get some ideas from your code and, again, your approach.

Good luck with your endeavor.

[alexfru]

Comments?

It would be nice to have a description of what this is and what it does.

[Antti]

Good luck with your endeavor.

Thank you very much. I don't think my OSDev path has been very optimal so far. Perhaps I made the beginner mistake and "wrote a boot loader" without a good reason and have spent a way too much time on it. I have a somewhat feature-complete boot loader (about 32 KiB and I can guarantee that is quite a lot of assembly even with some data) that prepares the system for the next firmware-independent stages. I have to carefully think about how to release it (a binary blob or open source). A way too much attention could be paid to source code and perhaps my work of trying to ensure it could be a usable and stable product is overlooked.

Features like the next ones listed have teached quite a lot things in general:

• Having little "process-like" stages in the boot loader.
• Unicode support (partial), fonts, etc.
• VESA video modes, buffering, color formats, etc.
• Memory map sorting and handling in general. Gapless...
• Basic "boilerplate", A20 gate, etc.
• Serial ports, keyboard for interactive features.
• Long mode, protected mode, and real mode. Back and forth.
• Boot loader API for the next firmware-independent stages (that still depend on firmware but details are abstracted).
• Defensive programming. Checksums, CRC-32 etc.

It is just a "reinvention of wheel" and it is better never claim anything else. With this released MBR I paved the way so it is not so big a step to release something more. Perhaps I am not ready to take the critique for the whole work yet.

[Antti]

It would be nice to have a description of what this is and what it does.

You are right. I try to work on that and write some kind of formal description. As an informal description, I would say that it does "what a volume boot record should depend on" and this is mostly a de facto standard. This is not part of any OS.

[Antti]

I just released the next version which is (I hope so) the final version. Those who were interested in checking the first version, I recommend checking this latest revision. There are verbose comments that should explain the latest modifications.

[Antti]

This topic is still the first one on the "Announcements, Test Requests, & Job openings" list so I would like to kind of "close" this and release the version 1.0. The GitHub page contains build instructions but those are deliberately not too detailed because I want to avoid giving instructions for wiping out important data.

If there is a computer that boots correctly with some other MBR but not with this, I would really like to hear about that case. I tried my best to make this reliable.

Thank you very much.

[Octocontrabass]

If there is a computer that boots correctly with some other MBR but not with this, I would really like to hear about that case.

I could arrange that pretty easily; I still have several computers that don't support any of the INT 0x13 extensions.

[Antti]

I could arrange that pretty easily; I still have several computers that don't support any of the INT 0x13 extensions.

This request for comments has been a very good lesson. I did not predict that this particular feature would be seen as highlighted as this. Your comments on this feature are valid and I acknowledge the drawback. I underestimated the relevance it may have when opening the code for public review. The comment is not something I like but it is definitely something that I need in the long run.

I would like to emphasize that there is CHS support in the MBR and it is designed to safely cover the supported range. It should work on your test computers in almost all typical cases and if not, the behavior is fully defined and safe. The latter is a very important detail. Also, instructions are 8086-compatible which I ranked higher and the "high 2-bit support" would complicate the calculations for rare cases that were never tested in practice.

It was a design choice that may or may not be good and I'd hope that these things are put into perspective. I agree that to some extent it was a failure because it raised negative feedback.

[Antti]

This can not be left unsolved. I will implement this CHS feature with all the bits.

There is a sketch version of the CHS routine. Any suggestions or comments? I will test this thoroughly and release version 1.1.

[Octocontrabass]

I didn't see any obvious bugs, and it looks like it will get the right results for all valid C/H/S combinations.

With a bit of algebra, it's possible to come up with an algorithm that requires fewer instructions and less shuffling of data, but I suspect you're not interested in that since you're still overriding the assembler's optimizer.

[Antti]

Version 1.1

• CHS disk access code rewritten.

I'd really appreciate comments on this new release. Like a fresh start to this topic.

With a bit of algebra, it's possible to come up with an algorithm that requires fewer instructions and less shuffling of data, but I suspect you're not interested in that since you're still overriding the assembler's optimizer.

Oh no, I'm not that tough. If there is a way to significantly improve this, I'm all ears. Please note that this is more packed than before. As a small detail, the ReadChs routine is exactly 96 bytes, the old one and the new one. It does not help to reduce it one or two bytes because I'd like to have ReadLba ("naturally") aligned on a 16-byte boundary anyway (like ReadChs itself).

Please note that there are 24 bytes unused (the "BPB") and that's a huge potential.

still overriding the assembler's optimizer

Are you referring to "and cx, strict word 0x003F"? There was a discussion...