Making a EPROM Burner

[tokumaru]

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

[wyatt8740]

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.

[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.

[wyatt8740]

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.

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

[wyatt8740]

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

[wyatt8740]

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)?

[nintendo8]

I did change the loop length, but when I get replacement chips, i will try the new one. thanks

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.

[wyatt8740]

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:

Code: Select all

flash  dumpedfile.bin -d -s 262144

another possible way:

Code: Select all

flash  dumpedfile.bin -d -s 2Mbit

or:

Code: Select all

flash dumpedfile.bin -d -s 2M

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):

Code: Select all

Waiting for RDY command
RDYReady recived
Waiting for RDY command
RDYReady recived
Manufacture ID: 0xBF
Detcted as: SST/microchip
Device ID: 0xB6
SST39SF020A

Chip is erased

Segmentation fault

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?

[wyatt8740]

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/201 ... epair.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.

[nintendo8]

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.

[wyatt8740]

I fixed the segmentation fault

Thank you!

I tested this and still get stuck while dumping I will try to fix it.

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.

[nintendo8]

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.

[wyatt8740]

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.