Bochs: int13_diskette: ctrl not ready

Erukaron · **Posted:** Sat Oct 17, 2020 5:20 pm

Hello everybody,

i have an issue with bochs reading my floppy drive. After reading a few sectors (1 - 10) bochs exits with the following error: [BIOS ] int13_diskette: ctrl not ready.

The error occurs while executing interrupt 13h, but the parameters given to the interrupt seem to be fine:
AX: 0x0201
BX: 0x0900
CX: 0x0004
DX: 0x0100
ES: 0x0000

Here is the floppy disk reading part:

Code:

; input: 
;   dl -> device
;   es:bx -> Buffer to read to
;   ax -> Start sector
;   cx -> Number of sectors
;
; output:
;   carry -> On error

fat_read_device:
    mov di, FAT_READ_RETRIES ; retries for error -> 5

    .try_load:
        push ax
        push bx
        push cx

        push bx
        mov bl, dl ; remember device
        mov dx, ax

        int 0xe2 ; Convert lba to chs -> Writing to cl, ch and dh

        mov dl, bl
        pop bx

        mov ah, 0x02 ; Read device es:bx
        mov al, 0x01 ; Number of sectors to read
        ;xchg bx, bx
        int 0x13
        jnc .done ; test if succeeded

        xor ax, ax ; Reset disk
        int 0x13
        dec di ; decrement error counter
        pop cx
        pop bx
        pop ax
        jnz .try_load ; attempt to read again

        stc
        ret

    .done:
        int 0xcf ; Feedback disk operation -> Print a '.'

        pop cx
        pop bx
        pop ax
        add bx, word [bpbBytesPerSector] ; next sector
        inc ax ; read next sector
        loop fat_read_device ; repeat until cx sectors are read
        ret

I do only get this error with bochs in debug mode. If i start the system in non debug mode, it works fine.

Has anyone had the same issue or does anyone have an idea what i am doing wrong?

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 693

I haven't looked at the code but how big is your disk image? As well did you set the stack (SS:SP) somewhere out of the way where you know it won't be overwritten by the sectors you read?

Erukaron · **Posted:** Sat Oct 17, 2020 5:31 pm

It's 1,4MB big.

Erukaron · **Posted:** Sat Oct 17, 2020 5:36 pm

Erukaron wrote:

It's 1,4MB big.

But only bytes 0x0 - 0x9d00 contain code or files, the rest of the image file is filled with zeros.

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5143

Memory corruption is my first guess, but it could also be that you're poking some hardware you shouldn't.

I don't see anything wrong in the code you've posted.

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 693

Memory corruption is my guess as well. Was why I asked about SS:SP. Strange errors like this can often occur because the stack is being clobbered by the read or you read the sector on top of the code that is being used. The values of the registers didn't suggest they were reading across a DMA boundary or anything like that either.

I wonder if they can show us the state of *all* the registers (including all the segment registers) before the call to the int 13h that fails.

Erukaron · **Posted:** Sat Oct 17, 2020 6:03 pm

The hardware i write to is the PIT:

Code:

timer_init:
    cli 

    mov al, 36h ; PIT channel 0
    out 43h, al ; select channel

    mov ax, TIMER_DIVISOR
    out 40h, al ;send low byte
    mov al, ah
    out 40h, al ;send high byte

    sti

    mov word [cs:timer_tick_count], 0

    ret

resetting the display cursor

Code:

    ; Set low byte
    mov al, 0x0f
    mov dx, 0x03d4
    out dx, al

    mov al, bl 
    mov dx, 0x03d5
    out dx, al

    ; Set high byte
    mov al, 0x0e
    mov dx, 0x03d4
    out dx, al

    mov al, bh
    mov dx, 0x03d5
    out dx, al

and the end of interrupt procedure

Quote:

kernel_acknowledge_hardware_interrupt:
mov al, 0x20 ; send end of interrupt (eoi)
out 0x20, al ; send eoi to master pic
out 0xa0, al ; send eoi to slave pic

ret

Here is a screenshot of the registers and the current stack content just before executing the int 13h that fails.
https://www.dropbox.com/s/dm5h1ebn9mt8myt/error.PNG?dl=0

All values in hex:
ax: 0201
bx: 0900
cx: 0004
dx: 0100
si: 55f1
di: 0008
bp: 3735
sp: ffc6
ip: 581d
flags: 2
cs: 0000
ds: 0000
es: 0000
ss: 1000

Erukaron · **Posted:** Sat Oct 17, 2020 6:08 pm

MichaelPetch wrote:

or you read the sector on top of the code that is being used.

The read fails upon reading the root directory, but i left space for it in front of the kernel, so no code should be overwritten.
First code starts at 3300h.

0x000000 - 0x0004ff : Interrupt vector table and bios data (1,25 KB)
0x000500 - 0x0020ff : Root Dir (7 KB)
0x002100 - 0x002eff : FAT (4,5 KB)

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 693

I just noticed you are doing some other weird stuff like added `int 0xe2`. If you have done that then you have amended the interrupt with new interrupts.You are also fiddlin with the PIT timer 0. If I were you I'd try to minimize the problem space by eliminating all the strange changes. Maybe you corrupted something in the Interrupt Vector table as well. Maybe you have latched onto other interrupts and it is causing disk read problems. I think the only way of helping is if you put your entire project somewhere (like Github) so we can build it and test it.

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 693

Have you tried loading starting loading at 0x600 rather than 0x500? I don't know if BOCHs uses the area between 0x500 to 0x520 for anything (some real BIOSes do).

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5143

Erukaron wrote:

The hardware i write to is the PIT:

INT 0x13 depends on the PIT. Reset the PIT to its power-on configuration before calling INT 0x13, or do not write to the PIT at all.

Erukaron · **Posted:** Sat Oct 17, 2020 6:56 pm

Thank you for your help and your ideas so far.
I'll try again without altering the PIT and calling the code inside interrupt 0xe2 via "call" instead of "int". Interrupt 0xe2 is used as software interrupt and converts the logical block address into cylinder/head/sector format.
Yes, i altered the ivt, redirected the timer interrupt and installed a few interrupts from 0x80 to 0xff but apart from the timer interrupt all interrupts from 0x00 to 0x7f are untouched.
I'll also relocate the start of the loading to 0x600 and stop messing with the timer interrupt.

If nothing of the above will help, i'll upload my code to github or dropbox and would be glad if you would be able to take a look at it.

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 693

I hope when you redirected the timer interrupt you still called the original BIOS timer interrupt vector to do whatever work it was previously doing?

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

Octocontrabass wrote:

INT 0x13 depends on the PIT. Reset the PIT to its power-on configuration before calling INT 0x13, or do not write to the PIT at all.

Alternatively, you can redirect interrupt 8, and jump to the original vector at the same rate it used to be invoked (ca. 18Hz). Since the PIT is set to its slowest setting after boot (lots of things depend on that), you can always do that by just counting how many interrupts have happened.

Erukaron · **Posted:** Sun Oct 18, 2020 2:41 am

MichaelPetch wrote:

I hope when you redirected the timer interrupt you still called the original BIOS timer interrupt vector to do whatever work it was previously doing?

Yes, i invoke the old interrupt after my code has finished.

Reprogramming the PIT was the error. If i leave it untouched, everything works as it should now.

nullplan wrote:

Alternatively, you can redirect interrupt 8, and jump to the original vector at the same rate it used to be invoked (ca. 18Hz). Since the PIT is set to its slowest setting after boot (lots of things depend on that), you can always do that by just counting how many interrupts have happened.

I'll do a little bit of testing with this approach.

Thank you for your advice!

OSDev.org

Bochs: int13_diskette: ctrl not ready

Who is online