Making a EPROM Burner

I am on an extremely tight budget and need to have a way to develop NES games, but I cannot spend more than $30. I have an Arduino Uno and an Arduino Leonardo, some 4021 Shift Registers, and I want to know if that is enough to make an EPROM burner / programmer. I need to be able to burn 256kb EPROMS (I'm going for a total of 512kb when PRG and CHR roms are both included) and I am relatively new to EPROMs and hands-on electronics. I have a working knowledge of the 6502 and 2A03, as well as lots of documentation.

so my question to you is if I can make an EPROM burner / programmer that can make these, a good explanation for beginners of how EPROM programming / burning is done.

...And just in case they exist, are any $30 or less EPROM burners / programmers? I don't care if it uses an LPT, 9 pin D-SUB, USB, or, hell, even RS/232 or a beBox Geekport. As long as it works, I probably have the required hardware somewhere, or know someone else with access.

...And no, I don't want a copyNES and a powerpak lite. The powerpak lite is cheap enough, yes, but the copyNES is $70 and I really don't want to go more than $5 or so over budget.

Okay, so now I've ranted, and I would really appreciate a reply, even if my hopes are in vain.
And I'm really new here, so please correct me if I said anything incorrect, and please help me figure out which EPROMs I would use. I want to be doing MMC3 development, and I need compatible 256KB EPROMS (one CHR and one PRG).

My neighbor used to work for Verizon, and he actually has a really great repetoire of knowledge of the 6502, the 8086, and a lot of other old stuff. He gave me my soldering irons and he's really swell, so he can help me out if possible, but I need a poke in the right direction.
...Fun fact: the phone redirection systems at verizon still use 8080s! Isn't that weird?

If you're really on a tight budget and only looking to develop NES games I wouldn't suggest EPROMs. They have a pretty high initial investment with a ~$40+ burner and ~$10+ eraser. You can actually get started with flash/EEPROMs for quite a bit cheaper due to simpler programming and erasing abilities if you're willing to put in a little effort. If your handy with a arduino/microcontroller kit you can easily build yourself a flash/eeprom programmer/eraser. Or you can even build yourself a kazzo for well under $20 if you're good with an iron. I've written new firmware/software for dumping and flashing flash/eeproms that's compadible with Nintendo's original unmodified ASIC mappers like MMC1,2,3,4 etc. The software/firmware is kinda in the early beta release stages but I'm willing to share it as it currently is. The original creator's software/firmware is capable of doing the same thing I believe although the documentation is challenging as it is in Japanese and sparse.

If you must use preexisting microcontroller hardware, use ROMs that supports 5V-only programming, like flash or EEPROMs. I built a 28C64 programmer in ~two hours (90m wiring; 30m code) using a PIC and a C compiler.

EPROMs require 12V+ and that requires huge obnoxious repetitive buffer circuits that will eat into your budget. Don't do it.

I made a sst39sf040 programmer using an arduino uno and 3 74hc595.
The sst39sf040 (cost $2 in single quantity at digikey) is cheaper than some eproms and does not need 12v only 5v and it is still in production and it does not need uv light to erase.
Here is the wiring: Pin refers to the numbering on the arduino uno.
The D0:D4 to go A0 to A4
D5:D7 go to Pins digital pins 5 to 7
Pin 11 CE#
Pin 12 OE#
Pin 13 WE#
Pin 10 is the serial strobe for the shift register this must be connected to all 3 shift registers
Pin 9 is the storage register this also must be connected to all 3 shift registers.
Pins 2,3 and 4 is the serial output pins 2 is the LSB. Unlike pin 9 and 10 those are different per each shift register.
A0:A18 goto the output from the 3 shift registers. Make sure you have which one is LSB and MSB right.
I will warn you that this can get messy as there are lots of wires be careful and check your work. My program verifies every byte if you see any errors check your wiring.
Here is the part that runs on the arduino uno
https://github.com/ComputerNerd/sst39sf040-avr
Note that I used avr-gcc instead of the arduino IDE to compile this if you do not have avr-gcc it can be modified with ease just change int main() to void setup() and add void loop() {} at the bottom of the program and I think it will compile just fine in the arduino IDE.
And here is the part that runs on your computer I have only tested it on linux but I used a cross platform library so it may work on windows
https://github.com/ComputerNerd/sst39sf040-computerside
Also my code can be easily adapted to run on the very similar lower capacity chips. The sst39sf020a and the sst39sf010a. Just change the main for loop to run for less bytes.

Nice, a PDIP 5V flash chip still in production.

You have just saved my life. I am horrible with the physical aspect of electronics and while I like 9t I am not going to spend lots of money for a paralell port willem when i only have a paralell port on my 1995 ibm pc. Thanks for giving directions!

Would it need to be altered for a SST39SF020? I only need 2Mbit/256kb chips.
EDIT: That was stupid and a question you answered

And my desoldering iron is clogged; is there a way to remove the mask roms from my donor without one?

Can one make a MMC3 board into a TKROM board without too much effort?

A TKROM board is one of the many MMC3 boards, so your question doesn't make much sense...

Perhaps you mean, can you convert a TSROM (no battery) into a TKROM (with battery)? Both are MMC3 and identical aside from battery backing. If you splice in the battery baacking circuit from the wiki you should be able to make something like a TSROM work as a TKROM

You can snip the legs of the mask ROM chips with diagonal cutters or some such, and then smack out the heated leg remains of the PCB one by one until you have usable holes. Not ideal, but it's a solution.

So called desoldering braid is cheap and does job pretty well. Could be even replaced with an old stranded copper wire used for power supplies, used it in the past to desolder multi pin parts.

An extension of this method that I just remembered using for this exact purpose (successfully) is to, for each pin on the chip:

-Heat the solder on the pin for the chip
-Whack the cartridge on the table, solder-side-down
-Observe the solder blob now on your table and the de-soldered pin
-Cackle like a maniac
-Do this for each pin from step 1

Glad I can help anyways I forgot to mention that my program reads the device id before running you should get
Manufacturer’s ID 0xBF
Device ID (This depends on the chip) SST39SF010A 0xB5 SST39SF020A 0xB6 SST39SF040 0xB7
And there is the datasheet http://www.microchip.com/wwwproducts/De ... e=en549494

that is what I meant! Thank you!


sounds like a plan!

i have found two old award bioses. they are 29c020-21 chips. these are flash, right? will they work? they are the exact size i needed (2Mbit).

If you mean http://soft-manual.narod.ru/chips/flash ... 29C020.pdf then the answer is most likely yes however I hate to see part sacrificed. I don't think it is worth it to destroy a computer just for an NES game.

Don't worry I will dump the chips to flash images first. And I found these beauties in a pile of junk in a factory corner. I have the pentium II's and III's and in the future I may write the images to new flash chips, but right now they are just boards, no other hardware or power supply. I can try to find other chips first though.

...anyway, I have three of the chips, so if I ever need one I can place it into the board.

Thanks for the info and I hate to see stuff ruined too, but this already was. A stripped board.

What is the minimum write and read speed for the flasher? One of mine is 210ns per read/write.

About dumping the chips... I just committed a patch to my repo for both the computer side and arduino side that allows for the dumping previously it would always go into write mode which would erase the whole chip now it will go into dump/program mode based on which program on the computer you run. Go check it out
https://github.com/ComputerNerd/sst39sf040-computerside
https://github.com/ComputerNerd/sst39sf040-avr

I compiled these on my slackware box and they seem to work fine, but I will probably end up having to do all of this on Windows (My parents don't even know I have linux on a flash drive and they wouldn't be happy if they did because it's not something that they know anything about). Will this program compile in MinGW/msys? I haven't had a chance to try it yet, but I really am looking forward to messing with this once I get the 74hc595 registers. I'm glad that there's a dumping program now!

And to anyone who knows, should I get two 32 pin DIP IC sockets? I am a relatively poor solderer and I would like to know if there's a big risk of hurting the flash chips. I know they are pretty heat-sensitive. I can say that I successfully replaced the LED in my NES with a green one for fun, and that I did the 'extra audio channel support' hack (connect pins 3 and 9 on the expansion port) without any problems, but I am still wary of doing something wrong. What can I do to minimize the time applying the iron to the board (i.e. the best ways to prevent having to fix mistakes)?

Ok It does compile with mingw and it does not have any need for extra libraries than what is included.

I tried to compile it both with avr-gcc and with the arduino IDE using your directions; both gave me errors. Arduino IDE gave me 'not defined in this scope' (maybe the functions that defined them had to be called inside the setup() loop before they could be used?) and the avr-gcc I am working on and may have an answer to.

Could you please post all errors generated by avr-gcc.

Should have used the makefile. D'oh! It's working now
Now when my 74hc595's get here I can try it!
Also, I did end up ordering two sst39sf020's. They supposedly have a memory retention twice that of the 29c020's (according to the datasheets).

anyway, the error log was this:
http://pastebin.com/2jfd00zQ

Sorry for the double post, but I felt that this deserved a bump rather than an edit.

I compiled the avr and host pc programs successfully, and my stuff from digikey arrived today! I am ready to roll once I wire in the 74hc595s. Is there anything I have to be really careful not to do? e.g. if i wire 'x' up wrong, the flash chip will burst into flames?

Thanks for the help :D

Glad to hear it make sure you replace 524288 with 262144 in both programs so it works with the smaller capacity flash chips. Also for stuff that you should be real careful to do is not mix up ground and voltage that will kill the chip but don't expect flames just a bad smell in your room. Also for your flash chip there is no A18 that is Not connected. Also don't connect two wires to the same pin.

Thanks!

...By the way, how would I upload the output of avr-gcc to the arduino? Would I use avrdude? I just saw something in the makefile that can be invoked with
.

Is it okay to hit 'reset' on the arduino while a chip is not being written, but is connected? The LED flash would blink the WE# line a few times.
Would I have to change the makefile for an atmega16u2 (Arduino Uno R3)?
*EDIT*
That was stupid. There are two Atmel Chips on the arduino, ATmega16u2 for USB I/O, and ATmega328p for everything else. Sorry!

The arduino uno r3 uses an atmega328p the atmega16u2 acts as a usb to serial converter so in others you would want to change it to atmega328p however I believe I already have it set to that and if fact make writeflash should already be able to program your arduino uno r3 assuming that is is at /dev/ttyACM0 which the makefile is currently set to use if not you will have to change that. Also yes you do use avrdude make sure you have that installed.

Okay! I had to run make as root because I'm too lazy to set up valid permissions to access /dev/ttyACM0 as a non-root user, but it seemed to work! I still have to desolder my Mario 3 ROM chips and add a battery (TKROM conversion) but I think it's going to work! Thanks a million.

I would like to add that the 29c020 chips (which I did NOT try to write) cannot be written the same as the 39sf020 chips. they are pin-compatible for read operations, however, so I will dump those chips anyway.

On the 74hc595 chips, which pin is serial strobe? Is serial strobe 'SER' on this datasheet?
On the same datasheet, is 'RCLK' the storage clock? And is SRCLK what the 'LSB' and 'MSB' lines go to? (I know that LSB is 'least significant bit' and MSB 'most significant', and these are like the endian-ness, is that correct?)
Does pin 12 (OE#) go to OE on the shift register, the sst39sf020, or both?
I'm pretty sure that is correct, but I really am a software guy. I just love hardware, but I'm too tentative to fry anything.

OE# only goes to the flash chip. Serial strobe is the clock that is SRCLK this is common with a 3 shift registers (connected together) that goes from pin 10 on the arduino uno to pin 11 on the shift register. RCLK is the storage register think of this as a latch.
I also forgot to mention that Pin 10 on the shift register needs to be plugged in to 5v and pin 13 needs to be plugged into ground in addition to plugging in the vcc and gnd. SER (pin 14) is the actual serial data which I called the LSB middle and MSB. the LSB contains A7:A0 meaning that pins A7 thru A0 are connected to the flash chip and the 8bits come from the parallel output of the shift register. The MSB is pins A17(A18 for F040):A16 those get connected to the pins labled as such on the flash chip.
This datsheet http://www.nxp.com/documents/data_sheet/74HC_HCT595.pdf gives a nice brief sentance explaining what each pin does I find it less confusing than the other datasheet

Thank you for clearing that up; I have decoded paralell->serial shift registers before, but with little understanding of what the register was actually doing.

But does 'A7' go to the LSB's Q7, or Q0? I'm sorry but my knowing that the 6502 and 2A03 take big-endian is making my brain a bit confused, even though I know that the NES CPU is not involved in this process.

A7 goes to Q7 on the shift register that is connected to pin 2. A8 goes to Q0 on the shift register that is connected to pin 3 and so on.
So here is the address mapping
A7:A0 Q7:Q0 shift register pin 2
A15:A8 Q7:Q0 shift register pin 3
A7:16 Q1:Q0 shift register pin 4
note that the ':' symbol means anything in range of x and y.

Okay, I tried this and something's wrong. I am using a SST39SF020. This is the output I get when I try to write the PRG or CHR:

and so on. It begins with 'byte 255 at address 00001 should be x' though.

Is there a pin connection I need to make to the registers that I haven't made?

*EDIT*
I probably messed up when I forgot to connect the storage register and serial clock to any but the MSB. Trying it now. It seems to be working
Thank you so much for being patient with my stupidity.

By the way, whenever I attempt to dump the chips, the program freezes at

I don't know why, but the flashing was apparently successful.

Does anyone know a good place to go for a visual illustration of how to modify a TSROM board for eeproms/eproms/flash chips? I already have sockets installed and want to modify the tracks on the PCB unless there is an easier way. I only have two sockets, and don't want to order anything else, so I don't want a solution that requires two more.

Visual? This is the only one I'm aware of.

Thank you!

I managed to snap a lifted pin off of my CHR flash, so I am ordering more (and backups this time!) That really will help in the future, I think. And the flashing program seemed to work, nintendo8.

About the flash dumper getting stuck I think you forgot to change how long the loops run for. I updated my programs both the avr and computer-side to detect the capacity of the flash chip based on the chip ID. Also I merged the reading capabilities to the writing program to read instead of write specify -d after the file name I have not tested it but it should work if not please tell me.

[url][/url]
I did change the loop length, but when I get replacement chips, i will try the new one. thanks :)

And now, a dumb question:
If I don't have a dremel (i know I should), how would I cut the tracks properly?

Right now i'm testing my cart with a (hacked by me) copy of Earth Bound (zero). I read on this page:
http://datacrystal.romhacking.net/wiki/EarthBound_Zero
that there is 16 x 16kB PRG ROM and 32 x 8kb CHR ROM. are these then different sizes and do I need another chip (besides either 29c020 or sst39sf020)? Am I even splitting the file correctly, so together i have a 256kb PRG and a 256kb CHR (2Mbits each)?

I still think it is a software issue and not a hardware issue. Also if the game took smaller flash just don't connect all address lines to the NES cart and you only have larger flash just don't connect some of the high address lines.

Thanks, it's working it seems. I havent wired the chips in yet but i dumped the bios chips and they are good!
I think it would be good to add an argument like -s or --size that a user could use with unknown chips to dump. The 29c020 is read the same as any other chip (even the sst39sf020) but written differently, and since the 29c020 is half the default size, I think a chip size argument would be nice. I just edited the source code to alter the default size, but there should be an easier way.
example:

another possible way:

or:

Just an idea. I tried this with the code and while it is a bit overcomplex the way I handled it, it does work (at least, the first example does, because it uses the simplest format).

ONE PROBLEM:
It encounters a segfault when attempting to WRITE a sst39sf020 (2mbit chip). The old version (which I backed up) still will write them fine. It just won't dump correctly

console output with the new version (i did check that what I did was not the cause; it was not. your version had the same problem):


If you would like to test I have some extra sst39sf020 chips and could mail you one in a RohS compliant bag and holder. But they are cheap and I would prefer not to pay the price of the chip in postage (if you live in the United States/maybe Canada).

The old one and new one will only dump the SST39SF020 up to 0x023FFF, though (in decimal, it reads up through the 147455th loop). it works perfectly for the 29C020. Still, for all I know, the chip might not actually write properly either, since I can't dump the whole thing to check. Could I have the shift registers messed up? I don't think they are messed up.

And I have noticed that the led (CE) line stays on when writing is done. Is that the problem?

If possible, I would like to know how i would remap the pins using two sockets stacked on each other, to avoid snapping IC pins. Someone here
http://blog.tynemouthsoftware.co.uk/2013/02/commodore-vic20-repair.html
made a new kernal (sic) chip for his VIC-20, remapping pins with a 24 pin DIL header and a 28 pin socket. I don't have a DIL and am vehemently against ordering anything else at this point. Does anyone know if this can be done with two sockets, or if there's a way to make a socket's pins longer?

And can I wire this to my board just like an EPROM described here? Last time I did I don't think it worked, but I could have done something else wrong.
http://nesdev.com/NES%20EPROM%20Conversions.txt
The board itself is not messed up, i inserted the original Mario 3 rom chips into the sockets and the game ran. 'Earth bound' (the game i hacked and am testing with) will not, and neither will the unhacked version of earth bound.

I fixed the segmentation fault I believe also maybe the reason it is not dumping all the way is because linux is missing some bytes I have had some problems with 1megabuad on linux so I changed it to 0.5megabaud which works more stable. Also I do not need any flash chips the f040 is so similar to the f020. Edit I tested this and still get stuck while dumping I will try to fix it.

Thank you!

Up to where it gets stuck, the original file and the new one seem to match. I would like to point out that I was able to fully dump 29c020 flash chips, just not SST39sf020 chips. Have you tested the chips you burned with a repro cartridge? do they work? If not it may be the same reason.

I have not test it in a a cartridge but at one point I did have dumping working and everything was the same. I do not know what is causing the stuck glitch It does not make sense to me. I will look at it later.

The verification on my chips is good, but do you think it could still be bad wiring regardless?
this is getting to be a pain in the a$$, so i'm thinking of offering to pay someone to make me a repro.