KBD map translation problem...

[stonedzealot]

I've been reading through hardware manuals and managed to get into working keyboard and inport routines without help from others' code (I'm sorta proud of that). Unfortunately, there is one thing that just absolutely puzzles me, it seems so basic.

So I wrote a little kbd IRQ handler:

Code: Select all

kbdirq()
{
   char scancode, asciified;

   scancode = inportb(0x60); 
   asciified = scancode_convert(scancode);
   if(asciified != 0)
      k_printf(temp, 1);
   outportb(0x20, 0x20);   
}

Very simple. The problem is that the scancode_convert function (which is just returning an ascii translation of the scancode inputted, no other handling) puts out crap (random strings from 1 to 3 characters, usu. none of them being the character I want).

I know that the scancode is being passed right because if I push (A) on the keyboard, it returns 1E (which is correct), and I know the k_printf can handle temp, because if I initialize it to "A" it can print. I also know that entry 1E (30) in the keymap is 'A'.

The reason this is so frustrating is that all scancode_convert is doing is saying return = keymap[scancode] where keymap is an array of all the lowercase ascii characters, and as I said before, I know that entry 1e is 'A'.

What am I missing here?

[bkilgore]

Code: Select all

kbdirq()
{
???char scancode, asciified;

???scancode = inportb(0x60); 
???asciified = scancode_convert(scancode);
???if(asciified != 0)
??????k_printf(temp, 1);
???outportb(0x20, 0x20);???
}

I'm curious about what the variable "temp" is. I don't see it defined in that function. I'm also curious about the "1" that you are passing...what's that for? Anyways, one thing you have to keep in mind that

Code: Select all

k_printf("h");

is different than

Code: Select all

k_printf('h');

because the first passes the pointer to a null-terminated string, and the second passes an ASCII representation of a character. It's possible that your k_printf statement is treating this as a pointer to a string, and loading values at that memory location (i.e., if you pass 'A', reading characters starting at memory location 65) until it hits a null-character, which explains the multiple random characters. Normally to print a single character stored in a char data-type, one would do a call like

Code: Select all

k_printf("%c", chr)

where chr is a char containing the character to print.

This is the first thing that comes to mind that could cause this problem, if I understand you correctly.

[stonedzealot]

Sorry, that temp variable is another name I had for asciified, since I wasn't copying directly from the code, I just mixed the two names...

The 1 in the k_printf is the line on which to print

It's not a null terminator problem, as I've added them and it did nothing. Also when this is the problem you'd usually get something like "Hello World!4SAHjgf97" or whatever...in these random characters, the target character was nowhere to be seen (most of the time).

I can't use k_printf("%c", chr) because I haven't programmed in an stdargs unit...but in all honesty, that shouldn't be necessary.

[Pype.Clicker]

well, either your kprintf is not at all a printf-like function, it takes one character and displays it (and you should rather name it "kputc" or something), or it actually take a string as the first argument and then you're calling it the wrong way.

Code: Select all

char getKeyboard(void);
char decode(char);
void kprintf(char* string, int line);

keyboard_handler()
{
    char scancode, ascii;
    scancode=getKeyboard();
    ascii=decode(scancode);
    kprintf(ascii,line);
}

is wrong. a char is *not* a string (i.e. an array of characters ended with the nul character). kprint will (as explained above by bkilgore) try to use the character as a memory address where the text to be displayed lies. You'll get nothing but garbage that way.

Code: Select all

keyboard_handler()
{
    char scancode, ascii[2];
    scancode=getKeyboard();
    ascii[0]=decode(scancode);
    ascii[1]=0;
    kprintf(ascii,line);
}

is the right way to create a one-char string for kprintf (if you don't have a '%c' feature nor a single-char display for now).

[stonedzealot]

That's what I just did...didn't refute bkilgore's string/char argument...I just meant that coding an entire stdarg should be unnecessary (at this stage). Anyway, unfortunately I'm away from my test computer and my comp running bochs at the moment so I'll update this post when I can getto it and test out the code.

Oh well, I hope that is the problem. Thanks bkilgore and Pype.