Breathing life into a half a century old RCA COSMAC Micromonitor emulator of CDP1802 microprocessor
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
trackin-ps.zipLTSpice simulation files for the tracking power supplyx-zip-compressed - 3.04 kB - 09/03/2026 at 19:48 |
|
|
cdp18s030-ps.pdfSchematic of the power supplyAdobe Portable Document Format - 129.23 kB - 09/03/2026 at 19:47 |
|
|
In past it was common to refer to the computer communication data rates like in teletype lines, in terms of characters in a second, regardless the type of communication. The manual of the Micromonitor, when describing the terminal line communication refers to the data rates also that way, in characters per second. Modern careless reader after a quick glance may confuse that to bit rate, and wonder, how slow that can be, like 10, 30, or 120. No modern system handles that slow bit rates, but, nah!, "I can hack it!", with modern microcontroller and bit banging or configurable logic, easy piece.
And that I did, for a short while. Rather than reading, I studied the schematic, and looked at the actual bit rate. Micromonitor has a HW UART and derives the bit rate by dividing from the processor crystal frequency 2.112 MHz (What an odd frequency?!) Though there may have been some baud rate generators available, like Motorola MC14411 used in their MEK6802D5 evaluation kit and was available already in 1975, rather than using competitor's chop, RCA used their CMOS BCD divider CD4059A for generating multiple clock rates. It takes some hacking mindset and engineering ingenuity to generate with this chip three different bit rates that are standard, in this case 110, 300, and 1200 bits per second, common rates for terminal equipment at that time. That juggling also explains the strange processor clock frequency.
How the DC4059A datasheet describes the function of the divider and its configuration isn't exactly the clearest way of doing it, so it took some time to decipher the division and the rates from the schematic. The division goes in three steps. The first is inverting output fed back DFF, and the last is divide by 16 in the UART. In the middle there is the CD4059A. The rate calculation is visualized below.
The RS-232 DB-25 connector has been standard for decades with the pin numbering of the functions and the voltage level set in the EIA standard RS-232-C in 1969. Therefore this interface of the Micormonitor is compatible with the modern serial-to-USB adapter cables. The U232-P9 with DE-9 to DB-25 adapter worked just fine.
These days the 8N1 (8-bits, no parity, one stop bit) is the most commonly used, but in past it was common to use 7-bit ASCII with one of the parity modes to detect errors in transmission (over long terminal cables) and two stop bits to avoid loss of synchronization due to small differences in the clock rates of the two connected devices. The Micromonitor uses 7E2 (7-bits, even parity, 2 stop bits) for the 110 baud communication and 7E1 for 300 and 1200 baud. The slow 110 baud terminal could be a mechanical one with less accurate timing (like Teletype model 33, for which reason the Micromonitor has also the 20 mA current loop interface) while the higher data rate terminals at the time were electronic, with clock derived from a crystal, so the loss of synchronization is less a issue with those.
With PuTTY and 1200 baud line, it became much easier to use the debugger than from the flaky keypad:
The original plan for the minimal target board was just the CPU, oscillator, and TC5517A with address lines A8-10 grounded for 256 bytes of memory. It was a small change to add TPA clocked capture FFs for those address lines for full 2 kB.
Initially the target board turned out to have a serious flaw, as it was not possible to handler the ZIF socket lever.
Other components than the memory are SMDs and thus on the copper side of the board.
This is the RC oscillator. Same circuit as in the self test card.
The address FFs are also singles:
To test the memory board, I first checked with memory reads and writes that some addresses work correctly, writing a few locations with some random bytes and then checking that they held the values.
The next test was to write at the beginning of each 256-byte page a distinct byte, values were 0x11, 0x22, etc. Those also worked fine.
The next test was to enter a small program that fills one page with bytes 0x00...0xFF. The program was as follows:
| Address | Instruction | Bytes | Comment |
| 0x00 | SEP 0 | D0 | P <- 0 |
| 0x01 | SEX 1 | E1 | X <- 1 |
| 0x02 | LDI 0x40 | F8 40 | D <- 0x40 |
| 0x04 | PLO 1 | A1 | R(1).lo <- D |
| 0x05 | LDI 0x00 | F8 00 | D <- 0x00 |
| 0x07 | PHI 1 | B1 | R(1).hi <- D, R1 now point to 0x0040 |
| 0x08 | STR 1 | 51 | *R(1) <- D |
| 0x09 | INC 1 | 11 | R(1) <- R(1) + 1 |
| 0x0A | ADI 1 | FC 01 | D <- D + 1, DF <- overflow |
| 0x0C | BNF 0x08 | 3B 08 | if DF == 0 goto address 0x08 |
| 0x0E | BDF 0x0E | 33 0E | if DF != 0 goto address 0x0E (infinite loop) |
After executing this program I checked the address range 0x0040...0x013F for the values 0x00...0xFF. All was OK.
So, with this card I have a primitive computer with a CPU and 2 kB of memory.
The next step is to check the serial port and see if the debugger can be used from the external console.
After studying some alternatives for making the 7-segment hex displays one feasible may be to use a simple programmable logic device like Renesas SLG46824 to convert the nybble input to 7-segment display hex digit patterns. A quick check with AI provided a solution which fits into the limited resources of this chip. The logic patterns require 16 of the 19 logic elements of the chip leaving 3 for DFFs, and thus one external DFF like SN74LVC1G79 is needed. The SLG devices have relatively high drive current specifications so they can typically drive the LEDs directly making external driver transistors unnecessary.
The converter schema from the GreenPAK designer:
The LUT contents are:
P1: 0x04
P2: 0x9E
P3: 0x04
P4: 0xD0
P5: 0xE0
P6: 0x8E
P7: 0x20
P8: 0xE
P9: 0x18
Ma: 0x8D
Mb: 0x7B
Mc: 0x27
Md: 0x7B6D
Me: 0x8D
Mf: 0x27
Mg:0x72
The simulation with the SPICE in the GreenPAK designer confirms the correct patterns:
Even though feasible, for the moment I won't include the display to the target circuit, but only the memory and the logic it requires. That will be sufficient to further test the debugger.
Tinkering the self-test card took some prestidigitation with sharp knife, LT1SC soldering tip, and Leica A60.
The oscillator was made as described in the previous log. The inverter for the EF1 was made of a '1G57 multi-function gate.
After plugging in the card and the processor nothing remarkable appeared to happen. No eight dots on the display, suggesting the Micromonitor could be faulty. But not really. The manual tells to use known good processor as the target, and untested recycled processor is not such a thing. So after inspecting the device with oscilloscope, it seemed almost to work, sometimes.
After some closer study, it became obvious that the pins of the target processor were so dirty and oxidized that even the first time to get to the 8-dots prompt was a miracle. So cleaning the pins by removing the old solder and cladding with fresh tin, the processor began to respond correctly to the Micromonitor. No issues with the self test circuit so far.
After a little playing with the debugger it seems to be alive.
The keypad has some contact issues as well as some bouncing, but nothing really unexpected so far.
So, now that I have and in-circuit debugger, I need a circuit to debug in. And what would be more apt to the theme than make something like Cosmac ELF? The schematic can be found in the net. However, some components may be hard to come by, so have to improvise.
For the RAM I found a 2 kB TC5517AP. Simply tying the high address lines low I can start with 256 bytes aliased across the whole memory space, like the original one. A bit more difficult to find are the two hex displays with internal latch and binary to hex chars converter. That calls for a hack...
Instead of the original self test board which, according to the description in the manual, is a board that is plugged into the external memory board edge socket and connected with the DIL40 connectors of the target cable to the target connector socket, this self test board will be a DIL40 hack plugged directly into the target socket and connected with a single cable to the memory socket for the 5V supply (pin B of the external memory connector P1).
The 100 kHz oscillator will be a 200 kHz RC oscillator made with dual unbuffered 7404 gates (NL27WZU04) and a divider made of single D-flop with inverted output (SN74AUP1G80). The concept is like shown in this simulation.
Lacking the models of actual components the actual frequency will be seen by measuring the live circuit.
After building the circuit C=470pF and R=8.2 kΩ resulted in 104 kHz.
After checking the board, mostly visually, all appeared to be OK. The first power-on was to be tested with the logic only, so the only elcos in the serial line drivers don't matter at this time.
Raising the current carefully and observing the behavior of the device, all appeared to be electrically OK. At 5V the current needed was 180 mA, something expected of that many CMOS packages on the board.
That, however, is expected, as the 8 dots in the display only appear after the debugger has detected the processor. For that a live processor is needed in the target processor socket. Also some target system should be there, but lacking that the self-test card that came with the system can be used. Except that no self-test card came with it.
However, the manual has the circuit for the self test card, so the next step is to make one.
However (again), some checks can be made right away, the interesting one is to see if the system's own processor is alive. Quick check with oscilloscope showed that the crystal oscillator is running. The next check was to see the timing pulses TPA and TPB.
Those appear to be OK, too.
So the next step is to make the self test card and check the system further.
To be able to verify and potentially repair a power supply sometimes requires figuring out the schematic in detail. For simple linear and switching regulator designs that follow the example circuits given in datasheets and application notes, that may not be necessary. This power supply appeared to contain some circuitry that I'm not familiar with, so the next step was to draw out the schema, with KiCad.
With some luck, all could have been just fine, but as often, some are not. The first step in the testing is to limit the current to something like 20-50 mA and slowly rise the voltage to the expected maximum, which can be determined from the specifications of the components, electrolytics and semiconductors.
In this case the first ramping of the capacitor C9 to 9V went fine, but on the next ramp it shortcircuited. Without current limiting much more damage would have occurred. Others seemed to be OK on that firs testing, but because of the one major failure I decided to desolder all e-caps and test them individually.
Each cap was first slowly ramped to the maximum working voltage without exceeding the charging current on 20 mA and held there until the leakage current went below the usual maximum leakage current CV/4000s (for 5300µF/25V that is 33 µA). The voltage was then mainatained for 10 min. Then the procedure was repeated.
All remaining caps passed that test.
After the leakage test each cap was measured with LCR meter (100Hz) for capacitance and Q. Requirements set was that capacitance was at least 80% of the nominal and Q above 10 (my arbitrary choice for this kind of a quality check). One capacitor, C7, had less than 40% left of the nominal capacitance. That had to be changed. C4, the other large cap, had 87% of the capacitance but Q was only 2. That indicates large ESR and that will need to be changed soon, too. Others were withing the requirements.
Lacking an axial cap for replacing C9, two 4700µF/25V radial caps were soldered to a trip boar in parallel and the combination was soldered to the place of C9; attached with two-sided tape and a zip tie.
After these fixes the PS appears to work correctly. The tracking section was tested by taking the tracking input from another channel of a power supply and the output voltage followed the input as expected. To understand the circuit correctly it was simulated with LTSpice (simulation files are in the attached zip file tracking-ps.zip).
The restoration of a computer often begins with the power supply. It is critical not to turn on the potentially degraded and fragile device until the safety of the power supply and the other circuitry has been verified to not contain shorted components, especially the electrolytic and other capacitors. There is also a chance there are degraded solderings which may trigger a major destruction rare or unobtainable components.
The first step in this project was to take out the power supply and verify that it is wired for the correct voltage (220V for Europe).
Though a bit unorthodox, also the PH-163 power cord receptacle was changed to a modern IEC C8 one for which cables are available.
The original socket will be saved for a chance that the fitting plug becomes available.
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates
About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API Do not sell or share my personal information
Cliffweb03
Ken Yap
KingOfKYA(Travis K. )