Knuckles Chaotix NTSC regression

[DUSTINODELLOFFICIAL]

With core v230501, it seems that roughly 50% of the time the title screen and demos of Knuckles Chaotix (NTSC version) fail to run properly. When it fails, it's during the title screen animation, immediately after Metal Sonic "zooms" into the screen. You can see the beginnings of the title screen zooming in before it disappears, leaving only the background behind it. It will continue to the demo and freeze at some point before the demo comes up. It also seems that if one cycle of the title and demo is OK, the next one will fail. I haven't played extensively, but it seems if you start the game before this happens, it functions properly.

The PAL version seems unaffected by this, but seems to have unrelated animation/scrolling issues. I'm not sure if this is accurate to the hardware or not, but it's potentially another issue.

[Toryalai1]

I just checked this and I can reproduce the issue. To reproduce, let the demo run twice.

[jeffkrull]

I was able to reproduce the issue with letting the demo run only once, even after rebooting the core.

I'm not sure if it's related, but I've also noticed some intense performance issues with Knuckles Chaotix even in the main game. Stages have intense slowdown, especially in Marina Madness (all levels), though the music does not lag. I'm not sure if this happens on real hardware, but on videos I've watched online of the game, I don't see the problem happening there. I'm also not sure if this was an issue prior to this new core version, but I never played too far in the game before this version, thanks to not having SRAM support until now.

[PLEYOR]

This started happening for me when I updated MiSTer using the Update All script. I was using a previous version of the 32x core, updated to most recent 32x core and had the same issue. So I suspect it isn't the core that is broken, more the OS?

[Toryalai1]

If this is working with the latest core version but the previous main release then it is a main bug.

[asturur]

After the release of 20230501 there are other 2 builds:

May 11 https://github.com/MiSTer-devel/S32X_MiSTer/pull/48

Jul 03 https://github.com/MiSTer-devel/S32X_MiSTer/pull/49

Can you see if the but persists in one or both?

[jeffkrull]

The problem still exists in the July 03 build.

[asturur]

for the sake of not corrext fix, there is an open pr with a bunch of builds that implement latest changes to the sh core made for the saturn core. There are 3-4 builds there if you want to have a look.

[YLFAndy]

for the sake of not corrext fix, there is an open pr with a bunch of builds that implement latest changes to the sh core made for the saturn core. There are 3-4 builds there if you want to have a look.

Thank you Asturur, good point. I deleted the above comment and I'll make sure I have all of those avenues checked before S32X_NoWait.zip submitting an update. I was not at my computer and doing all of this remotely so I'll resubmit if the updates show the same result.

OK, I pulled the latest SH and double checked my work - I had used the wrong MiSTer branch but the fix still works with the latest MiSTer-Devel and latest SH (The line number in S32X.sv is @714). I also checked sound on this one and it seems OK. Again, that setting is there for a reason, but using latest and leaving it 1 results in KC being corrupted after the intro. This appears to let it work. Thank you again!

[asturur]

i wasn't picking in your comment, i was just saying i blindly applied changes to the submodule of the cpu. Some issues have been fixed in this way in the past ( xmen and mayan ) but i have no idea what those new commits may do.

[YLFAndy]

i wasn't picking in your comment, i was just saying i blindly applied changes to the submodule of the cpu. Some issues have been fixed in this way in the past ( xmen and mayan ) but i have no idea what those new commits may do.

You actually pointed me to an issue I had - an old zip file for the branch! So I really appreciate it! I'm digging the stuff you're experimenting with. Thank you!

[YLFAndy]

OK, a little more digging - so the issue was introduced when a check was added to line 838 of rtl/32x/IF.sv. AS_N_SYNC[0] was &&ed in the if block. This reg gets updated by memory state changes in ba.sv as far as I can tell. There is a no-return possibility in the state change to MBUS_FINISH, so it's possible the SH never gets unblocked in a specific case (and executing something on the Genesis side can free it up again, which is why you can get past it). All of that being said, I also realized while going through the code that the Genesis side is all pulled from the now-archived pre-Nuke core. So all of this might be futile anyway as I'm guessing someone will have to cherry pick the necessary parts of the supported core and rewire the 32X code to keep it in a supportable state.

Current workarounds that seem to be fine - Either set USE_ROM_WAIT to 0 in S32x.sv OR remove && AS_N_SYNC[0] from line 838 of IF.sv. Or be smarter than me (very easy to do) and figure out why the memory access side of the Genesis isn't returning execution to SH. :)

[asturur]

Does your PR fix the regression now @YLFAndy ?

[YLFAndy]

Does your PR fix the regression now @YLFAndy ?

Yes, and apparently WWF Raw as well? I didn't test it when I was spot checking but apparently it didn't run and now it does.

This is incorrect. The tester had loaded WWF Wrestlemania first, which allows RAW to run, unrelated to this fix.

[asturur]

this can be closed i think no? This has been fixed and released

[Toryalai1]

This ticket can be closed