Just thinking...if you were to do that for the 8 row lines using the proper shift register and leaving the column lines direct connected...would that not have been maybe easier programming-wise as well as...well...conceptually, a "neater" design?
We have different ideas of "rows" and "columns" as it seems. I've called the bunch of 20 lines the rows, and the other 8 lines the columns. No problem, just terminology.
But it's true, you could use a 74HC165 or similar to read out the 8 columns instead of driving 8 of the rows with a 74HC164 as done in the current design. Instead of the 8 diodes to protect the outputs of the 74HC164 from themselves, you'd have to use 8 pull-up resistors to pull the columns to a defined high level (the rows are driven in inverted logic, so that the active row is pulled to low level). Resistors and the 74HC165 are slightly more expensive than diodes and the 74HC164, respectively, at my electronics distributor; so I could use this as an excuse for the design decision. :wink:
The real reason, however, is that I have simply re-used my design (thus part of the firmware) for the IBM M4-1, which has 9 columns. I needed even more MCU I/O pins on that design for the trackpoint, so I've used 2 chained shift registers to drive 16 of the rows. It was the better choice for that design, but probably not for the terminal keyboard. I just didn't consider this alternative anymore.
I think we should change the design to use a 74HC165 for reading the columns. It's really nicer, also from the firmware's point of view. The matrix scan rate would suffer a bit, but that's most probably not a problem here.
also, i know your preference is usb for the interface...but would it be feasible to have this controller operate in ps/2?, perhaps mode-selectable by jumper?
Hm, maybe it could be possible to incorporate the code from Inornate's ps2avr project. Don't know how hard this would be, though.
I'm bound to say, however, that support for PS/2 mode has very low priority for me. It's not that I dislike PS/2, but the industry will stop supporting it sooner or later, no matter what the gamers say (gamers are supposed to kick out their money for game consoles). So, it's unlikely that I will start work on that any time soon. PS/2
input is a different story, though...
If someone else is willing to add PS/2 support, then I will happily provide any help needed, of course.
A terrific project, and many thanks for sharing your information with us so freely.
That's what's so cool about open source: you've noticed a problem, and because you could
see the problem, it was possible for you to come up with a better solution, thus improving the project. Impossible with closed, proprietary stuff.
