Potential AR Patch Bug when Modifying Code List

[Birds-of-Paradox]

Hello,

I'm not 100% certain if this is the best place to post this, but I believe I have encountered a bug with the Satiator's patch for Action Replay cartridges. The equipment involved is as follows:

NTSC Sega Saturn Model 2 w/ Satiator running fw156 and mnu66
Action Replay originally running fw version 2.01 (The physical model with the 27-pin connector port on top)

I've followed the guide for re-flashing the Action Replay cartridge with the patched firmware (I have tried both arpatched-2.bin and arpatched-3.bin), and in both cases have reached a point where the patched firmware is behaving as expected (satiator menu boots by default, holding down A during boot brings up the Action Replay menu instead).

The issue occurs when the list of action replay codes is modified once the patched firmware has been applied. In my case, I was attempting to add the region bypass code for non-NTSC disc versions of Panzer Dragoon Saga (a PAL copy was used in testing). Creating the new code works fine, and will allow the disc to boot as normal, but only until the console has been powered off. Powering off the console once the code list has been modified seems to corrupt the Action Replay's modified firmware, as any further attempts to boot the system are met with a hang on the Sega splash screen until the cart is re-flashed with either its original firmware or the patched firmware with an unmodified code list.

I have tested and can confirm that this does not happen when the region bypass code is added to an unmodified Action Replay running its original firmware, regardless of how many times the system is subsequently powered off. It only seems to occur when the code is added to an Action Replay that has been modified with the satiator-compatible firmware.

I unfortunately cannot test this with a different Action Replay cart, as I only own the one, but this issue has been repeatable and consistent in multiple attempts, and only once the firmware has been modified. Any help or advice that could be offered would be greatly appreciated. I can supply additional test results if necessary, as long as I have the required materials.

[SONIC3D]

It would be more helpful if you provide the model of the flash ROM chips on your cart PCB as a reference.

There are many different Flash ROM models on market. Each has different prefix command bytes to trigger the real user data writing. And different models may have different page size (SST 29EE010 needs 128 bytes in a batch, AMD AM29F010 and SST 39SF010 need 1 byte, ATMEL AT29C010 needs 256bytes, there are a lot more different models...).

Cheating device maker like Datel or EMS may use different type of chip in different batch. And the corresponding Flash ROM accessing code may be slightly different.
By using a Flash ROM with different Flash ROM accessing code, data may be damaged. For example, code logic assuming you are using SST 39SF010, and write 3 bytes of command data and 1 byte of user data each time. But the actual chip is 29EE010, it will accept 128 bytes for each write command. So it will accept the first byte of userdata correctly and then treat the later 3 bytes of command data of the second write request as user data. Then the final data page write to 29EE010 is not correct.

The real result may be more complicate then the above case. So the best practice maybe check the chip model, provide it to some Saturn related forum and request a clean AR ROM that suitable for your chip(and confirm if it is working), then try to find someone who can patch it to adopt Satiator.

[Birds-of-Paradox]

Thank you for looking into this. I've updated the original post with photos of the chips in my specific Action Replay for clarity, but if I'm reading this right, it sounds like it's less of a bug and more of an incompatibility with multiple possible configurations for Action Replay devices anyway. I'm assuming any kind of fix would require writing a different version of the modified firmware entirely (or at least altering the existing one).

In regards to restoring my original firmware, I did create a backup of the unmodified firmware before flashing the patch, so I've been able to restore to that for the time being.
I'll leave this open for a while longer in case anyone has anything else to add, but for the most part I consider this resolved. Thank you again for your time.

[abrasive]

It may also be even simpler than this - I located my hook code at a Flash location I thought was unused, but perhaps it gets stepped on by the cheats. Unfortunately I just moved house and do not have my lab set up yet, so I can't yet answer the question: where are the cheats saved?

[Birds-of-Paradox]

I may be in over my head at this point, as I don't really know how to look at where the Action Replay locates its saved codes. The best I can offer is dumps of my Action Replay's original firmware before and after adding a code (taken via the Satiator's Action Replay Tools), along with the one that causes hangups after the console is rebooted (AR_Patched_3_Code_Added), since there is an opportunity to back up the broken firmware before rebooting, when everything still seems to work.

Thank you for taking the time to respond. I very much appreciate the help.

AR_Patched_3_Code_Added.zip
AR_Original_FW_Unmodified.zip
AR_Original_FW_Code_Added.zip

[SONIC3D]

Split the AR ROM into 4 64KB segments. Then the first segment(0x0000-0xFFFF) is for AR program code. The second one(0x10000-0x1FFFF) is for cheat code DB. The rest 2 parts(128KB, 0x20000-0x3FFFF) is for storing your game saves backup data, which is managed by the Memory Management feature in AR.

I have checked the 3 roms provided in your reply. "AR_Patched_3_Code_Added.zip" contains 3 suspicious point:

1. The patch code is put near 0x16200 which is stay within the range of Cheat Code DB of AR. And the "_ubc_isr" function code is stay at 0x16140. Your last cheat code data(Panzer Dragoon related) occupied the data block 0x16100. If data chunks are read 0x100 each time for parsing in AR program logic. The "_ubc_isr" function code of satiator patch code may be treated as cheat code data chunk and make the parsing code failed to run. Or maybe the "_ubc_isr" code and the nearby code are overwritten by PanzerDragoon cheat code data so satiator patch no longer work properly.
2. The patched code at 0x0F00 copy 44 bytes of data from 0x16638 to 0x220000(RAM). I didn't checked where the code will jump to 0x220000 as the code will jump to 1633C first for a bunch of logic. But that 44 bytes of code is weired, it looks like the original entry code of ARP ROM. It will copy 0x10000 bytes of code from 0xF00 to 0x280000 and them jump to 0x28001A. But the code be loaded to 0x28001A(offset 0x0F1A in ROM) is no longer same as original code. The original one is jump to 0x288BEC. But the code is modified by satiator patch. So if any code run to 0x220000, the running result would be unknown...(I have not analyze the code further)

I highly suspect that it's the first point I mentioned caused your problem. So maybe @abrasive should consider move the patch code to an offset a bit more near the tail of the ROM. Maybe in the region of save backup. Since I think the 64KB space is already small as precious Cheat DB storage, while less people use the 128KB memory backup feature.

[xhul-dev]

It makes total sense that the satiator code gets nuked by further cheat code additions, due to where it's located.
Here is a cool concept worth testing:

1. Encapsulate the satiator code into a dedicated fake cheat code entry, called "Satiator - Don't touch!" or whatever.
   That way, the AR wouldn't crash when accessing the cheat code listing, so the user would be able to use any other code without problem.

2. Locate the entry at the very beginning of the cheat code area.
   That way, users can add new cheat codes at will, and we're sure the satiator entry doesn't get moved by any nasty defragmentation if some other entries are modified|removed.

@abrasive:
Don't hesitate to let me know how that sounds, i could so some testing on the 2.02 firmware, i have the convenient USB Datalink.