Connecting a 16-key keypad to VIA: Did I do it right?

[JeffJetton]

Hi all! First post here.

I'm working on adding one of those ubiquitous, cheap, 4x4 matrix keypads to my Ben Eater build.

The good news is, it works. (So far at least!) But maybe that's just due to dumb luck? I'm still very much a learner when it comes to hardware, so I'm not sure I'm using the best design. Here's what I'm doing:

• The four "column" pins of the keypad are connected to PA0-3 on the VIA (65C22), which are configured as inputs. I also have them pulled low using 1K ohm resistors.
• The four "row" pins are connected to PA4-7 on the VIA, configured as outputs. No pullups or pulldowns.
• To scan, I'm setting each output pin in sequence by writing the appropriate value to the port, then checking the input from the same port to see if any of bits 0-3 are on. I'm also doing some simple software debouncing.

Questions:

• Are the pull-down resistors necessary? If so, does 1K seem like a good value (I just sort of guessed)?
• In a discussion on Reddit, someone mentioned that the older 6522 (no "C" in it) worked differently and needed the inputs to be pulled up or something like that. The scanning then works in reverse, pulling one line low and checking for low inputs instead of high. Would that be a better way to go, even with the 65C22? Or maybe to make the whole design compatible with either chip?
• Basically, am I on the right track at all here?

Thanks a bunch!

- Jeff

[GARTHWILSON]

Welcome.  WDC's W65C02S has true CMOS inputs; so when there's no connection through any button being pushed, then yes, you'll need a resistor to pull the input up or down.  Rockwell's and other brands' CMOS VIAs' inputs are not high-impedance, and are really more like and LSTTL input which would require a very heavy resistive load to pull down to a valid-low logic level; not just because they take more current, but also because the logic-low level is such a low voltage, like 0.8V or lower, rather than 30% of Vcc like WDC's ICs use.  Non-CMOS VIAs won't be able to pull up to a logic high against a 1K to ground.  Rockwell's R65C22 can pull all the way to Vcc (unlike NMOS), but is still asymmetrical, able to pull down much harder than up.  WDC's W65C02S has symmetrical outputs, able to pull up just as hard as down.  When you do pull up to nearly 5V with a Rockwell or WDC VIA against a 1K resistor, you'll have nearly 5mA.  That's kind of heavy.

I would recommend changing the resistors to 10K or more, and using them to pull up rather than down.

Be sure to go through the 6502 primer.  There's plenty of evidence (although not proof) that Ben Eater got a lot of his ideas from there.

[Yuri]

JeffJetton wrote:

Hi all! First post here.
Questions:

• Are the pull-down resistors necessary? If so, does 1K seem like a good value (I just sort of guessed)?
• In a discussion on Reddit, someone mentioned that the older 6522 (no "C" in it) worked differently and needed the inputs to be pulled up or something like that. The scanning then works in reverse, pulling one line low and checking for low inputs instead of high. Would that be a better way to go, even with the 65C22? Or maybe to make the whole design compatible with either chip?
• Basically, am I on the right track at all here?

That's generally how most keyboards operate. They light up a row (or column) and then see what comes back with a value on the column (or row).

Whether you need to pull up or down will likely depend on the ICs your using (I defer to Garth's post), but in large part I'm not aware of any (dis)advantages of doing it with high level logic vs. low level.

Edit:
With a 4x4 (16 key) matrix the pins on the 65C22 are sufficient and the grid space is small enough I think this is a good way to go with a simple 6502/6522 setup.

With larger more complex keyboards you'd likely run the strobe through a de-multiplexer like the 74x138, or a pair of them. I've been looking at using a PIC chip or some other simple programmable chip that can do this for me in the background and then send interrupts along to the CPU.

[BigEd]

I suspect pull-ups are more common because
- in TTL inputs, there's a natural inbuilt pullup. You wouldn't want to fight it
- in TTL outputs, pulldown is stronger. It's the better choice to act against a resistor
- the logic threshold is lower than halfway. A pullup has less work to do to get a given level of noise immunity

Note that these don't apply to CMOS, but you might as well do the usual thing.

I see there are cunning ways of combining diodes with switches to read many more switches using even fewer I/Os.
https://www.ednasia.com/encode-dozens-o ... our-lines/
This is not the same idea as charlieplexing which is used for driving LEDs. But it's a similar kind of ingenuity.

[jds]

BigEd wrote:

I see there are cunning ways of combining diodes with switches to read many more switches using even fewer I/Os.
https://www.ednasia.com/encode-dozens-o ... our-lines/
This is not the same idea as charlieplexing which is used for driving LEDs. But it's a similar kind of ingenuity.

That's some complex stuff just to save a few pins, but it's interesting to see what some people think of. At the bottom of the article there's a section on reusing the keyboard scanning ports to also talk to a character LCD. It reminded me of the complete opposite, using a 6545 video controller to scan a keyboard, it's in this application note:

http://6502.org/documents/appnotes/syne ... 5_crtc.pdf

[drogon]

jds wrote:

That's some complex stuff just to save a few pins,

Pins = Money and when you can save 0.1c on a million unit product run you do.

-Gordon

[GARTHWILSON]

drogon wrote:

Pins = Money and when you can save 0.1c on a million unit product run you do.

Maybe I went through it too fast; but it looks like the addition of all the diodes would defeat that.  When I'm designing something for our company to sell, I have to consider the price of the parts (of course), the PCB real estate they'll take up (making the board bigger and more expensive), and the price of putting them on the board (which may exceed the price of the part).  I'm usually not in a situation where time to market is critical; but if I were, I'd have to consider also the lost sales from taking a little extra time to figure out how to save that 0.1¢ per unit.

[barnacle]

Re Garth's point: I have in a couple of cases found it a cent or two cheaper to use a single more expensive component rather than a larger number of cheaper parts. As he points out, there is also the cost of actually putting a component on the board (and only your board stuffer, er, constructor, will be able to advise you as to costings).

If you have been told to try and save a few dollars on a PCB assembly - and remember, every cent saved is a cent on your bottom line - then you look at everything. Is it cheaper to use a connector or for someone to solder wire tails? etc.

Neil

[JeffJetton]

Thanks, all, for the advice and tips! I appreciate your helping a newb like me.

I might try giving the "pull up" design a shot. I'm thinking the required changes to the scanning logic should be pretty straightforward, but we shall see.

On the one hand, I hate to change a working design. On the other hand, messing around with things is how you learn. (This is true in any area, but I'm beginning to see that it's especially true in electronics.)

And yes, I am trying to keep this as simple as possible. The idea being that anyone else with a finished Ben Eater kit (or similar) could implement it themselves cheaply and quickly. It's just a 16-key keypad, so I figure there's probably not a lot of benefit for additional complexity anyway. At a certain point you might as well just add a full-blown keyboard interface or UART, etc.

[BigEd]

(It's a pity that 5x4 keypads aren't quite as cheaply available: it's a natural size for hex+functions, or for a calculator. 16 keys isn't quite enough, and 32 is a lot.)

[JeffJetton]

BigEd wrote:

(It's a pity that 5x4 keypads aren't quite as cheaply available: it's a natural size for hex+functions, or for a calculator. 16 keys isn't quite enough, and 32 is a lot.)

If you'll indulge me in a bit of rambling about this project...

That was precisely the problem I had for the longest time as I was turning this idea around in my mind. Nearly all of its "inspirations" (KIM-1, Heathkit ET-3400, Micro-Professor, etc.) have at least 20 keys, and it's for the very reason you mention: Hex plus functions. But good luck finding an off-the-shelf keypad that's inexpensive and widely-available.

In contrast, those 4x4 jobs are everywhere and can be had for a song. Heck, I already had one lying around from one of those "build a gazillion Rasperry Pi/Arduino projects" kits. I thought maybe I could go with certain multi-key combinations executing the commands or something?

But then, while I was tinkering around with writing an emulator for the (octal-based) PDP-8, it hit me: You don't need to use hexadecimal! I set about whipping up an octal-based monitor for the 6502, and surprisingly, it worked pretty well. That right there frees up half the keys on the keypad for other things. (In theory, you could even pull off octal with a 3x4 keypad, and I briefly thought about repurposing an old touch-tone phone as an input device. Imagine how cool it would be to use the hook switch as a reset button!)

The one snag was dealing with 16-bit addresses. It's a bit of a pain splitting up an octal number into two 8-bit chunks, since, unlike hex, the "split point" falls in the middle of a digit. I actually wrote up a couple pages of documentation covering a few ways to do the math, and even built a function into the monitor that would calculate the split for you. Not very elegant though.

That problem got solved while I was researching the similarly 8-bit/octal-based (originally) Heathkit H8 and learned about how it used "offset" or "split" octal. This encodes the MSB and LSB of a 16-bit address as two separate octal numbers. The addresses are essentially "pre-split". I rewrote the monitor to work that way, and it turns out to be a total game-changer.

[BillO]

I'm more of a hardware guy so I've used 74C922 and 74C923 keyboard encoders for this.

The 74C922 encodes a 4x4 matrix and the 74C923 does a 4x5 for 20 keys. In the past I have used one of the same little 4x4 keyboards for the HEX numbers and then added 4 more push buttons as function key along with the 74C923. This makes a nice stand alone keyboard that can be used for various experiments/systems as required.

For me, cutting down on code is more important the saving on hardware.

Just another way to skin the cat.

[Michael]

One possible low-cost solution, if I may? I've used some 24-key and 44-key IR Remotes in PIC projects in the past. The IR Receiver IC comes with the keypad and only needs a single pin and pull-up on the host. The NEC IR protocol is relatively easy to decode and you can print custom keypad overlays.

[Michael]

Another interesting serial I/O (keypad & display) chip;

TM1637, DIP-20, 2-pin interface (CLK & DIO), 6-digit 7-segment display, and 16-key keypad. Chips and 4-digit and 6-digit display 'modules' are available on AliExpress and elsewhere.

[GARTHWILSON]

JeffJetton wrote:

In contrast, those 4x4 jobs are everywhere and can be had for a song. Heck, I already had one lying around from one of those "build a gazillion Rasperry Pi/Arduino projects" kits. I thought maybe I could go with certain multi-key combinations executing the commands or something?

Just use a 4x4 with one of the keys being a shift key.  This is from a workbench prototype of something I did for work ten years ago:

keypad.jpg (53.17 KiB) Viewed 3907 times

(I apologize that there's not more resolution.)  The shift key is in the lower-left corner, and there's an LED to the left of it that's hardly visible in the picture.  The things labeled in red are shifted-key functions; so the hex digits A-F are over the 1-6, HOME is over the left arrow, END is over the right arrow, and SPACE, DEL, and INS/REPL are down the left column.  You never press two keys at once; so you activate the shift by pressing it before pressing one of the keys where you want the shifted function.  The LED lights up until you press the shifted key.  If you change your mind, press SHFT again and it goes off.  If you don't want to dedicate an LED (and the output to drive it), you could put that indication in the LCD.  Four of the keys did not have a shifted function assigned yet.