What's new
By:
Filters

Espgaluda 2 (CV1000) repair of bad U2 NAND using JTAG

Yeah I'll do a dump of U2 later, right now I'm troubleshooting an issue with my G4 hack where the checksum works correctly in MAME but is BAD when on PCB, checksum is off by 2, very weird...
 
rtw said:
The advantage of dumping the whole U2 is you just start it up and then do something else :)
Click to expand...
Oh definitely, a full u2 dump of this would be great.

rtw said:
Thanks for the info @buffi, I was not aware that this was an issue in Ibara. Many of the CV1K dumps were actually done twice to combat NAND issues.
Click to expand...
This is highly unlikely to be a bad dump. The bug is in four different spritesheets (bug in 788-791 in WL, fixed in 773-776 in BL).

Other than some of the more obvious changes like bullet and item colors, there's also a minor fix in the ending text, where they stopped using parenthesis in BL, see example:

WL Asset #877
u2_877.png

BL Asset #862
u2_862.png


This is also done for the two assets following that one in BL and WL
 
Maybe we should have a separate Cave JTAG thread from this repair thread btw.

Wasn't really sure how kosher that was with all the rules around that on this forum, but I was told posting repair info was explicitly ok so hey.
 
alamone said:
Yeah I'll do a dump of U2 later, right now I'm troubleshooting an issue with my G4 hack where the checksum works correctly in MAME but is BAD when on PCB, checksum is off by 2, very weird...
Click to expand...
Nice, pardon my question but what is the G4 hack ?
 
@buffi good idea, looking forward to more of your deep knowledge of U2 anomalies :)
 
G4 = Gradius IV. The checksum for 27P shows as "OK" in MAME but "BAD" in the actual PCB when I'm testing using all options enabled. It's only off by 2 values which is weird. Older versions seemed to have passed the checksum fine on PCB so I'm wondering what changed since then.

http://alamone.net/g4tool/
 
Thanks for the info, that looks like a very nice tool!
 
rtw said:
@buffi good idea, looking forward to more of your deep knowledge of U2 anomalies :)
Click to expand...
I haven't looked too much into other stuff tbh. Was mostly curious on what the differences between Ibara WL and BL were.
There's a handful of bigger changes, but these two things are just small bugfixes
 
alamone said:
Hi, I did use the NAND adapter for that one, it still did not work. But I believe the problem is with the clip, as I tested it out with some memory chips not mounted on PCB and it exhibited the same problem with bad reads past 0x8000, which to me indicates that the address lines past that are not making good contact or are faulty on the clip. I'll have to take a look at the source code to see if I can resolve the undetected chips problem, but that might also be a clip related issue. I don't think it's a bus contention issue as I am halting the CPU before doing the read.
Click to expand...
Oh, what I've meant is that in the source code of the Flashcat software you can check flashmemory.vb to see the whole NOR flash definitions and if yours aren't there you can add them.
 
I fixed the G4 checksum problem (well just bypassed it forcibly) so I'm now starting the dump of U2.
Using Tigard, it reads 10 pages in about 7 seconds, so it should take around 13 hours for a full dump.
 
alexcom said:
Oh, what I've meant is that in the source code of the Flashcat software you can check flashmemory.vb to see the whole NOR flash definitions and if yours aren't there you can add them.
Click to expand...
Yeah that's def. a plus that they release the source code so it's easy to add new definitions. Their support seems to be also pretty helpful if you have issues. Initially I had problem with their DIP42 adapter which they resolved with a special firmware command.
 
Thank you @alamone your U2 contains the exact same assets as the existing dump except asset 496 which has 1 byte difference.
 
At this point I would try to read out asset 496 again, just to verify.
 
Relevant diff is just one bit in 0x3E25901.
This should be in page 482 (each page is 0x21000 bytes)

If you are using my JTAG tools, could you please run:

Code: 
sudo python3 K9F1G08U0M_JTAG.py read_page --filename=pg.bin --page=482

A few times, check that they produce the same value and then paste that here. Each run should be very quick since it's just reading one page.

The byte on offset 0x3901 reads 0x10 in the new dump, and 0x00 in the old one. (It looks very much like the dump in mame is the correct one)

Looks like either bad dump, or possible NAND corruption
 
Last edited:
Hi, I ran the page dump 3 times and got the same data each time. It is attached. I used the command you provided. I assume you meant each page is 2112 bytes, and each block is 64 pages, which means it should be in block 482. If that's so, should the page number be instead 30854 (0x3e25901 / 0x840)?
 

Attachments

  • pg1.zip
    1.1 KB · Views: 70
Last edited:
Here is page 30854, which is the correct page I believe. Offset 0x781 is 0x10 in this dump. As with before, I did 3 dumps and they were all the same. So it looks like it might be a bit flip or NAND corruption as you say, assuming the MAME set is the correct dump. I'm guessing that the error correction area is unused in the cave PCBs.
 

Attachments

  • pg30854.zip
    463 bytes · Views: 47
That is correct the error correction area is unused in CV1000.

if you look at the images your dump contains a single bit flip in an area of black so my belief is that this is NAND corruption.
 
alamone said:
Hi, I ran the page dump 3 times and got the same data each time. It is attached. I used the command you provided. I assume you meant each page is 2112 bytes, and each block is 64 pages, which means it should be in block 482. If that's so, should the page number be instead 30854 (0x3e25901 / 0x840)?
Click to expand...
Yes, you are 100% correct. For some reason my brain switched the meaning between page and block, and I remembered it as the tool was dumping blocks, but it's actually pages.
alamone said:
Here is page 30854, which is the correct page I believe. Offset 0x781 is 0x10 in this dump. As with before, I did 3 dumps and they were all the same. So it looks like it might be a bit flip or NAND corruption as you say, assuming the MAME set is the correct dump. I'm guessing that the error correction area is unused in the cave PCBs.
Click to expand...
rtw said:
That is correct the error correction area is unused in CV1000.

if you look at the images your dump contains a single bit flip in an area of black so my belief is that this is NAND corruption.
Click to expand...
Yep, looks like it's probably NAND corruption. Unlikely to matter much here. If you run into more issues with those sprites later, you can use the steps in page1 to move the assets in that block somewhere else.

Sortof happy that the bitflip was present in your later dumps as well, since that sortof validates that the JTAG dumping works as expected (I haven't tested it for full U2 dumps more than once)
 
You must log in or register to reply here.
Back
Top