eisdt wrote:
intx13, will you post the code you wrote to dump the MBR to disk?
The code I wrote wasn't working on the laptop for some reason. Worked fine on Bochs. Possibly because of the very bug/feature we identified? It's on a PC without an internet connection though, but if I get a chance I will grab it. You could probably reproduce it really quickly.. something like this (untested):
Code:
[BITS 16]
section vstart=0x7C00 align=1
top:
jmp 0x0000:force
prepad:
times 400 db '.'
force:
xor AX, AX
mov DS, AX
mov SI, dap
mov AX, 0x4301
mov DL, 0x80
int 0x13
jmp $
dap:
db 0x10
db 0x00
dw 0x01
dd 0x00007C00
dq 0x0000000000000001
postpad:
times 446 - ($ - top) db '.'
parttable:
times 64 db 0
dw 0xAA55
buffer:
times 512 db 0
Code:
nasm -f bin <that file>
When assembled and written to disk, the first 512 bytes should be a bootable MBR containing the "dump 0x7C00 - 0x7EFF" code, and the second 512 bytes should be zeroed. After running, the second 512 bytes should be replaced with the MBR read back from RAM at runtime.
Quote:
However, shouldn't this issue be discussed on a separate topic? I marked this one as solved because the problem of printing out was indeed solved, though the sneaky one of the BIOS touching reserved memory was not and, therefore, is missing a solution I believe should be given to on a separate topic and documented accordingly. It's very weird that such a problem doesn't seem to have any material about it.
Well I think the problem of printing was
because of the bug/feature. I believe that either (1) the bug is in INT10H and since your solution avoids INT10H the bug doesn't occur or (2) the bug has to do with the BPB and happens prior to execution of the MBR, and your solution happened to be structured in a way that it wasn't noticeable affected (Brendan's suggestion).