This is a continuation of a previous article. Quick summary: I tried to build a device for dumping an EPROM via Arduino, and I constructed a device that had no chance of working. Oops.
This post will continue where that one left off. I'll walk through some of the process to hopefully get to a solution that works...
To summarize the overall project; I want to build a device that will illuminate an UV light-erasable ROM (EPROM) device, and also dump out its contents. I will then take the contents, display them as a graphic, and animate them over time as the bits fade away into an erased oblivion.
When we last left this, the above circuit was what I was going to work with. The Arduino would shift out a 16 bit address, which will be stored in the 74HC595 serial-in, parallel-out shift registers. Those would output to the address lines of the EPROM device. The 8 data line outputs of the EPROM then are read in directly by the Arduino. I started to look around for the parts, and I was planning to buy them from Sparkfun.com, for a very reasonable price. I was all set to place the order, but then I started thinking about other ways to sample the data, and then it hit me...
In the late 1980s, I had an Amiga 1000 computer (see previous post about restoring it). We used Macintosh SE computers in High School, and as a result, we bought the "AMAX" Macintosh emulation system for the Amiga. It was a lot easier to carry a floppy or two, rather than a SE or SE/30 in a plastic milk crate, not to mention that MacWrite was a substantially better word processor than TextCraft. ;)
AMAX consisted of software you run that emulated the Mac's hardware, as well as a "cartridge" that plugged into the floppy drive port of the Amiga. I remember hearing that they went with the floppy drive port because it was the only appropriate port identical on all Amigas that were available at the time. (Amiga 1000, 500, 2000).
The cartridge served two functions. First, it let you plug in a Mac floppy drive right into the Amiga so that you could read and write 800k Mac floppies directly. There was something about Amiga drives and Mac drives supporting a different number of drive speeds, so full Mac compatibility on the Amiga's drives was directly impossible. Future versions of AMAX that used an internal card on the Amiga 2000 worked around this issue. It was possible to make a floppy that supported just the sectors/speeds that were the same on both, but they only stored 272k of content. But I digress...
The other function of the cartridge was that you needed to plug in Mac roms into it, which the software would read in as it starts. Rather than storing the ROM on the Amiga, this protected the copyrights or whatever. But the important thing here is the function. I had picked up a few AMAX cartridges for $2 apiece at the awesome Active Surplus on Queen Street in Toronto a bunch of years back, so I dug one out.
Instead I decided to desolder the chips! My guess at the original function is something like: the Amiga issues a clear to the 74LS393 binary counter chips, ganged together to yeield a 16 bit output, rather than two dual-4 bit outputs. This will reset their 16 bit output value to 0. The 74LS165 parallel-in, serial-out register then latches the 8 bit output from the ROM, and provides it through shifting to the Amiga via the floppy port. From there, you need to simply pulse the clock on the '393, and it will increment through every address. Then you just latch and shift in the data. There's also a 74LS139 demultiplexer, which might be responsible for sequencing through those events, or perhaps something to do with the Mac floppy drive. I had a slight mishap and lost the 74LS165, which is okay since I didn't need it for this project anyway. Regardless, $2 plus some time -- I'm already ahead and I haven't even removed the D23s yet (which are the same size as Amiga RGB Video connectors! Perfect for another project...)
With a slight change in gears I can adapt my design to use the parts I now have in my toolbox thanks to my desoldering tools. Instead of the Arduino shifting out an address, it will instead do the process described above. It will first clear the 393s, then alternately cycle between clocking out a pulse to increment their values, and reading in the value directly. Since I'm accessing the ROM data from start to finish, sequentially anyway, this solution works out perfectly. I also show four LEDs in the above diagram. Three for various status, one for UV illumination.
About the UV illumination... The data sheets for the EPROMs show that they should be erased with 253.7 nanometer light, at 15-20 minutes, 2.5cm distance at 15 Watt/seconds per cm^2. I dont know how to measure this with respect to LEDs, but I'm going to just wing it and see what happens. The sheet also says that 253.7nm is the optimal wavelength for erasing them, but anything below 400nm should work. I believe the UV LEDs I have are somewhere between 350nm and 400nm, so it should work. The other issue is that the LEDs are substantially less powerful, probably a tenth to a hundredth the power. We'll see once we get this going, but I expect it will take on the order of weeks to erase a rom, rather than minutes.
The good thing about this project, in comparison to using EPROMs functionally, is that you want speed of erasure for functional use. I personally found that my eraser worked on most of the devices I own in about 10 minutes. I would often have a chip or two in the eraser, while programming and debugging others. It worked out fairly well. For this project, it's completely okay if it takes on the order of hours to erase a device. I'll find out how well it works once I get it going. I may use more than one LED just to speed it up a little, in case it takes on the order of days instead of minutes or hours.
I bought some wire wrap wire for address, data, and control lines, and did most of the work of wiring those up one evening at Interlock. I used red for control (counter clear, clock data cascade lines) as well as eprom address lines. I used blue for data lines. In the above pictures you can see how the wires were routed around (there was some more writing on the bottom, obviously.) You can also see how the UV LEDs are mounted with some stiff solid core wire. I reduced the number of LEDs to two plus the UV LEDs for no real reason at all. (There is an Arduino underneath there somewhere...)
On the two images above, you can see a jumper on the left of the first image, bottom of the second image... this changes what one pin is used for. For smaller EPROMs, pin 26 of the 28 pin footprint is used for VCC, powering the chip. In the larger packages, VCC is moved to pin 28, and pin 26 is used for Address line 13. It's confusing. A table that shows all of the pinouts doesn't really help too much, but it was necessary so that I could figure things out for wiring it up.
Next is firmware. I wrote a pretty simple program for the Arduino that simply enables the EPROM, resets the counters, then clocks through the addresses, reads them in and sends that data down through the serial link. After getting the enable lines wrong (active low, rather than active high), I managed to get it spitting out actual accurate ROM contents. As you can see in the above, it read out of the ROM (right half) 0xf3, 0x3e, 0x00, and so on. In a disassembly of Ms PacMan on the left, you can see these bytes in cyan, just to the right of the red numbers 0000, 0001, and so on.
The other half is a simple program that runs on a host computer that simply reads in serial data and logs it out to a file. That content looks like this:
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
I've now had this running for 12 hours with no change in the bits at all. I'm thinking that it will require running for upwards of a week or two to have any affect on bits. I may need to just drop the Arduino and ROM shield into my eraser to get the results I'm looking for... or at least a "control" to prove that the idea has a chance of working from here.
If nothing else, I now have a way to read EPROMS from an Arduino. Awesome!
No comments:
Post a Comment