Keyboard IRQ 1 does not come through, please help.

[ehenkes]

During Devolepment of my Mini OS I hit a problem, which I currently cannot solve.
Timer IRQ0 works, Exceptions work, keyboard_handler is fine, but Keyboard IRQ 1 does not come through. Perhaps you can give me a hint how to solve this HLT:
http://www.henkessoft.de/OS_Dev/Downloa ... 0nicht.zip
http://www.henkessoft.de/OS_Dev/Downloads/IRQ_Test.PNG

I do not see a mistake in the C code, perhaps the problem is in isr.asm, about the stack or linker script.

Thanks a lot
Erhard

[JamesM]

Hi,

Have you cleared the keyboard buffer? If the keyboard has buffered input, it will never raise another IRQ until the buffer is cleared.

To do this, while the DATA_READY flag (0x01) is set in register 0x64, read register 0x60. Then, the keyboard will send IRQs again.

Cheers,

James

[ehenkes]

The first IRQ1 does not come.
if you send it by

Code: Select all

__asm__("int    $0x21");

, then the whole chain starts:
IRQ1 (--> 33) --> keyboard_handler --> getch() with this code:

Code: Select all

int ShiftKeyDown; // Variable for Shift Key Down

unsigned int FetchScancode()
{
	return( inportb(0x60)); // port 0x60: get scan code from the keyboard
}

unsigned int FetchAndAnalyzeScancode()
{
	unsigned int scancode; // For getting the keyboard scancode
	while(TRUE) // Loop until a key to be pressed
	{
		while ( !(inportb(0x64)&1) ); // 0x64: read keyboard µC status register
		scancode = FetchScancode();

		if ( scancode & 0x80 ) // Key released? Check bit 7 (10000000b = 0x80) of scan code for this
		{
			scancode &= 0x7F; // Key was released, compare only low seven bits: 01111111b = 0x7F
			if ( scancode == KRLEFT_SHIFT || scancode == KRRIGHT_SHIFT ) // A key was released, shift key up?
			    ShiftKeyDown = 0;	// yes, it is up --> NonShift
			continue;	// Loop
		}

        // Key was pressed. Capture scan code of shift key, if pressed
		if ( scancode == KRLEFT_SHIFT || scancode == KRRIGHT_SHIFT )
		{
			ShiftKeyDown = 1; // It is down, use asciiShift characters
			continue; // Loop, so it will not return a scan code for the shift key
		}
		return scancode;
	}
}

Do I need to start the process by

Code: Select all

inportb(0x64)&1

before waiting for the first interrupt during my program? No, doesn't work. Only sending IRQ 33 by assembler really helps starting the process.

__asm__("int $0x21"); once is enough. Is there another way to kick this off?

[jgraef]

May it be possible that the keyboard buffer is filled even if the first IRQ didn't arrive. That could be if you hit a key, when you haven't installed your IRQ handlers yet. So it is a good idea to just clear the keyboard buffer at startup in your keyboard driver.

[JamesM]

The first IRQ1 does not come.
if you send it by

Code: Select all

__asm__("int    $0x21");

, then the whole chain starts:
IRQ1 (--> 33) --> keyboard_handler --> getch() with this code:

Code: Select all

int ShiftKeyDown; // Variable for Shift Key Down

unsigned int FetchScancode()
{
	return( inportb(0x60)); // port 0x60: get scan code from the keyboard
}

unsigned int FetchAndAnalyzeScancode()
{
	unsigned int scancode; // For getting the keyboard scancode
	while(TRUE) // Loop until a key to be pressed
	{
		while ( !(inportb(0x64)&1) ); // 0x64: read keyboard µC status register
		scancode = FetchScancode();

		if ( scancode & 0x80 ) // Key released? Check bit 7 (10000000b = 0x80) of scan code for this
		{
			scancode &= 0x7F; // Key was released, compare only low seven bits: 01111111b = 0x7F
			if ( scancode == KRLEFT_SHIFT || scancode == KRRIGHT_SHIFT ) // A key was released, shift key up?
			    ShiftKeyDown = 0;	// yes, it is up --> NonShift
			continue;	// Loop
		}

        // Key was pressed. Capture scan code of shift key, if pressed
		if ( scancode == KRLEFT_SHIFT || scancode == KRRIGHT_SHIFT )
		{
			ShiftKeyDown = 1; // It is down, use asciiShift characters
			continue; // Loop, so it will not return a scan code for the shift key
		}
		return scancode;
	}
}

Do I need to start the process by

Code: Select all

inportb(0x64)&1

before waiting for the first interrupt during my program? No, doesn't work. Only sending IRQ 33 by assembler really helps starting the process.

__asm__("int $0x21"); once is enough. Is there another way to kick this off?

Please, if you ask for an answer to your question, read the response that I gave. You don't just poll port 0x64, you read port 0x60 too.

[ehenkes]

<deleted>

[JamesM]

Read it!

I specifically said that you have to read from I/O location 0x60 until bit 0x01 in I/O location 0x64 becomes unset.

Your manual software interrupt 0x21 is not helping matters, it is only disguising the problem.

If you cannot and will not read and research, I will lock this thread.

James.

[ehenkes]

Code: Select all

void keyboard_init()
{
    /* Wait until buffer is empty */
    while (inportb(0x64) & 0x01)
      inportb(0x60);

    // __asm__("int $0x21"); // also possible, but not perfect.
};

Thanks, this code works, but I didn't find it anywhere up-to-now.

[pcmattman]

I didn't find it anywhere up-to-now

Why'd you need to look for it? The answer is right here:

I specifically said that you have to read from I/O location 0x60 until bit 0x01 in I/O location 0x64 becomes unset.

If you can't go from that to C code, then (I personally feel) you need to step back and do some more learning before you continue.

EDIT: And before the times get pointed out, there's this from earlier in the thread:

To do this, while the DATA_READY flag (0x01) is set in register 0x64, read register 0x60. Then, the keyboard will send IRQs again.

[ehenkes]

Thanks, I was confused last night by other source code out there in the huge internet. Port 0x64 and 0x60 offers a lot of read/write combinations.

[Love4Boobies]

Combinations? Combinations of what?

[JamesM]

Leave it there, there's no need to carry this into a flamewar / interrogation.

[ehenkes]

there's no need to carry this into a flamewar / interrogation.

Thanks, I am fire proof.

[JamesM]

there's no need to carry this into a flamewar / interrogation.

Thanks, I am fire proof.

Hi,

If you think that an inability or refusal to read and understand simple and explicit information or answers is something to be proud about, you have found the wrong forum.

I suggest when you post your next question you heed this else the only replies you get will be flamebait.

Cheers,

James