Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Game freeze upon CATSFC menu open #31
Version: CATSFC 1.28
Upon step 7, emulation froze. Menu did not appear, and neither taps nor buttons functioned. Closing lid did not trigger sleep mode (which was implemented recently even for CATSFC menu). Upon DS hard reset, I was able to reload SRAM from step 6.
Could not reproduce; simply posted for your convenience. Feel free to close the issue if you find it might simply have been bad luck on my part.
Might it be filesystem corruption? It has unfortunately appeared at random ever since NDSSFC 1.06.
With the card in your computer or a card reader, do you see oddly-named files in the real-time save directory, /CATSFC/gamerts? Does a filesystem check report a bad directory structure, duplicate file names or other such errors?
In 1.29 I will compile with new library additions by GBAtemp user BassAceGold, and he has worked on the filesystem access a fair amount. I will try your steps with a(nother) game I own and report back.
Just tried with Super Mario World, using similar steps (6. Get to a castle or ghost house, saving to SRAM) in the latest code. It may have been a fluke in your case, or the connection with the microSD card may have not been fully secure and it errored when accessing a file.
I noticed it a lot using NDSSFC, but since BAGSFC fixed it, I haven't noticed until just the once today; so as I said, not a pressing issue. Regardless, I took your advice:
No odd file names, just the normal .rts and .srm files. Even using the folder options "Show hidden files" and "Show system files", I saw nothing out of the ordinary, and no duplicate naming.
Did a file check via Windows tools from properties menu (yeah, I should have used Linux, but I didn't want to reboot), and it found (and automatically changed) duplicate file names. Some .rts files were renamed FINAL
Did a second file check, and it found "nonvalid long folder entries", which it "removed". No noticeable change in navigable directories.
Did a third check, and it found no problems.
I suppose this would fix the problems, but I don't like that it changed file names on me when they all had different file names. That'll teach me not to use Windows utilities. <.<; Thank God I back up my card.
Renamed files according to my backup, modified dates, etc. Did a final check and found no errors. Reloaded into DS2 and works as it should.
I noticed that CATSFC was the only subfolder on the drive that had issues; I use all of my emulators on a regular basis. For a better understanding, is it that CATSFC incorrectly saves files to FAT filesystems, and when it loads an invalid reference it causes the crash?
That line may be the resolution to the bug. The thing is that BAGSFC must have been compiled by BAG using his own library, and he must have been working on his filesystem stuff already.
So I think the problem is that it now wants correct file names, but CATSFC before 1.29 (and to some extent, 1.28) compiled against non-BAG libraries, so it output garbage file names. CATSFC 1.29 is really the CAT-NEB-BAG-NDSSFC 1.29 release, because it actually uses all improvements made by everyone. (And the SDK modifications are now in this project's source, so anyone else can build upon them correctly.)
For now, do fix all of the card's filenames, and report back if any more file bugs occur, but it might be over now.
Supercard-forumers noticed that too: http://forum.supercard.sc/forum.php?mod=viewthread&tid=6487&page=7#pid45770 (September 2010)
Correct. Pre-1.28 CATSFC wrote garbage, and post-1.28 can't read it back.
Played only FF4 this time. Multiple SRAM saves and save state saves (this time only on 1 and 2). Current version I believe is 1.28.
Checked files like last time. First check resulted in duplicate file names once more, this time only with the two save states that I modified. Details revealed more than 2 duplicates.
Second check again resulted in removal of "long folders". Third check showed problems resolved.
As a simple speculation, it seems to me that 1.28 writes new save states and redirects pointers (instead of literally over-writing previous save state information) and does not erase the old data.
I will upgrade to 1.30 and test again in the same fashion.
That's what versions of CATSFC before 1.19 did; they wrote to a new state and updated a map of states and their numbers.
CATSFC 1.19+ actually overwrites the file by using
Sorry that I hadn't gotten back to you. Started a new job after graduation and hadn't had time to play until last night. Working fine, no errors. Seems fixed to me as of 1.30. Upgraded to 1.34 this morning, and I will post any feedback if relevant.
As always, thank you for all of your efforts, Nebuleon!