bootloader int 0x13 loading floppy tracks

[slacker]

i am trying to load multiple tracks into memory but i am having trouble...

Code: Select all

;=============BOOT LOADER============
[bits 16]
[org 0x7c00]
jmp 0x0:main

;=============FUNCTIONS============
kbd_wait:
in al, 0x64
and al, 0x02
cmp al, 0x0
jne kbd_wait
retn

;=============VARIABLES=========
t_pos dw 0
nullsel equ 0x0
codesel equ 0000000000001000b
datasel equ 0000000000010000b

;=============GDT===============
gdtdata:
dw 24
dd gdt                  

gdt:
null:
dd 0
dd 0
code:
limc1 dw 0xffff
basec1 dw 0x0000
basec2 db 0x00
prefsc1 db 10011010b
prefsc2 db 11001111b
basec3 db 0x00
data:
limd1 dw 0xffff
based1 dw 0x0000
based2 db 0x00
prefsd1 db 10010010b
prefsd2 db 11001111b
based3 db 0x00

;=============CODE===============
main:
xor ax, ax
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

mov ax, 0x7000
mov ss, ax
mov sp, 0x0

call kbd_wait
mov al, 0xd0
out 0x64, al
call kbd_wait
in al, 0x60
or al, 0x02
mov bl, al
call kbd_wait
mov al, 0xd1
out 0x64, al
call kbd_wait
mov al, bl
out 0x60, al
call kbd_wait

readtrack0:
mov ax, 0x1000
mov es, ax
mov bx,   0x00
mov ah,   0x02
mov al,   17
mov ch,   0
mov cl,   2
mov dh,   0      
mov dl,   0
int 13h
jc readtrack0

readtrack1:
mov ax, 0x1000
mov es, ax
mov bx,   0x2220
mov ah,   0x02
mov al,   18
mov ch,   1
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack1


readtrack2:
mov ax, 0x1000
mov es, ax
mov bx,   0x4620
mov ah,   0x02
mov al,   18
mov ch,   2
mov cl,   1
mov dh,   0      
mov dl,   0
int 13h
jc readtrack2

readtrack3:
mov ax, 0x1000
mov es, ax
mov bx,   0x6a20
mov ah,   0x02
mov al,   18
mov ch,   3
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack3

readtrack4:
mov ax, 0x1000
mov es, ax
mov bx,   0x8e20
mov ah,   0x02
mov al,   18
mov ch,   4
mov cl,   1
mov dh,   0      
mov dl,   0
int 13h
jc readtrack4

readtrack5:
mov ax, 0x1000
mov es, ax
mov bx,   0xb220
mov ah,   0x02
mov al,   18
mov ch,   5
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack5

readtrack6:
mov ax, 0x1000
mov es, ax
mov bx,   0xd620
mov ah,   0x02
mov al,   18
mov ch,   6
mov cl,   1
mov dh,   0      
mov dl,   0
int 13h
jc readtrack6

readtrack7:
mov ax, 0x1000
mov es, ax
mov bx,   0xfa20
mov ah,   0x02
mov al,   18
mov ch,   7
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack7

readtrack8:
mov ax, 0x21e2
mov es, ax
mov bx,   0x0
mov ah,   0x02
mov al,   18
mov ch,   8
mov cl,   1
mov dh,   0      
mov dl,   0
int 13h
jc readtrack8

readtrack9:
mov ax, 0x21e2
mov es, ax
mov bx,   0x2400
mov ah,   0x02
mov al,   18
mov ch,   9
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack9

readtrack10:
mov ax, 0x21e2
mov es, ax
mov bx,   0x4800
mov ah,   0x02
mov al,   18
mov ch,   10
mov cl,   1
mov dh,   0      
mov dl,   0
int 13h
jc readtrack10

readtrack11:
mov ax, 0x21e2
mov es, ax
mov bx,   0x6c00
mov ah,   0x02
mov al,   18
mov ch,   11
mov cl,   1
mov dh,   1      
mov dl,   0
int 13h
jc readtrack11

cli
lgdt [gdtdata]


mov eax, cr0
or al, 1
mov cr0, eax

jmp codesel:pmode
[bits 32]
pmode:

mov eax, datasel
mov ds, eax
mov es, eax
mov fs, eax
mov gs, eax
mov ss, eax
mov esp, 0x7000

jmp 0x213de

hang:
jmp hang

;=============FORMAT============
db 'goon'
times 510-($-$$) db 0
bootsig dw 0xAA55

[Curufir]

Reset the drive on errors before trying the read operation again.

[slacker]

if i want to read the first couple tracks would i read them like this:

head 0 track 0
head 1 track 0
head 0 track 1
head 1 track 1
head 0 track 2
head 1 track 2

?

[Pype.Clicker]

yes, this is roughly how you should load them ...

[slacker]

i tihnk i got my sectors loaded into memory but i get a bochs error cs == 0 when i try to jmp to 0x213de. i have a flat mem model with codeseg base =0. when i jmp to a loc like 0x100000 where there is no code, i get running in bogus memory so my jmp can't be illegal and my gdt is set up correctly. attached is my bochsout file

[attachment deleted by admin]

[Pype.Clicker]

what about enabling the instruction trace with "trace-on" on the internal debugger shell ? it would teach you at which location the faulty instruction stands ...

hmm ... by the way, Bochs knows it already: cs=0x08, eip=7ffc3 ... Check what you have there

[slacker]

i get the error when i try to jump to 0x213de. when i jump to 0x100000 i dont get the error but i need to jumo to 0x213de....

[pini]

May you should try a far jmp, like this

Code: Select all

jmp SEGMENT:OFFSET

I don't think that you will be able to jump at that address in real mode and a near jmp instruction.

[Pype.Clicker]

@pini: he's no longer in realmode at that point !
@slacker:
are you *certain* your entry point is still at this address ? There's nothing strange you don't get the error when you jump to garbage memory, as the execution stops with the 'bogus memory' message.
By the way, when you jump at the kernel, you may encounter instructions later on that does a bad jump or a bad return ...

i truly suggest you enable the instruction trace on bochs and execute step by step from your 0x213de entry point, cross checking with your assembly source to figure out what's going wrong ...

[slacker]

ok the thing was that my code was running in bogus memory at 0x213de. i thought that this was the entry point because i download a PE viewer so i can see the address of the entry point. but this is what is weird: isn't the entry point address in the optional header the offset from the beginning of the exe? i set the base of the PE equal to 0x10000 when i linked it so i figured the entry point would be base+entry point so in this case 0x213de. i was getting an entry point vale of 0x113de. but when i was jumping to 0x213de i got the error so i tried for the hell of it to jump to 0x113de and it worked, but this is a problem since no matter what base i set the image to, the entry point stays the same. this means the entry point must be relative to the image base and not a physical address. so if this is true why does jumping to 0x113de work while 0x213de does not while loading the image file at 0x10000?

[Tim]

How are you dealing with alignment when you load the EXE?

Sections in a PE image (and many other types of image) are aligned to some multiple. The alignment on disk can be different to the alignment in memory; typically disk alignment is 512 bytes, and memory alignment is 4096 bytes (hopefully the reasons behind these numbers are obvious). So with the defaults, an offset within the file is not the same as an offset within virtual memory. The entry point is a virtual address.

An easy workaround for this is to set the file and memory alignments to the same value, probably 4096 bytes. In Cygwin ld, this is achieved using:

Code: Select all

--file-alignment <size>            Set file alignment
--section-alignment <size>         Set section alignment

[slacker]

this didnt work, the entry point address is 0x10000 larger than it should be....

[Pype.Clicker]

what if the entry point given by your PE analysis tool was *already* base + offset_in_file ? so you're loading the file and store it in [0x10000 .. 0x12345] and your entry point is at offset 0x13de within the file (you can check the symbols map), which make it appear at address 0x113de in the mapped file

make sense ?

[slacker]

i dont think it is displaying base + offset because when i set the base to 0, the entry point does not change. also when i dump the exe i can see that the entry point value is the same as in the dump as the pe viewer shows...i'm stumped.

[slacker]

i think i have found the problem. i was looking at the .text section header and i found it had a virtual address of 0x11000. i think i have to relocate the sections and the entry point address i was getting was based on relocation....is this true?