Trouble with INT 13, AH=42, copying sectors from CDROM

[Twicetimes]

I'm writing a boot loader, attempting to load the next few sectors from the boot CD. I've got a handful of things working (printing to screen via bios, etc).

So far, I have:

• Built my .iso in non-emulation mode, and assuming 2048-byte sectors
• Checked the drive id left in DL by the bios, and it's 0xE0 (indicating the CDROM drive, according to various references)
• Set cs/ds/es/ss to 0x7c0 (using org 0)
• Checked that int 13 extensions are available using int 13, AH=0x41 (They are. The feature mask is 7, indicating full support)
• Set up a disk access packet structure and populated it with the values for the int 13, AH=0x42 call
• Checked that the carry is not set (it's not), and that the return code in AH is 0 (it is)

So in theory, it looks like the read sector call worked, but I'm checking the outcome by reading the first byte of the destination address I specified in the DAP, and it's zero (not what I expected).

I've tried specifying a couple of different sector numbers to copy, which have non-zero values in the first byte, so that I can easily spot them, but no luck.

I'm trying to use 0x500 as the destination address for the sector read, as that's where I'm going to continue the loader.
I've also tried specifying the destination address as 0x00500000 (50:0000 in segment form should equal 0x500, correct?)

Here are the relevant bits of code:

Code: Select all

    mov ax, 0x4200
    mov dl, [driveid]
    mov byte  [dap.size], 0x10
    mov byte  [dap.unused], 0
    mov word  [dap.nsectors], 1 ; 1 sector should be 2048 bytes
    mov dword [dap.dst], 0x00000500
    mov dword [dap.start_sector], 16   ; Sector 16 (the boot sector, just for testing purposes, starting at 0x8000 on the .iso)
    mov si, dap
    int 0x13

    ; carry / AX indicate no errors

    cmp word [0x500], 0x0143 ; these happen to be the first 2 bytes from 0x8000 on the .iso
    ; ...but the word at 0x500 isn't 0x0143, it's 0.

; ...

dap:
    .size         resb 1
    .unused       resb 1
    .nsectors     resw 1
    .dst          resd 1
    .start_sector resq 1

Is there anything glaringly wrong here? Any advice would be much appreciated. If I've left out any crucial information, please let me know.

[Octocontrabass]

Is there anything glaringly wrong here?

In your "cmp word [0x500], 0x0143" instruction, the memory address [0x500] is relative to the DS segment, which you've said earlier is set to 0x7C0, meaning this instruction is accessing linear address 0x8100.

I recommend setting all of the segment registers to 0 instead of 0x7c0. (You'll also need to change your org statement.)

[Twicetimes]

Ahhh, ok thanks. My understanding of when DS is used was wrong (I thought it was only in relation to certain registers).

My reasoning for using org 0 and a segment of 07c0 was that with org 7c00 and segment 0, I couldn't see how to set a new 'org' setting when I jumped to a lower address for stage 2 of the bootloader. Nasm doesn't let you set org twice, which means at the least I'd have to build stage 2 as a separate binary presumably? Without the ability to say 'org 0x500' after having jumped to 0x500, surely Nasm would adjust all my label addresses to be relative to 7c00?

[Octocontrabass]

Ahhh, ok thanks. My understanding of when DS is used was wrong (I thought it was only in relation to certain registers).

All memory operands are relative to a segment register. If you set them to 0, then you can pretend segment registers don't exist.

Nasm doesn't let you set org twice, which means at the least I'd have to build stage 2 as a separate binary presumably?

This sounds like a perfect use case for sections. For example...

Code: Select all

section stage1 start=0 vstart=0x7c00
// stage 1 code here
section stage2 start=0x800 vstart=0x500
// stage 2 code here

Here, the vstart parameter is used to define the starting address of each section, instead of an org statement. You can read more about it in the NASM manual or the YASM manual.

[Twicetimes]

That looks ideal. I wasn't aware of that syntax. I've had a vague (probably unsubstantiated) notion that sections (in the linker sense) didn't apply when making a flat binary. Is this something different altogether?

[Octocontrabass]

They're the same thing. A flat binary has no concept of sections, but the tools you use to make the flat binary don't have that limitation.

It's not uncommon to assemble code into an object file, then link that object file into a flat binary. NASM is just letting you take a shortcut in that process.

[Twicetimes]

All working now. Thanks for all your help.