Grabbing keyboard input from user (PMODE)

[imate900]

I need some help about getting keyboard input. I want a simple way to do this in protected mode. I tried:

Code: Select all

char *monitor_getchar()
{
  return inb(0x60);
}

but it does nothing. Please help me.

[pcmattman]

Uh, are you kidding?

I can tell that you haven't looked around and you certainly haven't read the wiki.

Not to mention your "monitor_getchar" function is returning a char*.

[neon]

Wait... You are trying to a character from the keyboard but you already have a CLI? Im confused...

*edit: Also, why would the monitor get a character from the keyboard? If it is not, then why is your function named in such a way?

[Troy Martin]

Waiting for a character from the keyboard is simple; you repeatedly check the input buffer empty flag (in port 0x64) until it tells you there's a scancode in the buffer, then do your inb(0x60) to get the scancode, then pull the ASCII character from a table (use the scancode) to get the character.

Waiting for the scancode is just the same without using the char array.

[imate900]

Waiting for a character from the keyboard is simple; you repeatedly check the input buffer empty flag (in port 0x64) until it tells you there's a scancode in the buffer, then do your inb(0x60) to get the scancode, then pull the ASCII character from a table (use the scancode) to get the character.

Waiting for the scancode is just the same without using the char array.

Now, I am having heaps of trouble. I will need to implement V86 in some way.

[neon]

Now, I am having heaps of trouble. I will need to implement V86 in some way.

Why is that? The method Troy Martin posted is the standard correct way of waiting for a keystroke and getting it from the keyboard.

If you describe the problems a bit more and show some code we might be able to help.

[imate900]

Now, I am having heaps of trouble. I will need to implement V86 in some way.

Why is that? The method Troy Martin posted is the standard correct way of waiting for a keystroke and getting it from the keyboard.

If you describe the problems a bit more and show some code we might be able to help.

OK, code:

Code: Select all

int monitor_getchar()
{
  int ready;
  do {
    ready = inb(0x64);
  } while (ready != 0x1c);
  int t = inb(0x60);
  int temp = inb(0x61);
  outb(0x61,temp | 0x80);
  outb(0x61,temp & 0x7F);
  return t;
}

I think I'm getting the scancode as 0x1c and nothing else.

[Troy Martin]

Okay, seriously, get yourself a bookmark to the wiki page on the keyboard, an IDT and IRQs before working on this. Polling is ugly, and even I'm rewriting TBOS32 to use an IRQ.

With an IRQ, your wait_char function or whatever it's called only needs to repeatedly check for a flag to be set by your IRQ instead of polling the keyboard ports.

[neon]

Why are you testing if the status register is 0x1c? You only need to test bit 0...

[imate900]

Why are you testing if the status register is 0x1c? You only need to test bit 0...

Ok, but HOW? I know this is not easy pezzy. More exactly, what are the values if the keyboard buffer is full, or empty.

[pcmattman]

You do know how to test bits don't you - bitwise AND?

[imate900]

You do know how to test bits don't you - bitwise AND?

You missed: More exactly, what are the values if the keyboard buffer is full, or empty.

[pcmattman]

You only need to test bit 0...

[neon]

k, here is a bit more info. Please keep in mind that alot of this information is available in the Wiki and the web.

Most of what you have gotten so far is right. You are reading the KBC status register from port 0x64, and testing it. The KBC status register has the format (taken from my site. I removed all of the specific bits to reduce the size of the table)...

Code: Select all

    *  Bit 0: Output Buffer Status
          o 0: Output buffer empty, dont read yet
          o 1: Output buffer full
    * Bit 1: Input Buffer Status
    * Bit 2: System flag
    * Bit 3: Command Data
    * Bit 4: Keyboard Locked
    * Bit 5: Auxiliary Output buffer full
    * Bit 6: Timeout
    * Bit 7: Parity error

Bit 0 will be set if the KBC output buffer is full. Data will be placed into the output buffer on either an error condition, make code, or break code.

So, just loop testing bit 0 of port 0x64. When it is 1, we know that there are data in the buffer that we can read.

Afterwords, read the buffer from port 0x60 (The Keyboard Encoder Input Buffer).

The valid values that are read from the input buffer are in the following table (taken from my site)...

Code: Select all

0x0	Internal buffer overrun
0x1-0x58, 0x81-0xD8	Keypress scan code
0x83AB	Keyboard ID code returned from F2 command
0xAA	Returned during Basic Assurance Test (BAT) after reset. Also L. shift key make code
0xEE	Returned from the ECHO command
0xF0	Prefix of certain make codes (Does not apply to PS/2)
0xFA	Keyboard acknowledge to keyboard command
0xFC	Basic Assurance Test (BAT) failed (PS/2 only)
0xFD	Diagnostic failure (Except PS/2)
0xFE	Keyboard requests for system to resend last command
0xFF	Key error (PS/2 only)

In most cases it will be the key scan code (either a make or break code) that you can use for using as needed.

Hope this helps out a little more in understanding what you need to do.

[Love4Boobies]

Do you happen to know if the 83C51KB (MCS 51) is implemented in PCs? From what info I could gather from the wiki, it's becoming more common. However, is this also true for PCs or only embedded devices? Intel gracefully got rid of tons of MCS documents so I couldn't find the info I needed on this.