Replacing The Broken Microprocessor in a Telefunken RT200


NOTE: This is a project for people who are absolutely crazy, like me. It took me altogether more than two months of work to do this project, not counting the hassle to find appropriate information (and realizing that I had to find out things myself). This report mostly has documentational purposes and there is probably noone who has an RT200 with the same problem and can use this text as a 1:1 guide. To do something like this, you need to have experience in reverse engineering devices, understanding both analog and digital electronics, building hardware, and programming embedded controllers. If you try something similar along the lines of this project, you are absolutely on your own and I might not be able to help you out. Especially, you are yourself responsible for anything you break. So for the moment, lean back, read, enjoy, and see if you can reuse some aspects for your projects.

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.


Some Reverse Engineering

Since the tuner's PCB is single-sided, it is principally possible to reverse-engineer the device by following the traces, but at least in Germany, there is a much simpler way: go to, the web page of the Lange circuit service in Berlin. This company offers a unique service: it archives schematics and manuals for about any piece of audio/video equipment that was ever sold in Germany. Manufacturers usually only have schematics for the newer devices, but Lange always gets a copy of the schematic and stores it (hopefully) forever. It might even happen that when you ask a manuacturer for an older schematic, they will automatically forward your request to Lange. Of course this service is not free; expect about 20..40 DEM plus shipping, depending on the number of pages to copy. I however think that this is well worth the money, given the amount of time and nerves you save. Fortunately, this schematic already gives the pin functions of the central microprocessor IC (a Matsushita MN4500 by the way, but that doesn't help anyone...):
Pin No.NameDirectionFunction
2LWOutputgoes high if switched to long wave AM (unused on the RT200)
3MWOutputgoes high if switched to medium wave AM
4FMOutputgoes high if switched to FM
5OUTLED OUTOutputgoes high to turn tuner on
6MUT OUTOutputgoes high to mute the AF output
7LATCH OUTOutputcontrols data transfer to the synthesizer chip
8DIGIT OUT 5Outputrow selectors for the display/keyboard matrix
9DIGIT OUT 4Output"
10DIGIT OUT 3Output"
11DIGIT OUT 2Output"
12DIGIT OUT 1Output"
13DIGIT OUT 0Output"
14KEY IN 0Inputsense lines for the keyboard matrix
15KEY IN 1Input"
16KEY IN 2Input"
17KEY IN 3Input"
18STAT DETInputgoes high when a signal of sufficient quality is received; needed for auto scan
19PWR DETInputissues a 'reset pulse' after the main supply comes back
20KEY IN 4Inputsense lines for the keyboard matrix
21KEY IN 5Input"
22BCDOUT 0Outputcontols the decoder driving the station key LEDs
23BCDOUT 1Output"
24BCDOUT 2Output"
25BCDOUT 3Output"
26TESTInputunused input
27RESETInputlow-active reset for the CPU
29LOCKDET INInputgoes high when the synthesizer's PLL has synchronized to the programmed frequency
30CLOCKINInput250Hz clock from the syntesizer chip for the internal timer
31SEGMENT OUT 0Outputsegment data for the display + addr/data for the synthesizer chip
32SEGMENT OUT 1Output"
33SEGMENT OUT 2Output"
34SEGMENT OUT 3Output"
35SEGMENT OUT 4Output"
36SEGMENT OUT 5Output"
37SEGMENT OUT 6Output"
38SEGMENT OUT 7Output"
39Vdd----5V supply voltage
40CPU CLOCKINInputCPU clock input (562.5kHz)
Luckily, these are all only digital functions and the processors works with a standard 5V supply and TTL levels, which simplifies the selection for a new processor:

Selecting a Microprocessor Platform

The microcontroller market offers lots of different families and variants of controllers. Some of them are well-known and for general-purpose use, some of them were designed with a specific application in mind. Since the synthesizer's PLL loop (see below) is completely done in the PLL chip, the main CPU's functionality mainly consists of driving the multiplexed display, querying the keys, running the internal clock for the timer and moving around some data - all not very advanced tasks even a 4-bit CPU could handle (I guess the original MN4500 is a 4-bit CPU!), but most 4-bit-CPUs are not general purpose and difficult to get or require expensive development systems, so let's settle with an 8-bit core. What other things do we need? Summing up, I settled with a CPU family that is the most widely used family of 8-bit controllers: The 8051 family. Originally introduced by Intel, 8051 derivatives are available from more than a dozen of manufacturers. The two 'standard' ROMless components 8031 and 8032 are available from probably more than 10 different manufacturers. I finally settled for the 80C32, the variant with more internal RAM (needed for the stations' frequency storage) and a third timer (not needed here). By coincidence, I got an TS80C32X2 from Temic, formerly Telefunken Microelectronics. It has the nice capability of running in X2 mode, i.e. an internal frequency divider is turned off and the device runs at double speed with the same external clock. A very nice feature, especially considering the low external clock frequency.

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

As you may imagine, it is by far too complex to explain the firmware on a line-by-line basis at this place; I'm also not going to explain the basics of the 80C32's architecture at this place - there's plenty of literature available in the Internet about that. I will therefore describe the basic building blocks and line out how they work together:


Of course, the first step after a power-on or a reset is the initialization. The interrupt-driven background processes have to be initialized, and some global memory cells are resetted to meaningful defaults.

Interrupt Routines

There are two interrupt-driven background processes that run on the CPU. At least on a standard C32 without X2 mode, they consume about 70% of the CPU time, which is no miracle given the low clock frequency. The remainder is however still fully sufficient for our purposes.

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

The RT200 has a row of buttons that release each other and define the current 'operating mode' of the tuner's 'user interface': Once the system is initialized, the CPU contiuously queries which button is pressed and branches into the appropriate sub-handler. Normally, this handler immediately returns to the main loop once the appropriate actions are done, but it may decide to delay this return in case a multi-key entry (time or frequency) is made. Of course, such an entry is immediately terminated in case the operation mode changes, so the key input routines inside these handlers also regularly check the current mode.

The Timer Section

is not overly complex: The handler for the 'Timer On' and 'Timer Off' modes is basically the same. in 'Timer On' mode, this handler is additionally followed by another routine that compares the current time against the preprogrammed timer values and issues the appropriate on/off sequences when necessary. This check is only done if the seconds value is zero; i.e. there is no problem with the background interrupt process updating the time in the same moment this routine runs. Problems only would occur if the comparison took longer than a minute...

Programming the Synthesizer Chip

The probably hardest part was the programming of the synthesizer chip, the chip responsible for selecting the frequency to be received. Its function is to generate a freely programmable frequency that is mixed with the amplified and coarsely preselected signal from the antenna. When you mix two frequencies properly, you get as a result two new signals with a frequency of the sum resp. difference of both frequencies. In our case, only the difference is interesting. If we program the synthesizer with a frequency that is higher than the signal to be received by a fixed amount, the difference remains constant and the following circuits need not be tunable; they can be accurately adjusted for this frequency. This principle is called Superhet Receiver in contrast to a Straight Receiver where all circuits have to be tuned synchronously to the frequency of the station to be received. Though this is in theory doable, it becomes extremely difficult to keep more than two variable circuits 'in tune'. Two circuits is however not enough for a good selection, so practically all radio receivers, including the simplest pocket radios, are superhet-type receivers.

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.NameDirectionFunction
2OSC OUTOutputGoes high if PLL has locked
3OSC1----Connect to 4.5 MHz crystal
5CLOCK1Output562.5 kHz clock for CPU
6CLOCK2Output250 kHz clock for CPU timer
7VCC CLOCK----+5V supply
8PD OUTOutputOutput of Varicap voltage
(externally amplified with 741 OpAmp)
9LATCH CLOCKInputcontrol signal from CPU
10DAIN 3InputData/Address input from CPU
11DAIN 2Input"
12DAIN 1Input"
13DAIN 0Input"
14VCC----+5V supply
15AM LOINInputInput from AM oscillator
16FM LOINInputInput from FM oscillator
17SW/MWInputSelect short or medium AM wave band
(unused, tied low)
18FM/AMInputSelect 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:

Reverse Engineering the RT200
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:

The frequency to be programmed (remember this is 10.7 MHz resp. 450 kHz higher than the frequency ultimately to be tuned) is simply written in BCD code to the synthesizer's registers. Specifically: Note that in AM mode, you can only tune in 9 kHz steps!

Adding a Remote Control Input

The larger brother of the RT200, the RT300, features a remote control input to control the tuner via the infrared remote control receiver in the RP300 pre-amplifier. Now that we have a firmware we can extend and modify easily, there is no reason not to add some nice features you had always been missing...

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

Below is a photo about how I installed the board in the RT200.

New Processor Board in the RT200
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

The program's assembler sources are available here. To assemble them, you need my own cross assembler AS, which is available here on the same server.
Back to List
©2000 Alfred Arnold,