My 6502 computer

[viridi]

Proxy wrote:

why not just use one of the VIAs directly?
assuming you don't use the VIA's handshaking feature you can use the CA/CB pins as free I/O.

so a 74HC163 with it's clock and reset inputs hooked up the VIA's CA2 and CB2 pins (with some pull ups or pull downs). the output of the counter goes to a 74HC154 which then goes to the keyboard matrix. the other side of the matrix is then simply hooked into the VIA's regular IO pins (however many are required, though even just 8 inputs give you 128 keys).

so to scan the keyboard (assuming 74HC163 clk = CA2, reset = CB2, matrix input on Port A) once you:
1. reset the counter by pulsing CB2
2. read the value from Port A and store it into memory
3. pulse CA2
4. repeat 2 and 3 a total of 16 times
5. now either leave the raw keyboard data in memory for non-ISR code to handle or directly convert it to a bit/bytemap of which keys are being pressed at the moment.

sure it's a lot more software overhead and based on polling (i recommend some form of timer interrupt anyways), but it keeps the IC count low and makes hardware less complex.
which is good because fixing software mistakes is a lot easier and requires fewer cuts and botch wires than fixing hardware mistakes!

plus you still have one of the ports free which you could use for some software SPI for some cheap expansion (SD Card, RTC, various sensors, tiny displays, etc).

You are right it is more risky than doing it in software. Something similar as what you describe is how it was done in the older computers like the Commodore machines and the BBC Micro I have looked at how they did it. Perhaps I could use some programmable logic that would also reduce the number of chips and that is also reprogrammable in case of mistakes. But I don't have any experience with that except for programming a ROM chip if that counts as programmable logic.

[barnacle]

It's not just the scan/decode choice.

If you have a completely cpu driven keyboard scan (i.e. the main CPU, not an auxiliary part) then it has to spend a certain amount of it's time just scanning the keyboard, as well as managing the debounce and rollover in software. If you have a completely hardware approach, you need to know when a key is ready, so probably an interrupt, as well as handling (probably) debounce and rollover.

Similarly for something like PS/2, you either need to poll the clock line - rapidly - or have it trigger an interrupt (again, processor time) to decode the data, and you still need to sort out the keydown/keyup messages as well (you might want both edges of a key press, as Windows did (does? I'm out of touch) in an event loop).

My split the difference approach I think will be to use an external processor to mediate a PS/2 keyboard, read the individual packets, and spit them out as serial data - so I'll still need to sort out keydown/up messages at the processor, but the PS/2 sorts everything else out. (Or I can make it just send the keydowns as they happen and sort out control and shift there.) As it happens, I already have an SPI uart, so adding another is no great shakes.

I could do this with an eight-pin part, but I have a box full of STMs with 48 pin, so that's what it'll likely be.

(Or alternatively, use the same STM to handle an external UART channel and talk to it by SPI, let it sort out streams from serial port and keyboard. Time to play.)

Neil

[Yuri]

barnacle wrote:

(you might want both edges of a key press, as Windows did (does? I'm out of touch) in an event loop).

Windows does keep track of the make/break state of each key on the keyboard (somewhat) for video games.

Imagine if you will a typical modern game these days that likes to use WSAD for forward, backward, left, and right movement. Very often players will push Some combination of Forward+Side or Backward+Side.

They may also have something like 'F' to interact, or 'Space' to jump.

If all you want to do is type, then yea, keeping detailed track of the make/break codes doesn't make sense. Last key pressed is good enough, but if the game engine forgot you were pressing "forward" when you hit "jump" and you ended up falling into the bottomless pit because of it, you wouldn't have very happy players.

[viridi]

barnacle wrote:

It's not just the scan/decode choice.
If you have a completely cpu driven keyboard scan (i.e. the main CPU, not an auxiliary part) then it has to spend a certain amount of it's time just scanning the keyboard, as well as managing the debounce and rollover in software. If you have a completely hardware approach, you need to know when a key is ready, so probably an interrupt, as well as handling (probably) debounce and rollover.

Can't I just handle the incoming keypress with the 6522, the 6522 can trigger an interrupt on the 6502 right?

barnacle wrote:

Similarly for something like PS/2, you either need to poll the clock line - rapidly - or have it trigger an interrupt (again, processor time) to decode the data, and you still need to sort out the keydown/keyup messages as well (you might want both edges of a key press, as Windows did (does? I'm out of touch) in an event loop).

I'm not sure if I need keydown/keyup messages. Windows did/does this but did those older computers have have keydown/keyup messages? Something like the C64 or the Acorn BBC Micro?

[drogon]

viridi wrote:

I'm not sure if I need keydown/keyup messages. Windows did/does this but did those older computers have have keydown/keyup messages? Something like the C64 or the Acorn BBC Micro?

You may not need them but if you use a PS/2 keyboard then you'll get them because that's how they work... Although the 'driver' can hide it all from you. Making a PS/2 keyboard present a 7-bit + strobe interface is relatively easy with a micrcontroller.

(The other issue with PS/2 keyboard is language - some keys are in the wrong place)

If using your own matrix/polling scheme then it's entirely up to you - one thing that may influence that decision is games (or even some non-game tasks) if you want to detect e.g. how long a button is pressed - think of something like space invaders - simple left/right/fire controls, but if you can only get keypressed then you push a key to start moving then you need to push another key to stop moving/change direction rather than simply let the key go. Or even moving a cursor - auto-repeat has to be implemented... somehow...

-Gordon

[viridi]

drogon wrote:

You may not need them but if you use a PS/2 keyboard then you'll get them because that's how they work... Although the 'driver' can hide it all from you. Making a PS/2 keyboard present a 7-bit + strobe interface is relatively easy with a micrcontroller.

(The other issue with PS/2 keyboard is language - some keys are in the wrong place)

If using your own matrix/polling scheme then it's entirely up to you - one thing that may influence that decision is games (or even some non-game tasks) if you want to detect e.g. how long a button is pressed - think of something like space invaders - simple left/right/fire controls, but if you can only get keypressed then you push a key to start moving then you need to push another key to stop moving/change direction rather than simply let the key go. Or even moving a cursor - auto-repeat has to be implemented... somehow...
-Gordon

Ok clear. Thanks drogon. In the design I found that the keyboard is scanning constantly by some clock circuitry (perhaps I can use the system clock for that). All columns are scanned by the 74154 4-Line to 16-Line Decoder/Demultiplexer (with a 4-bit binary counter as input). The rows are scanned by the 74150 (with second 4-bit binary counter as input). When a key is pressed the 74150 captures that and strobes when the row of that key is active. Then the keyboard should output 7-bits these come from both the 4-bit counters and shifting/control logic. I could also send a strobe bit to the 6522.

I guess the keyboard would send data many times to the 6522 if the user holds down a key and the 6502 wil get interrupts every time then left/right/up/down movement would be appear. Please correct me if I'm wrong.

[viridi]

I've thought about it and I've come to the conclusion that I want to keep it simple. So I wont go into the rabbit hole of making the ascii keyboard now. Perhaps some other time.
So I will go for matrix scanning with the 65C22. That is what those older micro's did back in the day so why not. I think I will go for the same design as the Oric computer like GARTHWILSON describes on his potpourri page. Nice and simple!

I also want to add two game controllers/joysticks. I have found a schematic for that as well with two 74HC257 multiplexers. The circuit uses address decoding logic to select one of the two controllers. I have to figure that out.

So I would need to implement some software to scan the keyboard as well as the controllers via the 65C22?

[drogon]

viridi wrote:

I've thought about it and I've come to the conclusion that I want to keep it simple. So I wont go into the rabbit hole of making the ascii keyboard now. Perhaps some other time.
So I will go for matrix scanning with the 65C22. That is what those older micro's did back in the day so why not. I think I will go for the same design as the Oric computer like GARTHWILSON describes on his potpourri page. Nice and simple!

I also want to add two game controllers/joysticks. I have found a schematic for that as well with two 74HC257 multiplexers. The circuit uses address decoding logic to select one of the two controllers. I have to figure that out.

So I would need to implement some software to scan the keyboard as well as the controllers via the 65C22?

How many keys do you think you need? One trend today is for smaller keyboards (which I'm not overly fond of, but they exist and work), and you can get away with 44 keys - see e.g. https://www.wired.com/story/tiny-keyboards/

That would work with an 8x6 matrix, so 2 ports of the 6522 with 2 pins left over. (and some clever logic and/or matrix placement to detect 2-key roll-over so you can use the shift and ctrl keys with other keys)

As for joysticks - look at the old NES controllers (Or Famicom ones - but make sure it's the old style and not USB!) - these use a shift register internally. You need 3 pins per controller, however you can double some up, so with those 2 data pins left over for the data inputs, you can reset/latch and clock 2 controllers at the same time (using the CA2 and CB2 pins as outputs) and just sample either or both to read the buttons pressed...

I did this many years ago - maybe not that relevant here, but it has the schematic of the joystick..

https://projects.drogon.net/nes-control ... pberry-pi/

-Gordon

[viridi]

drogon wrote:

How many keys do you think you need? One trend today is for smaller keyboards (which I'm not overly fond of, but they exist and work), and you can get away with 44 keys - see e.g. https://www.wired.com/story/tiny-keyboards/

That would work with an 8x6 matrix, so 2 ports of the 6522 with 2 pins left over. (and some clever logic and/or matrix placement to detect 2-key roll-over so you can use the shift and ctrl keys with other keys)

The Oric computer keyboard seems to have 58 keys. It is a 8*8 matrix so 64 keys are possible.

drogon wrote:

As for joysticks - look at the old NES controllers (Or Famicom ones - but make sure it's the old style and not USB!) - these use a shift register internally. You need 3 pins per controller, however you can double some up, so with those 2 data pins left over for the data inputs, you can reset/latch and clock 2 controllers at the same time (using the CA2 and CB2 pins as outputs) and just sample either or both to read the buttons pressed...

I did this many years ago - maybe not that relevant here, but it has the schematic of the joystick..

https://projects.drogon.net/nes-control ... pberry-pi/

-Gordon

I plan to use controllers with sub-d 9 pin connectors. I have a The Arcade joystick. But it is also possible to create my own controllers like they did for the Agon Console 8 https://shop.heber.co.uk/agon-console8-joypad-in-black/. Or like these https://www.pcbway.com/project/sharepro ... 67618.html.

The NES controllers are great but it is hard to find the NES connectors to solder onto the board.

[Yuri]

viridi wrote:

I plan to use controllers with sub-d 9 pin connectors. I have a The Arcade joystick. But it is also possible to create my own controllers like they did for the Agon Console 8 https://shop.heber.co.uk/agon-console8-joypad-in-black/. Or like these https://www.pcbway.com/project/sharepro ... 67618.html.

The NES controllers are great but it is hard to find the NES connectors to solder onto the board.

No need to use the actual NES (or SNES) connector. The point is the controllers had a shift register, the 74xx165 to be specific, to read the buttons and then serialize the data down the line.

Each port on the NES had one had a +5V line, GND line, one line to tell the shift register to load the state of the buttons, and another that was a clock line to shift the data out. The final 5th line was the data line, which got feed into a 74xx595 that the CPU would later read. There's no reason this can't feed back into a 6522 though.

The SNES used the same idea, but doubled the shift registers to go from 8 bits to 16, which increased the number of buttons available on the controller. As I recall the default SNES controller only had 12 buttons. Though I think they got kind of clever with the protocols as they later added a mouse, which I presume just sent actual byte data down the line.

The whole thing was rather simple, James Sharman builds a set for his homebrew CPU video series, and uses the same concepts as the NES controller:

https://www.youtube.com/watch?v=d_ztfv2ZM6k

At any rate, there's really nothing special about the (S)NES connectors other than their shape. You could easily use a "traditional" 9 pin joystick connector, or any other connector your heart desires. There's a plethora of options out there.

[viridi]

Yuri wrote:

viridi wrote:

I plan to use controllers with sub-d 9 pin connectors. I have a The Arcade joystick. But it is also possible to create my own controllers like they did for the Agon Console 8 https://shop.heber.co.uk/agon-console8-joypad-in-black/. Or like these https://www.pcbway.com/project/sharepro ... 67618.html.

The NES controllers are great but it is hard to find the NES connectors to solder onto the board.

No need to use the actual NES (or SNES) connector. The point is the controllers had a shift register, the 74xx165 to be specific, to read the buttons and then serialize the data down the line.

Each port on the NES had one had a +5V line, GND line, one line to tell the shift register to load the state of the buttons, and another that was a clock line to shift the data out. The final 5th line was the data line, which got feed into a 74xx595 that the CPU would later read. There's no reason this can't feed back into a 6522 though.

The SNES used the same idea, but doubled the shift registers to go from 8 bits to 16, which increased the number of buttons available on the controller. As I recall the default SNES controller only had 12 buttons. Though I think they got kind of clever with the protocols as they later added a mouse, which I presume just sent actual byte data down the line.

The whole thing was rather simple, James Sharman builds a set for his homebrew CPU video series, and uses the same concepts as the NES controller:

https://www.youtube.com/watch?v=d_ztfv2ZM6k

At any rate, there's really nothing special about the (S)NES connectors other than their shape. You could easily use a "traditional" 9 pin joystick connector, or any other connector your heart desires. There's a plethora of options out there.

Ah ok that was what you ment. Yes of course I can do something like that. I have seen that video a while back, great video! I have to watch it again as it has been a while.

I found a schematic at https://github.com/barbeque/sg1000 it is an open source clone board of the Sega SG-1000. It looks like the SG-1000 console scans both controllers from time to time.

[viridi]

Could something like this work?

I use port A of the 6522 to scan through the columns and rows using a 74238 (columns) and a 74151 (rows). When a key is pressed pin Q of the 74151 will be high that is passed to port B of the 6522. Then I know on which row and column a key is pressed.

Here is a schematic:

I just added all 64 possible keys I probably will remove some of them as I might not need them.

[Yuri]

viridi wrote:

Could something like this work?

I use port A of the 6522 to scan through the columns and rows using a 74238 (columns) and a 74151 (rows). When a key is pressed pin Q of the 74151 will be high that is passed to port B of the 6522. Then I know on which row and column a key is pressed.

Here is a schematic:

ViridiKeyboard.jpg

I just added all 64 possible keys I probably will remove some of them as I might not need them.

This can work, but consider that the multiplexer is expecting only one row to be active at a time. If you expect to have key combinations such as Shift+Letter (as I expect you will with only 64 or less keys) you will need to make sure to pick locations where it is unlikely two or more keys will get pressed/read in the same column at the same time.

To put it another way, if column 3 is the one you're currently scanning, and keys on rows 2 and 4 are both pressed, you won't be able to tell both are down, the multiplexer is just going to pick one.

Many PC keyboards did/do this to save on costs though, and as I say, they tried to arrange the keys in such a way that multiple combinations where unlikely to come up. If you can accept this, then it is a good way to go, if not you'll want to be able to check each row independently.

There are of course plenty of way to do this and still save on pins on your 6522 if you're trying to keep some around for other things. (E.g. reading game controllers)

At the risk of summoning some ire, Ben Eater mentions this in one of his videos on the PS/2 keyboard:
https://www.youtube.com/watch?v=2lPzTU-3ONI

[John West]

Yuri wrote:

To put it another way, if column 3 is the one you're currently scanning, and keys on rows 2 and 4 are both pressed, you won't be able to tell both are down, the multiplexer is just going to pick one.

It's a multiplexer, not a priority encoder. It will give you the status of the key you ask for. If the keys on rows 2 and 4 are both pressed, it will respond when you select row 2, and again when you select row 4. And this keyboard has diodes on every key, so it won't have the ghosting problem that diodeless matrices have (which might be what you're thinking of?).

This design will work, it will just take a while to scan every key.

[Yuri]

John West wrote:

Yuri wrote:

To put it another way, if column 3 is the one you're currently scanning, and keys on rows 2 and 4 are both pressed, you won't be able to tell both are down, the multiplexer is just going to pick one.

It's a multiplexer, not a priority encoder. It will give you the status of the key you ask for. If the keys on rows 2 and 4 are both pressed, it will respond when you select row 2, and again when you select row 4. And this keyboard has diodes on every key, so it won't have the ghosting problem that diodeless matrices have (which might be what you're thinking of?).

This design will work, it will just take a while to scan every key.

*opens mouth inserts foot*

That being said, you could use two '139s connected to 4 output pins of a 6522, and then read in 4 keys at a time. For a 16x4 matrix. Still might be sluggish though.