Replacing The Broken Microprocessor in a Telefunken RT200

Introduction

The root of this project is one of my collecting passions, Telefunken Hifi components built in the late 70s/early 80s. The RT200 is an FM/AM Tuner with a built-in timer clock, i.e. you may use it to switch other devices on and off at preprogrammed times. Typically, those were the cassette deck and/or amplifier, either to wake yourself in the morning with a sound quality better than any alarm radio clock or make unattended recordings of radio programs.

I bought this RT200 for a few bucks at a flea market. Normally, there are few things in a synthesizer-based digital tuner that can break: no movable parts except for the buttons, no lamps to burn out, just a NiCd accumulator that may start to leak after a couple of years of operation. This RT200 however was perfectly dead: plug it in and you won't get any reaction to key presses, just a few cryptic symbols on the display.

Checking the parts that are usually broken in such a case (power supply, clock generator) revealed nothing, so it was clear that the central microprocessor chip had passed away. A truly uncommon event, so I guess this happened due to incompetent repair attempts by the previous owner.

Contents

Some Reverse Engineering

Selecting a Microprocessor Platform

• Must be available in CMOS, to allow operation from the built-in accumulator for power failures or for times when the tuner is not connected to a mains supply.
• Must be able to run with the slow 562.5kHz clock supplied by the synthesizer chip. Of course we could add an own oscillator, but I already said that there is no need for much compute power and the low clock helps keeping the power consumption low.
• Must be available without problems. Not yet another obscure chip ;-)
• Development tools must be available for free at best...

The other stuff around the CPU is pretty basic: an address latch to demultiplex address and data lines, an EPROM for the code (the C32's internal RAM of 256 bytes is sufficient for this task), and some latches and bus drivers for additional parallel I/O: since the external memory interface eats a lot of I/O lines, an I/O expansion is necessary in some way. I could have used one of the more modern x51 variants with built-in flash EPROM and thereby get most of the processor's pins as I/O, but as I already mentioned, I have a strong preference for components that are not single-sourced.

The whole circuitry is built on a prototype card and wired with thin isolated copper wires, a popular method for prototypes. Needs a bit patience and requires accuracy...the connection to the tuner's mainboard is done via a ribbon cable with a crimped plug on one end and an IC socket on the mainboard; of course, I had to unsolder the broken processor and replace it with a socket. The DIL connector is in my case a simple IC socket with the cable soldered onto it wire by wire; there are however also crimpable connectors available for this end.

Basic Layout of the Software

Initialization

Interrupt Routines

The first process runs at about 400 interrupts per second and is used to drive the flourescent display and read the keyboard matrix. As with most consumer electronics, the RT200's display is a 'dumb' display that does not the refresh by itself, so the processor has to do the multiplexing itself. It works in the following way: Initially, the CPU outputs the data for the leftmost digit to the SEGMENT OUT pins and pulls the DIGIT OUT 0 line low while DIGIT OUT 1..4 remain high; this way, the contents of the leftmost digit are displayed at the correct place. In the next cycle (==interrupt), the first digit is turned off, the data for the second digit outputted, and the second digit is turned on. This process continues until the last digit is done, and we jump back to the first digit. So at any point of time, only one digit is on, but if this done fast enough, you get the impression of a still display. Similar to a computer monitor, about 60..70 complete cycles are needed per second for a flicker-free display, which results in the interrupt frequency mentioned above for 6 digits.

The other regular process is an interrupt service routine triggered by the precise 250Hz delivered by the synthesizer chip. This clock is used to run a real-time clock needed for the time display and timer functionality. For each interrupt, a byte in memory is incremented. As soon as its value reaches 250, the seconds value is incremented. The rest should be clear ;-)

Since the keyboard matrix and display share their row select, is is only natuaral that the process mentioned first also scans the keyboard. If one row of the matrix is pulled low, any key that is pressed and connected to that row will generate a low level on the keyboard scan lines. The scanned values are stored in 6 consecutive memory cells, resulting in an image of the keyboard matrix stored in memory that gets updated regularly. The x51 family allows to assign either a low or a high priority to each interrupt source. In our case, the keyboard/display multiplexer gets a high priority, while the clock update process works with the standard (low) priority. This is necessary to allow the multiplexer to interrupt a running clock service routine. Especially when one or more counter(s) roll over, the clock update consumes more time and can significantly delay the next multiplex cycle (don't forget we have a rather slow 8032!) and result in a visible sort of 'flicker' resulting from some segments being turned on longer than others and therefore seeming to be brighter.

Main Loop

• Timer On: Normal tuner operation, timer function enabled;
• Timer Off: Normal tuner operation, timer function disabled;
• Timer Set: (Re)program timer settings;
• Timer Check: Recall/display timer settings;
• Timer Cancel: Erase timer settings;
• Clock Set: Set the timer's clock.

The Timer Section

Programming the Synthesizer Chip

The synthesizer chip generates a variable frequency with a tunable oscillator whose frequency is divided and compared to a given reference clock. The difference signal is fed back to the oscillator's tuning circuitry. As soon as the oscillator is 'in tune' (i.e. the regulator doesn't have to correct any more), the oscillator outputs a frequency that is the reference clock multiplied by the divisor. So if we make the divisor programmable, we have an oscillator with a programmable frequency!

In case of the RT200, a Matsushita MN6147 is used that contains the reference oscillator, frequency comparator/regulator, and the programmable divider. The oscillator is an LC-circuit inside the RF frontend that contains a Varicap diode. A Varicap is a diode that operates in blocked direction and varies its parasitic capacitance according to a DC voltage applied to it.

From the schematic, we get the MN6147's pinout:

Pin No.	Name	Direction	Function
1	Vss	----	Ground
2	OSC OUT	Output	Goes high if PLL has locked
3	OSC1	----	Connect to 4.5 MHz crystal
4	OSC2	----	"
5	CLOCK1	Output	562.5 kHz clock for CPU
6	CLOCK2	Output	250 kHz clock for CPU timer
7	VCC CLOCK	----	+5V supply
8	PD OUT	Output	Output of Varicap voltage
			(externally amplified with 741 OpAmp)
9	LATCH CLOCK	Input	control signal from CPU
10	DAIN 3	Input	Data/Address input from CPU
11	DAIN 2	Input	"
12	DAIN 1	Input	"
13	DAIN 0	Input	"
14	VCC	----	+5V supply
15	AM LOIN	Input	Input from AM oscillator
16	FM LOIN	Input	Input from FM oscillator
17	SW/MW	Input	Select short or medium AM wave band
			(unused, tied low)
18	FM/AM	Input	Select AM or FM operation

Though this helps understanding the circuitry, it doesn't help us with out new firmware, since there is no information about how to program the synthesizer to a certain frequency. After a couple of phone calls with Panasonic/Matsushita Germany, it was clear that I would have had to contact the japanese mother company to get this piece of information (the people I spoke to however were quite friendly and trying to help me, I must add at this point!).

Since I also own a still working RT200, there was a simpler way of finding things out: take a working sample, tap onto the data and clock lines, and see what is happening when the frequency changes. I was able to use a digital logic analyzer from HP for this job:

Click here or onto the photo for a full size version of this picture.

Shown on the LA's display is the result of a single programming cycle. The synthesizer chip contains a couple of registers, each 4 bits wide. With a low-to-high transition of the clock line, a certain register is selected; with a high-to-low transition, data is written to the addressed register. So a single write operation consists of the following steps:

• Apply register address to data lines
• Pull clock line high
• Apply register data to data lines
• Pull clock line low again

• Write 0 to register 2
• For FM:
  • Write 1 to register 1
  • Write hundreds of MHz to register 3
  • Write tens of MHz to register 4
  • Write ones of MHz to register 5
  • Write hundreds of kHz to register 6
  • Write 2 to register 7 if +50 kHz, otherwise write 4
• For AM:
  • Write 2 to register 1
  • Divide frequency by 9
  • Write hundreds of kHz to register 3
  • Write tens of kHz to register 4
  • Write ones of kHz to register 5
  • Write 0 to register 6
  • Write 0 to register 7
• Write 7 to register 8

Adding a Remote Control Input

The RP300 contains a Siemens infrared receiver & decoder chip that outputs the code of the pressed button as a 6-bit-code (all bits zero means that no button is pressed). For the 'less intelligent' devices like the cassette deck or the record player, some logic decodes these codes into individual signal lines for the controllable functions. The tuner in contrast directly gets the 6-bit-code and has to do the decoding itself. The reason for this is simple: About 20 buttons of the remote control are assigned to the tuner, and you only have 8 pins in the used DIN connectors. Of course this also saves I/O pins at the tuner's processor, and what is more interesting: the tuner also can 'see' codes destined for other devices in the system and react on them. For example, if you turn the system off via the remote control, the tuner can also turn itself off automatically. And what is more interesting: The buttons on the RP300's front panel run via a virtual remote control whose signal is merged with the IR receiver's output, the tuner also can notice when you switch the signal source to 'Tuner' and turn itself on. Another goodie I added to display the selected signal source on the tuner's display for a few seconds. Adding the remote control input was relatively simple: the signal are fed into the system with an extended low-level keyboard scan routine. Whenever a higher-level routine queries the keyboard, this routine first checks the remote control input for a non-zero code and returns this code in case the code translates to a 'usable' button. Otherwise, the normal key matrix scan is initiated.

Actual Implementation

Click here or onto the photo for a full size version of this picture.

There is space in abundance in the right half of the cabinet, enough to install a standard Eurocard-sized prototype board (160x100mm). Since this was a singular project, I didn't feel the need for a real PCB (and the circuitry underwent quite a couple of changes...). a 40-wire ribbon cable connects the board to the socket of the old processor. I could have used one of these handy DIL connectors for the cable, but you know, it was Saturday and all shops were closed...Due to the low clock frequency, such a long cable is not a problem except for slight interferences during AM receival (who needs that in a Hifi tuner anyway...). All connections, including power supply, are made via this ribbon cable. The only other connector is the RP300 remote control input in the rear right corner.

Program Source

Back to List