Something that I've just knocked together to get some basic input going. I'm sure many people have done this here, but thought it might be of interest to those just starting out.

This was made around a keypad that I purchased on ebay. The keypad has the usual rows and columns matrix (4x4 keys consisting of 0-9 and A-F) and to which I've attached an Atmel ATMEGA 328P-PU microcontroller which does the scanning (thus taking the responsibility/work load from the 6502 / VIA).
The 328P pulses each row low and (for each row) then checks the columns to get the row and column combo of the key being pressed. If a key ahd been pressed then does a lookup to determine the equivalent ascii code which is then outputted to the VIA. The VIA IRQ pin is then pulsed low to tell the VIA that a key has been pressed and data is ready.

I've gotten the hardware assembled (looks a bit messy on the soldering as I had to rework some of it) and have mostly completed the 328P firmware (see attached), although I've got to make a few adjustments; namely I need to clear the code up a bit and add in some comments and also possibly add in R3 (a 10K pull up resistor for the IRQ line). R3 shouldn't really be needed as it's actively driven by the 328P so I might not put it in, but we'll see how things go in testing as it's lack might cause the VIA to generate spurious IRQs during the 328P's (admittedly brief) initialisation.

BTW I've included an SPI header so that the 328P can be programmed in-situ.

Here's a couple of pictures and a circuit diagram plus the firmware (I used Atmel Studio 6.2):

[edit] Updated the firmware AVR source code with bug fixes and comments

(I like it... for a while it's bugged me that you can readily get 16-key keypads but a KIM-1 needs 7 more keys than that. And the answer came to me: octal! Eight keys for number entry and eight left over for functions!)

Then why not go binary and have 14 for other functions! Or have a smaller keypad!

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I was kind of tickled to see how well these little NEC IR remotes work. Maybe use a simple plastic coated paper overlay for a new key legend.

Connect the IR Receiver IC output to a single pin on the VIA and let the 6502 decode the signals, or perhaps use an 8-pin PIC to decode the signals and send key press data to the 6502 VIA or ACIA.

I have one of those remotes on order from China and was wondering what I'd do with it. Now and I know:)

I've updated the source code file as I had the rows and columsn mixed up. That's now been corrected. Also included comments.

The price and the idea of using a single VIA pin for keypad input is appealing, isn't it? It would certainly make for a nice small front panel. Also, I wonder if you couldn't use an 8-pin PIC as a PS/2 Keyboard to IR transmitter? Might be a nice incremental upgrade for a "starter" system.

I've also thought about using something like a 4.3" resistive touch screen overlay for a keypad, but, personally, I prefer tactile feedback from buttons.

Two years ago I hooked up an C64 keyboard to an Arduino an wrote a little key-scanner to use the keyboard. Using an Arduino Leonardo would cause the whole thing act as an USB keyboard.
Using an 74HC138 I could reduce the number of "line driving pins" to 3. So one via should have enough pins to make a simple 8x8 keyboard work.

Mario.

_________________
How should I know what I think, until I hear what I've said.

Thanks to me being a bit blind and also to Atmel Studio 6.2 masking a source code error, I've spotted a few issues and corrected them.

Here's the new source code and circuit diagram.



I've also run into an issue that Michael kindly pointed out to me, although I think it's a slightly different one than initally thought (correct me if I'm wrong, Michael).
When I press two keys on the same row as each other, I get a large pull on the power rail. If press three keys together, I get even more pull.

Here's what happens when keys are pressed and held down on the same row. Note that keys pressed at the same time on different rows do not cause issues:

Resting current use: alternates between 3 and 5mA
1 key pressed: 3mA (does not rise to 5mA)
2 keys pressed together: 37mA (+34mA)
3 keys pressed together: 55mA (+18mA)
4 keys pressed together: 72mA (+17mA)
The above does not differ if different key combinations are used.

The way my keypad circuit works is that it holds all rows HIGH by default
When a row is being scanned, it drops that row LOW.
The Column inputs are then checked to see if a LOW is detected on a column and if so, the row/column number combination is recorded, the ascii value looked up and outputted on the VIA interface pins (along with the VIA IRQ dropping LOW for 10ms).
The column lines are held high using a 10K bus resistor network connected to +5v rail.

I don't understand why there is this power draw? Can anyone see from my diagram if I've mucked something up? If it were completely shorting out then my benchtop PSU would go to the max allowed current and then start dropping the voltage. This doesn't happen.

it sounds like you should be tri stating the rows which are not scanned? Right now the row that isn't scanned is driving the row that is, via the key switch.

Alternatively to tri stating you can use diodes, eg. how the ULA and key matrix were arranged in the Spectrum. But since you are using a controller I would just tri state.

See: https://github.com/aslak3/keyboardcontr ... ter/main.c

This is the code for my C64 keyboard AVR-based controller. It shows the principle of rotating the DDR, leaving the "unscanned" row in input in tri state.

EDIT: added some details, since I wrote the first post using my phone.

_________________
8 bit fun and games: https://www.aslak.net/

Hi Aslak3

That's pretty much what was recommended by Michael (from this forum) as well. What I'm really after is understanding what is actually happening - are the columns drawing the current from the row pin, for instance? So we have roughly 18mA per column (i.e. per key). This might explain it, although I don't understand quite why this would cause such a large draw for each.. .

I'm sure you've figured this out by now, but I'll write anyway. This is mentioned in the keypads & keyboards section of the potpourri page of the 6502 primer at http://wilsonminesco.com/6502primer/potpourri.html#KBD . Basically you have contention, where two row outputs get shorted together and one is trying to pull the line up and the other one is trying to pull it down. If they're dedicated to the keypad and you're not using them for other things at the same time, the way to handle it that makes the hardware simplest when you're using a VIA is in software. You write 0's to all those bits in the output register and leave them, then only change the data-direction register to scan the rows. That way, you'll never have one pin trying to pull up a line that another pin is trying to pull down.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes indeed, although I'm not getting these on different rows being shorted together - just different columns for the same row. So if I press 0,1,2,3 (on the same row) then I get the issue. If I press 0,6,A,F (diagonally down and to the right) together then I don't. So I'm not sure that this is contention? Only because it seems to involve one output and mulitple input pins....

The following might make it clearer (forgive the crudity of my MS Paint skills). This show what is happening when keys 0,1,2,3 are all held down together and that row then being scanned:


The Rows are AVR outputs and the Col(umns) are AVR inputs. If I held down, say, buttons 0 and R and then got an issue, then I would also think contention, but I don't I only get an issue with a combination of buttons 0,1,2,3 - i.e. ones on the same row. Same row, same output pin.
(the red arrows should point the other way as the columns are srawn to 0V by the row, but you get what I mean)

[edit]

I've added in 1N4148 diodes into the rows, but although a good idea to prevent contention, doesn't make any difference to this issue. Here's an updated circuit diagram:

Hi Mike,

I mentioned in the PM that your description of rows and columns and how they're being used wasn't consistent in your schematic and code. The AVR code suggests your keypad matrix is wired like this;

The AVR code shows you're driving the column pins (RD0..RD3) as outputs with row pins (RD4..RD7) as inputs which is contrary to your schematic and your description of the scanKbd() function. This also suggests your pull-up resistors are connected to the column lines and you're relying on the AVR internal weak pull-ups for the RD4..RD7 row inputs.

To avoid short circuits from multiple concurrent key presses in the same row while scanning the keypad I suggested either adding four diodes to the circuit or modifying the key scan code to only set one column line at a time to an output (low) during each column scan while leaving the remaining port D pins as inputs with pull-ups. Here's a quick-n'-dirty (untested) example;



Your new code still has a DDRD assignment operand with only seven bits instead of eight. Bit 7 should be a '0' anyway but it seems sloppy.

Consider using a switch state memory or switch state latch to distinguish between "new press" and "still pressed" switch states each time through the main loop. Use switch state logic to qualify sending "new press" data and strobe to the VIA while ignoring "still pressed", "new release", and "still released" states.

Good luck on your project, Sir. It looks great...

Cheerful regards, Mike

I'm ashamed to say that you're right (we need a forum icon for face palm lol). I did originally have them a different way around, left the project for a couple of weeks and obviously completely forgot. Thank you for your persistence in letting me know where I'd gone wrong, Michael.

One thing: I can't seem to use the diodes. The rapid pulsing of the rows isn't translated throught the 1N4848 diodes - I get a very shallow square wave ripple on the other side. Anyone got any suggestions on a different type? If not, I'll try and slow down the scanning to see if that helps (and yes, I have the diodes the correct way round :p).