[Solved] BIOS I/O function causing older systems to freeze

[pranavappu007]

I have a small "kernel" that is loaded in using my own Boot loader. The Boot loader loads the entire kernel(written in C) and sets the CPU to 32-bit and jumps to the kernel. And the kernel is loaded correctly. For accessing disk drive, I have a set of subroutines in assembly that switches the CPU back to real mode, runs a BIOS I/O interrupt, switches back to 32-bit mode, get the stack back, and return back to C code.The Code snippet that I've posted below runs on emulators and my laptop with Insyde BIOS, but when tried to run on my old hardware, it freezes right at int 0x13.

Code: Select all

.
.
   mov ah, 0x02                             
	mov al, [0x7a00]                     ;1
	mov cl, [0x7a01]                     ;1
	mov dh, [0x7a02]                    ;31
	mov dl, [drivedata]                   ;sets by bios
	mov ch, [0x7a03]                    ;0
	mov bx, [0x7a06]                    ;0
	mov es, bx
	mov bx, [0x7a04]                    ;0x7000
	int 0x13
	jnc diskreadnoerr
.
.

I have been using the same code snippet to run multiple filesystem based functions like list files, create new one, save to a file, read from a file etc. on both emulators and my real hardware. It worked with no problems, but when I tried to do the same on my old pc, it freezes.
And yes, I tested using debug-prints and found that the CPU executes successfully upto int 0x13, then it doesn't come out. Doesn't go to error routine either. It stucks somewhere inside that routine.
I also tested by directly giving the arguments instead of reding it from memory, but still it didn't work. I have no idea why this is happening.

This is how I jumps back to real mode..

Code: Select all

.
.
	lgdt [gdt_desc_16]
	jmp 0x8:$+7
	mov eax, cr0
	and al, 0xfe
	mov cr0, eax
	jmp 0x0:bit_16_start
[bits 16]
bit_16_start:
	mov ax, 0
	mov ds, ax
	mov ss, ax
	mov fs, ax
	mov es, ax
	mov gs, ax
	mov ax, 0x7900
	mov sp, ax
	mov bp, ax
.
.

Don't know if this is needed, but here is the 16-bit protected mode gdt I used:

Code: Select all

null_16:						;NULL gdt
	dd 0x0
	dd 0x0
	
gdt_code_16:					;code segment descriptor
	dw 0xffff				
	dw 0x0					
	db 0x0					
	db 10011010b
	db 00001111b
	db 0x0
gdt_data_16:					;Data segment Descriptor
	dw 0xffff
	dw 0x0
	db 0x0
	db 10010010b ; 1 st flags , type flags
	db 00001111b ; 2 nd flags , Limit ( bits 16 -19)
	db 0x0

EDIT: I found something. I am more confused now.

I can actually call some BIOS routines! I used 10h to reset video mode and used my own 16-bit subroutine to that prints strings using 10h and it all worked! Right until int 0x13!
Then I tried to reset disk using int 13h. But no even that didn't happen.
my modified code:

Code: Select all

[bits 16]
	mov dl, 0x80
	mov ah, 0
	;int 0x13                                                   ;doesn't work!
	mov al, 3
	mov ah, 0
	int 0x10                                                    ; works!
	mov bx, checkdata
	call print_bx                                              ;also works!
	mov al, [0x7a00]
	mov cl, [0x7a01]
	mov dh, [0x7a02]
	mov dl, [drivedata]
	mov ch, [0x7a03]
	mov bx, [0x7a06]
	mov es, bx
	mov bx, [0x7a04]
	mov ah, 0x02
	int 0x13                                                     ;doesn't work!

If real mode has problem, how am I able to call a function from the boot loader to print a string but not even reset the disk system?!

[iansjack]

You know, it's much easier to write a protected mode disk driver than to mess about switching back to real mode and using BIOS calls. And it's going to be a whole lot more efficient.

[BenLunt]

First, I agree with iansjack. It is a bit easier and you will have to do it eventually anyway.

My first few impressions of your situation is that you might be reading too many sectors at a time. 0x7F is the limit.
Also, your buffer should not cross a 64k boundary. i.e.: You can't read sectors to a buffer where one or more of the sectors will cross into the next 64k aligned block of memory.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[pranavappu007]

First, I agree with iansjack. It is a bit easier and you will have to do it eventually anyway.

My first few impressions of your situation is that you might be reading too many sectors at a time.

This piece of code will only read 1 sector, as I only need a small table I stored inside it.

[pranavappu007]

You know, it's much easier to write a protected mode disk driver than to mess about switching back to real mode and using BIOS calls. And it's going to be a whole lot more efficient.

I didn't know that at the time I wrote the function. But as I now have a somewhat working setup that I can even use later for things like video services, I like to continue with it unless I have no other option.

[PeterX]

What do you do after the int 0x13 if carry flag is set? Simply retry?

EDIT: I recommend, though it probably doesn't cause the problem:

Code: Select all

bit_16_start:
   mov ax, 0
   mov ds, ax
   mov fs, ax
   mov es, ax
   mov gs, ax
   mov ss, ax
   mov sp, 0x7900
   mov bp, 0x7900

[pranavappu007]

What do you do after the int 0x13 if carry flag is set? Simply retry?

print a red 'X' and hangs. And the red X does print on my laptop if actual disk error occurs.

[PeterX]

What do you do after the int 0x13 if carry flag is set? Simply retry?

print a red 'X' and hangs. And the red X does print on my laptop if actual disk error occurs.

May I ask about details of your "old system"? Maybe that's the reason?

[pranavappu007]

May I ask about details of your "old system"? Maybe that's the reason?

My new system is a laptop with Insyde BIOS and I regularly update the BIOS whenever a new version is it, so it is the latest supported version. The laptop is an HP Notebook 15 bs658tx.
My old system is a socket 775 build that features pentium E5700 with an Asus P5KPL-AM/PS Motherboard. It had one update available and I did that, but don't know the version.
Update: It also doesn't work on an i5 4th gen system with GIGABYTE motherboard..

[PeterX]

I must admit I can't find an error in your code. I personally suspect a broken BIOS.

Or you did something in pmode that leads to unreal mode or such weirdness.

Maybe the number of heads is below 32 on your old system? So head=31 would exceed the disk's limits.

[iansjack]

Your choice is something of a dead-end street. More and more computers nowadays support UEFI only, with no BIOS emulation.

[pranavappu007]

Maybe the number of heads is below 32 on your old system? So head=31 would exceed the disk's limits.

no, as my actual kernel resides in 32,34. It loads so no broken BIOS too.

Or you did something in pmode that leads to unreal mode or such weirdness.

I suspect - no I know this is the problem... Would you give me an insight of what kind of action might have an effect at this?
If you need more info, I use memory at 0x18000(stack),0x20000(for an "Interpreter"),0x50000 for a text editor and 0x70000 for file load and save function.
Also uses location in the code, and a real mode stack at 0x7900
My OS is around 32KB and is loaded at 0x7e00 right besides the boot loader, as actually both of them is one big program.

[pranavappu007]

Your choice is something of a dead-end street. More and more computers nowadays support UEFI only, with no BIOS emulation.

Doesn't matter as I am not writing a commercial OS, I just need to learn. UEFI and BIOS are both good to learn

[PeterX]

Replace

Code: Select all

jmp 0x8:$+7

with

Code: Select all

jmp 0x8:$+5

That's important, or else you skip over part of the to-real-mode instructions

[iansjack]

I just need to learn.

That's why I suggested writing a protected-mode disk driver rather than relying upon the crutch of the BIOS.