BIOS. LBA mode reading doesn't read sectors












1














I'm working on my own bootloader and I'm using QEMU as a test lab to check/debug it. Right now I want to practice with reading of sectors using BIOS extensions. According to the docs QEMU uses SeaBIOS which should support int 13h AH=42h.
I have this code



bits    16                      ; we are in 16 bit real mode

org 0 ; we will set regisers later

start: jmp main ; jump to start of bootloader


Print:
lodsb ; load next byte from string from SI to AL
or al, al ; Does AL=0?
jz PrintDone ; Yep, null terminator found-bail out
mov ah, 0eh ; Nope-Print the character
int 10h
jmp Print ; Repeat until null terminator found
PrintDone:
ret ; we are done, so return


ReadSectors:

mov ah,0x42
mov dl,0x80
mov si,dap
int 0x13
jc .error
jmp .exit
.error:
mov si,msgFailure
call Print
cli
hlt
.exit:
ret


main:

;----------------------------------------------------
; code located at 0000:7C00, adjust segment registers
;----------------------------------------------------

cli ; disable interrupts
mov ax, 0x07C0 ; setup registers to point to our segment
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

;----------------------------------------------------
; create stack
;----------------------------------------------------

mov ax, 0x0000 ; set the stack
mov ss, ax
mov sp, 0xFFFF
sti ; restore interrupts
xor ax,ax
mov ah,0x41
xor dx,dx
mov dl,0x80
mov bx,0xAA55
int 0x13
;----------------------------------------------------
; Display loading message
;----------------------------------------------------

mov si, msgLoading
call Print
call ReadSectors
mov si,0x200
call Print
cli
hlt
dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_seg: dw 0x0000
buf_off: dw 0x7E00
lba: dd 0x0
dd 0x0

msgLoading db 0x0D, 0x0A, "Loading Boot Image ", 0x0D, 0x0A, 0x00
msgCRLF db 0x0D, 0x0A, 0x00
msgProgress db ".", 0x00
msgFailure db 0x0D, 0x0A, "ERROR : Press Any Key to Reboot", 0x0A, 0x00

TIMES 510-($-$$) DB 0
DW 0xAA55


It checks if the extensions are supported using AH=41h function and then reads 1 sector starting from LBA=0h to memory 0000:7E00.
I'm using gdb to connect to qemu machine to check register and memory. So what I see is that




  • int 13h AH=42 returns CF=0, so there is no error

  • int 13h AH=41h returns CF=0,CX=7, so it means that BIOS supports extensions.
    But then I check memory at address 7E00 and I see only zeros, but I expect to see the code of bootloader as it is stored in the LBA=0h sector.


This is how I create disk image



nasm bootloader.asm -o ./bin/bootloader.bin
dd if=/dev/zero of=./floppy/floppy.img bs=1024 count=1440
dd if=./bin/bootloader.bin of=./floppy/floppy.img conv=notrunc


And this is how I run qemu



qemu-system-x86_64 -s -S -hda ./floppy/floppy.img


Can you please help with understanding what I'm doing wrong.
Thanks!










share|improve this question




















  • 1




    In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
    – Michael Petch
    Nov 23 at 8:03








  • 1




    @preciousbetine The org directive seems correct with respect to the segment selector OP chose.
    – fuz
    Nov 23 at 9:19






  • 2




    @preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
    – Michael Petch
    Nov 23 at 9:39








  • 1




    @preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
    – Michael Petch
    Nov 23 at 9:48






  • 1




    @Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
    – Andrew Bolotov
    Nov 23 at 9:52


















1














I'm working on my own bootloader and I'm using QEMU as a test lab to check/debug it. Right now I want to practice with reading of sectors using BIOS extensions. According to the docs QEMU uses SeaBIOS which should support int 13h AH=42h.
I have this code



bits    16                      ; we are in 16 bit real mode

org 0 ; we will set regisers later

start: jmp main ; jump to start of bootloader


Print:
lodsb ; load next byte from string from SI to AL
or al, al ; Does AL=0?
jz PrintDone ; Yep, null terminator found-bail out
mov ah, 0eh ; Nope-Print the character
int 10h
jmp Print ; Repeat until null terminator found
PrintDone:
ret ; we are done, so return


ReadSectors:

mov ah,0x42
mov dl,0x80
mov si,dap
int 0x13
jc .error
jmp .exit
.error:
mov si,msgFailure
call Print
cli
hlt
.exit:
ret


main:

;----------------------------------------------------
; code located at 0000:7C00, adjust segment registers
;----------------------------------------------------

cli ; disable interrupts
mov ax, 0x07C0 ; setup registers to point to our segment
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

;----------------------------------------------------
; create stack
;----------------------------------------------------

mov ax, 0x0000 ; set the stack
mov ss, ax
mov sp, 0xFFFF
sti ; restore interrupts
xor ax,ax
mov ah,0x41
xor dx,dx
mov dl,0x80
mov bx,0xAA55
int 0x13
;----------------------------------------------------
; Display loading message
;----------------------------------------------------

mov si, msgLoading
call Print
call ReadSectors
mov si,0x200
call Print
cli
hlt
dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_seg: dw 0x0000
buf_off: dw 0x7E00
lba: dd 0x0
dd 0x0

msgLoading db 0x0D, 0x0A, "Loading Boot Image ", 0x0D, 0x0A, 0x00
msgCRLF db 0x0D, 0x0A, 0x00
msgProgress db ".", 0x00
msgFailure db 0x0D, 0x0A, "ERROR : Press Any Key to Reboot", 0x0A, 0x00

TIMES 510-($-$$) DB 0
DW 0xAA55


It checks if the extensions are supported using AH=41h function and then reads 1 sector starting from LBA=0h to memory 0000:7E00.
I'm using gdb to connect to qemu machine to check register and memory. So what I see is that




  • int 13h AH=42 returns CF=0, so there is no error

  • int 13h AH=41h returns CF=0,CX=7, so it means that BIOS supports extensions.
    But then I check memory at address 7E00 and I see only zeros, but I expect to see the code of bootloader as it is stored in the LBA=0h sector.


This is how I create disk image



nasm bootloader.asm -o ./bin/bootloader.bin
dd if=/dev/zero of=./floppy/floppy.img bs=1024 count=1440
dd if=./bin/bootloader.bin of=./floppy/floppy.img conv=notrunc


And this is how I run qemu



qemu-system-x86_64 -s -S -hda ./floppy/floppy.img


Can you please help with understanding what I'm doing wrong.
Thanks!










share|improve this question




















  • 1




    In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
    – Michael Petch
    Nov 23 at 8:03








  • 1




    @preciousbetine The org directive seems correct with respect to the segment selector OP chose.
    – fuz
    Nov 23 at 9:19






  • 2




    @preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
    – Michael Petch
    Nov 23 at 9:39








  • 1




    @preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
    – Michael Petch
    Nov 23 at 9:48






  • 1




    @Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
    – Andrew Bolotov
    Nov 23 at 9:52
















1












1








1







I'm working on my own bootloader and I'm using QEMU as a test lab to check/debug it. Right now I want to practice with reading of sectors using BIOS extensions. According to the docs QEMU uses SeaBIOS which should support int 13h AH=42h.
I have this code



bits    16                      ; we are in 16 bit real mode

org 0 ; we will set regisers later

start: jmp main ; jump to start of bootloader


Print:
lodsb ; load next byte from string from SI to AL
or al, al ; Does AL=0?
jz PrintDone ; Yep, null terminator found-bail out
mov ah, 0eh ; Nope-Print the character
int 10h
jmp Print ; Repeat until null terminator found
PrintDone:
ret ; we are done, so return


ReadSectors:

mov ah,0x42
mov dl,0x80
mov si,dap
int 0x13
jc .error
jmp .exit
.error:
mov si,msgFailure
call Print
cli
hlt
.exit:
ret


main:

;----------------------------------------------------
; code located at 0000:7C00, adjust segment registers
;----------------------------------------------------

cli ; disable interrupts
mov ax, 0x07C0 ; setup registers to point to our segment
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

;----------------------------------------------------
; create stack
;----------------------------------------------------

mov ax, 0x0000 ; set the stack
mov ss, ax
mov sp, 0xFFFF
sti ; restore interrupts
xor ax,ax
mov ah,0x41
xor dx,dx
mov dl,0x80
mov bx,0xAA55
int 0x13
;----------------------------------------------------
; Display loading message
;----------------------------------------------------

mov si, msgLoading
call Print
call ReadSectors
mov si,0x200
call Print
cli
hlt
dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_seg: dw 0x0000
buf_off: dw 0x7E00
lba: dd 0x0
dd 0x0

msgLoading db 0x0D, 0x0A, "Loading Boot Image ", 0x0D, 0x0A, 0x00
msgCRLF db 0x0D, 0x0A, 0x00
msgProgress db ".", 0x00
msgFailure db 0x0D, 0x0A, "ERROR : Press Any Key to Reboot", 0x0A, 0x00

TIMES 510-($-$$) DB 0
DW 0xAA55


It checks if the extensions are supported using AH=41h function and then reads 1 sector starting from LBA=0h to memory 0000:7E00.
I'm using gdb to connect to qemu machine to check register and memory. So what I see is that




  • int 13h AH=42 returns CF=0, so there is no error

  • int 13h AH=41h returns CF=0,CX=7, so it means that BIOS supports extensions.
    But then I check memory at address 7E00 and I see only zeros, but I expect to see the code of bootloader as it is stored in the LBA=0h sector.


This is how I create disk image



nasm bootloader.asm -o ./bin/bootloader.bin
dd if=/dev/zero of=./floppy/floppy.img bs=1024 count=1440
dd if=./bin/bootloader.bin of=./floppy/floppy.img conv=notrunc


And this is how I run qemu



qemu-system-x86_64 -s -S -hda ./floppy/floppy.img


Can you please help with understanding what I'm doing wrong.
Thanks!










share|improve this question















I'm working on my own bootloader and I'm using QEMU as a test lab to check/debug it. Right now I want to practice with reading of sectors using BIOS extensions. According to the docs QEMU uses SeaBIOS which should support int 13h AH=42h.
I have this code



bits    16                      ; we are in 16 bit real mode

org 0 ; we will set regisers later

start: jmp main ; jump to start of bootloader


Print:
lodsb ; load next byte from string from SI to AL
or al, al ; Does AL=0?
jz PrintDone ; Yep, null terminator found-bail out
mov ah, 0eh ; Nope-Print the character
int 10h
jmp Print ; Repeat until null terminator found
PrintDone:
ret ; we are done, so return


ReadSectors:

mov ah,0x42
mov dl,0x80
mov si,dap
int 0x13
jc .error
jmp .exit
.error:
mov si,msgFailure
call Print
cli
hlt
.exit:
ret


main:

;----------------------------------------------------
; code located at 0000:7C00, adjust segment registers
;----------------------------------------------------

cli ; disable interrupts
mov ax, 0x07C0 ; setup registers to point to our segment
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

;----------------------------------------------------
; create stack
;----------------------------------------------------

mov ax, 0x0000 ; set the stack
mov ss, ax
mov sp, 0xFFFF
sti ; restore interrupts
xor ax,ax
mov ah,0x41
xor dx,dx
mov dl,0x80
mov bx,0xAA55
int 0x13
;----------------------------------------------------
; Display loading message
;----------------------------------------------------

mov si, msgLoading
call Print
call ReadSectors
mov si,0x200
call Print
cli
hlt
dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_seg: dw 0x0000
buf_off: dw 0x7E00
lba: dd 0x0
dd 0x0

msgLoading db 0x0D, 0x0A, "Loading Boot Image ", 0x0D, 0x0A, 0x00
msgCRLF db 0x0D, 0x0A, 0x00
msgProgress db ".", 0x00
msgFailure db 0x0D, 0x0A, "ERROR : Press Any Key to Reboot", 0x0A, 0x00

TIMES 510-($-$$) DB 0
DW 0xAA55


It checks if the extensions are supported using AH=41h function and then reads 1 sector starting from LBA=0h to memory 0000:7E00.
I'm using gdb to connect to qemu machine to check register and memory. So what I see is that




  • int 13h AH=42 returns CF=0, so there is no error

  • int 13h AH=41h returns CF=0,CX=7, so it means that BIOS supports extensions.
    But then I check memory at address 7E00 and I see only zeros, but I expect to see the code of bootloader as it is stored in the LBA=0h sector.


This is how I create disk image



nasm bootloader.asm -o ./bin/bootloader.bin
dd if=/dev/zero of=./floppy/floppy.img bs=1024 count=1440
dd if=./bin/bootloader.bin of=./floppy/floppy.img conv=notrunc


And this is how I run qemu



qemu-system-x86_64 -s -S -hda ./floppy/floppy.img


Can you please help with understanding what I'm doing wrong.
Thanks!







assembly x86 boot bios osdev






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 at 8:13









Michael Petch

25.1k556100




25.1k556100










asked Nov 23 at 0:27









Andrew Bolotov

324




324








  • 1




    In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
    – Michael Petch
    Nov 23 at 8:03








  • 1




    @preciousbetine The org directive seems correct with respect to the segment selector OP chose.
    – fuz
    Nov 23 at 9:19






  • 2




    @preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
    – Michael Petch
    Nov 23 at 9:39








  • 1




    @preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
    – Michael Petch
    Nov 23 at 9:48






  • 1




    @Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
    – Andrew Bolotov
    Nov 23 at 9:52
















  • 1




    In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
    – Michael Petch
    Nov 23 at 8:03








  • 1




    @preciousbetine The org directive seems correct with respect to the segment selector OP chose.
    – fuz
    Nov 23 at 9:19






  • 2




    @preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
    – Michael Petch
    Nov 23 at 9:39








  • 1




    @preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
    – Michael Petch
    Nov 23 at 9:48






  • 1




    @Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
    – Andrew Bolotov
    Nov 23 at 9:52










1




1




In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
– Michael Petch
Nov 23 at 8:03






In the disk address packet (DAP) offset is first followed by segment. So buf_seg: dw 0x0000 buf_off: dw 0x7E00 should be buf_off: dw 0x7E00 buf_seg: dw 0x0000 . The reason for this is because x86 is a little endian processor so segment:offset is stored as offset first and segment second.
– Michael Petch
Nov 23 at 8:03






1




1




@preciousbetine The org directive seems correct with respect to the segment selector OP chose.
– fuz
Nov 23 at 9:19




@preciousbetine The org directive seems correct with respect to the segment selector OP chose.
– fuz
Nov 23 at 9:19




2




2




@preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
– Michael Petch
Nov 23 at 9:39






@preciousbetine : The org 0 where he has it is correct, and he is also correct to load the segment registers with 0x07c0. That is because a segment:offset pair of 0x07c0:0x0000 is physical address 0x07c0<<4+0x000=0x07c00. Altrnatively he could have used org 0x7c00 and set the segments to 0x0000 since 0x0000<<4+0x7c00 also equals = 0x07c00. Both represent the same physical memory address.
– Michael Petch
Nov 23 at 9:39






1




1




@preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
– Michael Petch
Nov 23 at 9:48




@preciousbetine : with NASM (with the BIN format) the placement of the otg doesn't matter. No matter where you place it, it acts as if was at the very beginning.
– Michael Petch
Nov 23 at 9:48




1




1




@Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
– Andrew Bolotov
Nov 23 at 9:52






@Michael Petch Thanks a lot! It helped. And also now I store DL in memory and then I use it in all int 13h functions. And thanks for recommendation how to set up SP.
– Andrew Bolotov
Nov 23 at 9:52














1 Answer
1






active

oldest

votes


















3














In the Disk Access Packet (DAP) the segment:offset pair is stored with offset first followed by segment. This is because the x86 is a little endian processor and the pair is stored in reverse order. Your DAP should be changed to:



dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_off: dw 0x7E00 ; Place offset before segment
buf_seg: dw 0x0000
lba: dd 0x0
dd 0x0





share|improve this answer

















  • 2




    I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
    – Martin Rosenau
    Nov 23 at 10:17













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53439378%2fbios-lba-mode-reading-doesnt-read-sectors%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














In the Disk Access Packet (DAP) the segment:offset pair is stored with offset first followed by segment. This is because the x86 is a little endian processor and the pair is stored in reverse order. Your DAP should be changed to:



dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_off: dw 0x7E00 ; Place offset before segment
buf_seg: dw 0x0000
lba: dd 0x0
dd 0x0





share|improve this answer

















  • 2




    I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
    – Martin Rosenau
    Nov 23 at 10:17


















3














In the Disk Access Packet (DAP) the segment:offset pair is stored with offset first followed by segment. This is because the x86 is a little endian processor and the pair is stored in reverse order. Your DAP should be changed to:



dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_off: dw 0x7E00 ; Place offset before segment
buf_seg: dw 0x0000
lba: dd 0x0
dd 0x0





share|improve this answer

















  • 2




    I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
    – Martin Rosenau
    Nov 23 at 10:17
















3












3








3






In the Disk Access Packet (DAP) the segment:offset pair is stored with offset first followed by segment. This is because the x86 is a little endian processor and the pair is stored in reverse order. Your DAP should be changed to:



dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_off: dw 0x7E00 ; Place offset before segment
buf_seg: dw 0x0000
lba: dd 0x0
dd 0x0





share|improve this answer












In the Disk Access Packet (DAP) the segment:offset pair is stored with offset first followed by segment. This is because the x86 is a little endian processor and the pair is stored in reverse order. Your DAP should be changed to:



dap:
packetSize: db 0x10
reserved: db 0x0
sectorsNumber: dw 0x1
buf_off: dw 0x7E00 ; Place offset before segment
buf_seg: dw 0x0000
lba: dd 0x0
dd 0x0






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 23 at 9:58









Michael Petch

25.1k556100




25.1k556100








  • 2




    I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
    – Martin Rosenau
    Nov 23 at 10:17
















  • 2




    I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
    – Martin Rosenau
    Nov 23 at 10:17










2




2




I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
– Martin Rosenau
Nov 23 at 10:17






I have also seen some (buggy?) BIOSes that require the ES register to contain the segment value which is stored in the DAP. These BIOSes ignore the segment value in the DAP and take it from the ES register.
– Martin Rosenau
Nov 23 at 10:17




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53439378%2fbios-lba-mode-reading-doesnt-read-sectors%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

What visual should I use to simply compare current year value vs last year in Power BI desktop

How to ignore python UserWarning in pytest?

Alexandru Averescu