New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SF2X/CPS2: launching a core too fast produces visual artifacts #561
Comments
It is not just launching a core too fast. It also happens when loading a certain core before SSF2. Loading Karnov's revenge in the NeoGeo core will result in massive glitches and flickering in the SSF2 games when loading them afterwards. Here is a video where SSF2 is working normally and then I start the NeoGeo core: |
The game does not clean up the memories, neither does the hardware. But it should eventually overwrite old values. I wonder if this is related to the game data download being performed through the DDR memory. |
I tried removing the address text. Game loads much slower, but issue still occurs :( |
Thank you |
At least the games test Object and Work RAM so when those tests are finished the RAM should have the same contents every time. |
That's a good point. But if Ryu's silhouette can be seen in those scenes, there must be some wrong data in memory. It could be a MMR (device register), but I cannot think of something that could produce that silhouette effect |
I've uploaded the issue in video form in case it's useful https://youtube.com/shorts/sNsjTJykaDI?si=7DmcBiZeseXO3Jkh |
After some testing I determined that there are no glitches if the first bank (8MB) of SDRAM is cleared before starting the game. Only clearing 1MB at 0x500000 removes most of the glitches on the left half of the screen. What does the core use at that offset? |
Thank you for looking into it. You must be clearing the object RAM, which agrees with the images as what we see is wrong objects (sprites) displayed. |
If I interpret your source correctly then Video RAM and Object RAM are at 0x200000 and 0x280000. jtcores/cores/cps1/hdl/jtcps1_sdram.v Lines 160 to 161 in 29b50c1
Clearing only those offsets has no effect on the glitches. I don't know what is at 0x500000. Is it the M68K ROM? |
I think those offsets are referred to 16-bit words, whereas you're probably counting bytes. If you multiply by two, |
I cleared it with the Menu core. I modified it so I could select which part of SDRAM can be cleared. Ok so clearing Object RAM helps a bit but does not remove all glitches. I have found with Mame that this game only clears 0x0000 - 0x1C4F of both Object RAM banks. For 0x1C50 - 0x1FFF it reads the value then writes 0x00 and then writes the old value back. |
In principle, it is possible to have the MRA overwrite that region on start up. But I am not sure whether it will work with the current core as cores often do address transformations while downloading the MRA data
Maybe the regular VRAM also has the same problem?
I would need to check if that part of the object RAM is meant to be special. Maybe the object MMR go there. I do not remember off the top of my head. MMR sometimes cannot be read back and I do not implement the reading. Maybe in this case reading is supported and not implemented (?). I'd need to check it. |
Some more testing in Mame: Filling Video RAM or 0xFF0000 RAM with random values shows no glitches. Hyper SF2 also only clears Object RAM up to 0x1C4F but is not affected because it places the 0x8000 last sprite indicator in Object RAM which SSF2 does not. X-men vs SF clears Object RAM completely. So it appears that SSF2 expects uninitialized Object RAM to have certain values. I think the Menu core that I modified is somehow not clearing Object RAM completely when writing 0x00 to 0x500000-0x5FFFFF.
Clearing Object RAM in the core itself seems like a better idea. |
Cool, I'll try when I can after it's published and will update this thread with the results. Thanks!! |
I wanted to test the updated core but the cores update on friday were built from commit 4f7da4b which is from May 11th, before you committed the fix. |
@paulb-nl you can use this one to test it: |
Thank you for the test build. Unfortunately the issue remains. Looking at your fix, it seems you are clearing a copy of the Object RAM which is in BRAM. BRAM is always cleared to 0 during loading of the FPGA bitstream so that is not needed. What needs to be cleared is Object RAM in SDRAM: jtcores/cores/cps1/hdl/jtcps1_sdram.v Lines 269 to 273 in 299bb31
Reproducing this is easy. Load Karnov's revenge in the Neo Geo core and then load SSF2. |
I see. Thank you. I will tackle this when executing #511 then as it will be easier to do when full SDRAM framework is used. |
If launching a core very quickly after booting the system, the game shows with visual artifacts. An easy way to repro is to use the bootcore=lastcore option (which launches the game in 10 seconds)
This happens in Street Fighter 2X but it likely affects other CPS2 cores as well.
If waiting 15-20 seconds before launching the core, the issue doesn't happen.
The text was updated successfully, but these errors were encountered: