About cheat codes implementation in Action Replay firmware

cafe-alpha

Established Member
I'm currently implementing cheat codes behavior as described in yabause wiki : master codes with C30x opcode patch code at specified address (06000914, 06000924, etc), and when this interrupt is triggered, I overwrite memory with value set in selected cheat code(s).

Currently, some (few) games work, but the other games experience slowdowns or graphics glitches ... and I'm out of ideas in order to fix this :/
Does anyone has an idea of what I'm doing wrong ? I tried to cache everything (from selected cheat codes to interrupt handler code) in high work RAM, but this didn't changed anything from current solution running directly from cartridge ROM and reading cheat codes from cartridge ROM too.

Interrupt handler code itself is mostly written in C, but quite small (~300 bytes), so I suppose it's not worth the hassle to write it into assembly in order to gain some execution speed.
→ Is there some synchronization (with VDPs, etc) required when cheat codes interrupt handler is triggered ?
→ Does some more tricky know-how such usage of UBC is required ? This would probably work well for one code enabled, but I don't have any idea how this would be usable when two or more codes are enabled.
→ Something completely different is used ?!
→ What's most important : is there somebody ready to help me regarding cheat codes ? :)


And, does yabause supports cheat codes functionality when emulating Action Replay cartridge ROM ?
I tried a bit with version 0.9.15, but both cheat codes cache location and memory for selected codes weren't modified. This REALLY would help me if cheat codes behavior could be emulator-reproduced at assembly level (= not on emulator built-in cheat codes feature level).
 
  • Like
Reactions: vbt

cafe-alpha

Established Member
cafe-alpha said:
Please find some free time in front of your dev Saturn, and do the dirty job by yourself !


CyberWarriorX said:
If I remember well, execution time is very tight, so you may want to improve this first if that wasn't done before.


Thank you for your help ! Especially @CyberWarriorX : your remembers were right :)

So basically, I added an assembly version of cheat codes handler : it is based on the C version of the cheat codes handler, but without support of extra features such as USB connectivity, and with cheat codes cached in RAM (vs cheat codes usage bitfield in RAM, but codes in ROM for the C version). Not having to check the "cheat codes usage bitfield" has the advantage of not having to do bit shift (which is a bit CPU cycles greedy on SH-2), and storing enabled codes in RAM avoids to access cartridge's ROM, which may be quite slow and/or may cause A-bus congestion.
Also, unused registers are not saved/restored to/from the stack, which saves quite a lot of CPU cycles per interrupt.

As a consequence, several games (not all) that didn't worked well so far are now working correctly, and as an example, here is unlimited time code for NiGHTS, tested with cartridge ROM based cheat handler, with missing graphics because of slow cheat codes handler :
20170723_nights_ct_rom_ihr.jpg


And the same game, same cheat code, same etc with assembly based cheat codes handler :
20170723_nights_ct_inram_ihr.jpg

(image is blurry because in screenshot of video)

There are still many details to fix regarding cheat codes (cheat codes list, menu stuff, individual testing, etc), but at least, the core of the feature is 90% finished :banana:

Edit : I uploaded a video showing difference between both (cartridge ROM based and in-RAM) cheat codes handlers here :
 
Last edited:

cafe-alpha

Established Member
5 months from previous update ... but in fact I didn't stopped cheat codes stuff :)

Among several major improvements, it's now possible to do USB transfer with cheat codes bare minimum (patching one opcode within game), without the need of spare room in RAM : solutions in previous post required some RAM (in order to store cheat codes configuration, interrupt handler, etc), and since current solution does USB transfer only, it no longer needs to verify configuration.

20171221_xmas_nights_vdp1view.png

This is a VDP1 snapshot (VDP1 only, hence the lack of background) taken from SatLink from real hardware running Christmas NiGHTS. I didn't had time to take a video this time, but game was running a normal speed when playing, and showing some instant glitches when processing I/O from PC.

PS: Merry Christmas ! (a bit early, but that's better to wish it now than forgetting to wish it on D-day :) )
 
Top