Oh definitely, a full u2 dump of this would be great.The advantage of dumping the whole U2 is you just start it up and then do something else
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).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.
Nice, pardon my question but what is the G4 hack ?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...
I haven't looked too much into other stuff tbh. Was mostly curious on what the differences between Ibara WL and BL were.@buffi good idea, looking forward to more of your deep knowledge of U2 anomalies
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.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.
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.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.
sudo python3 K9F1G08U0M_JTAG.py read_page --filename=pg.bin --page=482
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.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)?
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.
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.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.