nesdev.org

So I think I already know the answer, but I'll put this out anyway, to get more insight.
Over the weekend, I burned a NROM to eproms and my Willem verified them as good; used 27c256s for both (4xCHR bin). Then I tested them on my socketed cart and the program seemed to work, but thinking back I was too hasty because there were a few bad/wrong tiles that I wrote off to a bad cart edge connection.
So today I transferred the eproms to a ReproPak board. The program itself runs fine but the CHR issue with the tiles remains. Maybe 6 or 7 bad tiles that show up at the same spots after a powercycle; so bad data or bad hardware?
What gets me is the Willem verified the eprom as good, I assume it's just a bad device; was a pull from god knows where. Or could this be an issue with the split .nes; I used a web page version of readNES that will pad the bin as needed, http://www.kevinselwyn.com/ReadNES/. I've used it before and it seemed to work fine, but I haven't compared the output from two different runs. Can someone recommend a free Hex editor that can compare two bin files?
I'm going to burn the same image to different chips and test on the devCart, a bad bin should be apparent if the errors are the same on both carts.
Yogi

If you look at the CHR in a CHR viewer or editor (such as FCEUX or Nintedulator's debuggers, or NESst), is there a pattern to which tiles are damaged? If so, it might be a connection issue.

Otherwise, I'd suspect a flaw in the UVEPROM.

I don't know of a good windows-friendly file comparer or wotnot. If you dump the CHR back from the UVEPROM and load it in NESst you can visually compare the original and the redump.

OK I'll load up FCEUX, only been using Nestopia but it doesn't seem to debug. Just hoping that there was a byte-for-byte compare tool, seems like I used one a long time ago.
I'm thinking a bad EPROM also; what bakes my head is the Williem verified it. Maybe the chip failed after programming during the install in the socket? Doesn't seem to likely, but IDK.
Oh well, off to fire up the burner, Thanks lidnariq
Yogi

I always use HxD which is a hex editor :
It is portable
It is a free tool
It has a very user friendly GUI
You can compare two files with it even with different length!

FARID wrote:I always use HxD which is a hex editor :
It is portable
It is a free tool
It has a very user friendly GUI
You can compare two files with it even with different length!

+1, HxD is the best free hex editor for Windows. I used to use XVI32, but it's a piece of shit compared to HxD.

Good call Farid, HxD is what I was looking for.

Unfortunately I'm still confused. Last night I burned a new set of '256 eproms with the original bin images and installed them in my socketed NROM devCart. They showed the same sort of errors.
Then I split the .nes again with the PHP readNES again and burned both a 4x CHS to a 27c256 and a 1x CHR to a 2764 (thinking there might be a issue with the 4x). Switched these CHR roms onto the devCart and both had the tile errors.
Using HxD I compared the old 4x CHR image with the new 4x, and the 4x with the 1x image. All are identical.
Also tested other carts in the NES, they ran flawlessly without having to reseat at all.

So:
1. Could be a corrupt CHR bin file. The original .nes runs perfect on emu, so could be a bit error introduced during the readNES split.

2. Could be a problem with the Willem programmer.

3. Could be 4 bad CHR EPROM chips, 3-27c256 and 1-2764

4.
A. Both the ReproPak and the re-purposed NROM carts are not making a good connection to the 72 pin; causing the same type of error on both.
B. Both carts have a problem with the installation of CHR eproms.
C. Could be a problem with the 72 pin connector that only effects these two carts.

Of this list, #1 seems like the most likely. Even though the other times I have used the web readNES it had worked fine. Next I'll split the rom with uCON64 and compare the two. I'll also try FCEUX's debug out.
The other possibilities: 2 & 3 seem very unlikely and #4 is only a little more probable.
So did I cover the possible causes or is there something else?
Yogi