| Home | Forums | What's new | Resources | |
| About cheat codes implementation in Action Replay firmware |
| cafe-alpha - Jun 26, 2017 |
 |
cafe-alpha | Jun 26, 2017 | ||
|
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). | ||||
|
cafe-alpha | Jul 23, 2017 | ||||||||||
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 :  And the same game, same cheat code, same etc with assembly based cheat codes handler :  (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  Edit : I uploaded a video showing difference between both (cartridge ROM based and in-RAM) cheat codes handlers here :
| ||||||||||||
