• Please review our updated Terms and Rules here

Determining keyboard protocol for dumb terminal

Yeah.. I'm sort of on the fence. It's really difficult to sort out the keyboard protocol without a keyboard to study. I may try disassemling the terminal eprom.
 
you can run the firmware with a debugger in mame.
i'm still hoping they are doing more work on the simulation so at least the keyboard protocol is known
 
Ok I de-listed the terminal since you seem pretty interested in figuring this out... and I would still like to find a way to be able to use it. I had planned to use this with terminal a Z80 computer project.

Could you share some links about how to run the firmware in mame with a debugger? I've only used mame to emulate arcade games, never for debugging the roms.

I haven't been able to get the terminal to respond in any meaningful way sending two characters. I tried all of the scan codes that didn't return anything as the first byte, but really got nowhere. Sometimes, it would return a scancode to the keyboard which would last a few keystrokes but I could not get repeatable results so far.

I would post the scancodes I am sending to get the entire alphabet, but they keep changing.

For examping, I sent:

First time around
0x10 -> 6
Second time around
0x10 -> FDX mode changes to BLK mode (?)
Third time around:
0x10 -> B

I haven't been able to figure out which series of keystrokes is changing the character set.
 
Last edited:
Al Kossow said:
could you send some pictures of the wrong keyboard pcb?
Click to expand...
Better photos of wrong but possibly Aspect 2.0 keyboard:

ibb.co

A2-C8-B3-F7-0-B24-4216-BB05-FECF27-B5-C90-D hosted at ImgBB

Image A2-C8-B3-F7-0-B24-4216-BB05-FECF27-B5-C90-D hosted in ImgBB
ibb.co ibb.co
ibb.co

5205-A4-B8-759-E-4417-A259-A11256-B3731-F hosted at ImgBB

Image 5205-A4-B8-759-E-4417-A259-A11256-B3731-F hosted in ImgBB
ibb.co ibb.co
ibb.co

3-FD83060-BB3-E-4368-8-FD8-88757-AE271-AC hosted at ImgBB

Image 3-FD83060-BB3-E-4368-8-FD8-88757-AE271-AC hosted in ImgBB
ibb.co ibb.co
ibb.co

8-A40-DCE8-4-DB8-4-DBD-9-EFB-91866-C7-CE8-BE hosted at ImgBB

Image 8-A40-DCE8-4-DB8-4-DBD-9-EFB-91866-C7-CE8-BE hosted in ImgBB
ibb.co ibb.co
ibb.co

572-D1-FFB-725-A-4-B85-A941-ECB071906-C9-D hosted at ImgBB

Image 572-D1-FFB-725-A-4-B85-A941-ECB071906-C9-D hosted in ImgBB
ibb.co ibb.co
ibb.co

3536090-A-FFCA-43-B9-8883-EABBD3-B819-FE hosted at ImgBB

Image 3536090-A-FFCA-43-B9-8883-EABBD3-B819-FE hosted in ImgBB
ibb.co ibb.co
ibb.co

FADA63-AD-CA85-42-F5-A4-C1-0-B2-D71572-FED hosted at ImgBB

Image FADA63-AD-CA85-42-F5-A4-C1-0-B2-D71572-FED hosted in ImgBB
ibb.co ibb.co
 
I had an idea, I'm going to watch the keyboard RX line with the oscilloscope. Maybe I can figure out what the serial signal looks like coming from the terminal. Number of bytes and data length, etc. Might help determine what it expects.
 
This is what the terminal sends to the keyboard on power up:
0x00
0x02
0x06
0x04
0x07
0x01
0x0b
0x0a
0x08
0x04
0x08
0x02
0x0e
0x08
0x02
0x0f
0x00
 
Last edited:
Chuck(G) said:
So the system is sending only 4 bits per byte. Hmmmmm. I wonder if the reverse is true; the keyboard sends 2 4 bit-of-8 per keystroke...
Click to expand...
That is a good observation. The scan codes which worked however all used more than 4 bits (many had 0000 for the least significant bits).

Character produced on the terminal is on the left, scan code (base 10) on the right. Not set in stone, they change each time something changes the keyboard type or language. I was hoping to see a bit pattern which represented shift for the uppercase letters, but I do not see a pattern unfortunately. I'm starting to think it's expecting something other than 8 bit bytes.

a = {'AUX_OFF':58, 'CLR':61, '0':7, '1':118, '2':16, '3':32, '4':102, '5':64, '6':80, '7':86, '8':112, '9':1, 'a':35, 'b':116, 'c':84, 'd':67, 'e':34, 'f':83, 'g':99, 'h':115, 'i':114, 'j':4, 'k':20, 'l':36, 'm':21, 'n':5, 'o':3, 'p':19, 'q':2, 'r':50, 's':51, 't':66, 'w':18, 'x':68, 'y':82, 'z':52, '\"':57, ',':81, ',':44, '|':6, '.':8, '-':9, '=':37, '`':15, ';':49, '<':43, 'A':6, 'B':28, 'P':24, }
 
weird.. it has a 5v regulator. that actually looks like a good quality keyboard with cherry switches. I don't know how much you'd want to mess with it, but dumping the microcontroller as an 8749 would be interesting
 
Al Kossow said:
weird.. it has a 5v regulator. that actually looks like a good quality keyboard with cherry switches. I don't know how much you'd want to mess with it, but dumping the microcontroller as an 8749 would be interesting
Click to expand...
You can do that?? I thought microcontroller rom was protected from being addressed externally?

Edit: OK, Found info here:
qemulator.blogspot.com

Dumping Intel 8049 ROMs

In addition to the Motorola 68008, the QL has a second processor, named by Sinclair the "Intelligent Peripheral Controller" (IPC). The sec...
qemulator.blogspot.com qemulator.blogspot.com

I will absolutely try it if it's possible, I buy and repair vintage computer stuff to learn more about electronics this one has been an interesting challenge.

What I expected was a keyboard in need of repair, not a keyboard in need of repair which turned out to be the wrong keyboard entirely and terminal needing to be reverse engineered. I've learned a lot already just from the help I've received from you and others in this thread. Thank you for taking the time to help, I'd have probably given up on it by now without your interest driving me on.

It has black linear switches. I did briefly try connecting the keyboard's data out to the serial in pin of the terminal but only got a garbage character now and then, so definitely not compatible unless maybe I could combine the clock and data to get a true serial data stream for the terminal.
 
Last edited:
I figured out the protocol for the "Version 2.0" keyboard. It doesn't appear to match what I brute forced with the terminal but it might lead me in the right direction.

Start bit which is always high, then starting LSB first, 7 data bits, followed by the "KEY RELEASE" bit. All standard keys just repeat, there is no key release bit set when released, but special keys such as CAPS, SHIFT, CTRL, etc, do not send repeats, but instead send a scancode with with last bit high when released. The scan code is the same as the key down scan code, but with last bit set high.

I confirmed this by analyzing the number keys, they increment sequentially in binary, bits set LSB first. Scancode shown is for number 1, which is 0x02.

It will be easier to map the scancodes this way than to dump the rom from the MC. If I can figure out the correct scancodes for the terminal I can write a simple conversion program for the arduino and stick it inside the keyboard, or build a little adapter box.
 

Attachments

  • IMG_5723.jpg
    IMG_5723.jpg
    133.7 KB · Views: 4
Last edited:
Not unlike the IBM iPoint wireless keyboard. A little more complicated, but basically, bit 7 set for make, clear for break, repeat is done by sending a special "repeat last key" code with the addition of some special codes, such as "all keys up" (probably needed for a wireless keyboard, since codes can get lost). 1200N81 using a 38KHz carrier. A "blue pill" serves to translate to PS/2 scan codes and appear like a PS/2 interface keyboard.
 
ASCII 2.0 Keyboard output (using DATA + CLK), this keyboard does not work with the terminal, but I am hoping the scancodes are similar:

Data format:

S01234567

S - Start Bit always high
0 - 6 Character Data bits
7 - Key Release Bit, high on release only for Ctrl, Function, Shift, Caps Lock, Setup, Break (these keys do not repeat)

No parity bit or stop bit

All other keys held down repeat scan code, speed controlled by keyboard.

F1 - 0x01
F2 - 0x3B
F3 - 0x3C
F4 - 0x3D
F5 - 0x3E
F6 - 0x3F
F7 - 0x40
F8 - 0x41
F9 - 0x42
F10 - 0x43
F11 - 0x44
F12 - 0x57
F13 - 0x33
F14 - 0x6A
F15 - 0x25
F16 - 0x5D
SETUP - 0x37
BRK - 0x4A
ESC - 0x19
1 - 0x02
2 - 0x03
3 - 0x04
4 - 0x05
5 - 0x06
6 - 0x07
7 - 0x08
8 - 0x09
9 - 0x0A
0 - 0x0B
- - 0x0C
= - 0x0D
BACKSPACE - 0x0E
DEL - 0x64
TAB - 0x0F
Q - 0x10
W - 0x11
E - 0x12
R - 0x13
T - 0x14
Y - 0x15
U - 0x16
I - 0x17
O - 0x18
P - 0x19
[ - 0x1A
] - 0x1B
` - 0x2B
PRINT SCR - 0xDB
CTRL - 0x1D
A - 0x1E
S - 0x1F
D - 0x20
F - 0x21
G - 0x22
H - 0x23
J - 0x24
K - 0x25
L - 0x26
; - 0x27
' - 0x28
ENTER - 0x1C
PREV - 0x6B
FUNC - 0x38
LEFT SHIFT - 0x2A
Z - 0x2C
X - 0x2D
C - 0x2E
V - 0x2F
B - 0x30
N - 0x31
M - 0x32
, - 0x79
. - 0x34
/ - 0x35
RIGHT SHIFT - 0x36
UP - 0x59
HOME - 0x6C
CAPS LOCK - 0x3A
SPACE - 0x39
\ - 0x62
LEFT ARROW - 0x5A
DOWN ARROW - 0x5B
RIGHT ARROW - 0x5C
LINE INSERT - 0x6F
LINE DEL - 0x70
SCRN CLR - 0x71
INS REPL - 0x72
NUM 7 - 0x47
NUM 8 - 0x48
NUM 9 - 0x49
NUM - - 0x7A
NUM 4 - 0x4B
NUM 5 - 0x4C
NUM 6 - 0x4D
NUM + - 0x4E
NUM 1 - 0x4F
NUM 2 - 0x50
NUM 3 - 0x51
NUM ENTER - 0x3F
NUM 0 - 0x52
NUM . - 0x53
 
Last edited:
In async mode, isn't the start bit always high (i.e. "space" level)? Else how would the start of a character be recognized?

Also, you need a "stop" bit to space the end of one character to the start of the next. It's not a real bit as such, just a given period of idle time. That's why, for example, 1.5 stop bits is an option.

Perhaps I'm misunderstanding.
 
Chuck(G) said:
In async mode, isn't the start bit always high (i.e. "space" level)? Else how would the start of a character be recognized?

Perhaps I'm misunderstanding.
Click to expand...
I don't know, but I did find this image of RS232 protocol framing.

This keyboard protocol is synchronous, similar to PS2, but the terminal is supposed to be using an older async serial keyboard.
 

Attachments

  • Screen Shot 2022-03-08 at 12.50.47 AM.png
    Screen Shot 2022-03-08 at 12.50.47 AM.png
    123.4 KB · Views: 3
You must log in or register to reply here.
Back
Top