ELF Mini-Terminal Keyboard Debouncing Fix

Though the terminal described in a previous post does work, it suffered frequent keyboard bounce. This means that when you press a key, instead of one character begin generated the terminal will likely generate two (or perhaps even more). This is quite irritating. The most likely issue especially considering the age of the terminal seemed to be that the key switch contacts require cleaning. The real issue turned out to be quite different, however. After dismantling the keyboard and removing the cover from the main unit I noted the following:

• The keyboard CPU is marked “AMI 8729MAJ S6803P”. The associated EPROM is a 2716. If 8729 is a date code, it is likely the 29^th week of 1987.
• The main board CPU is marked (Motorola) “MC6808P KC78795”. The associated EPROM is a 27256.
  

Both processors are variants of the once very popular Motorola 6800 series, described here: https://en.wikipedia.org/wiki/Motorola_6800. I have come across these before, and like the architecture. I dumped both EPROMs, as if the data for either were lost that is likely to be the end for this unusual terminal. Curiosity overcame me and I had a look at the contents.

 

Keyboard EPROM Contents

The CPU has various memory mapping modes selected by external pins. In this case, the mode is hardwired to 2, so the internal RAM is available and the ROM is external. Motorola called this an "Expanded Multiplexed Mode". I ran the code through Jeff Tranter's very useful "udis" disassembler, a "Universal Disassembler program for 8-bit microprocessors" (https://github.com/jefftranter/udis). The first few instructions are:

F800 .org $F800
;
; Reset
F800 00        .byte $00        ; Undefined?
F801 C0
F802 97        staa $14 [RAM / EPROM control]
F804 8E 00 FF  lds #$00FF       ; Setup stack
;
; Clear RAM (0xff81 + 0xff = 0x0080) to (0xffff + 0xff = 0x00fe)
F807 CE FF 81  ldx #$FF81
F80A 6F FF     clr $FF,x
F80C 08        inx
F80D 26 FB     bne $F80A        ; Loop until complete

There is something odd about this code. The very first instruction is a 0x00, which is undefined, even considering the extra instructions implemented on the 6803. Examining the main board firmware in the same way reveals the following initial instructions:

; Reset
B395 8E 7F FF  lds #$7FFF       ; Setup stack
B398 86 C0     ldaa #$C0
B39A 97 14     staa $14 [RAM / EPROM control]
B39C CE 00 80  ldx #$0080

The sequence "ldaa #$C0 / staa $14" is similar here, but with an 0x86 (ldaa - "load accumulator A") instead of 0x00. Is the keyboard firmware corrupt? Bear in mind that the CPUs are subtly different, albeit from the same family. I looked inside the keypad. but it uses a completely different approach. It has a no microprocessor, but uses discrete logic and a ROM to generate the appropriate codes. This is unfortunate, as I was hoping to compare the firmware with that of the keyboard.

Examining and commenting the rest of the keyboard code (approximately 370 bytes) revealed no further mysteries, and showed that keyboard debouncing was considered by whoever wrote it. It also revealed that the keyboard emits ASCII codes for almost every key, so there is no need for key code conversion by the main microprocessor. Other codes are used for keys that have no associated code, such as "Setup".

I patched the code so the first byte is a 0x86. The first two instructions now read:

F800 86 C0     ldaa #$C0
F802 97        staa $14 [RAM / EPROM control]

This makes  more sense. My programmer doesn’t seem to work with the 2732 EPROMs. It did seem fine with a Microchip 27C64, though. I programmed that with the 2K image replicated four times. The keyboard has obviously been designed with larger EPROMs in mind, so I didn't have to modify the board.

It works! The key bouncing issue is now resolved. I really didn't expect that. This sort of issue is easy to create when copying EPROMs if you happen to inadvertently edit the data in the programmer. I wonder if that is what happened here. It would seem strange that a hardware failure would result in just the first location being corrupt. I wonder how may other ELF terminals had the same issue.

I noted that VCC at the keyboard is just 4.41 V. That’s very low, and is caused by voltage drop in the thin, flexible coiled cable. It does seem to work, though, and I can't see an easy way of fixing this in a reasonably tidy manner.

Main Board EPROM Contents

I did disassemble the main code using the same disassembler, but didn't spend very long looking at it. The bulk of the space is used occupied by the demonstration pages.