This is inspired by Vid's guides to document my experience programming EPROMs. However, unlike Vid's guides, I didn't know what I was doing going down this path and had a hard time finding good material to help me get started. I'm just starting and there is a lot I don't know, but hopefully this helps the next person who goes goes down this path. Also, I hope that other's with more experience can add their know-how!
First was buying a programmer. I went with the Minipro TL-866CS for two reasons. It is cheap (as little as $30) and there was linux/mac OS software.
Rather than going super cheap and buying direct from China, I purchased the programmer and eraser from Amazon so I could get them quicker:
* TL-866CS: https://www.amazon.com/gp/product/B06XQ5WHWF : $50
* Eraser: https://www.amazon.com/gp/product/B014ZYWR
: $20
I wanted to use this software: https://github.com/vdudouyt/minipro (linux and mac)
But ended up having a lot of problems getting it to compile on Mac OS (thank you Apple for locking the system even more!)
So I ended up using VirtualBox to run Windows10 and run the TL-866CS software: http://www.autoelectric.cn/en/download.html
To get everything set up, i had to install Virtual Box. To get the USB port mapped to the virtual machine instance (VM) running windows to, I had to install the Virtual Box Extension Pack and then configure the VM: In VirtualBox, select the image, then select Settings->Ports->USB and select the MiniPro TL-866
Since I wanted to pull ROMs (and read and write) from the host operating system, I needed to set up a folder that that was accessible from inside the VM instance:
* To share a folder from the host OS with the VB Guest OS:
* Select image, then selection settings->shard folders->press “+” to add folder
* While the guest OS is running, from the top menu, select Devices->Insert Guest Additions CD image. . .
Now I could start testing. First, I took an old ROM with BoP L-5. I use the programmer to read it the image, save it, and the compare it to one I downloaded from IPDB. The files matched (success!)
For figuring out which chip is which, google and searching for datasheets really helps determine the correct manufacturer.
Next was Funhouse and to update to the 9.05H ROMs. First I had a problem with the files at IPDB. Eventually found the ROMs through PinMame. https://www.dropbox.com/sh/jd85os8e9qmtsrc/AAAliLyJmTdDpMOdGLJmPfkba?dl=0
The set of files included L-9, which I could use to try to apply the non-ghosting patch (worked): http://www.edcheung.com/album/album07/Pinball/WPC_Ghost_Busting.pdf
From there, I ran into the fun of figuring out the right chips to use:
* MPU required a 27C020 (changed jumper on MPU)
* Sound required 27C010
That is as far as I've gone, and will continue to post updates as I make my way through other systems.
Re - EPROM pinouts; Games use 8-bit EPROMs.
So 4Mb is 512k x 8. Any EPROM (UV eraseable, OTP, EEPROM) with this data format will work, as the pinouts are standardized. (Flash based EPROMs, not so much.) The most common are 27C040 and 27C4001 for 4Mb, 27C020 or 27C2001 for 2Mb. (Yeah, there's a pattern here!)
Figuring out which chip to use is not difficult either - take the size of the file on your hard-drive, multiply by 8. (So, a 4Mb ROM will accept a 512kb file. 2Mb will be 256k.) To find the size of the file, take the EPROM size, divide by 8. (It's that whole 8-bits thing, see. 
)
Quoted from Coyote:Re - EPROM pinouts; Games use 8-bit EPROMs.
So 4Mb is 512k x 8. Any EPROM (UV eraseable, OTP, EEPROM) with this data format will work, as the pinouts are standardized. (Flash based EPROMs, not so much.) The most common are 27C040 and 27C4001 for 4Mb, 27C020 or 27C2001 for 2Mb. (Yeah, there's a pattern here!)
Figuring out which chip to use is not difficult either - take the size of the file on your hard-drive, multiply by 8. (So, a 4Mb ROM will accept a 512kb file. 2Mb will be 256k.) To find the size of the file, take the EPROM size, divide by 8. (It's that whole 8-bits thing, see. )
Thanks Coyote, your insight is always appreciated!
One problem I seemed to have was that 27C040/27C4001 wouldn't work in FH, while the 27C020/27C2001 would (the 9.05H ROM needed at least 2Mb). Same with the sound ROMs -- 27C010/27C1001 would work, but anything larger would not. Not sure if there was a jumper that needed to be switched. Should the larger EPROMs work?
Quoted from lyonsden:Thanks Coyote, your insight is always appreciated!
One problem I seemed to have was that 27C040/27C4001 wouldn't work in FH, while the 27C020/27C2001 would (the 9.05H ROM needed at least 2Mb). Same with the sound ROMs -- 27C010/27C1001 would work, but anything larger would not. Not sure if there was a jumper that needed to be switched. Should the larger EPROMs work?
When using an EPROM that is twice as large as required, no jumper is required, however, you should copy the image to both halves of the EPROM. If the unused address line is floating and you have garbage data on the other half of the chip, it could try to be switching back and forth and breaking the program. If you have the data copied onto both halves of the EPROM then it doesn't matter if the extra line floats, it would find identical data either way.
Yup, what they said.
Because of how chips are addressed, and the circuits are designed, the game could get garbage back. Or the checksum not match right.
Also, pinouts BETWEEN the different versions are usually NOT the same. I.e. A 27C020 does NOT match a 27C040. May be *close*, but not exact. (Usually because of the added address lines, needed to access higher chip memory!)
If you use a bigger chip, and the board can support it (WPC can..), then you must double the image. (Run the command copy /b file1 + file1 outfile)
Quoted from snakesnsparklers:When using an EPROM that is twice as large as required, no jumper is required, however, you should copy the image to both halves of the EPROM. If the unused address line is floating and you have garbage data on the other half of the chip, it could try to be switching back and forth and breaking the program. If you have the data copied onto both halves of the EPROM then it doesn't matter if the extra line floats, it would find identical data either way.
Thanks for the info -- I'll try this with my FH ROM.
Quoted from Coyote:Yup, what they said.
Because of how chips are addressed, and the circuits are designed, the game could get garbage back. Or the checksum not match right.
Also, pinouts BETWEEN the different versions are usually NOT the same. I.e. A 27C020 does NOT match a 27C040. May be *close*, but not exact. (Usually because of the added address lines, needed to access higher chip memory!)
If you use a bigger chip, and the board can support it (WPC can..), then you must double the image. (Run the command copy /b file1 + file1 outfile)
For those in unix, that is the same as cat <file.rom> > <new.rom>; cat <file.rom> >> <new.rom>
Most EPROMs follow the JEDEC pin out standard. That being said you can always sub in the next sizes bigger eprom that are in the same package pin count. Just make sure you fill the entire EPROM tho with repeated copies of data. That way if extra unused address pins are tied high / low or even oscillating, the cpu finds the proper data because you filled the EPROM up.
The 24 pin 2732 (32KBIT) EPROM can replace the 24 pin count 2716 (16KBIT). Just double up the image.
The 28 pin 27512 (512KBIT) can be used in place of a 28 pin 2764, 27128, 27256 EPROM. Just 2x - 8x the image.
The 4096KBIT 27C040 can be used in place of a 2048KBIT 27c020. Just double the image.
Quoted from Coyote:Yup, what they said.
If you use a bigger chip, and the board can support it (WPC can..), then you must double the image.
Just tried this out tonight -- doubled up a 2Mb program for a 4Mb chip and it worked like a charm! Thanks all for the pointers.
While others are correct that the "floating" address pin on a larger than required device doesn't need to be tied... I'd highly recommend it.
Some devices may lock up if the address pin is oscillating (the spec sheet would show how an address setup/hold time can be violated)
Worse is the possibility that the oscillation generates spurious RF which could interfere with radios/cellphones/etc.
These behaviors aren't probably too likely, but are pretty challenging to troubleshoot.... Easier to tie the pin... Ground/VCC or the highest address pin are all good possibilities (designs I've been involved with all tied pins to ground since it pulls slightly less current)
Keep in mind this advice comes from my experience in embedded hardware/software... But not for pinball's.
-Dale
PS. Thanks for all of the great resources here for a pinball newbie!
I'm looking to get the non-ghosting patch tool (utility).
Please PM me if anyone has it and is willing to share. Thanks.
Quoted from T7:I'm looking to get the non-ghosting patch tool (utility).
Please PM me if anyone has it and is willing to share. Thanks.
Here you go: https://www.dropbox.com/s/ljjrhszv5kvz458/wpclp-master.zip?dl=0
Quoted from Syco54645:never had luck with the antighosting thing working...
I've put it on a couple of games and have been happy with the results -- do you recall which one didn't work for you?
Quoted from lyonsden:For those in unix, that is the same as cat <file.rom> > <new.rom>; cat <file.rom> >> <new.rom>
Also doable as a single command:
cat [file.rom] [file.rom] > [new file.rom]
Wanted to post an update to this thread as it had been a couple of years since I started it. I recently checked the Mac support for the Minipro program. The code has been branched and the new maintainer has made it very easy to install using homebrew: https://gitlab.com/DavidGriffith/minipro/
While it does not have a graphical user interface, the command line interface worked without a hitch (and is so much easier than running a windows VM to use TL-866CS).
Wanna join the discussion? Please sign in to reply to this topic.
Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
This page was printed from https://pinside.com/pinball/forum/topic/lyonsden-not-so-guide-to-eprom-programming and we tried optimising it for printing. Some page elements may have been deliberately hidden.
Scan the QR code on the left to jump to the URL this document was printed from.
Vail, AZ