ELF Mini-Terminal Video Fix

The ELF mini-terminal developed a rather odd fault. The cursor disappeared and reverse video did not work. The CRT alignment test screen looked odd too. Investigating this issue led me to trace out some of the circuitry of the terminal.

Oscillator and Mode Selection

The 20 MHz crystal-controlled oscillator provides the clock for most of the board. A 74hc258 multiplexer is used to select between 40 and 80 column signals. In 80 column mode, the 20 MHz clock is used directly, which is quite challenging for the logic in use. A lower frequency clock is used in 40 column mode.

 

Inverse Video Logic

The 6845 CRT controller generates a CURSOR signal, which is used to invert the video signal in this case. The character generator is a SAA5055, which is intended for the now obsolete Teletext system. This is somewhat overclocked in 80-column mode, but it seems to cope. This device only uses the lower 7-bits of the RAM data, and the terminal uses the otherwise unused bit 7 to invert the video in the same way as the cursor does. There is a significant delay between RAM read data entering the SAA5055 and the associated RGB output. This requires that the invert signal be similarly delayed so the inverted characters (and the cursor) appear in the correct location. This is the purpose of the chains of flip-flops IC23 and IC28.

 

Video Output

The video supplied to the monitor is taken from the SAA5055 character generator and inverted as required. The red, green and blue signals are mixed with a software-controlled bias (the brightness defined in the terminal setup menu) before being supplied to the monitor.

The fault in this case was IC28, a 74ac374 octal latch. This inhibited the invert video signal, which I called INV_DLY2 in the diagrams above. Fortunately, these devices are still available.

The PCB has only two copper layers. The layout must have been quite a challenge, as of course this includes power and ground. In addition, the pixel clock is 20 MHz in 80-column mode, which is quite challenging for the logic families used. A slightly alarming feature is that the +12 V supply is routed to various places mixed with the logic. A momentary short-circuit could do a lot of damage.

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.

ELF Mini-Terminal

I was given this terminal many years ago, rescued from a skip. I don't think it has been used much in its life. It is is good condition and the CRT appears to have plenty of life in it.

It actually worked as soon as I turned it on, though I did clean it up a bit and adjust the internal monitor controls a little to improve the greyscale. Some switch cleaner is very useful for this sort of thing as it really improves potentiometer operation in old equipment.

I can't find any data on it online, though there is a similar (and I suspect somewhat earlier) model described on the Computing History web site http://www.computinghistory.org.uk/. It supports an impressive number of demonstrations with (presumably) recorded Prestel and other sessions to show off its capabilities. These include 80 column mode and several levels of greyscale. The display is monochrome.

Real Owls Don't Like Acorns!

I do wonder about the page shown above. The text on the bottom right says "Real owls don't like acorns!". Did someone have an issue with Acorn Computers?

Internals

The case is nicely designed, and just four screws allow the monitor section to be hinged out of the way. The power supply then simply lifts out after disconnecting the mains input.

Main PCB

Major devices are:

1. MC6803P microprocessor. This is a member of the then popular 6800 family of 8-bit processors.
2. UM6845EA CRT controller. This generates timings and addresses for the video display.
3. SAA5055 Teletext character generator (U.S. ASCII version).
   
4. SCN2681 dual asynchronous receiver/transmitter, for the line and printer RS-232 ports.
5. CDM6264E3 8K x 8-bit CMOS static RAM.
6. NMC9346N EEPROM, used to store configuration settings.
7. 27256 32K x 8-bit EPROM.
   

Power Supply

The power supply is a conventional switching unit. I imagine it provides +5 V, +12 V and -12 V. A negative supply is required for the RS-232 drivers on the main board.

Monitor Section

The monitor electronics is housed on a neat little PCB mounted underneath the CRT itself.

Terminal With Keyboard and Keypad

I have a numeric keypad as well. Strangely, I can't see a way to connect both. Perhaps for some applications, the keypad is all that is needed.

There is an idea lurking in my mind that could use this terminal, which was really the motivation for blowing the dust off it. More soon, perhaps!