Game freeze upon CATSFC menu open #31

Closed
HitsuMaruku opened this Issue Feb 8, 2013 · 8 comments

Comments

Projects
None yet
2 participants
@HitsuMaruku

Version: CATSFC 1.28
Game: Final Fantasy IV (J) [Translation patched]
Steps to produce:

  1. Load game
  2. Loaded save state (manual)
  3. Restarted ROM from menu
  4. Load from SRAM
  5. Played ~5min
  6. Saved game to SRAM
  7. Pressed tap-area with thumb to bring up CATSFC menu

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.

@Nebuleon

This comment has been minimized.

Show comment
Hide comment
@Nebuleon

Nebuleon Feb 9, 2013

Collaborator

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.

Collaborator

Nebuleon commented Feb 9, 2013

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.

@Nebuleon

This comment has been minimized.

Show comment
Hide comment
@Nebuleon

Nebuleon Feb 9, 2013

Collaborator

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.

Collaborator

Nebuleon commented Feb 9, 2013

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.

@HitsuMaruku

This comment has been minimized.

Show comment
Hide comment
@HitsuMaruku

HitsuMaruku Feb 9, 2013

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 FINAL01.RT0, DRAGO01.RT2, etc., but others were left intact. Names were changed without reference to the different games (e.g. FF4 .rts files were renamed and interspersed with FF5 .rts files).

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?

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 FINAL01.RT0, DRAGO01.RT2, etc., but others were left intact. Names were changed without reference to the different games (e.g. FF4 .rts files were renamed and interspersed with FF5 .rts files).

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?

@Nebuleon

This comment has been minimized.

Show comment
Hide comment
@Nebuleon

Nebuleon Feb 9, 2013

Collaborator

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.

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.

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.

Awesome!

I noticed that CATSFC was the only subfolder on the drive
that had issues; I use all of my emulators on a regular basis.

Supercard-forumers noticed that too: http://forum.supercard.sc/forum.php?mod=viewthread&tid=6487&page=7#pid45770 (September 2010)

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?

Correct. Pre-1.28 CATSFC wrote garbage, and post-1.28 can't read it back.

Collaborator

Nebuleon commented Feb 9, 2013

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.

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.

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.

Awesome!

I noticed that CATSFC was the only subfolder on the drive
that had issues; I use all of my emulators on a regular basis.

Supercard-forumers noticed that too: http://forum.supercard.sc/forum.php?mod=viewthread&tid=6487&page=7#pid45770 (September 2010)

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?

Correct. Pre-1.28 CATSFC wrote garbage, and post-1.28 can't read it back.

@HitsuMaruku

This comment has been minimized.

Show comment
Hide comment
@HitsuMaruku

HitsuMaruku Feb 11, 2013

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.

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.

@Nebuleon

This comment has been minimized.

Show comment
Hide comment
@Nebuleon

Nebuleon Feb 11, 2013

Collaborator

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.

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 fopen(name, "wb"); for the same name as was used to initially write it. That's the name of the ROM without its extension, concatenated with _statenumber.rts

Collaborator

Nebuleon commented Feb 11, 2013

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.

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 fopen(name, "wb"); for the same name as was used to initially write it. That's the name of the ROM without its extension, concatenated with _statenumber.rts

@Nebuleon

This comment has been minimized.

Show comment
Hide comment
@Nebuleon

Nebuleon Apr 1, 2013

Collaborator

Assumed to be fixed as of CATSFC 1.34.

Collaborator

Nebuleon commented Apr 1, 2013

Assumed to be fixed as of CATSFC 1.34.

@Nebuleon Nebuleon closed this Apr 1, 2013

@HitsuMaruku

This comment has been minimized.

Show comment
Hide comment
@HitsuMaruku

HitsuMaruku Apr 6, 2013

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!

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment