jtcores
jtcores copied to clipboard
jotego
SF2X/CPS2: launching a core too fast produces visual artifacts
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.
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: https://youtu.be/N-a2xj3a_v8
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.
CPS2 is the only jtcore that uses the DDR download in order to speed up the ROM download. I think the NeoGeo core does it too. Maybe it is related to that.
I think you can disable it without recompiling the core by taking away the address="0x30000000" text in the mra file.
Could you try that and let me know how it goes, please?
I tried removing the address text. Game loads much slower, but issue still occurs :(
I tried removing the address text. Game loads much slower, but issue still occurs :(
Thank you
The game does not clean up the memories, neither does the hardware
At least the games test Object and Work RAM so when those tests are finished the RAM should have the same contents every time.
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. https://github.com/jotego/jtcores/blob/29b50c1ba50dad2c975a85c2ed8c86a0b8a1d0c3/cores/cps1/hdl/jtcps1_sdram.v#L160-L161
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, 0x28'0000*2=0x50'0000
How are you clearing it? By adding a part in the MRA?
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.
I cleared it with the Menu core. I modified it so I could select which part of SDRAM can be cleared.
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
Ok so clearing Object RAM helps a bit but does not remove all glitches.
Maybe the regular VRAM also has the same problem?
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.
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. Filling Object RAM with random values shows massive glitches in Mame like we see in the core. Filling with 0x00 or 0xFF 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.
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
Clearing Object RAM in the core itself seems like a better idea.
I cannot quite reproduce this issue but I have added logic to clear up the object RAM during reset in 581875c0, which follows @paulb-nl findings about this.
Let me know if you see it again. The files will be published next JTFRIDAY.
Cool, I'll try when I can after it's published and will update this thread with the results. Thanks!!