Sega CD / Mega CD - Cheat Search failures

I’m manually making some cheats for a few games I have, I’ve done quite a few already for NES, SNES, Genesis. Now I wanted to do a few for the Sega CD / Mega CD, but it appears that something is different with the games or that ties with RetroArch’s cheat engine.

I’ve already made a working cheat for Flashback - The Quest For Identity (USA), and now I attempted to do one for Mickey Mania - The Timeless Adventures of Mickey Mouse (USA), but it simply does not work. I have little doubt that I am doing things correctly because I even did a few cheats for the exact same game for the Genesis, but something isn’t quite right with this one.

Example: game starts with 4 lives, on the Genesis I would start with a 4-bit search for the value 4, then lose a life and search for the value 3, and so on. I will find a match at this point and it works fine. With the Sega CD version this approach does not yield any result. What is more puzzling is that I went as far as doing 32-bit searches by approximation (equal, not equal) and even then I cannot find any address that holds a value as simple as the number of lives.

So, the question is, what is different about the SegaCD or some of its games that the built-in cheat engine does not find anything usable for a particular game like Mickey Mania - The Timeless Adventures of Mickey Mouse (USA)?

I have a theory from some reading I did, the theory goes that the Sega CD (and its emulation) uses a special type of RAM that the cheat engine cannot access (or is scrambled somehow, don’t know). And the reason why I was lucky with * Flashback - The Quest For Identity (USA)* is because that game may be borrowing the Genesis part of the RAM and there the cheat engine can see and touch properly.

Here’s a quote from a forum post I found which leads to this reasoning:

Simply put, those are Sega CD RAM (or PRG RAM) cheats, which (as far as I know) no emulator supports. The FF-style RAM cheats work because some CD games use “Genesis” RAM for things. A good example of this is Sonic CD, thus some emulators like Genesis Plus GX and the MegaSD flash cart support them. To use PRG RAM cheats you’d probably have to use something like Cheat Engine or ArtMoney with an emulator to get them working. I believe lee4 has a signature link to a tutorial on using ArtMoney to cheat with Sega CD games.

It’s actually not as simple as creating a cheat that uses the Genesis RAM either since the game could be using PRG RAM (or Word RAM) for such things which I believe Lunar Eternal Blue is an example of.

source: https://gamehacking.org/vb/forum/video-game-hacking-and-development/retro-hacking/206572-request-sega-cd-codes?p=206574#post206574

Looking a little further into it, it seems that Sega CD does indeed have a special RAM mapping that is outside the scope of RA’s built-in cheat engine (r/w). Artmoney, which seems to have special emulator support with configuration specific to emulators and systems, Sega CD appearing with a memory mapping that looks something likes this:

| Description  | Emu. address |   PC address    | Size
1. RAM 512Kb   |   00000000   | EFC9F58045BD020 | 80000
2. RAM 256Kb   |   00200000   | F049F680F009F60 | 40000
3. RAM 64Kb    |   00FF0000   | EFA59E80F059F70 | 10000

I’m not sure if this support could be added to RA and if it would involve work on the core, if the core is not involved in the implementation I think this could be added as an improvement, but I guess there must be a reason why no emulator has ever implemented such feature and may be futile to expect it to be done for a single system.

Another mention of an emu that allows Sega CD RAM search is Bizhawk, haven’t tried the functionality though. But apparently this is supported:

  • CD PRG RAM
  • CD Word RAM(0) (1M)
  • CD Word RAM(1) (1M)
  • CD Word RAM (2M)
  • CD BRAM

I’ve played around with Bizhawk and was able to find memory addresses for health and lives on the S68K Bus. Unfortunately the same addresses did not work after restarting, in any case I think this confirms that it is a special RAM issue.

2 - 3 should be searcheable:

struct retro_memory_descriptor descs[] = {
         { mem, work_ram,     0,           0xFF0000, 0, 0, 0x10000, "68KRAM" },
         /* virtual address using SCD_BIT so all 512M of prg_ram can be accessed */
         /* at address $80020000 */
         { mem, scd.prg_ram,  0, SCD_BIT | 0x020000, 0, 0, 0x80000, "PRGRAM" },
      };

its just that the RA search engine lists ram address in sequence instead of virtual address indicated. so it always starts at address 0 for first block of memory, and the next block-whatever its address is starts at whatever the last address of the first block is.

block 1 in your list is not exposed. that might be sram but dunno.

in anycase, the memory maps were exposed as for retroachievements, which was the only items required for it to work.

Thanks for clearing that up.

I am not sure why exactly it doesn’t work. As I said, I only briefly tried using Bizhawk and even then managed to (easily) track dynamic addresses in the “S68K Bus” domain. I am still interested in making the cheats for RA, and to be fair in Bizhawk I also had no luck searching in the Work RAM or the PRG RAM.

I also remember reading some rumors that the creator of Kega emulator never implemented SCD cheat functionality because there was no good approach to it. I don’t know, I don’t have the kowledge about the technicality, just that some sections of the running code are not available to the emulator and so that is the reason why it cannot track values either by exact match or by approximation.

just a follow up, looks like you are looking at the “WORD” access for PRG ram ($200000) instead of its main byte access map ($20000).

as stated, RA’s cheat engine lists the structs sequencially, instead of actual address, so, based on struct above, RA result would be:

WRAM (64K RAM) @ 0xFF0000 will have ranges from 0 - $10000 PRG_RAM @ 0x020000 will be range $10000 - $120000

i dont really like this, coz the cheats then has to match how the struct are arrange so if other core implements this the other way around , then cheat will not work (assuming mem flag is set for the memory block)

see if figuring out where the range is suppose to be for the intended cheat, the cheat would work whatever you are trying to do. then if it does, ill look at exposing 1st RAM section you mentioned (which is intended for the save ram from the looks of it)

Thanks for getting back to it.

I have no clue how to proceed. As I mentioned before, I can only find anything usable with Bizhawk, and even then I have to search for the values in “S68K Bus” memory, which supposedly is in the 0x800000 range, at 0x000100 I can see the following:

SEGA CD         (C)SEGA 1992.AUGCD-ROM BIOS       8/ 4-1992     03:00      1.00 CD-ROM BIOS 

Visually, when targeting a value, like health in the game Mickey Mania, this is what I can see:

EDIT: Searching in CD WORD RAM (2M), starting 0x20000, I can find the correspondent value @ 0x00046E.

stange that i cannot edit my last post anymore when it was just got posted few hours ago. anyways i am just to correct that PRG ram range result will be 10000 to 90000 (prg ram full size 80000)

like what i have said, RA cheat engine does not reflect actual address, while bizhawk seems to represent specific address as intended it to be (or has manually named specific blocks of memory and does its own mapping).

in any case, RA’s search engine is really not comparable to how we knew about tradition cheat engines (was probably not intended to be such hence its own manual cheat files)

For every other platform RA’s cheat engine has worked as expected, not great but acceptable. Sega CD has been the only exception thus far. I could even dismiss the issue of finding the values since apparantly Bizhawk can do it just fine, but I don’t have any clue how I would go about to convert an offset/cheat from Bizhawk to RA, assuming that RA or the core can even deal with said offset from CD WORD RAM (2M) range.

Btw, all mentions I find to Sega CD cheats (typically Action Replay format) can only target the common Genesis 68K RAM area, nothing more.

other cores (if not most) works fine because you need to only map 1 block mostly and expect the memory map to start at zero which works fine in RA when using retro_get_memory_map/size api to access the blocks required. not in the case for sega cd / mega cd (and some other cores) which has multiple memory blocks that are at different address which has to use the RA memory descriptors (struct above for example)

you’ll have to do the address translations if you indeed to use cheats on such system.

you’ll have to pick brains out of the guys to actually do api stuff if you want anything to change (i think i’ve opened up this address issue before), coz i dont work at RA’s api implementations.