Fullscreen HTML5Med Res (??MB)HTML4

Extracting ROM data from old microcontrollers Chips like microcontrollers that require programming are a significant problem when repairing equipment. If that chip fails, can you get a replacement? Does the required code even still exist outside the chips in service? This article describes how such critical data can be preserved for future repairs. By Dr Hugo Holden This CRT-based video display unit is driven by the MC1468705G2 microcontroller. I wanted to extract the program data from it so I could clone it in case the original failed. B y the early 1980s, some manufacturers, like Motorola, decided to make a processor with internal RAM & ROM. It was a good decision, as that became the ultimate format for future microcontrollers. Before that, CPUs almost universally required peripheral external RAM and ROM chips to operate. The separate architecture is greatly preferred for equipment longevity and future repairs and restorations. That’s because ROM ICs can be removed from motherboards and their contents dumped at will, preserving the code. Faulty RAM is easily replaced, too. As most vintage computer restorers know, CPUs are generally fairly reliable, more so than RAM and ROM of a similar vintage. The popular ROMs at the time were various types of UV-erased EPROM. They have an attractive clear quartz window to allow for UV erasure, and you can see the IC die inside. Early types often had very large dies and are quite beautiful to examine. However, there usually isn’t any provision to get the data out of a microcontroller. So unless you can somehow get a hold of the original files used to 84 Silicon Chip program them, there is no way to generate replacements. Or is there? In the past, when I tried getting the original ROM file from the manufacturer, I had no luck. The original data files probably went into the bin decades earlier, like the Apollo 11 computers did. Generally, microcontrollers like the MC1468705G2 are used in systems controls, especially designs with touch buttons, key scanning and memory for settings. The microcontroller that’s the subject of this article was deployed in a 1980s vintage high-quality colour VDU (video display unit) made by Conrac. Conrac, based in California, was America’s premier CRT-based VDU maker. CRT-based VDUs are no longer manufactured. If this microcontroller failed, the Conrac VDU would be completely useless. Hence the desire to back up its contents. This sort of problem will be encountered more and more as time passes. Many modern appliances and equipment run internal firmware, which is usually not made publicly available. How will these devices be repaired Australia's electronics magazine without factory support when they get older? Clearly, if we want to repair and keep many vintage appliances (as they will be in the future) working, we will have to put our thinking caps on to figure out ways of extracting program data from many modern processors. In some cases, security locks make it even harder. Therefore, the purpose is not to copy manufacturers’ firmware to make rival equipment and sales but to keep vintage apparatus running. This helps prevent piles of e-waste from discarded products when they can be repaired and kept in use. It is unlikely that preserving this data from machinery that is decades old would greatly impact sales of new goods. From this point, I will refer to the original Conrac-programmed MC1468705G2 in the VDU I wanted to clone as the MCUC and blank MC1468705G2 chips I bought to clone the program onto as MCUTs. The MC1468705G2 Motorola described this device as a high-performance CMOS silicon gate technology 8-bit EPROM siliconchip.com.au microcomputer. It contains user-­ programmable, UV-erasable EPROM non-volatile memory, an oscillator, CPU and RAM. It also has an internal boot-loader program so that the micro can program itself without requiring an external programmer device, aside from some simple hardware. The MC1468705G2 has 112 bytes of onboard RAM, 2096 bytes (2KiB) of user-programmable ROM at locations 0x080 to 0x8AF, plus 11 extra bytes for programming the MOR (Mask Option Register and Vectors) at memory locations 0x1FF5 to 0x1FFF. This IC has 32 bi-directional I/O lines. The CPU was internally similar to the ubiquitous Motorola 6800. The manufacturers set it up so the user program bytes were placed in an external 8KiB ROM (such as an MCM68764 or MCM68766) in a ZIF socket on the programmer board. When the MC1468705G2’s bootloader was activated, it transferred the bytes in the external ROM into the micro’s internal ROM, a one-way trip for the data file. This programming event occurred when the reset switch on the programmer board was released. The self-­ programming was said (in the data sheet) to take 200 seconds or just over three minutes, ie, 100ms per byte. The verify program was then said to run for eight seconds. I have yet to determine why this was stated, as it is certainly not the case for the micros I have. Possibly those remarks only relate to the early version MJ3 mask variants. With the micro clocked by its usual 1MHz crystal, it takes only about one second to program the device, and the verify protocol takes another second to check all 2107 bytes. Fortunately, the verify program can be made to run separately, as this program is the key to extracting the micro’s ROM data. It might have been possible to do what I did even if I had to run the programming and verify sequence together, by disabling the micro’s Vpp programming voltage; however, that would have doubled the processing time. It appears that no program (firmware) was placed in the micro to export the ROM data from it, or at least nothing was documented by Motorola. There have been suggestions that this micro contains an “undocumented protocol” to export the files. However, without details on that, the bytes remain trapped within. The programmer board I realised that I would have to become familiar with programming this micro to have any hope of extracting the internal ROM data. If I was going to be 100% certain that I had extracted an accurate byte file from inside the IC, I would have to know what to expect. To this end, I bought three newold-stock MC1468705G2 micros and erased them, ready for programming. The next step was to build the Motorola programmer board, described in Motorola’s Application Note AN907A. It includes the circuit diagram and PCB patterns. Photo 1 shows the board I had made. I altered the PCB design a little by adding extra jumpers, for example, to run it from an external clock, to experiment with the IRQ line and to ground the Vpp line to disable micro programming while conducting some experiments. I also added headers to monitor the address lines, PA7 to PA0 and PD4 to PD0, corresponding to address lines A0 to A12. These were useful to monitor with a logic probe in the experimental stages of the project. In the Program & Verify mode, the microcontroller is held in reset by S2 being closed. +5V and -18V power is then applied via switch S1, then S2 is opened, releasing it from reset. Then the internal boot loader code runs, transferring the programming bytes from the 8KiB external ROM in the 24-pin socket into the micro. The Verify protocol runs after that. DIP switches S3, S4 & S5 are all closed in Program & Verify mode. To run just the Verify mode, S3 is left open. The board can be powered from +5V DC and -18V DC external power supplies or a 24V centre-tapped mains transformer. If a transformer is used, it is necessary to link out the -18V regulator IC. Because I ultimately used this board to power a “Data Extraction Machine” (DEM) via the 24-pin ZIF socket, I had to increase the 100μF filter capacitors to 1000μF. Extracting the ROM data In the Verify mode only, after release from reset, the CPU marches through all of the addresses in a sequence starting at 0x080 (decimal 128) for 2096 bytes, then it skips to address 0x0FF5 to verify the data in the MOR (mask option register) and then 0x0FF6 to 0x0FFF to verify the Vector locations. This adds 11 bytes, the total being 2107 bytes. Photo 1: I made this programmer board using the circuit from the Motorola data sheet. I added a few jumpers for flexibility. Photo 2: this Motorola MC1468705G2 microcontroller was one of the early examples with onboard RAM and nonvolatile storage; in this case, UVerasable EPROM. siliconchip.com.au Australia's electronics magazine January 2025  85 If all the bytes loaded to the micro’s internal ROM match the external one, the micro switches on the verify LED and the address lines go to zero and stay there. However, if a byte does not match between the micro’s internal byte file and the byte in the external ROM, the verify LED never lights. That is because the micro stops (stalls) the verification process. The program stops executing. Mercifully, the micro’s address lines stay on the exact address of the defective or mismatched byte. It does not keep incrementing the address or reset the address lines to zero in this condition. It stays there until the micro is reset. This creates the opportunity for data extraction by an external device in place of the external ROM. The idea is to keep changing the byte in the external ‘ROM’ while repeatedly cycling the verify program until the byte matches and the verify program moves on to the next byte (at the next higher address) and so on, until the entire ROM passes verification. How long might this data extraction Photo 3: my Data Extraction Machine. It plugs into the programmer board and continuously verifies the contents of the microcontroller against data in the onboard NVRAM, adjusting the data in the NVRAM one byte at a time until it matches the microcontroller code. Photo 4: the DEM plugged into the programmer board and well into the process of extracting the data, as you can see from the high address it has reached. 86 Silicon Chip Australia's electronics magazine process take? It appears to take around one second from when the micro is released from reset to verify the entire byte file. As it’s quicker if the verification fails earlier, across the entire ROM, that means an average of about half a second per attempt. In the best-case scenario, the trial byte would match on the first attempt. In the worst case, it could require 256 counts. So we can guess that, on average, it will take 128 attempts to extract one byte; about one minute at two per second. With a little over 2000 bytes to extract, that’s 2000 minutes or about 36 hours (one-and-a-half days). This system works by initiating verification, then monitoring the lower address lines, A0 and A1, for activity. If the activity stops for slightly longer than it takes to skip over the address, when the byte at the address verifies normally, that means the verification has failed. The emulator increments the trial byte to the next value, then pulses reset to re-run the Verify process. Conrac did not use all the user-­ programmable address space in the micro. The usable range is 0x080 to 0x08AF, but they actually used 0x100 to 0x7F9 and left the rest of the bytes as 0x00. There were also some zones in the used address range that were not programmed (all 0x00). If we set the trial bytes to start at zero, that will significantly accelerate the process. Having built and programmed the DEM, I found that it matched around 200 bytes per hour in the early phase of the file, slowing to around 28 bytes per hour towards the end. It took 26.2 hours to complete the process. At the end of the process, a Dallas DS1225 NVRAM IC holds a record of what is in the micro’s internal ROM. This is exactly the same byte file that was used to program the micro in the first instance. Essentially, this tool reverses the function of the Motorola programmer board and ultimately puts the micro’s byte file back into the external NVRAM. After the process is complete, the contents of the DS1225 can be extracted using a GQ-4x ROM reader, or similar, and the file saved. As the DS1225 now contains the correct data, it can also be used to program a fresh, blank micro. While I probably could have shortened that by reducing the time siliconchip.com.au Fig.1: this ‘cycle generator’ is responsible for determining when to trigger the next verification process. It waits until it’s sure the last verification step has failed before resetting the microcontroller and initiating the next one. constants on the DEM, ultimately, it was the speed that the Verify firmware runs that was the primary determinant of the total time taken. I was much more interested in reliable byte recovery than a quicker extraction. The Data Extraction Machine I designed the DEM board, shown in Photo 3, to plug into the 24-pin ZIF socket on the Motorola programmer board. Because any intermittent connection could ruin the long timeframe process, I didn’t use a breadboard or regular protoboard, but built it on a plated-through PCB with each connection carefully soldered. I covered the wiring side of the board with a styrene sheet to prevent accidental short circuits to the programmer board below. This board also obtains 5V power from the ZIF socket. Photo 4 shows the DEM plugged onto the ZIF socket on the programmer board. The siliconchip.com.au rectangular hole in the DEM is for access to the ZIF socket’s release arm. Most of the DS1225 NVRAMs in my stock now have discharged internal lithium batteries. Therefore, the DS1225 I have plugged into the DEM has an external lithium ‘support’. This is connected by milling the plastic casing down to the + battery terminal in the module, which, in this variant, is on the module’s top. Many other DS1225s have the battery at the bottom, making it more awkward to gain a connection to the battery’s + terminal. The negative terminal is pin 14 of the IC. With the additional current consumption on the 5V rail, it is worthwhile adding a flag heatsink to the 7805 voltage regulator on the programmer board (this can be seen in Photo 4). Also, as mentioned earlier, the two 100μF supply filter capacitors were increased to 1000μF. There are three plug-on wire links Australia's electronics magazine between the two boards. One is from the reset switch on the programmer board (it was isolated from the micro reset line by cutting the link track); the second is a feed to the micro’s reset pin. The third is to transistor Q6’s collector on the programmer board. This line goes low when the green verify LED activates, inhibiting the machine cycle of the monostable IC8 pin 3 on the DEM. Capacitor C1 is removed from the programmer board. Fig.1 shows the machine cycle (MC) generator on the DEM. Its job is to identify when the verify protocol has stalled due to a mismatched byte. The DS1225 on the DEM acts as a stand-in for the usual ROM with the source data that would have been in the 24-pin ZIF socket for programming the micro. Delay timers, based on BS270 Mosfets, give reliable detection of the absence of address activity but with a slow enough response time January 2025  87 that correct sequential bytes are prevented from being stepped over as the verification process proceeds. The system starts with the DS1225 blanked (all bytes = 00). If the file does verify, no MC pulses are generated. One of the problems with detecting dynamic address changes is that initially, the verify cycle starts at the address decimal 128 (0x080), with address lines A0 and A1 low. They remain low if there is a failure to verify. This means the circuit must be designed to create a machine cycle if the address is stuck at 128 for long enough. After that, though, the value 128 can be ignored. That could have been done by detecting the value of 128 across all the address lines. I decided to do it a different way, by detecting address 129 and using it to set a flip-flop. That was because this is no longer a concern once address 128 has been passed, which happens in the first minute or so. So, I can inhibit the 128 signal from that point using IC6 pin 12 and use the flip-flop output to light an indicator LED from its Q output terminal. This LED shows that everything is working, and the first byte was successfully matched. Because the Conrac micro was programmed for all zeros between addresses 128 and 255, the dynamic address detector, monitoring activity on address lines A0 and A1, was active right from the start. So it turns out I did not actually need the 128/129 fixed address detectors. But of course, I would have needed a crystal ball to know that in advance! The MC signal drives the memory controller circuit shown in Fig.2. Once a byte mismatch is detected and address activity stalls, the trial byte counter is incremented and written to the current address (that the verify program stalled on) in the NVRAM. Then the system reset is auto-pulsed by monostable IC10’s pin 12. This allows the micro to have another go at matching the new byte at that address in the NVRAM. Monostables IC8 & IC10 generate the required pulses to increment the trial byte counter (based on a 74LS393), write the new value to the Dallas NVRAM and provide the reset pulse after the MC is complete. With the bytes in the Dallas NVRAM being all initially 00, the initial block of 00s verifies very quickly, as does a block at the trailing end of the user program area. The MC signal is used to tristate (make high-impedance) the DS1225’s data pins since they are used as outputs when the programmer board is doing its verification but as inputs when incrementing the trial byte values. The MC pulse could be shortened to 5ms, but calculations suggest that would shave less than one hour off the extraction time. Most of the delays are in the time it takes the micro to run the verify program after resets, especially later in the process. I used relatively long monostable pulses in the 1.5-millisecond range to be 100% Fig.2: the microcontroller on the programmer board sets up the address lines for the NVRAM (IC14). If IC13 is active, data from the NVRAM can be read back via D0-D7 on the programming socket. When the data in the NVRAM needs to be updated, IC13 is deactivated and IC12 is activated to drive the NVRAM data lines with the next value from counter IC9. 88 Silicon Chip Australia's electronics magazine siliconchip.com.au sure that everything was stable for the NVRAM writes. Address displays Since acquiring the bytes from the micro takes a moderate amount of time, a progress indicator of some kind is desirable. I decided to use hexadecimal LED displays to show the address of the byte undergoing the matching process. The display is stable because the display modules have internal data latching. I used the Q2 output of monostable IC8 (at pin 12) to latch the current address undergoing matching into the displays. The Innocor INL0397 display modules I used are low-current CMOS versions equivalents to the famous Texas Instruments TIL311. I noticed that when the verification process has not started or is complete, address lines A0 through A12 are tristated by the micro, and sit at a high impedance. Because of that, I added 10kW pulldown resistors on these address lines to make sure they were not susceptible to noise pickup in that state, and to be sure that after power up, the displays showed 0x0000. To reduce the display brightness and current consumption, the display modules are blanked 50% of the time using a square wave oscillator, provided by two spare gates in IC4. The circuit of the address display part of the module is shown in Fig.3. Unexpected findings The MCUT devices, having similar markings to the MCUC and similar date codes (none of them being the alternative early MJ3 mask set versions), would all initiate the verify protocol when released from reset and in the verify mode, without -18V applied to the programmer board. This supply is used to apply a zener-­regulated -14V to the micro’s IRQ pin (pin 2). I preferred to keep that -18V supply disconnected. Also, I permanently grounded the Vpp pin (pin 3) of the micro with jumper J1 and had DIP switch S3 open for “Verify Only” mode. I didn’t want to accidentally damage the file by unintentionally programming the original Conrac MCUC! When I put the precious Conrac MCUC into the programmer board siliconchip.com.au Fig.3: the four displays directly read the binary address data and display it in hexadecimal (0-9 and A-F). The oscillator built from IC4b and IC4c halves their brightness using PWM control with a 50% duty cycle. and released it from reset (as I had done for all the other MCUTs I had been using), it sat there doing nothing, and the verify program did not execute. Gulp! This was a somewhat horrifying moment after all the work I had put into designing & building the data extraction system! After some experimentation, I found that the MCUC requires the -14V applied to the IRQ pin, or the verification process will not start. The MCUTs all started the process with that pin at 0V until I programmed them with the recovered Conrac byte file, and it became clear what was going on. When programmed with the extracted Conrac data, the MCUTs also required the -14V supply on their IRQ pin, behaving as the original Conrac MCUC does. The reason was that the MCUTs had been programmed with random byte data for my experiments, including the MOR register, and that affects how the micro responds when released from reset. Conclusion and outcome I have been able to program three blank micros with the original ConAustralia's electronics magazine rac file, and they all work perfectly in the Conrac VDU. My Data Extraction Machine is possibly the only one currently in existence for the MC1468705G2 microcontroller. The method outlined here may work for other similar microcontrollers as long as they have some sort of verification feature. Enough detail is presented in this article for anybody to build their own Data Extraction Machine. My design also requires the Motorola programming PCB, although the entire device could be built onto one PCB. To come full circle, I programmed the data file retrieved from the Conrac-­ programmed micro into a pair of vintage MC68766 UVEPROMs (as recommended by Motorola) as the external ROM device on their programmer board. To do this, I had to deploy my vintage BP Micro-Systems 1400 programmer, as new-generation programmers do not commonly support this UVEPROM. This programmed ROM represents what Conrac would have had in their factory in the 1980s. It verifies with the original micro from the VDU and the three replica micros I made as spare parts. SC January 2025  89