Data General 6246-A

MMcM

04 Apr 2021, 00:48

This keyboard, with FLS switches and tombstone keycaps, is from the D210/D211 terminals. There are pictures in the wiki. There are a couple topics about converting one here and here. In both cases, the existing controller was removed and the matrix wired directly. I thought I would see what could be done with the existing firmware.

The pinout of the DE-9 is given in the user manual.

The keyboard on the D411/D461 terminal has a very similar layout. The connector is round but the pin names are the same, so it may be that the signals are the same.

An outline of the protocol is in the patent.
  • The keyboard provides clock for bit-serial data in both directions.
  • The terminal uses a RESET pulse to (re)start the protocol with the keyboard identifying itself.
  • The keyboard triggers the IRQ line when key state changes but also periodically to give the terminal a chance.
  • The terminal sends LED and buzzer state in its data to the keyboard.
  • The terminal detects a lack of periodic IRQ and starts the RESET sequence until the keyboard is plugged back in.
As for the patentability of this, I believe that there were Canadian keyboards in the '70s that had fixed jumpers on the PCB and exposed on their parallel interface to distinguish French and English layouts. I suppose the novelty of the invention is sending this as key data in a special startup phase.

Some experimentation was required to determine the specifics of how this was implemented.
  • The initial state just from the keyboard / its pullups is RESET high, SI low, SO high, SCLK low, KBIRQ low.
  • RESET is pulled down briefly and SI, SCLK, and KBIRQ go high, which are their idle states.
  • SCLK then clocks 8 bits over SI for an identity of 3 for what seems like the normal American layout.
  • SCLK then periodically -- about every 70ms -- clocks 7F out for no key.
  • KBIRQ then goes low to signal the terminal to pick the shifted data up.
  • SO should ack this by going low itself.
  • SO staying high is a nack / lack of an ack and causes the keyboard byte to be repeated for a while before giving up.
  • SCLK then clocks the LED and buzzer states in.
  • SO should end low and then go idle high again.
  • When there is a key change, 7F is replaced by its code.
Reset sequence:
DG-6246A-RESET.png
DG-6246A-RESET.png (28.21 KiB) Viewed 195 times
Idle key:
DG-6246A-IDLE.png
DG-6246A-IDLE.png (27.59 KiB) Viewed 195 times
Space bar:
DG-6246A-SPACE.png
DG-6246A-SPACE.png (28.85 KiB) Viewed 195 times
The bit mask sent to the keyboard seems to be as follows.
  • 01 standby
  • 02 ALPHA LOCK
  • 04 ON LINE
  • 08 buzzer off
  • 10 F19
  • 80 F20
Here I am using MSB-first order. I don't actually know that this is correct in terms of how the terminal software thought about it, but the key codes do end up looking somewhat more uniform that way.

The default state of the keyboard after reset and before a new setting is loaded is all LEDs lit and the buzzer on. Which I guess makes for a kind of self-test, although it does make the debugging process rather louder than it might otherwise be.

Standby may not actually be a thing. The effect I see is that if the last bit into the keyboard is high, KBIRQ shuts down to low and nothing more happens until a new RESET. So I am guessing an explicit shutdown mode, though it could just be a way of detecting the lack of a terminal (but still getting power?). Anyway, I keep it low.

The key codes represent changes in key state: the same code is repeated when the key is released. This is not as good as having distinguishable break codes and results in stuck keys from time to time, but isn't so bad with an explicit reset that gets things in sync.

As far as I can tell, there is full n-key rollover.
DG-6246-A-converter.jpg
DG-6246-A-converter.jpg (455.15 KiB) Viewed 195 times
A handful of keys on this particular keyboard are not registering. I may need to try to squirt some contact cleaner in or disassemble them; I'd appreciate advice from anyone who has done that. The key codes do not correspond directly to the matrix, so they can't be inferred from that. I imagine that these codes are compatible with some earlier keyboard using the same protocol. The patent mentions a more complicated sensing system than these switches require.

Alternatively, if someone else has an intact keyboard, or if either of the MCUs removed from the earlier conversions was saved by snacksthecat or OldIsNew and is readable -- or I can borrow it to read -- we should be able to fill in the gaps.

4_404

04 Apr 2021, 01:13

MMcM wrote:
04 Apr 2021, 00:48
Alternatively, if someone else has an intact keyboard, or if either of the MCUs removed from the earlier conversions was saved by snacksthecat or OldIsNew and is readable -- or I can borrow it to read -- we should be able to fill in the gaps.
I have also done a controller swap on one of these, and still have the MCU. I can't read it, but if you're interested in it, let me know.

Post Reply

Return to “Workshop”