DITTO
I have no idea what the question was or what kind of answer it deserved...and BINGO!...he drops it like he was ordering coffee.
It just so happened that 500-series EPROMs were in a box and had the revision code written on them. If they were still in the machine, or didn't have the code written on them by whoever burned them before me, I'd have had no idea.
So maybe this is a good moment to resurrect a topic that was covered way back in this thread, and something I was meaning to get around to for like the last year or more, but life got in the way.
What I'm referring to is the process and equipment needed to 1.) copy the data of the EPROMs of my Otari MX80 without f**king them up, since I have no backup/spares (that's what I want to create)...and then 2. transfer the data to a computer file...and/or also find some spare EPROMs of the same type, and write the data to them or just have them ready for writing, as I think it's probably best to save the data as a file rather than on another EPROM.
Going back to some of the links I saved way back...I have this as my only starting point, and I'm sure if I call them, they can at least give me some guidance of that else I need (it looks like they have all the necessary stuff)...but I would like to have the conversation here too if anyone has done this or is clear on how to do it.
I mean...I understand the basic process...but I just want to be 110% sure, because I don't want to destroy my existing, working EPROMs from the MX80 while attempting to copy the data from them. That would a very unhappy situation...to say the least.
Here's that one link I saved:
MCUmall Electronics Inc. A low cost EPROM EEPROM Atmel PIC I2C SPI programmer online store
Fortunately I have the MX80 EPROMs in the same box at the Lynx ones. Mine are the following:
PG08211K (CPU board) - 27C256K (256Kbit)
PG08311 (remote card) - 27C128K (128 Kbit)
PG03311B (CB140 ROM) - 27C256-2 (256 Kbit)
Autolocator:
PG07121K (CB120 ROM) - 27C256G-25 (256 Kbit)
PG07122K (CB120 ROM) - 27C256G-25 (256 Kbit)
So you'll need at least two 27C256 EPROMs for the deck and remote (assuming the remote is a CB140 - others may vary), plus a 27C128 chip, and another two 27C256s if you're doing the CB120 autolocator as well.
It is probably a good idea to get a couple of spares, just in case you end up with a duff EPROM (especially when buying them used off ebay).
When I first started doing this with the Studer, I had problems getting hold of 27C128 chips. It is possible to substitute a 27C256 instead - but since it's twice the size, you'll need to have two copies of the program on the chip, one after the other so both halves of the chip contain the same program. (i.e. a 27C128 chip has 16KB of data. The 27C256 has 32KB - you'd need to have two copies, one running from 0000-3FFF and a second copy running from 4000-7FFF). This may be tricky depending on how good the software is for your burner. If you can get a 27C128 you won't have to mess around with that.
I've only used the ART programmer and its ancient DOS software (which happily works in DOSbox with a USB-parallel cable). But the basic process is this:
1. Carefully remove the chip from the deck. An EPROM remover tool is a good idea, less chance of bending the pins.
2. Place the chip into the EPROM burner. This has a ZIF socket with a lever. When the lever's up, the chip can be added or removed. When the lever's down, the chip is locked in place. MAKE SURE the chip is the right way around! There should be a notch on the ZIF socket showing which way round the chip goes.
3. Somewhere in the software there should be an option to read the contents of the EPROM. On my software you're supposed to choose the type of chip from a list first, so that it knows what pinout it's using. This should read the chip's data into memory, you can then save it to disk somewhere. More recent software might be able to autodetect, I have no idea.
4. Once this is done, the software will hopefully give you the checksum of the data. If you write this down, you can use it to check that the programming worked properly later. Remove the chip and put it somewhere safe, preferably on an antistatic foam mat.
Now we need to write a copy of the chip. As you may be aware, EPROMs are erased with UV light. On mine, the first step of programming the chip is that the software will read in all the contents first, to make sure it's blank. This protects you from accidents if you somehow tried to program the original by mistake, and also ensures that the EPROM is in a suitable state to be programmed.
If the target EPROM hasn't been erased first, you probably want to do so. You need an EPROM eraser, which is basically a UVC tube in a lightproof box with automatic shutoff and often a timer. I put mine in for 30 minutes.
5. Once you have a suitably erased EPROM, put it into the programmer.
6. If you don't still have the ROM data in memory, load it from disk.
7. Make sure you've got the chip type selected. This is likely to depend on the software. On mine it had a list of them from multiple manufacturers, since they may have slightly different strategies for programming. e.g. if you're programming an Intel D27256-2, pick that or the nearest match in the list. For a Mitsubishi M5L27256K pick that or a similar chip of the same size also made by Mitsubishi.
8. Burn the data to the chip. This may take a while. On mine the software verifies it afterwards, but if you're super paranoid, you could read the EPROM back into the software as per step 3, and make sure that the checksum is the same as you wrote down earlier.
Now you can remove the copy from the machine. What I tend to do is put the original in a box somewhere safe, and put the copy back into the deck to make sure that it works. Probably best to do this one chip at a time - otherwise if one of them does go wrong, you won't necessarily know exactly which chip is to blame.
It might be good idea to get some second-hand chips with data and practice steps 1-4 on those to make sure it works, before trying it on the real thing. The software should have a way to view the EPROM contents once it's been read in - there are nearly always some human-readable strings inside the program code.
Good luck!
