Combuster is right - the only thing the should matter is the size (or intended/future size) of the kernel itself, and the size of the FAT file system or disk shouldn't matter (unless the disk is larger than the original BIOS functions can handle, in which case you'd only need to start using the Int 13 Extensions). I'm guessing that if everything works with a 10 MiB disk, but it doesn't work with a 100 MiB disk when everything else is exactly the same, then you've got a bug somewhere or an incompatibility somewhere. For example, maybe your code only supports FAT12 and whatever you use to format the disk uses FAT16 or FAT32 for 100 MiB disks. Note: AFAIK the maximum partition size supported by FAT12 is about 32 MiB.Revelation wrote:While testing my bootloader, I stumbled upon an ugly problem. If the disk I use is 10 mb, the loader works, but if I make it 100 mb it fails, because the FAT is more than 1 mb and I am in real mode. Am I forced to go to protected mode before loading the kernel? If I am in protected mode, I can't read the FAT nor the kernel because I can't use my BIOS function calls anymore.
If you want to load your kernel above 1 MiB, then you can load some sectors in real mode, switch to protected mode, copy the sectors above 1 MiB then switch back to real mode (or maybe just use unreal mode). Virtual 80x86 mode is another (more complex) option. Building device drivers for every possible storage device into your boot loader is the worst option - don't do that (it'd be funny if you needed to load your boot loader above 1 MiB because there wasn't enough space below 1 MiB for all the device drivers it might need to load the kernelRevelation wrote:I don't really know what to do now. If I should go for protected mode, I must first detect which drive I must read from (from the DL register, but I don know how to translate that to a drive in pmode) and what kind of device it is (floppy, hdd, USB) (no idea how to do that either).
).
Code: Select all
XOR AX,AX
MOV DS,AX
MOV ES,AX
MOV ECX,Number of bytes to copy
MOV ESI, Base Address Source ; Physical Address
MOV EDI, Base Address Destination ; Physical Address
CLD
DB 67H
REP MOVSB 
Instead it works fine in all pc that i tested ,Love4Boobies wrote:I'm too lazy to see what DB 67H means right now but that won't work. In both real (even when enabling gate A20) and unreal mode, MOVS will only work with 16-bit registers. Also, you've cleared the segment registers so all you're doing is copying some code from segment 0000 to the same segment.
I guarantee that if ESI or EDI is greater than 0xFFFF you'll get a general protection fault in real mode; unless some code that ran before your code changed the segments limits (which would mean you'd be in unreal mode without knowing it), which isn't impossible - it wouldn't be the first time someone wrote buggy code to switch from protected mode to real mode...djmauretto wrote:Instead it works fine in all pc that i tested ,Love4Boobies wrote:I'm too lazy to see what DB 67H means right now but that won't work. In both real (even when enabling gate A20) and unreal mode, MOVS will only work with 16-bit registers. Also, you've cleared the segment registers so all you're doing is copying some code from segment 0000 to the same segment.
try and let me know.
Db 67h is Address-size override prefix.
My code work in all pc that i tried ,your code don't know i'm sorryThe bios doesn't leave you in unreal mode
