reading sectors, int 13h al = 02h error

[yolda]

Hi again for some reason i am unable to boot my kernel using int 13h al = 02h on BOCHS or sun virtual machine.
BUT i can boot from a VMplayer machine! :/ so far i know the error is in that loop, not in the reset command, but in the reading of the sectors. For some reason under some machines this interrupt isnt working, i even booted on a real machine P4, however my Core 2 Duo wont boot up either. Am i going over the current 64k limit? or is it a problem with the parameters? what about the segments, are they correct?

The kernel consists of 49 sectors:
1 sectors, 512 bytes read from file 'bootsect.bin'
48 sectors, 24596 bytes read from file 'kernel.bin'

Code: Select all

[BITS 16]       ; We need 16-bit instructions for Real mode

[ORG 0x7C00]    ; The BIOS loads the boot sector into memory location 0x7C00

	jmp 0x0000:start
start:

	 xor ax, ax
	 mov ds, ax
	 mov es, ax
	 mov ax, 0
	 mov ss, ax
	 mov sp, 0

	 mov [bootdrive], dl ; boot drive stored by BIOS in DL.
	 
	 mov di, 0FFh
reset_drive:
	
	dec di
	mov ax, di
	cmp ax, 0
	je errorMSG
	
	mov ah, 0               ; RESET-command
        int 13h                 ; Call interrupt 13h

	or ah, ah
	jnz reset_drive


        mov ax, 0
        mov es, ax

        mov bx, 0x1000          ; Destination address = 0000:1000
        mov ah, 02h             ; READ SECTOR-command
        mov al, 49           ; Number of sectors to read                             !!!!!!!!//I tried using 2-4 and a low # and still nothing
        mov ch, 0               ; Cylinder = 0
        mov cl, 02h             ; Sector = 2
        mov dh, 0             ; Head = 0
	mov dl, [bootdrive]

        int 13h                 ; Call interrupt 13h
        or ah, ah               ; Check for error code
        jnz reset_drive         ; Try again if ah != 0

ty.

[Masterkiller]

Code: Select all

mov al, 49           ; Number of sectors to read

Just after INT 13h, if CF is set, AH register contains an error code. Check your error code here: http://www.ctyme.com/intr/rb-0606.htm it'll tell you why it fails.
Some BIOSes may not support multisector or multi-track loading (or will fail if you pass the maximum number sector wtihout change to the next head/cylinder), it is highly recommended to load 1 sector at a time and keep control of the CHS to be proper at any time.

[kop99]

Code: Select all

xor ax, ax
    mov ds, ax
    mov es, ax
    mov ax, 0
    mov ss, ax
    mov sp, 0

Why do you set sp to 0?
write sp register for appreciate value(ex:0xffff), and retry...

[jal]

Code: Select all

xor ax, ax
    mov ds, ax
    mov es, ax
    mov ax, 0
    mov ss, ax
    mov sp, 0

Why do you set sp to 0?
write sp register for appreciate value(ex:0xffff), and retry...

And while we're at it, why set ax to zero at all since it's already 0 (because of the xor ax, ax), and also assign ax to sp using mov sp, ax? I think this must be an error, and it was intended to set ss to a different value?


JAL

[Masterkiller]

Code: Select all

xor ax, ax
    mov ds, ax
    mov es, ax
    mov ax, 0
    mov ss, ax
    mov sp, 0

Why do you set sp to 0?
write sp register for appreciate value(ex:0xffff), and retry...

when SP is 0, next push will be in 0x0:0xFFFE containing two byte value. It'll not fire an exception. An exception is fired when you put the SP register to 1, because it decrements to zero, write the first byte, wraps, write the second byte. If the wrap does not separate the stack value, no stack fault occurs. Actually setting up to 0 is better option than setting it up to 0xFFFF, because the stack become word-aligned (and you cannot push byte values into the stack). If too much pushing without poping reaching that stack value of 0x1 next push will cause stack fault. So it is quite better to use 0, instead of 0xFFFF.

[Troy Martin]

http://lrs.uni-passau.de/support/doc/in ... B-0041.HTM: Stack fault information