Noob QEMU int 10h question

[cnlohr]

So, I'm using the Bare Bones loader, etc. in the wiki with TCC and it's working wonderfully with QEMU and syslinux's mboot.

I can't get the VBE stuff to change the video mode, so, I figured I'd take a step back and use the lowest common denominator. I'll call int 10h and give it a shot.

Code: Select all

mov al, 13h
mov ah, 0
int 10h

in my loader before I call kmain.

Every time QEMU boots, it appears to get here, then crashes. I can try calling the same from inline assembly in code I know works because I can write text to the video ram. If I use BOCHS, I get the following errors and a stack dump.

Code: Select all

00216887396e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x10)
00216887396e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00216887396e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00216887396i[CPU0 ] CPU is in protected mode (active)
...STACK TRACE...
01626655492i[CPU0 ] 0x0000000000100221>> int 0x10 : CD10
01626655492e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
01626655492i[SYS  ] bx_pc_system_c::Reset(HARDWARE) called

Since I'm using all the syslinux stuff, do I have to move the processor into another mode to call int 10h? Is there something I'm doing supremely stupid?

[gerryg400]

You need to be in 16bit real mode to use the Bios calls like int 10. Are you still in real mode ?

[cnlohr]

Nope. Because of the syslinux stuff, it kicks me right into protected mode. I've been reading more, and I understand this is a problem. I've tried to gather together stuff from the forums to get something that can move from protected to real, call the interrupt, and back, but I can't seem to get any of it to play nicely together.

Has anyone written a function I can call from C that's effectively call_real_mode_interrupt_from_protected_mode( int interrupt, int eax, int ebx .... )

Charles

[Kazinsal]

You've got a couple options, then.

1. You can drop back into real mode, set up appropriate data segments and stack stuff so the BIOS doesn't have a heart attack, and then kick yourself back into protected mode.
2. You can set up a v86 handler and all its assorted requirements, but this requires a lot of work.
3. You can program the VGA directly. This is how the BIOS does it, anyways, so you know it'll work! However, if you get your numbers wrong, you could potentially damage older monitors on real hardware.

You may find Chris Giese's resources on graphics setup in protected mode useful: http://geezer.osdevbrasil.net/osd/graphics/index.htm

[cnlohr]

1) is the most attractive by far - I've found tidbits of 1) all over the place... but nothing complete enough to work from.

The page you linked references "Simple V86 mode monitor; calls 16-bit video BIOS from 32-bit pmode." But, I don't see this in the links section. Maybe I'm not looking to it as the right name?

Judging from the size of the virtual-8086 mode monitor file, this could be way over my head.

[gerryg400]

There are some pointers in this thread http://forum.osdev.org/viewtopic.php?f= ... 47&start=0

[cnlohr]

The example here solves everything: (exposes a simple mechanism to switch to real, call an int, and switch back)

http://www.rohitab.com/discuss/topic/35 ... cted-mode/

Is this something that should be posted on the wiki?

*EDIT* In practice his code seems not to agree with the rest of my environment, bochs will reboot sporadically after the interrupts are executed.

*EDIT 2* DURRRRRR I didn't realise the protected mode syslinux dumps you into didn't have an IDT either.

[turdus]

*EDIT* In practice his code seems not to agree with the rest of my environment,

Have you modified the selectors according to your gdt?

bochs will reboot sporadically after the interrupts are executed.

You can turn this off, in bochsrc set "reset_on_triple_fault" to "no". And learn how to read bochs messages, it was first complaining about idt gate, which could mean:
1. no idt at all
2. wrong system descriptor at given index
3. wrong processor mode (clear from bochs output)

Also real mode does not have IDT, so any error about it is more than suspicious. In real mode idtr points to IVT, at the start of RAM, which does not contain descriptors, rather seg:offs pairs. If your bootloader messes up this area, you won't be able to use BIOS functions (never used syslinux, so I suggest to check it with a debugger first).

[cnlohr]

As my second edit shows, I was totally being derpy. I didn't have any GDT either. The problem was his code was turning interrupts "back" on when I didn't have anything handling them.

So, now I'm getting started on that route. But his code does seem to work pretty superb. Makes it trivial to call real mode interrupts from protected mode C.