What's new
By:
Filters

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

By the way, that date string rtw mentioned, it shows up in the lower right corner of the test mode special ver. screen:

1668147300800.png


Here is the what the MAME set looks like, it instead just shows the current date/time:

1668147322586.png
 
According to @MetalliC.

Ibara does a strange sanity check on the RTC. If it passes the game version is printed on top of the date/time string.

If it does not pass the game will show the default date/time string which in MAME will be the current time.

On real HW, the RTC will be initialized with default values i.e.: '05.03.22'
 
right, recently dumped by @alamone set (which is main Ibara set in MAME now btw) when boot to special mode test mode always show its build date, while older revision show there current RTC time instead. that's what you see on screenshots above.

many of real Ibara PCBs owners does remove battery (in the scare if it may leak and damage the PCB), in this case older revision will show '05.03.22 - default date set by game after failed RTC check.
 
  • Like
Reactions: nem
alamone said:
Somewhat of a necro, but I'm doing some CV1000 things (aiming to develop practice mods for DFK 1.5) and was testing the various methods of JTAG.
So far I've been able to successfully skip the boot-up test sequence using MAME and write the modified code back to the PCB.

For reading 0x10000 bytes from U4, my rough benchmarks as follows (both using URJTAG):

Altera compatible USB Blaster (Waveshare branded): 1 minute 6 seconds
Tigard (FT2232 based): 11.6 seconds

So, to dump an entire U4 (0x400000 bytes for D type board), it would take approx. 43 minutes w/ USB Blaster and 7 minute 44 seconds for Tigard.
I'm assuming that write speeds are similarly faster for Tigard.

To get the python scripts working w/ Tigard, I had to use a line similar to the following to define the cable, wherein each parameter is a separate string:
self.c.cable("ft2232", "vid=0x403", "pid=0x6010", "interface=1")

I'm doing development using WSL2 / Ubuntu on Windows 11, which works fine using these instructions to passthrough the USB devices to WSL2:
https://learn.microsoft.com/en-us/windows/wsl/connect-usb

I also see that there's a FlashCat USB Pro for doing JTAG, which might have even better performance:
https://www.embeddedcomputers.net/products/FlashcatUSB_Pro/
Click to expand...
I bought a Tigard, seems fun. What frequency do you set in urjtag when interacting with the board?

Basically, it is FT2232H based, but the default urjtag instructions for it has it used as FT2232 which has a 6mhz cap apparently. Still faster than the Altera though, but feels like this should be possible to tweak a bit...

I'll just try changing this value #yolo
https://github.com/shuckc/urjtag/blob/master/urjtag/src/tap/cable/ft2232.c#L49

edit: Well, urjtag reports 12000000 as frequency used now, but its not really reading faster. Weird.
 
Last edited:
If you compile your own urjtag the frequency calculation should be fixed.

urjtag has a command called: frequency

Use your Salea to measure TCK
 
rtw said:
If you compile your own urjtag the frequency calculation should be fixed.

urjtag has a command called: frequency

Use your Salea to measure TCK
Click to expand...
Yeah I'm compiling it myself and increased the cap for FT2232.
I'm just wondering what frequency I should actually use :)

Reading at 6mhz vs 12mhz didnt seem to make a huge difference unless I fucked something up.
I'll hook up an oscilloscope to the clock signal later to verify if it actually changed.

Either way its faster than the usbblaster though
 
Can you share with us how you compile it for Windows ?
 
And then I do "cable ft2232 vid=0x403 pid=0x6010 interface=1" ... which caps it at 6mhz since it doesnt know its a ft2232h device (it thinks its ft2232 without H which has separate limits in code)

I didnt see an obvious way to get it to act like one. Probably needs further changes to the code. Just changing max frequency might not be sufficient
 
Same as me then, but a win build would be nice outside of WSL.

In the UrJTAG source code there are structures which describe your tap. You need to copy the details from a ft2232h into a new structure. I did it once but I am not at my machine just now.
 
Yeah that should be fine.
Sortof feel like I should just do the extra work and define a new Tigard specific tap with FT2232H then. We'll see
 
FWIW, even with untweaked default settings, Tigard does seem a fair bit faster at least.

I did a full U2 dump of a game I had with issues. Started it on Friday evening and it was finished at Sunday morning. Took around 30h I think (didn't time it, but based on estimate from looking at process on Saturday evening). That's uh... not fast, but manageable. With USB Blaster it's like 3-ish days.
 
Not sure how this happened, but my Muchi Muchi Pork PCB was exhibiting symptoms on one sprite that are similar to the one in the OP. However, after a recent boot-up, the problem is gone. I wrote about it here (with video to prove it):

https://cave-stg.com/forum/index.php?topic=1949.0

In this thread I read there is no error correction in the CV-1000 NAND, but it's hard to imagine how this PCB could "fix itself" unless there is, at least in Muchi Muchi Pork. Has anyone looked into this game specifically?
 
There is no error correction in CV1K.

Did this glitch occur many times ? I.e between power cycles ?

Did you change the voltage of the PCB ?
 
rtw said:
There is no error correction in CV1K.

Did this glitch occur many times ? I.e between power cycles ?

Did you change the voltage of the PCB ?
Click to expand...

It only occurred a few times. I think it did occur between one power cycle, but then I didn't turn it on again for 2.5 months (until today), and then the glitch was gone. Voltage was not changed (same supergun each time). Voltage is set to 5.03 ~ 5.04. I used to play this game on a supergun with the voltage set to 5.07 and I never saw the glitch then.

If there is no error correction, why has the glitch disappeared? Do you think the voltage is to blame?
 
Last edited:
My best guess is that the first failure was some bit going bad, causing decompression of that asset to fail (mmp uses a very cursed compression algo btw).

Then some other bit went bad in the same (bad) block, in a way that caused decompression to succeed, but with some incorrect pixel colors rendered.

Otherwise i dunno.

It would be possible to verify that using s jtag dump
 
Interesting ideas, thanks guys. I'll look into that extended test menu.

I don't have the equipment (or know-how) to do JTAG stuff, unfortunately.
 
Last edited:
I did the TGA test in the extended test menu. It took awhile, but I found one frame of one sprite that was causing the previous issue. In frame 01E4=228, I found the glitch:

zWvtGwUh.jpg


All the other frames of this sprite are fine, for example 01DA=218:

E07dmbeh.jpg


However, after doing this test I played again and still didn't see the glitch on the sprite in-game. Maybe the game is not loading that glitched frame, it's just skipping it? That's the only thing I can think of.

No other glitches were found in any other sprites, thankfully.
 
Last edited:
Thanks for checking.

This is my theory. Your NAND is slowly getting worse around this page/block. Initially the corruption was small and the asset could be decompressed without flagging any errors. As time goes by the NAND corruption increases and now the decompression fails meaning that the asset is not copied to VRAM at all giving an indication that the issue is fixed.
 
You must log in or register to reply here.
Back
Top