The Sinclair QL Forum

Hi All,

I dug out my old AH, issue 5 Sinclair QL that I wrote an enormous amount of code on "back-in-the-day" and enjoyed. Looking back on it now I can see how things went wrong. Enough about that!

A friend and myself have joked that this would be an interesting demo platform - mostly because it is so unexplored.

Now, My dev machine these days is a MacBook Air and what I want to do is to be able to automate control of the QL.

So far I can see that the only way to completely encompass automation is to hack into the keyboard interface so that I can remotely type into the machine. This would let me type "F1" or "F2" and then type a short basic routine that allocated vis RESPR and then accepted input (I remember that the only hope of decent performance was MCODE). That program could accept more keyboard input or start a process that read the rest of the code from serial port (via a QL->RS232 and an RS232 to USB adapter into my Mac).

So, the keyboard. It seems to be a fairly conventional matrix arrangement of 9 * 11. The keyboard scanning process is, for each row, set the row high and then read the columns to see which bits are set. Eventually one builds up a map of which keys a set and turn that into a keyboard scan code (or KEYROW for the QL).

I figure a USB attached device (PIC or similar) with enough I/O would do the job - however, it's been a LONG time since I hacked any hardware and, TBH, I mostly hacked SW anyway. I would really love some help here. I'm certain I can handle PIC coding and the required state machine but I'm not sure what sort of hardware I will need to take control of the keyboard I/O lines on the QL. The complete circuit would be QL <-> keyboard matrix I/O <-> uController <-> USB <-> Mac.

Anyone have any ideas to help please?

Burnttoy.

This is one of those things that is easier said than done

If you only want to connect to the existing keyboard matrix lines, you need to detect (read) the scan lines (output lines from QL to keyboard), use this info to decide what, if any keyboard input (input lines from keyboard to QL) need to change state. And of course, this needs doing quickly enough that the QL system can reliably read the "key stroke".

So the micro-controller will need lots of I/O pins

Mark

Looking at the issue 5 schematic, for the keyboard matrix you need 8 output lines and 8 input lines (yes there are more on a real keyboard, but these are duplicates).

As long as the existing QL keyboard and joysticks are disconnected, from a hardware point of view, it should be straightforward

Mark

More demos would be great! We already have Marq on the forum who released a small demo here:

http://theqlforum.com/viewtopic.php?f=3&t=304

This guy has done some hardware work in this area that may be useful.

There are some videos there and on youtube that would help too

http://www.deblauweschicht.nl/tinkering/tinkering.html

The keyboard is an 8x8 matrix as described in the details of the KEYROW superbasic function. The actual connections of the membrane have more pins in order to simplify the routing of the lines in the membrane.
In principle there are 2 ways hardware can be implemented to emulate a keyboard. One is to use a microcontroller to detect row activation by the IPC on an input port, and then, based on the state of the keys in that row, gathered from some other keyboard or keyboard interface, generate the appropriate response on an output port. The problem here is doing it quickly enough - basically, the IPC code that does this is a port write, followed by a port read, so there isn't much time for the emulation microcontroller to detect what the IPC wants, look it up and give it to it, especially if it has to manage another keyboard interface at the same time. That being said, today's small microcontrollers can run dozens of instructions in the same time it takes the IPC to run a single one.
The other possibilty is to use a crosspoint switch chip or simulate one using dual-port memory. This sort of chip actually implements a N x N matrix of switches which can be individually turned on or off through an interface of some sort, that usually looks like a IO port or a set of memory locations or registers. A dual port memory behaves in a similar fashion, in this case it would be an 8-byte RAM which can be accessed simultaneously on two sides - on one side by the IPC, on the other by the emulating microcontroller. In this case, the latter receives keypresses from some other keyboard or keyboard interface, translates them to the corresponding QL keys, and activates the corresponding switch in the crosspoint switch chip or sets the corresponding bit in the dual port RAM.
In principle the crosspoint switch system is the most flexible - for instance, it's possible (though the normal version of the IPC does not use this as far as I know) to select all key rows simultaneously to check wether any key is pressed, and if so, then determine which one(s). This will not work properly with a dual port RAM system, as it can only select one row at a time (like normal RAM, dualport RAM can only read or write one address at a time and since each row corresponds to one address, selecting all rows would mean a simultaneous read of 8 addresses in the RAM).
Analog Devices makes a number of crosspoint switch chips, ADG1288 look interesting. It's a full 8x8 analog switch array, controlled by an I2C port. Since most keyboard interfaces operate by sending codes for key press/release, these can simply be translated into crosspoint switch on/off, without the IPC ever knowing it's not working with a membrane...

What is your goal in automating the keyboard (other than it being a fun project )?