OSDev.org

Bonfra wrote:How can I check if that memory is available? is there some interrupt for it?

Try INT 0x12.

Bonfra wrote:AX is the number of sectors to read and for some reason, I was loading both the tables in memory so instead, the value should've been 0x40. In fact, with the right calculation (without multiplying by two) it boots up in VMWare.

The FAT can be bigger than 0x7F sectors, but some BIOSes can't read more than 0x7F sectors at once.

Bonfra wrote:Ok, I've finally tested the OS in the real hardware, and... it doesn't work
the VBR seems to work in fact the second stage bootloader prints a string but then nothing, maybe the VBR does not load correctly all the file: the instruction right after the print is a call to a function very deep in the code...
I don't know I need to do some more testing... If you notice something weird in this code let me know but I'm pretty sure about that, maybe is the fact that I assume that the memory that could be used by the EBDA is free, I may need to move around some bits

You should implement exception vectors that allow you to insert int 3 into the code and dump register state & halt. You should also print register state on faults. It's not so hard to do and definitely should be used in the second stage boot loader and forward. Since I never had the luxury of emulators with this built-in, I learned this the hard way on real hardware.

rdos wrote: You should implement exception vectors that allow you to insert int 3 into the code and dump register state & halt. You should also print register state on faults. It's not so hard to do and definitely should be used in the second stage boot loader and forward. Since I never had the luxury of emulators with this built-in, I learned this the hard way on real hardware.

Yes, I yet have this dump in the kernel and I'm planning to add it also to the second stage but the problem here is in the first stage not loading correctly the second stage.
I've also tried to move the address where I save the FS things to a lower address but still nothing

Some updates: I've managed to boot the image using BOCHS (but can't figure out how to build it with the debugger so I'm single-stepping with `jmp $`).
It stops to a different part of the code but still, I'm pretty sure it has to do with the VBR not loading correctly the second stage so it must be something in the FAT16 driver I wrote (or the read disk function but it works for the VBR...). Do you spot something weird or some wrong assumptions I took in this code?

Bonfra wrote:Some updates: I've managed to boot the image using BOCHS (but can't figure out how to build it with the debugger so I'm single-stepping with `jmp $`).

I wish the release would include a binary for gdb debugging in addition to the one for the built-in debugger, or restructure their code so you can pick one or the other at runtime. But I'm not sure it would help here. Unless I'm doing something wrong, gdb is completely useless until I've entered the kernel.

I don't see anything obviously wrong at a cursory glance. The only thing I can suggest is to not assume that a BIOS call isn't trashing registers and throwing off a looped read. Maybe set a Bochs magic breakpoint (or regular breakpoint) after a call to ReadSectorsLBA and make sure everything is still what it should be.

sj95126 wrote: The only thing I can suggest is to not assume that a BIOS call isn't trashing registers and throwing off a looped read. Maybe set a Bochs magic breakpoint (or regular breakpoint) after a call to ReadSectorsLBA and make sure everything is still what it should be.

It stays the same and nothing is touched but just to be sure and avoid future problems I've added pusha at the beginning end popa at the end of ReadSectorsLBA.