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.

Sennheiser EW100 G2 Repair

We use these Lavalier microphone transmitters with the PA in my local church. They are generally well constructed, and I have not had to open one until recently. The plug-in microphones do suffer, however, and I have to re-wire the microphone itself or connector about once a year. New ones don't fare much better than my repaired ones, so I seem to be doing a reasonable job.

 

Sennheiser EW100 G2

This transmitter failed completely, which is a first despite years of use. Disassembly revealed a very compact design, and an obvious issue. A power inductor had broken, so I suspect the transmitter had been dropped onto a hard surface. Finding a replacement was tricky, as I had to match not only the electrical characteristics, but also the replacement had to fit in the limited space available. After examining the wreckage and the datasheet for the associated boost regulator IC, I selected an EPCOS B82472P6223M000 (22 uH +/-20% 1.45A) part as a good match. Replacement was straightforward.

Inductor Replaced (top centre of PCB)

The inductor is the black square component at the top centre of the PCB. The associated regulator IC is on the underside.

The Inductor Shouldn't Look Like This!

After replacement and reassembly, everything worked as it should. The output signal is clearly visible using a FUNcube Pro+ receiver, which I find very handy for testing radio-related things.

Transmitted Signal

The main purpose of this post is to make life easier for anyone trying to repair one of these or a similar unit. I did see an advertisement offering replacement inductors at vastly inflated prices. I declined the offer, but it does imply that this is a known issue with these units.

 

Telex Model 530 Cordless Headphone

I look after the PA for my local church. As with most such systems, it includes an inductive loop system. This is fundamentally quite simple, and consists of a single long turn of wire around the inside wall of the church driven by an amplifier. The amplifier contains an aggressive automatic level control (AGC), and attempts to maintain a constant drive level over a wide range of signal levels. A suitably configured hearing aid will receive this signal and deliver it to the listener without unwanted acoustic interference. One issue is that unless you have a suitable aid, it is not easy to tell whether the loop is working or not. Some decades ago, a "Telex Model 530 Cordless Headphone" was purchased. This is a headset with a loop receiver and amplifier built in. It is many years since this was last used and nobody seemed to know much about it. I did find this catalogue entry - from 1989!

Telex 1989 Catalogue Page

Removing the pads from the earphones reveals a battery compartment. Unfortunately, I can find no reference to what battery it requires. Several batteries and cells would physically fit in the holder. The required item would be approximately 12 mm diameter and 28 mm long. This isn't much help, as after some research I concluded that the voltage could be 1.5, 3.6, 7.5 or 12 V! Telex do still exist, but I an not confident that I would receive much help for such an old product. Dismantling revealed the following:

Disassembly

 

Please ignore the glue stick, used to prop the headset apart! The circuit is very simple.

Schematic

Ignore the "12 V" marked by the battery as this was my initial guess based on dimensions. The circuit seems to operate nicely from anything above about 2 V, but was prone to oscillation. The IC is marked "MCC-2637632", but I could not find any information on it. The single electrolytic capacitor is fine in both value and ESR, so I left it alone. The preset potentiometer sets the bias level. I was surprised by the lack of supply decoupling, especially considering the cable run from one side of the headset (with the battery) to the other (with the amplifier). Adding a 100 μF capacitor between pins 2 and 4 of the IC made it stable. In the end, I opted to add a micro USB socket on a cable and wired it across the battery holder contacts. This allows the amplifier to be powered from any convenient USB battery pack. Given the low current consumption (a few mA), it would last very many hours powered this way.

I tried this in the church. It is possible to reduce the PA loudspeaker amplifier drive signals to zero and play music through the loop amplifier only. This allows me to investigate the effectiveness of the loop in various areas without having to contend with audio through both the speakers and headset. It loop really is very effective, with only a few small dead spots.

Greedy Gulch

Greedy Gulch is a text adventure game written by Mike Farley for the ZX81. It was published by Phipps Associates in 1982. Graphics are minimal, being limited to simple maps. The code appears to be entirely in BASIC, and leaves little unused space in the 16 KB RAM on this machine.

I remember playing this in the 1980s on my ZX81, but never completed it. I seem to remember not being able to cut some long poles into short ones, but it was a very long time ago.

Greedy Gulch on ZARC

 

During the COVID-19 plague lockdown, I wrote a passable ZX81 emulator on a custom Z80 system that I call ZARC. The display appears on a terminal emulator (minicom). If you are familiar with the ZX81, the display will look a bit odd. Yes, there are much easier ways of running ZX81 games but I wanted to do it this way! I recently got around to actually playing the game again. There are certainly some tricky parts. It is very easy to get lost in the desert, for example. There is a map to show you how to find the mine from the town, but unfortunately reversing the directions does not return to you the town. I did eventually work out a route by leaving items at locations in the desert so I could tell them apart. Without this, you can't tell where you are as the descriptions are identical!

It seems that the poles can only be cut in one specific location, which is possibly what had me stumped before. Without cut poles, the mine roof collapses and that is the end of the game. It turns out that I was very close to completing the game, though I had no way of knowing that at the time.

Completed - not much of a fanfare!

You can save progress by entering the STOP keyword in place of the input string (delete the quotation marks first). Then SAVE "<filename>" to save the entire programme with your current progress. After loading it (LOAD "<filename>"), enter CONT to continue. Do not RUN as this will clear the variables, which are required for the programme to operate.

Maps

You may wish to ignore this part if you want to explore on your own. These maps are quite rough, but do give the general idea. Some paths are reversible, and others not. Beware.

Main Map

It is easy to become lost in the desert. Zeek's map shows the way, repeated for convenience here. Don't forget to fill the water bottle before you leave.

Zeek's Map

The return journey is trickier, and took some time to work out. The initial direction of the arrows shows you the direction in which you should move.

Return Map

Manson EP-603 Power Supply

I bought a cheap "laboratory" power supply some time ago, one of these: https://www.manson.com.hk/product/ep-603/.

Manson EP-603 Power Supply

 

It is quite handy, but the ammeter has never worked and I decided to have a look. I can’t find a schematic for this particular model, though I did find some similar ones. The "BK Lab Power Supply Schematic 1670A_1671A_schem.pdf" seems identical. You should be able to find this easily online. All major semiconductors match, at least.

Interesting features include:

1. The +12V and +5V outputs are isolated from each other and the main output, which is handy and a surprise.
2. The regulators are all linear.
3. A relay is used to switch taps on the secondary winding for the main output, thereby allowing a modicum of efficiency over the output voltage range.
   
4. If you have to dissemble one of these, there are two hidden screws each side of the fixed output terminals. These may be accessed though holes in the PCB. It is wise to unsolder the meter terminals before removing the PCB.

The ammeter issue was due to bad soldering on the meter terminals. Now it is fine, and the meter calibration is about right. Despite this issue, the supply has not given me any other trouble and I do think it is reasonable value for money.

 

Internals

I took a few photographs while I had it apart. These may be useful if you come across a similar model. Click on the images for a more detailed view.

 

Front Panel PCB

Front Panel PCB (Reverse)

Heatsink Assembly

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!