Octocontrabass wrote:
Schol-R-LEA wrote:
As an aside, would anyone here be willing to critique the
boot loader code as I have it now, even though it isn't finished?
Any particular reason you chose to use nonzero segments?
That was an error - I reversed the values of
boot_base and
boot_offset at some point, and didn't notice it until the other day when it bit me.
As for why I define them in the first place, well, it's just a matter of being thorough. I originally wrote this back in the days when it was still common advice to force the segment value through a FAR JMP at the start of the boot loader (which was due to non-compliant BIOS in the 1990s, and already unnecessary by 2000). I noticed that old bit of code, and that was when I noticed the reversed values.
Octocontrabass wrote:
Where is your stack supposed to be? I suspect it's not where you want it.
My intention was to set it to just before the boot sector entry point, with a 512 byte stack size. I've since changed it to a segment which begins after the end of the entry point's code, to allow for a full 64KiB, but again, I suppose it would be simpler just to keep SS equal to the CS - it's not as if I am likely to use a full segment's worth of stack memory, after all.
Octocontrabass wrote:
Why set GS but not FS? Do you use GS at all?
I'm not sure, to be honest. I think I'd had both cleared at one point, though if that's the case I don't know why I deleted the line for FS. In any case, I really don't have any need to clear either of them, and will remove that line.
Octocontrabass wrote:
Good catch, and silly mistake on my part.
Actually, I noticed something else about that anyway - I should have been setting BP to point to the frame of those parameters, not to the point just before it, and performing those relative addressings based off of that. It's sort of the whole point of a base pointer, after all...
Octocontrabass wrote:
Why are you worried about different sector sizes? An IBM-compatible BIOS can only boot from disks with 512-byte sectors.
Only because the BPB defines it, and I was trying to be thorough, unnecessarily I suppose.
Octocontrabass wrote:
Errors while reading the disk will modify AX, but you don't set AX again before retrying the BIOS call.
OK, I need to fix that, thank you.
Octocontrabass wrote:
The AMD Athlon Processor x86 Code Optimization Guide has a very clever Hexadecimal to ASCII conversion that could save you some space, in case you find yourself running out.
I may need it, at that, though I have since commented out the
print_hex function in any case, as the printed section didn't really help the way I'd intended it to.
Octocontrabass wrote:
Schol-R-LEA wrote:
clusters per FAT
The BPB records the size of the FAT in terms of sectors, not clusters.
OK, that was an attack of the dumbs on my part. You're correct, it is always in terms of sectors.
Octocontrabass wrote:
Schol-R-LEA wrote:
From what I've read, this is something that early versions of MS-DOS exploited, by simply requiring that IO.SYS and MSDOS.SYS (or IBMBIO.COM and IBMDOS.COM) be the first and second entries in the directory of a bootable disk, and that they had to be fixed as starting at the first data sector (Head 1, Track 0, Sector 16) - meaning that the boot loader could skip all the work of traversing the directory and just read a fixed number of sectors to get both files at once.
This is true, and it's the reason why MS-DOS required using the SYS command to make a disk bootable instead of simply copying the files. Your choice of search engine should be able to find you annotated disassemblies of various Microsoft boot sectors if you'd like to take a look.
I will take a look, though I'd rather not take that particular way out if I could avoid it.
EDIT: I know that many of the things I'm computing at runtime could be just taken as constants instead - the locations of the FATs, the directory entry, and the first data sector aren't going to change, so there's no reason not to just use those values directly. For some reason, though, I keep thinking in terms of not wanting to repeat constants, whether as magic numbers ir as values in both the EQUates and the BPB. It's sort of pointless, though; I'm not sure if DRY is a meaningful concept in assembly coding. I'm just making extra work for myself, which is one of the bad habits I need to get over.
I also have to admit that I am nervous about how readable my code is, and I've bent over backwards for clarity even where it wasn't necessary. I'm not sure if it isn't making things worse at this point.