Page 2 of 2

Re: Experiments with the 8042 keyboard controller

Posted: Thu Mar 12, 2020 7:51 am
by Octocontrabass
Whoops, my mistake. What the wiki calls the "configuration byte" is called the "command byte" in some really old IBM manuals. You can probably guess I was looking at when I wrote that post...

Re: Experiments with the 8042 keyboard controller

Posted: Thu Mar 12, 2020 8:54 am
by sunnysideup
Alright! Makes sense!

There's another thing that came across my mind, the PS2 controller seems to have an output port too. Is this the same as the keyboard port that we were talking about? It doesn't seem so because there seem to exist ports called the first PS/2 port and the second PS/2 port
PS/2 Controller Output Port

Commands 0xD0 and 0xD1 let you read and write the PS/2 Controller Output Port.
This doesn't seem to be any of the registers I know (command/status). Why is this also called a **port**?

Re: Experiments with the 8042 keyboard controller

Posted: Thu Mar 12, 2020 9:59 am
by sunnysideup
Also I have a question about translation
Translation

The original IBM-PC keyboards (using the old XT interface) used "scan code set 1". The new AT keyboards generated different scan codes, or "scan code set 2". This change would have created compatibility problems for software that was expecting different scan codes from the keyboard. To avoid the compatibility problem, the keyboard controller supports a translation mode. If translation is enabled the controller will translate "scan code set 2" into "scan code set 1".

Whenever this translation is enabled (and by default, it is) there is no way to reverse it in software. For example, if you receive the byte 0xB5 from the controller, then you can't know if the original data (sent to the controller by the device) was the byte 0xB5; or if it was the two bytes 0xF0, 0x33; or if it was the two bytes 0xF0, 0xB3.
Source: [wiki]https://wiki.osdev.org/%228042%22_PS/2_Controller?[/wiki]

Okay, so current keyboards (interface compatible with the AT) use set 2 by default right? Why does it say that the keyboard controller enables translation by default??

Or is this too ancient to even talk about now? :oops:

Re: Experiments with the 8042 keyboard controller

Posted: Thu Mar 12, 2020 11:09 am
by Octocontrabass
sunnysideup wrote:There's another thing that came across my mind, the PS2 controller seems to have an output port too. Is this the same as the keyboard port that we were talking about? It doesn't seem so because there seem to exist ports called the first PS/2 port and the second PS/2 port
The output port is used to control the signals being output by 8 of the 8042 microcontroller's pins. The name simply comes from the fact that those 8 pins combined are referred to as a "port" in the 8042 datasheet, and they're all configured as outputs instead of inputs.

Of course, in computers that don't use a discrete 8042 as the keyboard controller, the pins may no longer exist, but the functionality is still there.
sunnysideup wrote:Why is this also called a **port**?
For the same reason port 0x60 and port 0x64 are called ports: Intel liked the name. (Well, that and "port" is a useful metaphor for how they're meant to be used.) It's just an inconvenient coincidence that the physical connectors you plug keyboards into are also called "ports".
sunnysideup wrote:Okay, so current keyboards (interface compatible with the AT) use set 2 by default right? Why does it say that the keyboard controller enables translation by default??
The translation is needed to remain backwards-compatible with PC and XT software, which would access the keyboard controller and expect to receive set 1 scan codes instead of the keyboard's set 2 scan codes.

As for why IBM decided translating set 2 into set 1 inside the keyboard controller was the best solution instead of making the keyboard produce set 1 scan codes, I have no idea. I suspect it was done to make the AT keyboard compatible with a serial terminal or something silly like that. (IBM really wanted people to use mainframes with dumb terminals.)
sunnysideup wrote:Or is this too ancient to even talk about now? :oops:
Personally, I think it's useful to learn how the hardware evolved while maintaining backwards compatibility. It helps contextualize the odd design choices. (Plus it's fun to write software for old hardware.)