OSDev.org

Posted: **Sat Oct 25, 2008 3:00 pm**

Hello everyone,

I developed a VESA-driver for our os-project in our university.

My last problem with it is that when I switch from VESA back to CGA and try to type on our console, I can't. Well that only goes for the real PC (which has got an Athlon-CPU, but I had the same problem on a PIII-machine). When testing it in BOCHS I can type anything I want after being back in CGA.

One of the guesses was that interrupts might not be served after the switch anymore, but that is at least not true for the watch/timer which is still sending interrupts and shows that it is doing so.

I also thought that I messed up something while calling the VESA-Functions by INT 0x10 but we also have a VGA-driver which goes back to CGA-Mode with the same routine as the VESA-driver (by calling the appropriate BIOS-function through INT 0x10). After coming back from VGA the keyboard works fine.

Maybe it is something with my code that enables VESA (this all happens in real mode, otherwise the OS is in protected mode):

Code: Select all

enablevesa:
	mov	ax,0x700		;put VBE-struct to 0x7000
	mov	es,ax
	mov	di,0x0	
	mov	eax,'VBE2'	        ;tell VESA-BIOS that we want VBE 2 rather than VBE 1
	mov	[es:di],eax
	mov	ax,0x4F00	        ;Function to get VBE Controller Information
	int	0x10
	cmp	al,0x4F		;is Function supported?
	jne	continue_cga
	cmp	ah,0x00		;successful?
	jne	continue_cga

	mov	ax,0x800		;position for VBE Mode Information struct
	mov	es,ax
	mov	ax,0x4F01	        ;function call for VBE Mode Information
	mov	cx,[0x8200]	;getting VBE Mode number (I put it there in my C++ code)
	mov	di,0x0	
	int	0x10
	cmp	al,0x4F
	jne	continue_cga
	cmp	ah,0x00
	jne	continue_cga

	;Set desired modes
	mov 	ax,0x4F02	        ;loading VBE mode-setting-function
	mov	bx,[0x8200]	;getting VBE Mode number
	or bx,0x4000	        ;enable linear Buffering
	int	0x10			;go for it
	jmp 	activate_pm

any ideas? I appreciate any hints or ideas you might have!

Best,
joegy

Posted: **Sat Oct 25, 2008 3:25 pm**

well
right now i can not tell the reason ( sounds wierd, because keyboard and video are 2 different things, and they are not connectede though the same wire- )
by sugestions would be:
1:
try to deactivate the keyboard ( and , are you sure that you can draw text ??, and also, is the used mem for vga, mapped another place), and then activate it ( or just try to activate it . )

2:
try to see if the IRQ handler ( assuming the problem is here) is not overridden.

3:
if nothing seems to work, try to make a little debugging program, ( because you cant see the registeres on real pc, as a debugger) and also see the memory, and then the anser might come to you.

KMT dk

Posted: **Sat Oct 25, 2008 11:00 pm**

Hi,

joegy wrote:any ideas? I appreciate any hints or ideas you might have!

In real mode, all interrupts act like "interrupt gates" do in protected mode, in that the CPU automatically disables IRQs (clears the "interrupt enable" bit in eflags when it starts the interrupt handler). This means that if you're writing a lengthy BIOS function or video ROM function, to avoid causing excessive interrupt latency you should enable interrupts manually in your interrupt handler. Switching video modes is a time consuming thing, so I'm guessing the video BIOS does do the right thing, and does enable interrupts (e.g. "STI") when it's switching video modes.

I'd also guess that when you want to switch video modes in your OS you type a command in your console - you probably type the command and then press enter, then the OS starts switching video modes, then you release the enter key, and the "key released" IRQ probably occurs while you're switching video modes in real mode. The keyboard probably locks up because the data isn't removed from the keyboard's controller or because the BIOS doesn't send an EOI to the PIC (and all lower priority IRQs end up blocked; where the timer's IRQ 0 has a higher priority and isn't blocked).

Maybe using VGA works because it's a little faster than VBE - there'd be a delay before the "key released" IRQ occurs, and the VBE functions would need to do extra work (e.g. unlocking some extended video registers, setting those extra registers). Of course clearing the screen would also take a lot longer for something like a 1024 * 768 * 32-bpp SVGA video mode (3 MiB of data) than it would for a 640 * 480 * 4-bpp VGA video mode (150 KiB of data).

Then only real mystery is why the PIT doesn't stop working sometimes.

Of course this is all just a guess. Try doing something like "sleep(5);" before you switch video modes, so that there's time for the "key released" IRQ to occur before you switch to real mode. If that fixes the problem then you'll know the problem is "unlucky timing"...

Note: The only way for a protected mode OS to reliably handle IRQs when it temporarily switches to real mode is to install real mode IRQ handlers - even masking the IRQs and/or reprogramming the PIC causes problems. For example, you might have a flag for each IRQ where the real mode IRQ handlers set the corresponding flag if it's IRQ occurs, so that when you switch back to protected mode you can check these flags and call the corresponding protected mode IRQ handler/s for each flag that was set by the real mode IRQ handlers. This doesn't fix IRQ latency problems though - it'd only fix the "lost IRQ" problem. Another idea might be for the real mode IRQ handler to switch back to protected mode, run the protected mode IRQ handler and then return to real mode, but that can get messy (for e.g. if the protected mode IRQ handler could cause a task switch).

Cheers,

Brendan

Posted: **Sun Oct 26, 2008 11:51 am**

Hello Brendan,

thank you very much. Waiting for a bit before going into real mode did the trick.
Pretty amazing that you figured it out that fast and accurate!

Thanks again,
joegy

OSDev.org

No Keyboard after Switch from VESA to CGA on real PC

No Keyboard after Switch from VESA to CGA on real PC

Re: No Keyboard after Switch from VESA to CGA on real PC

Re: No Keyboard after Switch from VESA to CGA on real PC

Re: No Keyboard after Switch from VESA to CGA on real PC