Author Topic: about scan codes  (Read 1323 times)

0 Members and 1 Guest are viewing this topic.

Offline chyros

  • a.k.a. Thomas
  • * Esteemed Elder
  • Thread Starter
  • Posts: 3499
  • Location: The Netherlands
  • Hello and welcome.
about scan codes
« on: Sun, 12 April 2015, 19:13:23 »
In preparation of a review I'll be doing sometime in the future, I'm reading up on scan codes a bit, but I find it hard to understand because what I'm reading seems to be conflicting with what I'm finding.

So there's three sets, 1 (XT), 2 (AT/PS/2), and 3 (some specific IBM thing), right? Now I have two keyboard tested program, and I use them to test my old keyboards with. All of these are PS/2, so set 2. When I press A, one returns "1Eh", and the other says "0x1E". I suppose both are simply an unnecessarily annoying way of saying "1E". But A for set 2 according to the majority (but annoyingly not ALL) of scan code tables isn't 1E but 1C; 1E appears to be A in set 1 (XT), which I'm absolutely not using. There's no confusion about the protocol, because one of the programs even mentions it's in PS/2. What am I missing here?
Check my keyboard video reviews:


Offline hasu

  • Posts: 3491
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: about scan codes
« Reply #1 on: Sun, 12 April 2015, 21:32:23 »
To see real scan codes of keyboard protocol you need to get signals on wires with Oscilloscope.

Most of programs on OS won't display real scan codes, instead they show OS specific codes.
What OS are you on? Assuming Windows... Interesingly Windows uses extended XT(code set 1) from historically reasons. PC or the OS translates all inputs into the XT codes after receiving scan codes from USB and PS/2 keyboards. So what you see on those programs is OS internal codes, not real scan code from keyboard.

You can know how to translate them from this table.
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf


And OSX still uses ADB as internal codes interestingly.
https://opensource.apple.com/source/IOHIDFamily/IOHIDFamily-606.1.7/IOHIDFamily/Cosmo_USB2ADB.c

Offline chyros

  • a.k.a. Thomas
  • * Esteemed Elder
  • Thread Starter
  • Posts: 3499
  • Location: The Netherlands
  • Hello and welcome.
Re: about scan codes
« Reply #2 on: Mon, 13 April 2015, 02:52:54 »
Cheers mate, that makes sense. Yeah, I am using Windows. When you think about it it's rather bizarre that Windows still talks in XT but can't understand it xD . That table is perfect, thanks.
Check my keyboard video reviews:


Offline Findecanor

  • Posts: 5082
  • Location: Koriko
Re: about scan codes
« Reply #3 on: Mon, 13 April 2015, 13:26:01 »
For the IBM AT to be backwards-compatible with old programs on the XT that read off the keyboard port themselves, the AT got an additional microcontroller whose only purpose was to convert from Set 2 (AT scancodes) to Set 1 (XT scancodes).

So, programs in DOS always used XT scancodes, and Windows was originally on top of DOS.
I don't know if PC hardware that has a PS/2 interface still does this though.

BTW, 1Eh is a notation common in x86 assembly language. 0x1E is C-language notation. ... and in assembly language for the 6502 or Motorola 680x0, you would write $1E.
🍉

Offline chyros

  • a.k.a. Thomas
  • * Esteemed Elder
  • Thread Starter
  • Posts: 3499
  • Location: The Netherlands
  • Hello and welcome.
Re: about scan codes
« Reply #4 on: Mon, 13 April 2015, 14:50:05 »
For the IBM AT to be backwards-compatible with old programs on the XT that read off the keyboard port themselves, the AT got an additional microcontroller whose only purpose was to convert from Set 2 (AT scancodes) to Set 1 (XT scancodes).
Wait, do you mean the AT keyboard converted itself back to XT on-board? Wouldn't that mean the AT keyboard should be compatible with an XT computer?
Check my keyboard video reviews: