nesdev.org

Several RPGs show some basic stats from all files on the file select screen. Final Fantasy VII for PS1 acts this way. If your file is corrupted enough to crash the subroutine in CT's file select screen that displays information about a file, it could cause behavior like what you describe.

I didn't think about that but it makes sense to me now. Seems like a pretty nasty flaw in the game's code to me that it can't handle that. I think it should have been a concern of theirs even though most people wouldn't run into the issue, it could certainly happen outside of building a repro.

Maybe this has to do with a name that does not contain only standard letters A-Z or a-z ? Just my 2 cents.

Also I'm pretty sure that CT does more than just a simple checksum to verify the validity of saves. With FF2 on the NES I was able to increase my HP and by decreasing another byte the same amount, the checksum was passed and the save was considerd valid. This didn't work for CT. Maybe it checks the sum of all bytes and the XOR of all bytes and both tests have to pass ?

Bregalad wrote:Maybe it checks the sum of all bytes and the XOR of all bytes and both tests have to pass ?

That's what Mario Paint does. Some games might use CRC. But no matter what hash algorithm you use, the hash of an inconsistent data set is still a valid hash.

I've built several custom SNES cartridges in the past and so far, I've never ever had to erase the SRAM in order to get the new game to work on the "donor" PCB.

Cali wrote: the game cannot boot up while the data is in there.

What makes you believe that?

Cali wrote: i must delete the sram, cause its full of garbage data...

If you have access to the SRAM on the cart (which you obviously have, otherwise you wouldn't be able to know that there is "garbage data"), why don't you just upload an empty SRM file onto it (i.e., a file filled with $FFs)? This would be the easiest and most hardware-friendly way to erase the SRAM.

Anyway... From what you describe, I'm pretty sure that the cause of your problems is to be found on the hardware side. Either you've blown the cart by using that 9V battery of yours on it, or those freezes are caused by poor contact between the cart and the SNES (which they are in 99.9% of all cases).

My last assumption would be that your console is faulty. Try playing Super Mario World on it for at least 14 hours and see whether you encounter a freeze/crash.

Sorry to re-float this thread. I don't know if it is against the rules, but I thought it would be better to post here.

I have EXACTLY the same problem with my Chrono Trigger repro. I did two of them: one on a japanese version of the game, and the other one on a japanese version of Dragon Quest VI (both use the same board). I changed the CIC in the first one to make it PAL, and the other donor board remained unchanged.

Well then, now the PAL version works properly, but not the NTSC one, which was done using Dragon Quest VI's PCB. I think it has something to do with SRAM too. The game checks $30:7FF8/FA/FC on SRAM and I think if data there is not the expected data, the game hungs.
I also have random hungs while playing, like our friend Cali.

The ROM I'm running is tested on a GameDoctor, so the problems aren't caused by the spanish patch.

I've built one repro using 4 M27C801 and the other one using 2 M27C160, but I think it hasn't nothing to do with all this trouble either...

Any ideas? Is there any way I can't trace at which opcode the game hungs using SF7?