Thunder Force V - Perfect System frozen on "NO MEMORY CARD DATA" screen

[SageSandwich]

Before opening this kind of issue, please ensure:

• Are you using a compatible console version?
• Are you using CD-R media, and not CD-RW?
• Did you copy all the files in the expected format to the memory card?

tonyhax version: 1.44 / 1.45 Installation method: Transferred the files to a memory card via uLaunchElf on PS2 Entry point game: Tony Hawks Pro Skater 2 Console model: SCPH-101 Integrity check: Passes BIOS version: V4.4 Target game: Thunder Force V - Perfect System (SLUS-00727)

Bug explanation: After the game boots, the game remains frozen on the screen which displays the text "NO MEMORY CARD DATA" in the bottom right corner. What is supposed to happen, is that the game would display this text for a second or two and would boot to the main menu.

[alex-free]

Had some time to test this out. I am using a SCPH-5501 in great refurbished condition, original Tonyhawk Pro Skater 2 USA disc, and the save game exploit to boot into a Thunder Force V - Perfect System USA burned at 10x to a high quality Verbatim DataLifePlus CD-R exactly as was done by SageSandwhich.

Results: Tonyhax v1.4.5 - Fails exactly where SageSandwhich says. Tonyhax International v1.2.2 - Works perfect, gets past that screen after a short disc seek or two...

Socram, this could be a number of things. AP-conflict, or maybe the latest changes I made to v1.2.2 of International is making it only work on my fork and not yours. I added a number of BIOS functions to mimic the official BIOS booting of games more closely in the last update to my fork. SetMemSize(8), InitDefInit(3), and SysInitMemory (0xA000E000, 0x2000). The original Tonyhax here does zero out the 0xA000E000 range for 0x2000 bytes, but the BIOS does SysInitMemory and does not zero it out like you are. I replaced that just recently in my fork to fix a different booting issue involving my new GameShark code boot method.

[socram8888]

@alex-free those aren't really needed - the SetConf call already calls SetMemSize, InitDefInit and SysInitMemory (https://github.com/socram8888/tonyhax/blob/master/loader/bios.c#L61-L73)

[alex-free]

@alex-free those aren't really needed - the SetConf call already calls SetMemSize, InitDefInit and SysInitMemory (https://github.com/socram8888/tonyhax/blob/master/loader/bios.c#L61-L73)

I can't really explain it, but without doing those explicitly my fork would get stuck on the doexecute call when using my new GameShark code entrypoint.

The GameShark code thing puts the console into a really weird state. Basically I am changing a jump instruction to go to a free address in RAM that contains the stage 1 loader which then loads the Tonyhax PS-EXE from a memory card pretty much like the save game exploit entrypoint. I was having an issue though with booting specific games this way when using my code for ridge racer USA, this fixed it for whatever reason.

I do believe the BIOS calls these functions and calls setconf. While it makes sense that it wouldn't be needed we both know the BIOS is a buggy mess.

In this case though it's probably an AP-conflict.

[socram8888]

The only explanation I can find is that, since (AFAIK) you are not clearing the RAM, some structure left in it could be interfering with the DoExecute call.

The DoExecute call in particular is incredibly simple since it only loads some registers from the executable header and then blindly jumps to it, so I'm not sure what could be causing that.

[socram8888]

Also regarding the bug in hand - this is probably related to the FreePSXBoot patch which gets injected in the memory card read loop. I've not had time to check and not sure when will, though.

[alex-free]

The only explanation I can find is that, since (AFAIK) you are not clearing the RAM, some structure left in it could be interfering with the DoExecute call.

The DoExecute call in particular is incredibly simple since it only loads some registers from the executable header and then blindly jumps to it, so I'm not sure what could be causing that.

I am indeed clearing the RAM, since removing all FPSXBoot patches a few versions ago in my fork due to so many issues encountered by them. Before that, I was indeed not resetting the BIOS A/B/C tables (that is what I meant about not clearing the RAM previously). The reason was to not wipe out the FPSXBoot builder patch it installs via the payload in stage 1.

Ever since removing the patches though, I have since had the same bios_reinitilize() function as the original Tonyhax up until now. This is what my bios_reinitialize function looks like now:

https://github.com/alex-free/tonyhax/blob/7fa5d0889d0cdb2839debcdab5fbeb6dc7c68d93/loader/bios.c#L13

This is what it looked like before (when doexecute would hang)

https://github.com/alex-free/tonyhax/blob/ecedc0e94688a999257eda2bda74d99dfd099482/loader/bios.c#L13

Notice how the above is literally the same as the one still in Tonyhax currently right now. Again, I never experienced this except for using the GameShark code to hijack the jump in Ridge Racer, and then using Tonyhax International started that way to boot into a specific game disc.

[alex-free]

@socram8888 ha I figured it out. Only SetMemSize(8) is neccesary to fix my fork. The other 2 things are indeed redundant exactly as you said.

My theory is Ridge Racer is using the same call at boot to set SetMemSize(2). Some games are known to do this. But the BIOS always essentially expects to boot games with a SetMemSize(8) setting.

The SetConf call does not set SetMemSize, you don't mention it in the code comments and I can reproduce the stuck at doexecute() issue with Ridge Racer USA GSHAX Code entrypoint by just commenting that out.

https://github.com/alex-free/tonyhax/blob/e768967c1c08097ff9b25a4f299940b123d8ae33/loader/bios.c#L48

is what my bios_reinitialize() looks like now.

Of course, the original Tonyhax doesn't have an entrypoint from any such game that is affected... my fork does though at least with Ridge Racer. It still might be a good idea to add that call for consistency with how the real BIOS boots exes.

[socram8888]

Good to know, thanks for the investigation! Will add said call, just in case.