Hardware keyboard

Hi all,

Playing with RiscOS BBC Basic on the Raspberry Pi here, I put the Pi in a case of a defunct home computer (a Commodore C16) and want to try and make the original keyboard functional. So far I have connected the keyboard in a 8 × 8 matrix to the Pi using 16 GPIO lines, 8 as row inputs with pull-up, the other 8 lines are switched to output on a pin-by-pin base to pull a specific column line low. With a small Basic program I can read out which key is pressed.

Next step is to add the keyboard to the OS.

My ideas so far:

Create a small assembler routine which connects to the Ticker Vector to scan the hardware keyboard comparing the state of the keys to a stored former state to detect key press/release.

Questions:

What is the best way to insert the key information into the OS ? (through the Insert Vector using buffer 0?)

The keyboard has a reasonable standard layout but some keys are non-standard and need some kind of translation so my guess is that using keyscancodes is not the best way?

How is key repeat handled by RiscOS ?

Regards,
Gert

One suggestion is to wire all the ‘ALT’ ‘CTRL’ SHIFT etc keys to one line so that the status of these keys can be read, as a byte of flags, by taking that line high (these keys do not auto-repeat). You also need to think about debounce as the switch may not cleanly make and break. Key repeat rate (and delay before repeat) is configurable in RISC OS.

Am I the only one to think that’s a heck of a lot of IO pins just for reading a keyboard?

There is an OS_Byte call to insert bytes (keys) into the buffer.

I think the simplest way to deal with the keys is to indirect into a table. Your keyboard will generate keys, so you take the keypress (say 1, 2, 3, etc across the top row) and use that as an offset into a table giving the desired key code for that key.

That said, it might be better to look at how RISC OS itself handles keyboards as this scheme can be broken easily – just configure the system to use a French keyboard and notice that yours won’t change. I’ll step out here as I don’t have experience with keyboard handlers.

It is indeed a lot of pins but the other option is to use a SPI or I2C IO extender and why would I do that?
The A+ (and B+) have enough pins and this Pi is dedicated to this project.. I still have the UART, SPI and I2C pins left. My test program can succesfully detect all 64 keys, the layout is such that SHIFT, CTRL and Commodore key can be used in combination with the other keys. The shift lock key is a hardware latching switch in parallel to the shift keys.. The whole keyboard matrix is used ‘as is’. Anyway, the pins and reading of the keyboard is no problem.

The Pi board is connected to the original mainboard (TED socket) and sits in the spare room next to the mainboard exposing its HDMI, microUSB and audio connector to the back and the USB port to the side. Video and audio is also routed through the original DIN output on the C16, the modulator tin can has been emptied and the RF output provides CVBS output.

At the moment I am fiddling with a simple keyscan routine which is installed using the CallAfter OS vector but I am struggling with reading the GPIO registers. I setup a translated membase with:

SYS “OS_Memory”,13+(1<<17),&20200000,&100 TO ,,,membase%

and made a small assembler routine to read GPIO levels from that membase% + &34 and membase% + &38 assigning those values to R1 and then try to read into R0 with a LDR R0,[R1]

But I get no meaningful results.. Is the base address &20200000 OK for the Pi A+ ?
It seems to translate to &F6500000 as membase%