Trouble with int 13h extended commands

[cnlohr]

I am trying to use int 13h, command 42h to simplify reading my data from disk, and it works perfectly in qemu, however, in bochs and virutalbox, I have problems.

I'm not sure what's going on with virtualbox but with bochs, I have a hint.

I started out by trying to call int 13h, cmd 0x42 to read from the disk, but that kept returning AH = 1, CF!

I eventually fell back to just trying to call command 0x41. Here's the output in bochs:

Code: Select all

(0) [0x000000007c1b] 0000:7c1b (unk. ctxt): int 0x13                  ; cd13
<bochs:4> r
CPU0:
rax: 0x00000000_00004100 rcx: 0x00000000_00090000
rdx: 0x00000000_00000080 rbx: 0x00000000_000055aa
rsp: 0x00000000_00000c00 rbp: 0x00000000_00000000
rsi: 0x00000000_000e0000 rdi: 0x00000000_0000ffac
r8 : 0x00000000_00000000 r9 : 0x00000000_00000000
r10: 0x00000000_00000000 r11: 0x00000000_00000000
r12: 0x00000000_00000000 r13: 0x00000000_00000000
r14: 0x00000000_00000000 r15: 0x00000000_00000000
rip: 0x00000000_00007c1b
eflags 0x00000046: id vip vif ac vm rf nt IOPL=0 of df if tf sf ZF af PF cf
<bochs:5> c
(0) Breakpoint 2, 0x0000000000007c1d in ?? ()
Next at t=14043993
(0) [0x000000007c1d] 0000:7c1d (unk. ctxt): jmp far 0000:7c22         ; ea227c0000
<bochs:6> r
CPU0:
rax: 0x00000000_00000100 rcx: 0x00000000_00090000
rdx: 0x00000000_00000080 rbx: 0x00000000_000055aa
rsp: 0x00000000_00000c00 rbp: 0x00000000_00000000
rsi: 0x00000000_000e0000 rdi: 0x00000000_0000ffac
r8 : 0x00000000_00000000 r9 : 0x00000000_00000000
r10: 0x00000000_00000000 r11: 0x00000000_00000000
r12: 0x00000000_00000000 r13: 0x00000000_00000000
r14: 0x00000000_00000000 r15: 0x00000000_00000000
rip: 0x00000000_00007c1d
eflags 0x00000047: id vip vif ac vm rf nt IOPL=0 of df if tf sf ZF af PF CF

Here's my code:

Code: Select all

	//Configure the stack
	mov $0xc00, %sp

	//Configure the segments
	xor %ax, %ax
	mov %ax, %ds
	mov %ax, %es
	mov %ax, %fs
	mov %ax, %gs
	mov %ax, %ss

	//First, preserve drive letter.
	mov %dl, DiskDrive

	mov $0x4100, %ax
	mov $0x00, %dl //Same response with 0x80, or the original dl (which is 0)
	mov $0x55AA, %bx
	int $0x13

Why would it fail?

If anyone is curious, here was the output for my CMD 0x42.

Here was the output:

Code: Select all

(0) [0x000000007d32] 0000:7d32 (unk. ctxt): int 0x13                  ; cd13
<bochs:5> r
CPU0:
rax: 0x00000000_60004200 rcx: 0x00000000_00090000
rdx: 0x00000000_00000000 rbx: 0x00000000_00000000
rsp: 0x00000000_00000bc6 rbp: 0x00000000_00000000
rsi: 0x00000000_000e7d78 rdi: 0x00000000_00000000
r8 : 0x00000000_00000000 r9 : 0x00000000_00000000
r10: 0x00000000_00000000 r11: 0x00000000_00000000
r12: 0x00000000_00000000 r13: 0x00000000_00000000
r14: 0x00000000_00000000 r15: 0x00000000_00000000
rip: 0x00000000_00007d32
eflags 0x00000202: id vip vif ac vm rf nt IOPL=0 of df IF tf sf zf af pf cf
<bochs:6> c
(0) Breakpoint 3, 0x0000000000007d34 in ?? ()
Next at t=14044821
(0) [0x000000007d34] 0000:7d34 (unk. ctxt): add dl, bh                ; 00fa
<bochs:7> r
CPU0:
rax: 0x00000000_60000100 rcx: 0x00000000_00090000
rdx: 0x00000000_00000000 rbx: 0x00000000_00000000
rsp: 0x00000000_00000bc6 rbp: 0x00000000_00000000
rsi: 0x00000000_000e7d78 rdi: 0x00000000_00000000
r8 : 0x00000000_00000000 r9 : 0x00000000_00000000
r10: 0x00000000_00000000 r11: 0x00000000_00000000
r12: 0x00000000_00000000 r13: 0x00000000_00000000
r14: 0x00000000_00000000 r15: 0x00000000_00000000
rip: 0x00000000_00007d34

My dap looks like the following:

Code: Select all

10 00 01 00  00 7e 00 00 00 00 00 00 00 00 00 00

Any ideas?

[Combuster]

//Same response with 0x80, or the original dl (which is 0)

DL=0 means floppy drive - which is apparently what you are booting from. The disk extensions don't work on floppies by default, and they probably don't work on harddisks (DL=0x80) because you don't have one configured.

[cnlohr]

Excellent. In hardware, I will be booting from an ATMega32u2, so I can make it look like whatever I feel like. Hard disk, here I come!

Question: Would they work on bootable USB hard drives?

[DavidCooper]

Question: Would they work on bootable USB hard drives?

On most machines, yes, and you can use USB flash drives too in the same way, making them look and behave like hard drives. They won't work on many ancient machines though, and they won't work on a few of the newest ones either (tablet machines like Microsoft's Surface) where the BIOS has been dropped. Whatever you're building, keep in mind that the BIOS will disappear from all future machines at some point, so make sure you have a plan in place to redesign the way you boot your OS when that time comes.

[Bender]

Whatever you're building, keep in mind that the BIOS will disappear from all future machines at some point

As a side note:
Not only the BIOS but all the legacy stuff, like floppy/HDD emulation, VGA (?), VESA/VBE etc. will soon be replaced by the newer standards; This BIOS Legacy Booting IMO would be discontinued once the manufacturers realise that no one needs it, I may be wrong.

[cnlohr]

For my projects, they don't need to be supported indefinitely. I just need to find environments in which they do operate. Apparently, my laptop does support this on a USB drive. This project is unlikely to last more than a month.

It appears that CD ROMs do not support the extended BIOS command either. Perhaps I should switch back to CMD 02h for compatibility purposes. Is there any really quick and easy way of saying "please take the first big chunk from the disk, and dump it into RAM at 0x1000000? It looked like int 13, cmd 42 was that!

Bender, You make a good point, that has me worried. How will I be able to boot off of 32kB of flash if I have to include device drivers

[neon]

Hello,

We can assert that the extended BIOS int 13h read functions do indeed work with CD drives and would also recommend its use. The extended BIOS services are particularly important for large capacity disks; some of which may not utilize the CHS addressing scheme.

Additionally, considering the project is not to last more then a few months, we recommend not concerning with legacy hardware and firmware API's becoming obsolete; they will eventually, but that is something long term projects need to address and not short term projects. Long term projects would have a more sophisticated boot environment that abstracts the firmware and hardware through a common independent API of its own.

If you plan to support CD's, hard disks, and USB drives, we recommend sticking with the extended BIOS services. Note that the disk number utilized by the BIOS is not necessarily standard; although 0 denotes the floppy and 0x80 denotes hard disk 0, the firmware is free to utilize any value in DL to refer to a particular disk. In other words, always use the DL provided by the firmware (or other VBR if chain loaded) rather then assuming that the VBR booted from a particular disk.

Why not just configure the USB device as a bootable hard disk and utilize the extended BIOS services to read from it if your laptop supports it?