Memory contents different on real hardware
-
- Member
- Posts: 5604
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Memory contents different on real hardware
What hardware are you using? Have you tried plugging in a different keyboard?
-
- Member
- Posts: 1146
- Joined: Sat Mar 01, 2014 2:59 pm
Re: Memory contents different on real hardware
I'm using a Samsung SDK3500 keyboard - I'll try another one if I remember.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
-
- Member
- Posts: 5604
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Memory contents different on real hardware
The chipset you're using is just as important as the keyboard, since there's a good chance the keyboard controller isn't passing all of your commands to the keyboard:
On an entirely separate note, it looks like you may not be parsing scan codes correctly. Those extra scan codes you're receiving shouldn't be the same as the shift key.When I tried writing data to the output buffer, I found the keyboard controller only forwards the "Set LED state" command and "Set Typematic Rate/Delay" command. It does not allow any other commands to be sent to the keyboard. However, it does emulate the keyboard's response by placing "acknowledge" (0xFA) in the input buffer when appropriate (or 0xEE in response to the "Echo" command.) Furthermore, if the keyboard sends it an erroneous byte, the keyboard controller takes care of error handling (sends the "Retry" command; if byte still erroneous; sends error code to keyboard and places error code in input buffer.)
Re: Memory contents different on real hardware
Not to mention the fact that there is no such thing as the shift key. There is a left shift key and a right shift key; they produce different scan codes.