I needed to copy a MC68705R3P chip and needed to build some hardware capable of doing this. There is an old project around dedicated to that, but the design is old and after looking at it, I decided it’d be easier to accomplish more modern electronics.
Below you will find information regarding my copier, which also doubles as a programmer, but it’s still a bit clunky and needs refinement. That said, if you’re interested in the firmware for it, the source code can be provided, and I’ve made a schematic for it in KiCad, but I haven’t done the PCB layout yet.
My copier is based on an Atmel ATMEGA1284P. Using the method that was discovered and documented by Peter Ihnat, I went about creating a copier using more modern technology than the copier I found here.
To understand roughly what my copier hardware does, please refer to Peter Ihnat’s documentation regarding the method he found based on timing clock pulses.
My firmware for the Atmel ATMEGA1284P MCU is licensed under the BSD license. You’re free to do pretty much whatever you want with it.
Before we get started, below is an image of the first revision of my copier. Using the schematic for the programmer circuit designed by Motorola and the information provided by Peter Ihnat, this is what I’ve come up with.
The circuit itself is fairly simple. There is an 8-bit data bus running between the M68K MCU and the Atmel MCU. There are 100ohm resistors inserted in this bus. The reason for these was to provide some current limiting in the case that the M68K MCU didn’t boot into programming mode and instead started to run its pre-programmed firmware. I wanted to ensure that neither chip would be damaged in this case, as the Atmel chip will drain current and the M68K chip could potentially source current. In the case where the M68K chip fails to boot into programming mode, the behaviour of that chip is somewhat undefined and unpredictable. The circuit needs to take this into account to avoid damage to either chip.
The Atmel MCU is running at 20MHz, which provides it ample time to react to anything that the M68K chip needs. An off-the-shelf Serial<->USB converter board is also used. This helps with debugging and also provides a method to get information out of the Atmel chip, such as a firmware dump of the M68K MCU.
The disconnected wire you can see is a 1MHz clock signal that was intended to be connected to the M68K MCU EXTAL pin. I’d disconnected the clock wire and replaced it with a 1MHz ceramic resonator as I was having problems getting my chips to boot into their programming mode. It turned out that this had nothing to do with the problem.
Above: The M68705 MCU being copied is on the left, the Atmel ATMEGA1284P is in the centre. You can also see that I have the ISP for the Atmel AVR connected to the board for easy firmware updates, and the USB<->Serial converter is also connected to another computer.
Regarding the problem getting the chips to go into programming mode, the problem was that the first chip I attempted to use was too defective (damaged) to boot into its programming mode. The second chip I used contained the same firmware but was a mask ROM version and it wouldn’t boot into its programming mode either. This is probably because it’s a mark ROM chip and likely doesn’t have the bootloader code in it to activate the programming mode, since it would never need it.
Eventually, I got a third M68K chip and it went into programming mode first try. I wasted quite a lot of time on this issue (days) but eventually got it figured out. The main problem was that I was blaming myself and my hardware for the problem, convinced I’d somehow done something wrong.
Then there was another problem. I could see that for the most part at least, my code was finally working. I was able to see firmware data. I was able to see some text in that data that identified the person who wrote the firmware I was trying to copy and the company that the firmware was written for. At this point, I knew that I was mostly there, but just couldn’t get the M68K MCU to verify that the code I’d retrieved from its EPROM was correct.
Resolving this issue, again, took days. The main problem in this case was an assumption I’d made.
I’d assumed that it was very improbable that an engineer would design a chip like this and then require 4097 bytes of data to program the chip. 4096 bytes made much more sense, and I’d assumed that the documentation was wrong. One night, I decided that I should figure out if I was wrong or if the documentation was wrong. I changed my code to work up to the 4097th byte, not expecting it to reveal anything or even work for that matter. To my surprise, it did work and another problem was solved.
That night, I finally got it. The verified LED turned on. The M68K MCU agreed that the firmware I’d fed it was the same as the firmware it was programmed with. Finally, I had succeeded. It took me much more time than I’d like to admit to get to this point. All up, probably a solid 2-3 weeks of work.
Here it is, the green LED is the Verified LED. The yellow LED is the Programmed LED. All those other wires you can see are connected to a logic analyser.
This was a great moment. Finally, things worked. Better yet, the results were reproducible. This was a small personal milestone for me, as I’ve been interested in “glitching” MCUs to reveal their code, and this, to me, is a small step in that direction. Personal gain isn’t the goal here, it’s more about learning and a bit of geeky fun.
Overclocking:
Going by the datasheet, the maximum programming clock speed is 1.1MHz, the minimum being 0.9MHz. As an experiment, I removed the 1MHz ceramic resonator and re-connected the clock wire to the EXTAL pin of the M68K MCU. I’ve been able to get the M68K MCU to work correctly at 5MHz, which means that getting a copy of its EPROM only took 5 minutes. Unfortunately, running the chip at 10MHz didn’t work out, but I was pushing the limits as it were.
The firmware contains pre-tested timing values for 1MHz, 3.33MHz, 5MHz and 10MHz operation. At this time, the code will need to be re-compiled and re-flashed to the Atmel MCU if you wish to try out these alternative clock speeds.
The default build runs at 1MHz. This is in order to give you the best chance of success and to conform to the limitations of the M68K MCU specified in the datasheet. It would be trivial to change the code to allow a simple DIP switch selection for the clock speeds, should you wish to do something like that.
Alternative methods:
Something else that I’ve been thinking about is the fact that since I have control over the clock for the M68K MCU, I should be able to eliminate the timing-based code and instead count clock ticks to determine if the bytes are correct or incorrect. Since incorrect guesses take more clock cycles than correct guesses do, it should be trivial. It would also mean that I’d be able to eradicate the timing values from the code and work solely on clock pulses, at any frequency capable of being produced by the Atmel MCU and that also works with the M68K MCU.
If you are interested in the code or the schematic for this project, please leave a comment below. I will publish that information if there is demand for it.