Mike's PCjr Page

Notice to existing and future purchasers of my PS/2 to PCjr keyboard converter:

This evening I was testing a converter I'm getting ready to send out and discovered some missing functionality. When NUMLOCK is on and you press SHIFT, the top row of number keys responds exactly the same as the keypad keys, which prevents you from typing symbols (!@#$%^&*()) when NUMLOCK is on. I decided to see how easy it would be to add an exception for the top row of keys that toggles NUMLOCK off while shift is being held down, and further discovered that my error handling code for reading from the PS/2 keyboard was completely broken.

The first bug is very noticeable, and I'm not sure how I didn't catch it during initial development (or maybe I did and just assumed it was a PCjr quirk, which it could be, but really that's no excuse for me not attending to it). The second bug is probably something that never would have been noticed if not for my poking around in the code to fix the first bug, and essentially means the converter would never detect a failed read from the PS/2 keyboard, and would always pass whatever scan code it thought it read.

I'm in a testing phase right now, but if all goes well, I will release the new code shortly. If you have the means, you'll be able to download the code and reprogram your own microcontroller and be on your way. Otherwise, you can contact me, and I'll do what I can to help you upgrade to the latest code.

Changes in progress:
-Adding an exception for the top row of number keys that toggles Numlock OFF on a keypress while shift is being held down and ON on a key release while shift is being held down. This is turning out to be a little trickier than I originally thought and may require a couple more nights of debugging, but as of right now it's pretty close to being there.
-Adding parity detection. Error detection previously just consisted of waiting for a time-out period and throwing an error if not enough bits were received. Now there will also be actual parity detection, and resends of misread keypresses will be requested from the PS/2 keyboard.

NOTE: If you're satisfied with your converter as-is, it's not strictly necessary to upgrade to the latest code, I just wanted to make sure this information was out there in case people *are* having issues.

The new software seems to be working, with one caveat: NUMLOCK will get 'out of sync' if you type symbols too quickly. It seems to do fine if you do no more than about three per second, and I've added in code that adjusts for typematic repetition, but for all my efforts, it still seems possible to outrun the code. It does seem to cope well enough with realistic typing situations, though, for example if I press two keys at once (something that's easy to do accidentally) it doesn't seem to have any issues. The problems seen with mashing a bunch of the keys down might be due to buffer overrun, but I'd have to do some thinking regarding how much I could feasibly increase the buffer size.

EDIT: Actually I didn't have to think too hard about the buffer size at all. If I go any more than double what it currently is, the compiler refuses to compile because there isn't enough memory on the device. It does seem to be able to weather a bit more now, but you can still out run it if you try.

The code is giving me more trouble than I thought it would, unfortunately. First I added the NUMLOCK work-around, and that seemed to do okay. Then I found the error handling bug and worked on it for a while, and realized after I thought I had fixed it, that I was inadvertently causing repetition of some keystrokes. I worked on that for a while and pretty much fixed it, but have now somehow lost the ability to update the keyboard LEDs (probably because I'm sending more than one type of command to the keyboard now and they're getting out of order or something). It will be a while before this next update is ready, most likely. I can update the units that are out there with the timing fix I did a while back if anyone still wants that, though.

You really are committed to making sure everything is 100% working with your products. I really admire that, too many people these days are of the "Eh, good enough" attitude.

I think I finally figured out the conflict between the error handling routine and the LED update routine. The following items were the sticking points for me:

1. To make error handling based on parity effective at all, it has to re-request the previously sent code from the keyboard while still in the reading routine, before the code it just read is committed to the buffer.
2. To make the error handling code work from within the reading routine, you have to be able to switch to the writing routine from within the reading routine without screwing up how the interrupts work. This is tough, because you got into the reading routine in the first place from an interrupt and not everything is cleared out yet.

So, my issue seemed to be that I was trying to implement either number 1 without number 2, or number 2 without number 1. That is, I was sticking the error handling code in the proper place, but screwing up the order in which things ran when an interrupt happened, or I was preserving the interrupt order, but running the error handling code from outside the reading routine, which also doesn't work.

I finally (I think) solved the issue after walking through the code and realizing that one way I did it essentially called the write routine twice without waiting for the interrupt again -- essentially locking up the keyboard completely because it never sent enough bits out to it -- and the other way I did it called the read routine again immediately after the write routine, which essentially just cancelled out the write routine (hence no LED updates). And it was all due to a slightly messy bit of code where for some reason I had elected to use two sequential IF statements instead of a single IF-ELSE. Without the ELSE in there, the interrupt routine was free to run both a read and a write within the same interrupt cycle, or if I called the write from within the read, run two writes within the same interrupt cycle. With the ELSE, it has to pick one or the other, so no more conflicts!

I am still testing it to make sure it's now working the way I think it does, though.

Okay, added buffer overrun protection back in. I thought it out more carefully before typing any code this time, and even though I can't tell if it's doing anything, I at least seem to have not broken any existing functionality this time. Next I'll take another stab at the NUMLOCK override code and see if I can't make that a little more robust as well.

Isn't it fun to go back over your code and wonder, "What was I thinking when I did THAT?"

<*> Jim

I think I actually have everything working.

I was key mashing like crazy and never got the Num Lock LED out of sync with what the computer was seeing, and the top row of number keys always worked the way you'd expect. To me, that says both buffer overrun detection and error handling are working as they should behind the scenes, because if they weren't, I would have expected some glitches that would have screwed up my key count or my LED state or both.

I'll give it some additional testing (just standard typing, since I've already navigated the 'try to break it' test successfully) and if all goes well, I can start offering the actual feature update to people instead of just the timing adjustment I've done up until now.

I know this is an old thread, but jmetal88 just built two of these for me. I love it! No more fumbling with the weird Jr keyboard. I will keep it for historical accuracy, but will probably never use it again. Thanks jmetal88.

KenG wrote:I know this is an old thread, but jmetal88 just built two of these for me. I love it! No more fumbling with the weird Jr keyboard. I will keep it for historical accuracy, but will probably never use it again. Thanks jmetal88.

Thanks for the good review!

For those of you reading this who might be interested, I have enough parts to build seven additional units at the moment, but none pre-built as of yet.