Internal Keyboard Buffer Full Problem with Bochs

[catcalls]

Hi Forum,

I'm developing an OS in 32-bit Assembler. The area being worked on at the moment is the Keyboard driver and Multi-tasking. There seems to be a problem somewhere that causes an error with my kbrd_Driver.

Internal KBRD Buffer Full. Ignoring scan code (ab)

That is basically the problem. I cannot type to the screen when that happens. It seems to happen _after_ I set scan code set 2. That's when it all screws up?

Any ideas?

Thank you in advance,

Cat.

[thepowersgang]

Well, that seems to me that your are not emptying the buffer on interrupt.
Afaik, Scancode set 2 uses multi-byte scancodes, so you need to remember to read all bytes of the scancode.

[catcalls]

Code: Select all

    474 IntKBrd:
    475         pusha
    476 ;       mov ax, ds
    477 ;       push eax
    478 ;       mov ax, 0x10
    479 ;       mov ds, ax
    480 ;       mov es, ax
    481 ;       mov fs, ax
    482 ;       mov gs, ax
    483 
    484 ;.spin:
    485 ;       in al, 0x64
    486 ;       and al, 0x01
    487 ;       jz .spin
    488         in al, 0x60
    489         mov edi, 0x0B8000
    490 ;       mov bl, 'C'
    491         mov bl, al
    492         mov bh, 00011111b
    493         mov word [edi], bx
    494 
    495         mov al, 0x20
    496         out 0x20, al
    497 
    498 ;       pop ebx
    499 ;       mov ds, bx
    500 ;       mov es, bx
    501 ;       mov fs, bx
    502 ;       mov gs, bx
    503 ;
    504         popa
    505 ;       add esp, 8
    506 ;       sti
    507         IRETD

This is the code for my Keyboard Interrupt. Some of it is commented out because it crashed on entry or exit.

As you can see I read the byte from the Keyboard. Do I need to read two bytes or more>?

What do you think?

Kind regards,

Cat

[thepowersgang]

Hmm... a look at my (outdated) code seems to say that there is one interrupt per byte. Are you acknowledging the interrupt with the PIC (well, is your handler running more than once?)

[catcalls]

Hmm... a look at my (outdated) code seems to say that there is one interrupt per byte. Are you acknowledging the interrupt with the PIC (well, is your handler running more than once?)

Hi TPG,

the _outb 0x20, al_ supposed to acknowledge the PIC. Is that not right?

I've also modified the code to use;

Code: Select all

outb 0xa0, al

where al = 0x20.

Weird problem, no?

[catcalls]

What I'm currently thinking right now is this;

When Scan Code Set 2 is set, I do an 'Unmask IRQ 1'.

But, later on in the code, I enable Interrupts, but then set the timer.

I've been commenting out some code, but from what I can gather, it seems interrupts are not enabled.

How do I enable Interrupts!?

Should I insert an STI somewhere in the code, or is it more complicated than that?

Kind regards,

Cat

[thepowersgang]

Well, to enable interrupts, STI should be somewhere in your main code path (i.e. not in the interrupt handler).

(Sorry about missing the PIC ACK, it's early in the morning for me)

Probably the best thing to do is to check if the handler is being called, dumping the scancode each time.

[catcalls]

Sorted it!

The IntTimer interrupt was being executed, even though I disabled enabling the timer 'tick'.

There fore, I thought to myself, if I _have_ to out to 0xa0 and 0x20 the hex 0x20 for each interrupt, then perhaps I should put that code into the timer as well, eh?

As soon as I did, I noticed that the X (timer output to screen) was flickering when I pressed a key!

So, I commented out the print X code in teh timer, and ran bochs again. I can write to the screen via keyboard now!!!

Yay!

Sure, I need to translate the scancodes to proper characters now. And, move the cursor along and backwards on delete.

But, it's firing! BOY! It's firing!!!

[gerryg400]

if I _have_ to out to 0xa0 and 0x20 the hex 0x20 for each interrupt

Not quite. You need to ack the PIC (or PICs) that interrupted you. Because of the way the second PIC is chained through intr2 on the first PIC, you should

Code: Select all

   if (intr_num is 0 to 7) {
      port 0x20 = 0x20
   }
   elseif (intr_num is 8 to 15) {
      both ports 0x20 and 0xa0 = 0x20
   }

Note, I've never really thought about it before. I'm not sure which PIC should be ACK'd first. I usually ACK port 0x20 then port 0xa0, but that is probably not correct.

Does anyone know which way round it should be ?

[Chandra]

if I _have_ to out to 0xa0 and 0x20 the hex 0x20 for each interrupt

Not quite. You need to ack the PIC (or PICs) that interrupted you. Because of the way the second PIC is chained through intr2 on the first PIC, you should

Code: Select all

   if (intr_num is 0 to 7) {
      port 0x20 = 0x20
   }
   elseif (intr_num is 8 to 15) {
      both ports 0x20 and 0xa0 = 0x20
   }

Note, I've never really thought about it before. I'm not sure which PIC should be ACK'd first. I usually ACK port 0x20 then port 0xa0, but that is probably not correct.

Does anyone know which way round it should be ?

I don't think there really is hard and fast rule for acknowledging the PIC. Even then, I acknowledge the Slave Controller(0xA0) and then to the Master Controller(0x20). I believe either way should work, though.

Hmm.... since this is about Keyboard and Timer, it really doesn't count because you got to acknowledge only the Master Controller, afterall.

[gerryg400]

Hmm.... since this is about Keyboard and Timer, it really doesn't count because you got to acknowledge only the Master Controller, afterall.

True, that's what I was originally saying but my thoughts wandered. And I now believe that you are correct, it doesn't matter which one is ACK'd first.

I hope catcals got that original point.

[Combuster]

I may reason that acknowledging Master controller first is the right thing to do, but this is purely a thought excercise and I believe PIC was made to allow either order.

A similar thought exercise suggests me to ack the slave first to preserve interrupt priority at all times.