BIOS. LBA mode reading doesn't read sectors
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
|
show 6 more comments
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
1
In the disk address packet (DAP) offset is first followed by segment. Sobuf_seg: dw 0x0000
buf_off: dw 0x7E00
should bebuf_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 Theorg
directive seems correct with respect to the segment selector OP chose.
– fuz
Nov 23 at 9:19
2
@preciousbetine : Theorg 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 usedorg 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 theotg
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
|
show 6 more comments
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
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
assembly x86 boot bios osdev
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. Sobuf_seg: dw 0x0000
buf_off: dw 0x7E00
should bebuf_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 Theorg
directive seems correct with respect to the segment selector OP chose.
– fuz
Nov 23 at 9:19
2
@preciousbetine : Theorg 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 usedorg 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 theotg
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
|
show 6 more comments
1
In the disk address packet (DAP) offset is first followed by segment. Sobuf_seg: dw 0x0000
buf_off: dw 0x7E00
should bebuf_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 Theorg
directive seems correct with respect to the segment selector OP chose.
– fuz
Nov 23 at 9:19
2
@preciousbetine : Theorg 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 usedorg 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 theotg
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
|
show 6 more comments
1 Answer
1
active
oldest
votes
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
2
I have also seen some (buggy?) BIOSes that require theES
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 theES
register.
– Martin Rosenau
Nov 23 at 10:17
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
2
I have also seen some (buggy?) BIOSes that require theES
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 theES
register.
– Martin Rosenau
Nov 23 at 10:17
add a comment |
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
2
I have also seen some (buggy?) BIOSes that require theES
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 theES
register.
– Martin Rosenau
Nov 23 at 10:17
add a comment |
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
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
answered Nov 23 at 9:58
Michael Petch
25.1k556100
25.1k556100
2
I have also seen some (buggy?) BIOSes that require theES
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 theES
register.
– Martin Rosenau
Nov 23 at 10:17
add a comment |
2
I have also seen some (buggy?) BIOSes that require theES
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 theES
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1
In the disk address packet (DAP) offset is first followed by segment. So
buf_seg: dw 0x0000
buf_off: dw 0x7E00
should bebuf_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 usedorg 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