OSDev.org

[attachment deleted by admin]

Your bootsecter is 15 bytes too long.

How would I go about deleting the extra 15 bytes from my bootsector. Where would I even start?

beyondsociety wrote: How would I go about deleting the extra 15 bytes from my bootsector. Where would I even start?

Well, to be honest, you could start by simplifying the code. Rather than having a single boot loader that works for both floppies and HDs, it might be better to have specific version for each. You know, for example, that a FAT12 disk will always have 1 cluster per sector and two heads, and uses no sector remapping, so why handle the alternative cases? Similarly, there are instances with floppies which never apply to hard drives (I hope you'll forgive me if I can't think of any off the top of my head), whihc can then be removed form the HD boot code.

Beyond that, well, there are usually a few things that can be tightened up on. Perhaps you could trim down the messages a bit, though I can understand that that isn't very desirable.

Also, AFIACT you don't actually access anything by way of either FS and GS, so you can put off initializing them until after you've loaded the second stage.

You might try explicitly setting as many of the jumps to SHORT as possible. I'm don't believe NASM automatically optimizes these, and even if it does it does no harm to make it explicit. This potentially would shave off a byte per jump where applicable.

While it is probably won't save space, I was wondering why LBACHS is called in every pass of .SECTORLOOP, rather than once at the beginning and saving the value. It looks as if there are no arguments or side effects that differ from iteration to iteration, yet you call it on each pass. You also save the values of AX, BX, and DX and restore them once each pass, as well.
What am I missing here?

Oh, one unrelated point: if you want to be able to read your FAT12 disks from Windows, the jump past the DIB has to be a JMP SHORT followed by a NOP. Windows checks for this, and won't read a bootable disk that has anything else in the first three bytes of the boot sector. If this doesn't bother you, feel free to ignore it.

Hope this helps. Any corrections of mistakes I've made would be appreciated.

beyondsociety wrote: How would I go about deleting the extra 15 bytes from my bootsector. Where would I even start?

This is sort of a "hack" and really isn't very good coding pratice... but you can do it by changing:

[tt]times 510-($-$$) db 0[/tt]

to

[tt]times 495-($-$$) db 0[/tt]

The problem should be fixed.

K.J.

I don't know about anyone else, but a quick glance at that "hack" makes me think NASM will complain about it being 30 bytes over instead of 15. I think he means to say TIMES 525-($-$$), but that right there would defeat the purpose of trying to make a 512 byte bootsector.

The best thing you can do with such an overly-complicated boot process is to initially load the next sector, or next few sectors, and use that/them as a continuation of the program.

From a practical point of view, a quick glance at your code shows the ASCII text "Executing Boot Sector", that right there isn't necessary and probably will be ignored by most people, and probably not even seen on some computers... the faster the computer, the shorter the timeframe for the displayed message. There is your 15+ bytes, and believe me, you won't miss it

Finally, from the sight of your "variable" list, most of them are extra code because they are most likely constants, and are less than one DWORD. You are better off saving the "extra" space for ASCII data instead of redundant simplistic variables.

DynatOS wrote: The best thing you can do with such an overly-complicated boot process is to initially load the next sector, or next few sectors, and use that/them as a continuation of the program.

Not an option, in this case. The goal of this design, based on the comments, is to implement FAT12. In that case, the second sector must contain the beginning of the first File Allocation Table (the same holds true for Fat16; only under FAT32 can you normally have a reserved area larger than 1 sector). For more info on the FAT12 filesystem, see the 'FIle Systems' page at the Operating Systems Resource Center.

Perhaps some comments at the start explaining the design goals and limitations are in order.

Since I am assuming that BeyondSociety has consider other options, arguing against using the FAT design is probably not helpful.

DynatOS wrote: Finally, from the sight of your "variable" list, most of them are extra code because they are most likely constants, and are less than one DWORD. You are better off saving the "extra" space for ASCII data instead of redundant simplistic variables.

If you're referring to the DIB (the DIsk Information Block, the group of variables at the start of the code, also called the BIOS Parameter Block)., there's nothing that can be done about that;. It is a required data structure for any FAT-compatible filesystem, and has to be in the specific location and order that it appears in. That 56 bytes is simply part of the price you pay for a familiar and relatively easy-to-implement filesystem. Again, a few comments marking the DIB off and explaining it for those unfmiliar with FAT12 might be called for here.

OTOH, if you mean the data that follows after the code, I thought that those were constants, too, when I first looked at it. However, a more careful reading shows that they are in fact variables. It might have been clearer if they were RESB and RESW instead, though, as all of them seem to get initialized in code before use and none have default values. Whether they have to be variables or not would require a more detailed review of the code; some of them may prove to be constant in practice, in which case they can be replaced with EQUs. I doubt it, though; BeyondSociety seems to have put quite a bit of thought into this design.

Just a simple solution before you try all the wise advices above mine: shorten your string messages ;D it's cheap and it won't trouble your code behaviour. (msgFailure, for instance, can be a good start point )

DynatOS wrote: From a practical point of view, a quick glance at your code shows the ASCII text "Executing Boot Sector", that right there isn't necessary and probably will be ignored by most people, and probably not even seen on some computers... the faster the computer, the shorter the timeframe for the displayed message. There is your 15+ bytes, and believe me, you won't miss it

I don't know about anyone else, but a quick glance at that "hack" makes me think NASM will complain about it being 30 bytes...

Err... yeah. I was thinking of a slightly different issue. I didn't realize that the code was greater than 512 bytes.

K.J.