Using the 1.53 Windows port, I found that the first byte of a cheat will be set this way when I generate a cht file with an initial value of 0x04 (disabled and no saved value), load the rom, open the cheat dialog, enable the cheat, then close the dialog by clicking ok. The saved value is not saved to the cht file and the byte is set to 0x00 (enabled and no saved value). Now I close snes9x, reopen it and load the rom. At this point the infinite loop is encountered and snes9x has to to be force closed (I didn't spend anytime trying to debug the actual location of the infinite loop (or whatever is causing the hang), but it must occur somewhere after S9xGetByteFree() is called in S9xApplyCheat() during rom loading).
The cht file should have been saved with the first byte of the cheat set to 0x08 in the use case above, but the Windows port (only tested 1.53) does not do this. If the cht file was saved properly, this infinite loop issue would have been avoided. It appears this issue I'm seeing with saving the cht file is caused in the "ID_CHEAT_ENTER" switch case starting at line 2166 in wsnes9x.cpp:
Code: Select all
case ID_CHEAT_ENTER:
RestoreGUIDisplay ();
S9xRemoveCheats ();
DialogBox(g_hInst, MAKEINTRESOURCE(IDD_CHEATER), hWnd, DlgCheater);
S9xSaveCheatFile (S9xGetFilename (".cht", CHEAT_DIR));
S9xApplyCheats ();
RestoreSNESDisplay ();
break;
Looking at this code, it also becomes apparent that a simple workaround is to re-open the cheat dialog and click ok again (so everytime you want to enable a cheat, open the dialog, enable the cheat, click ok, then reopen the dialog and click ok again). If you do this then the cht file will be saved properly and the next time you open snes9x with cheats enabled it will not get stuck.
It would be awesome if this could be fixed in the next release
