Sega Genesis Game Genie Codes don't work.

[Cibomatto2002]

On the Game Strider you can't get Game Genie codes to work like these codes I already know these codes work in Kega Fusion.

Using BizHawk-2018-05-01

Strider (UE) !
SHA-1 26FE42D13A01C8789BBAD722EBAC05B8A829EB37

Infinite Life In The Life Gauge. Galoob GENIE

AK8T-AA5R
AKVT-AA94
AJLT-AA9E

[NarryG]

Cheats are pretty broken in Waterbox cores and GPGX is a Waterbox core.

I've wanted to take a look at where the issue actually lies (as the methods are there, they just don't seem to do anything), but then I saw how complex it was to get a Waterbox environment set up and that plan fell apart.

@nattthebear may be able to give a better explanation as to why they're actually broken, but for now the best solution if you need cheats is to just use a 1.x version of Bizhawk.

[nattthebear]

Cheats don't work on waterbox cores when they try to modify things in read only memory, because you can't do that. Anything else though should work just as well as it did in 1.x. I can look into this; where should I start? Is this code confirmed to work in 1.x? What methods are they?

[NarryG]

I just verified the cheat does work in 1,x

The cheat is applied to the M68k bus, Appears to be within the rom section.
0x007D6E
0x0063FA
0x0015E4
Are all set to 0x6002

In 1.x, the MD Cart domain is actually flagged as read-only but you can still manipulate the rom through the bus and since this is a genie code, it's applying to the bus.

In 2.x, the MD Cart domain is flagged as read-only and manipulating it through the bus doesn't work.

This same situation applies to bsnes. Rom domain is flagged as read-only, you can manipulate it through the bus in 1.x, you can't manipulate it through the bus in 2.x

This does seem to be an issue of preventing writing for integrity purposes (as it won't change back if disabled as it's changing the actual value rather than patching it on the fly like a real cheat device would), but it is annoying for the end user to say the least.

1.x seemed to only protect memory through the Read-Only flag when creating the domain (which is why poking the bus directly worked), but it looks like Waterbox actually protects the memory from being written from what I can tell?

[nattthebear]

So it is codes to read only memory. Not much to be done about that then. I floated the idea once of allowing all the protections to come off for a cheat code mode that would have no determinism guarantees, but in general the team thought it was too much hacky effort for not enough gain, and I don't disagree...

[vaportropicae]

Is there a way to change the 2.x version of Bizhawk so we can apply game genie cheats to the bus?
I mean a cheat system like those from KEGA and Gens where the game file is protected against modification (read-only), but we can modify M68k.
Sry my bad english.

[NarryG]

You can make them work if you override the read-only on the rom domain and port the code to use that domain rather than the bus but otherwise there isn't much you can do besides use a 1.x build.

Change

BizHawk/BizHawk.Emulation.Common/Base Implementations/MemoryDomain.cs

Line 23 in fe3e7c3

public bool Writable { get; protected set; }

to

public bool Writable { get { return true; } set { } }

That'll override the frontend based read-only protection. This'll allow you to poke the ROM domain and other read only domains, although some domains (such as the bus) still wont be writable.

If you felt like digging into Waterbox, you could probably disable the protection on the bus but Waterbox is dark, mysterious, and requires using some obscure build toolchain.

[YoshiRulz]

see also #1350

[nattthebear]

I need some people to weigh in on this. Do we have a general policy on writes to "ROM" domains?

With the waterbox lazystates work, it isn't difficult to fix this now for genesis. But ROM pokes would be saved in savestates, unlike other cores that allow ROM pokes.

Do we want to do anything with this?

[YoshiRulz]

It's no secret that our cheats system doesn't work well with everything else, so I think whatever small hacks are necessary to get code conversion working are worth it—a sentiment shared by the author of related issue #1401. We can block poking ROM in the Hex Editor and RAM Search/Watch if "random" pokes tend to cause problems. (I don't know if cheat devices put restrictions on overwriting ROM. Would "random" pokes be any worse?)

[zeromus]

I'm okay with there being a discrepancy between cores in this area. I don't like that cheats are implemented by actually poking ROM, but independently of that (if for no other reason than for DEVELOPING cheats) users want to poke roms. I think I might even go as far as to say the ideal behavior is to be able to poke roms. That it's technically read only is not something that ANY SINGLE USER cares about. It's there, it's visible: they want to tweak it.
I am totally okay with the changes being in the savestate. The way I see it, at t=0 the user has a workbench of equipment, one of which is a ROM whose data has been set from an indicated file. If the user now changes that data, that's his business.

A more serious problem is that there may be some homebrewers or hackers who want to load a state and test a modified rom. In general this is wildly unsafe but in certain cases it is practical. I am alright with ruining this use-case. It can be re-added if anyone actually demands it by a function (conceptually, at least, I'm not saying it's clean in our UI paradigms right now) to clobber the rom from a given file. If it was truly absolutely necessary this could be made into an option or a command line option. I think it's unlikely.

So I vote for allowing rom pokes and savestating it.

[nattthebear]

With fbee96c I allow writes to the required memory domain. I tested the game in question with the cheats in question, and noticed two problems:

1. By default, the game genie decoder puts these cheats on the M68K BUS, but that doesn't allow writing to the ROM as it's still obeying the rules the CPU normally would use. I can't locate technical details on the innards of mega drive game genie design, but given that it sat between the cart and the system, I think MD CART is the domain that makes sense.
2. The exact codes given crash the game if they're present from startup. But if you don't have them initially enabled, and then turn them on later, they do seem to work. Dunno what's going on there.

I'd say this is fixed good enough, but if there are any remaining problems feel free to reopen.

A more serious problem is that there may be some homebrewers or hackers who want to load a state and test a modified rom. In general this is wildly unsafe but in certain cases it is practical. I am alright with ruining this use-case.

The implementation details of waterbox make this one really interesting: If you poke the ROM with memory domains and then save a state, and then later load the same state but with a different ROM (barging down any hash checks in your way), the pokes you made override the new ROM. In fact, an entire 4KiB block around any poke you made will come from the old ROM and not the new ROM. For an added bonus though, this 4KiB is aligned to the emulator's memory alignment in the host system, not the emulated system, so may or may not correspond to any interesting alignment in the emulated ROM.