USB Boot Problem

[Masterkiller]

I know this question is discussed, but I was unable finding answer to that question in the other posts. I am trying to make loader on my USB Flash. The boot sector uses int13h/AH=42h to load next stage of the loader. Since to USB Flash and Floppy drive has 512 byte sector and both use first sector to boot (only CD use 17-th) I tested the loader on emulated floppy drive (.flv file) on Bochs and MS Virtual PC and it works fine, but on real hardware it just stops. As I tested it seems that DL does not contain proper BIOS drive number. On the boot process of USB it contains (in hex):

Code: Select all

AX = 0000
CX = 0001
DX = 0000
BX = 7C00
SP = 03F6
BP = 1000
SI = 0003
DI = 0000

Is there another way to get booting device BIOS drive number and if yes - how? Or... ...Am I using the proper way (int13h/AH=42h - Extended Read) to load stage 2 from USB device?

[Combuster]

DL = 0 (first floppy drive)?
Emulated floppy drive?

Looks correct to me

[bewing]

You can't use the AH=42h command with a floppy drive (at least on real hardware). Not legal. Must use the CHS versions.

[Masterkiller]

DL = 0 (first floppy drive)?
Emulated floppy drive?

Looks correct to me

Yes, the value zero is correct.

You can't use the AH=42h command with a floppy drive (at least on real hardware). Not legal. Must use the CHS versions.

No, it seems that BIOS set the USB flash drive to 0, but not emulating floppy. Flash drive is not based on CHS system. I have tried but AH=02h/INT13h hang the boot process and interrupt never returns. AH=42h/INT13h works and on return carry flag is clear. Floppy drive does not activate, so drive number 0 is not floppy, so it is USB Flash drive, but system hangs when it tries to jump to loaded code, probably I'm not jumping to valid address. It should be 1000h:0000h but maybe I am wrong.

10x for help!

[AJ]

Hi,

Even if that works on an emulator, you should not rely on undefined behaviour. Int 0x13 extensions are only designed to work when bit 7 of the drive byte is set. If your OS relies on something else, what happens when it meets a standards-compliant PC which does not support int 0x13 extensions?

The best way here is to write two functions; AH=0x02 and extension method. You can then detect which is available and use the most appropriate method.

Cheers,
Adam

[Masterkiller]

Hi,

Even if that works on an emulator, you should not rely on undefined behaviour. Int 0x13 extensions are only designed to work when bit 7 of the drive byte is set. If your OS relies on something else, what happens when it meets a standards-compliant PC which does not support int 0x13 extensions?

The best way here is to write two functions; AH=0x02 and extension method. You can then detect which is available and use the most appropriate method.

Cheers,
Adam

The kernel itself is independent. It rely that it will be loaded in specified location in memory. The kernel also rely that there is at least 5-6 MB writable device. In the emulator I emulated it as HDD. I need to test it on real hardware in a read/write device so I chose my USB flash drive. I only need the loader. Kernel is stand-alone program.