So how does a PS/2 keyboard interface work?

As for the 'next' video, my vote would be to both leverage a microcontroller, delivering the 'key' to the 6502 via interrupt, and to interface directly, writing Assembly to manage all of the plumbing. I'd be interesting in weighing # of bytes and # of interrupts required to manage a 10 character keyboard buffer versus having an inexpensive controller present but next to the 6502 to handle the 'heavy' lifting.

As things get more complex (read large and repeated circuitry), it would be cool to have a series on how to transfer this and/or other bits into keycad; but only as an "add-on video" so that we stick with the breadboard to get things working.

Curious (if anybody knows) will the same basic mo apply to a 90's DEC VT320 terminal; been looking to pick one up and the native (RJ11) keyboards are few and far between (OR sellers want additional $$). If so, I assume it should be straightfwd to map from PS2 to an older but possibly similar standard?

As always, great video! I did not understand how did we passed bit 11 from pin 2 to second breadboard at 23:00... Can we actually use any Q-pin as a serial output? I thought only pin 9 can be used for that.

I'd say a microcontroller circuit that decides the keyboards basically random scancodes into ascii, and special codes into a custom code, and then have the keyboard do an interupt request. And then when the computer gets the interupt, you could have any special codes be addresses or pointers to a subroutine that does whatever the key does. Like home, it can run a custom subroutine to move the pointer on the lcd display to the front. And etc for other keys. Normal keys can just be a default subroutine, like adding it to the display, so that every key is a subroutine, just some are special. This is just to keep the system modular.

As you were building up to your final design, I was imagining how I might do it: A counter and comparator to generate the latch signal, and then interrupt the CPU to read that key and add it to an internal buffer for later event handling. Maybe some extra logic to ensure the start/stop/parity are correct before asserting the interrupt.

Really enjoyed the video! As a little kid I always wondered why the keyboard cable did not have 84 cables (one for each button). At some point I learned it was a serial interface, but now I know exactly how that serial interface works. Looking forward to seeing a video on how to hook the keyboard up to the 6502. At 30:20 you talk about the 6 bytes for Print Screen break, yet only 5 of them are highlighted in yellow on the screen. Not sure if that was deliberate but it jumped out as odd to me.

have you tested it with a USB to PS/2 adapter? PS/2 keyboards are a less likely to come by and some times can be pricey.

Well, this makes me appreciate the work done on the Commander X16 (and I guess, by partial proxy at least, Commodore) since I don't have to worry about scancodes directly in my code (not yet anyway though not all keys are implemented yet and may still require having to read the raw keyboard scancodes). Certainly gives me a greater appreciation for what's going on just to type things, thanks Ben! Great video as usual!

From my experience I was able to get away by leaving 595 output latch floating. But I guess it's not the intended use?

Hey Ben! Thank you for the great video!

I got an AT (and PS/2) keyboard working with a 65C02 SBC I designed a couple years ago. http://forum.6502.org/viewtopic.php?f=4&t=5345&hilit=Potpourri6502 What I did was just interface the clock/data directly to a VIA and let the 6502 work out reading it. It's also pretty simple to have the VIA trigger an interrupt which just stores the presses in a buffer that the CPU can read from.

Rumors say, NASA is building a Rover to find and land at the end of the shift register chain Ben built for this video

Thanks Ben

Excellent, thanks Ben.... love the use of the traditional: "Here's some I prepared earlier..." moments to add LOADS more Shift registers... :-)

Am I right to assume that the release code + scan code is for situations where you, say, press A then press B then release A then release B. If just a release code was sent then you would not know in which order the keys were released. This is important in gaming. And might be used for adding umlauts to international characters. For instance on a Mac you press Alt+e to get the ´symbol then press the e to get é. Or Alt+n n to get ñ.

Instead of a microcontroller, couldn't you use one of your old tricks and treat the scan codes as addresses for a properly prepared ROM to get ascii codes?

I recalled that the codes are called SCAN codes because the 8048 microprcessor in the IBM keyboards scans the keys sequentially to generate the codes. If you look at the key positions the scan codes make sense. http://www.seasip.info/VintagePC/ibm_1501105.html

I was curious about how to interface a keyboard, I was considering PS/2 for an interface, but figured the only option was to send an interrupt for each scan code. So I'd like to see how that would work versus other options. The microcontroller sounds like an interesting option as well.

At 18:06 you read off the first 4 bits inverted (1101 instead of 0010). Cool video though! I have heard anecdotally that PS2 accessories are better for gaming because the latency is lower than USB, seeing how simple the protocol is I could probably believe that now... (maybe some day you'll hook your oscilloscope up to some USB gadgets and we can see how complex that is).