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.
Keyboard Hacking/Automation
- 1024MAK
- Super Gold Card
- Posts: 592
- Joined: Sun Dec 11, 2011 1:16 am
- Location: Looking forward to summer in Somerset, UK...
Re: Keyboard Hacking/Automation
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
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
Standby alert
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
- 1024MAK
- Super Gold Card
- Posts: 592
- Joined: Sun Dec 11, 2011 1:16 am
- Location: Looking forward to summer in Somerset, UK...
Re: Keyboard Hacking/Automation
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
As long as the existing QL keyboard and joysticks are disconnected, from a hardware point of view, it should be straightforward
Mark
Standby alert
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
- vanpeebles
- Commissario Pebbli
- Posts: 2821
- Joined: Sat Nov 20, 2010 7:13 pm
- Location: North East UK
Re: Keyboard Hacking/Automation
More demos would be great! We already have Marq on the forum who released a small demo here:
http://qlforum.co.uk/viewtopic.php?f=3&t=304
http://qlforum.co.uk/viewtopic.php?f=3&t=304
- Mr_Navigator
- QL Fanatic
- Posts: 782
- Joined: Mon Dec 13, 2010 11:17 pm
- Location: UK, Essex
- Contact:
Re: Keyboard Hacking/Automation
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
There are some videos there and on youtube that would help too
http://www.deblauweschicht.nl/tinkering/tinkering.html
-----------------------------------------------------------------------------------
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
Re: Keyboard Hacking/Automation
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...
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...
Re: Keyboard Hacking/Automation
What is your goal in automating the keyboard (other than it being a fun project )?