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