The Sinclair QL Forum

OK, I'll scan it. To get all the detail it'll probably be too big for forum so I'll email or dump it somewhere.

I was hoping to add a different keybaord, so I did all the key tables (from EPROM dump). But the tin foil thing seemed worth a try first, it worked with the membrane switches on a Yamaha synth.

BTW, George where did you get info from ? (I did it the hard way and concur with description), there is no link from footnote [1]

Silvester wrote:BTW, George where did you get info from ? (I did it the hard way and concur with description), there is no link from footnote [1]

Hello Silvester,

footnote 1 referred to the photos at ebay (item #154371862956).

It's all guessing: As IC24 (8049) of a QL reads the "bus" and pulls only one line of port 1 high at a time while scanning the keyboard, there are not too many ways to use a 74LS148 and 8 kilobytes of (EP)ROM to "fake" a keyboard matrix. – I am not sure: The two 74HC14s may be used instead of two 74LS04s to not only invert the 74LS148's input lines, but also (unsuccessfully) to "debounce" the resulting ROM codes, and a few (two?) of the ROM's address lines may reflect the state of modifier keys or different keyboard layouts. The two transistors suggest an open collector clock/data keyboard protocol is used, and so on. – Your circuit diagram and EPROM dump will be very appreciated.

George

THe Schön PC keyboard did not have any bounce problems. In addition, there were Corsor keys, which worked diagonally at the keypad.

Here are the scans of what I did back in 2009 on the Schon PC keyboard and interface. Hope they are of use in reviving/repairing or for curious interest.

Like several long term projects I have running (don't we all?), I still have to get around to resolving three issues with the original design:

First is the DEL LINE key bug, hitting it emits code 195 (ALT CTRL left arrow) followed by a hanging 255 (ALT), so the next key hit is sent as ALT + key hit. AFAIK this wasn't a documented feature (to what end?).

Second is the silly '_' single underscore key. Intuitively I always hold SHIFT for underscore, but more annoyingly you don't get '-' minus key unshifted, having to resort to using the NUMPAD '-' whenever needed.

Third is the F11 and F12 keys which just emit SHIFT F1 and F2 (replicating F6 and F7), could be reassigned to something more useful.

But on the positve side, the NUMPAD 'Recall' key usefully emits ALT+ENTER, and 'Stuff' key emits ALT+SPACE.

---

David

Interesting circuit - looks like the 8049 in the picture is just the normal IPC - so replacing this with a Hermes chip would presumably be possible.

The Eprom's data lines feed the row inputs to the IPC and the address lines are provided by the 8749 chip and the 148 chip - the 148 device and the inverters are just providing a decode of the current scanned keyboard column - so an 8 to 3 encoder - this provide 3 addresses for the lookup table in the ROM. The 8749 reads the plugged in keyboard, and outputs 9 bits of address for the ROM lookup table.

So the QL IPC would read the virtual key matrix that's effectively created in the ROM - with the main lookup code being provided by the keyboard reader on the interface. It's scan code is effectively used to provide a map - the selection of which map is being done by the QL IPC. Any non valid key combinations would just return 'no key pressed' to the QL.

Let's assume you pressed the J key on the keyboard - that would provide a certain scan code which is fed to the ROM. For all but the QL column which actually has the J in it, the ROM would provide 'no key pressed' data to the row input of the IPC, then when column that has the J key in is selected, the ROM returns the correct ROW data for a J Key.

Thanks Silvester

Pr0f wrote:Interesting circuit - looks like the 8049 in the picture is just the normal IPC - so replacing this with a Hermes chip would presumably be possible.

I agree. The circuit only makes sense re-using (see post #40171) the QL's IC24 (8049, see post #40433), thus using a Hermes 8749 should be possible.

Pr0f wrote:The Eprom's data lines feed the row inputs to the IPC and the address lines are provided by the 8749 chip and the 148 chip - the 148 device and the inverters are just providing a decode of the current scanned keyboard column - so an 8 to 3 encoder - this provide 3 addresses for the lookup table in the ROM. The 8749 reads the plugged in keyboard, and outputs 9 bits of address for the ROM lookup table.

So the QL IPC would read the virtual key matrix that's effectively created in the ROM - with the main lookup code being provided by the keyboard reader on the interface. It's scan code is effectively used to provide a map - the selection of which map is being done by the QL IPC. Any non valid key combinations would just return 'no key pressed' to the QL.

I also agree to this (see posts #40171 and #40433), and I think Silvester (David) would also concur with your description (see post #40432).

Pr0f wrote:Let's assume you pressed the J key on the keyboard - that would provide a certain scan code which is fed to the ROM. For all but the QL column which actually has the J in it, the ROM would provide 'no key pressed' data to the row input of the IPC, then when column that has the J key in is selected, the ROM returns the correct ROW data for a J Key.

The file "keytab0.jpg" in David's zip file "Schon_tab.zip" confirms this. You can see that the key "J" is represented at address 0b0arrrcs100010 of the EPROM (with rrr for the keyboard row address encoded by the 74LS148, a=1 for an active "alt" key, c for "ctrl", and "s" for "shift"). As the data representing the "J" key must only be active while KBO4 (P14 of IC24) is high, and the file "INTsched.jpg" (in "Schon_sch.zip") points out that this port line is encoded by the 74LS148 for EPROM's address lines A10, A9, and A8 as 0b011, we should read the "J" data at addresses 0b0x011xx100010 (because the state of "alt"/A11, "ctrl"/A7, and "shift"/A6 which are scanned by KBO7/P17 don't care), and data at addresses 0b0xrrrxx100010 must represent "no key pressed" (zero) for rrr=(001,010,100,101,110,111) or representing the state of "alt", "ctrl, and "shift" for rrr=000 – a high level on KBO7/P17).

The EPROM dump ("KBD_485A.bin" in "Schon_tab.zip") confirms that data at addresses 0x0322, 0x0342, 0x0382, 0x03C2, 0x0B22, 0x0B42, 0x0B82, and 0x0BC2 is 0x80, and is 0x00 at addresses 0x0122, 0x142, and so on. EPROM data 0x80 will be read by IC24 as "KBI7 is high" which is the case while KBO4 is high and the key "J" (connecting KBO4 and KBI7 in the QL's keyboard matrix) is hold down.

@David: Thank you very much for uploading your meaningful and informative documentation. I analyzed your EPROM dump using the QL's keyboard matrix documentation and can confirms what you've written in "keytab0.jpg": The lines A5...A0 are addressing the codes (from 0x01 to 0x3D) for ESC 1 2 3 4 5 6 7 8 9 0 - = TAB Q W E R T Y U I O P [ ] £ A S D F G H J K L ; ' ENTER \ Z X C V B N M , . / SPACE CAPSLOCK F1 F2 F3 F4 F5 UP LEFT RIGHT DOWN (and no key for 0x00, 0x3E, and 0x3F). As far as I can see, A11, A7, and A6 are simply representing the states of "alt", "ctrl", and "shift". (And if I am not wrong, there is an error at address 0x08B0 containing 0x96 instead of 0x86.) Thanks to your file "Schon_sch.zip", we know that address lines A10/A9/A8 represent a high level on (in that order) KBO7, KBO6, KBO5, KBO4, KBO0, KBO1, KBO2, and KBO3.

@Ralf: Thank you (sorry, nothing's bouncing): Your hint ("cursor keys which worked diagonally") tells us why we see extra data at addresses 0x150x whereas there are zeros at all other EPROM addresses with A12=1: When KBO1 is high (A10/A9/A8=0b101), the 8749 pulls A11, A7, and A6 low (maybe "alt", "ctrl, and "shift" should not be held down) and selects EPROM addresses 0x1502, 0x1504, 0x1508, and 0x150A where two data bits are "1" representing simultaneously active left-down, right-down, left-up, and right-up arrow keys (0x150A to 0x150D containing codes for the up, left, right, and down arrow keys).

I have not looked into the files showing the external keyboard schematics and key codes intensively. I was wrong guessing that an open collector clock/data protocol is used (see post #40433). At least the "cheap" design avoids a third keyboard controller IC, but I do not want to see the 8749 program code activating more than one LED at a time. (What is going on there? Time multiplexing P26 and P27? I do want to see the code.)

George