6502.org

There's a metal plate on back. There are 17 tiny screws holding the plate onto the plastic top part, and two posts with threaded metal nuts embedded in them for mounting the keyboard in a case. It looks like a solidly built unit, all told.

I looked at this keyboard again recently, and found that the wider of the two ribbon cables appears to have 16 lines, not 12 as previously stated.

It so happens that there are 16 keys in the top row, which means that cable is probably the columns lines.

There are 5 rows of keys, but 7 lines in the narrower cable, which means only two lines are unaccounted for. Would a switch-and-diode matrix need ground and VCC lines?

Both cables have the same numbers printed on them despite being different sizes, but the Internet doesn't know what those numbers mean.

Maybe, but it wouldn't be surprising if you were to get a surprise. Who knows what the manufacturer might've done!

If I were doing it, I'd steer clear of any assumptions and just suss it out in the manner I described up-thread. It shouldn't take long.

-- Jeff

I wouldn't put it past them to do something odd. Last time I went to digging for info on the keyboard, I learned that they were selling some kind of developer kit for it back in the day. That's probably where they revealed the secret of the cable pinout.

A bit of digging around of Fujitsu keyboard specs suggests: 8 x KBDIN and 16 x KBDOUT, with KBDIN being X (rows) and KBDOUT being Y (columns).

It sounds as though a scanning technique similar to what Commodore did in their eight-bit machines ought to work.  As I recall, they used a 6522 in everything up to and including the VIC-20, and a 6526 in the C-64 and C-128, to strobe the rows and columns.

One column would be driven low whilst all others were driven high.  Each row in turn would be checked to see if it were high or low, with an index incrementing for each column/row pair checked.  When a row was found to be low, the index was used to look up the corresponding keystroke in a table.  Doing all this required dozens of bit-twiddling VIA/CIA data I/O accesses, which was accomplished with code crammed into the jiffy IRQ handler.

There is no N-key rollover with this arrangement and complicating matters, the C-64 and C-128 joystick ports share some lines with the keyboard, which meant accidental joystick movement would inject random characters into the user’s typed input.

Since this Fujitsu unit has 24 lines in all, the Commodore technique could still be used, but would require a pair of 65C22s to get the required number of inputs and outputs.

BTW, in mechanical drafting, the rows would be Y and the columns would be X.

Thanks!

I assume there are diodes amongst the key switches. If you had to speculate, would you say the anodes are towards KBDIN or KBDOUT? That's exactly what I intend to do, except the terminal will be separate from the computer, and use an ESP32 and two MCP23017 I2C port expanders instead of VIAs to scan the matrix.

As Dr. Jefyll noted above, this keyboard may follow the C-64 scheme, or the designers may have thrown in surprises.

If you only need to encode 16 columns, why not a '154 4-16 decoder? And perhaps a '137 priority encoder for the rows? That reduces your interconnect to only seven leads, plus maybe a ground reference.

Neil

There are only two leads with I2C (SCL and SDA).

That's how the BBC keyboard is scanned. b0-b3 counts through a 74xx45 to select columns 0 to max, and the eight rows are 74xx156 to go from 8 rows to 3 bits.

It also includes a counter that scans through the columns by itself so the 6502 only has to look at the keyboard when the scanner has selected a column with a key pressed. But in "non-free-running mode", the 6502 can write to b0-b3 of the VIA to select columns, and read back which row is intercepted, which the Beeb handily wires to b4-b6, so you get a 7-bit key number, and b7 as the pressed/no-pressed line.

I did a lot of messing about with keyboard matrix scanning and layout in the '80s, eg link and link, and still fiddle with them now.

All this talk about keyboard decoding hardware reminded me of a chip I bought awhile back for this purpose, the KR9600-PRO. This is a 9 row by 10 column keyboard encoder in a wide DIP-40 package.

Fair point, though I'm not a fan of I2C.

Are there any generic 8-bit parallel interface (6502/6800/8080) to/from I2C or (preferably) SPI parts that anyone can recommend. (Oooh, wouldn't I2C or SPI port pins on a 65c02 chip be nice?)

Neil

An SPI master is usually an add-on IP when designing a custom SoC. Maybe you could make a standalone one with an FPGA. This project purports to implement an SPI master for FPGA-based projects.

I know little to nothing about FPGAs, so I've tended to avoid them. I have considered a discrete hardware approach: how hard can it be?

Neil

I don't like that that's called an "encoder". The output is purely the X*Y matrix address: An "encoder" should output the key matrix encoded into something more useful than the simple matrix address, such as the ASCII character code, as with things such as the AY3-4592 and AY5-3600.