Arcade_Offset
Arcade_Offset copied to clipboard
atrac17
Vsav Resets the rom when i press any attack button
Issue :
When i try to select the character (on Mister FPGA) the game resets. Happens in both 1.3 and 1.4
I tried using a second controller that maybe would help, but it did not, as it resets as well.
Using the latest MiSTer update_all.
controllers : Hori Fighting Commander, Razer Panthera DBFZ, xbox elite 2.
This has to do with a change to the CPS2 core and fx68 relating to O.Deejay resetting. It will take some time to figure out an additional patch to fix.
It's the program ROM showing a violation and resetting. There is a way to work around this, download the previous CPS2 core prior to the update and place an _ in front of the name. Then in those two MRA files for jtcps2 edit it with an _ in front.
This has to do with a change to the CPS2 core and fx68 relating to O.Deejay resetting. It will take some time to figure out an additional patch to fix.
It's the program ROM showing a violation and resetting. There is a way to work around this, download the previous CPS2 core prior to the update and place an
_in front of the name. Then in those two MRA files forjtcps2edit it with an_in front.
thank you i will try that now and report back
Great, I'll leave this open and probably make a work around as the only thing changed in jtcps2 relates to the fx68k module. I'll probably add a core that will run hacks since none of the other logic has changed that pulls from Arcade_Offset for a few of these games.
Had a hunch as to what the problem might be. Thanks for reporting. @jotego any idea why changing the dtack makes certain hacks reset now that O.Deejay doesn't reset?
@jotego could this be related https://github.com/jotego/jtoutrun/commit/a6c5b9429e9bad9cdf5dea3125d966d5c9628e12?
The O.Deejay fixed was unrelated to the DTACK signal, and it had to do with the decrypter memory range. So this issue could be related to the memory range encryption applies to
The O.Deejay fixed was unrelated to the DTACK signal, and it had to do with the decrypter memory range. So this issue could be related to the memory range encryption applies to
Okay, I understand.
I can see that in the .mra for Aesthetic Edition, there are patches in the >= 0x100000 range (in file vm3.10m); for Vsav at least, nothing is encrypted above address 0x100000.
I'm not sure what the nature of these changes are, but if there are any opcode changes, a change to the decrypter memory range could certainly have broken Aesthetic Edition (opposed to the proposed DTACK root cause).
I would have to know more about how the .mra file was made.
