Keyboard interface software — final video

Hi Ben I love your videos, and love the way you explain things. With that said, the software in this video, in particular, has a few software decisions that grate on me. At 2:55, you say that since the keys are being written in an interrupt handler, we should disable interrupts. The algorithm you use to communicate, however, is called "single producer, single consumer", and is a lock-free algorithm. What this means is that it maintains atomicy even if interrupted. Another thing that jumped at me was how much work you do inside the interrupt handler. While completely theoretical at 1Mhz clock, two new keys might arrive while we're still processing, which would cause one of them to be lost. Instead, what I'd do is just push the raw scan codes into the same buffer construct you used, and then do all the processing from the main loop. Aside from being safer, this would also simplify the code. Now, instead of marking you've seen the "key up" code as a state and returning from interrupt, you can just wait for the next scan code to arrive (as you're no longer inside the interrupt handler), and use the location in the code as the state signifying this is a key release. I have other nitpicks, but those are the two that really jumped at me.

Shachar Shemesh

The LS chips are TTL. The HC chips are CMOS. *For the most part*, they should be fairly compatible, assuming you run the CMOS chips at 5V VCC.

Shachar Shemesh

I see sometimes youre using 74ls chips, and other times 74hc. Could you explain a but about when to use which? Or is it just what you have lying around?

Richard

With 'input' solved (just code remaining), maybe moving 'up' to a bigger dot matrix LCD screen, THEN BASIC, though a 6502 based Text editor followed by an ML monitor or an assembler would be easier. Storage comes next but I do hope to see the worlds worst vid card bestowed with a character set and a screen editor even if it was only VT100 addressable to start.

Michael Weitman

Now we need a BASIC interpreter for it. Has anyone started working on this yet?

Warren Garabrandt

Well done and way to bring it around to a good closing. Time flies when you are having fun; I hoped for another hour : ) which included: Cursor backspace, cursor left/right; side scrolling; and when enter is pressed, reset a key buffer so that a program can grab the string entered. Of course this list could go on forever and as you suggested, others can take this concept and extend it. Thank you so much; I'll be starting my own build soon.

Michael Weitman

You could implement USB on a breadboard, at least 1.1 low- and full-speed variants (and that's enough to run all usb keyboards). There really isn't that much going on hardware-wise, but the protocol is much more complicated, requiring precise timing and the poor 6502 might be too slow for that.

Lovin it!

Love the video In your usb video please could you explain why you couldn’t implement USB on a breadboard? I know the specification is a lot more complex but I believe there are other (timing/interference) issues that would make it difficult as well which would be good to hear.

ASCII shifting doesn't really map the symbols on the number keys and others correctly. The ASCII people were looking at earlier keyboards that looked a little different. But the control characters can certainly be handled with bit flipping!

Your diagram for the write/read pointer in the buffer were fantastic. Simple and effective.

Chris Jenkins

Ah gotcha! No worries whatsoever. Thank you kindly for the info - that is a very slick trick! :)

Its the 1<<5 bit my bad, just googled the reference again https://catonmat.net/ascii-case-conversion-trick

Michael Timbrook

*edited* I haven't been able to watch the video yet, but my way of doing shifted characters was to copy/paste the characters from 0x00-0x7F to 0x80-0xFF and replace the pasted characters with their shifted counterpart. That way, if the shift flag is set, my computer just adds 0x80 to the scancode. This does technically leave F7 in a different position than normal as its scancode is 0x83, and adding 0x80 results in wrapping around to 0x03, but my guess is function keys are going to want their own way of being handled before trying to convert them to ASCII anyway.

Ascii is configured in a way so that if you flip the 5th bit it switches between cases! No need to have a different lookup table for that you can just flip a bit. *edit 7th -> 5th

Michael Timbrook

As it stands, pressing both shift keys at the same time and then releasing them would leave the shift bit set. A simple improvement (short of tracking left and right shift separately) would be to clear the shift bit when shift is released (e.g. "and #~SHIFT") instead of flipping the bit using eor.

Phil Dennis

You could use a USB to parallel board to allow access to usb peripherals without a lot of SMD hardware - like https://www.mouser.com/datasheet/2/117/usb245r-ds-v10-14240.pdf its a bit pricy but fun to play with.

Exited for the USB comparison, I've always wanted to know how inputs are encoded! Keep up the good work

Corin Baurmann