Hi guys, long time no chat...More-or-less recently I've been filling blanks in the perpetual game genie master code list. Mostly I've been doing easy stuff for "Impossible" games using dissasemblers and sophisticated debuggers like the emulator FCEUXD SP.
Now for the specifics...I've ran my Game Genie(s) through a copy of Laser Invasion without trouble, other than the fact that you have to chart or guess the characters to put them in.
In this situation...do you guys think it would be possible to wire an seperate SRAM on the game genie itself that would only operate when the GG code was active for access to the PPU memory (theoretically aleviating this issue).
This is just a hypothesis at this point, but if my NES instinct is telling me correctly, this might just be crazy enough to work.
P.S.: a cheaper alternative possibly wiring a transistor to the (bluntly stated) mirroring lines to only pass their state when the cartridge is active (essentially forcing 1-screen/h/v mirroring...lol).
I must be missing something because I don't understand what you are doing. Game Genie doesn't have "Master Codes". It intercepts 3 addresses and can patch them. Debuggers are a great way to figure out game genie codes that are useful. But what is this about MMC5?
MottZilla wrote:
Game Genie doesn't have "Master Codes". It intercepts 3 addresses and can patch them.
Sometimes a game checksums itself and, if it fails to match, either locks up or (in the case of Bucky O'Hare and some other Konami titles that I can't think of at the moment) locks out all difficulties below expert. This was originally intended to help fight mapper hacks, title screen hacks, and other patterns of commercial copyright infringement at the time. If your game uses this, you may need a "master code" to disable this checksum behavior.
Quote:
But what is this about MMC5?
Apparently the MMC5 forces a blank screen during the Game Genie's menu.
It's not a copy protection check I'm trying to combat...I'm simply looking to get the graphics for the game genie to display properly with MMC5 and 4-Screen titles.
Quote:
Apparently the MMC5 forces a blank screen during the Game Genie's menu.
I'd assume the MMC5 is hijacking the GFX data by default, which could cause this...but A transistor workaround would technically work there too by bypassing the external memory in favor of the internal one.
Oh ok, now your first post makes alot more sense. Very interesting problem.
Does the Game Genie pass through the CIRAM /CE line, or does it always set CIRAM /CE to CHR /A13?
If the CIRAM /CE line isn't passed through, then any game that maps any kind of memory to PPU $2000-2FFF will fail to work as expected. MMC5 games may or may not work, depending on how they use EXRAM. Games that use 4-screen mirroring will always have trouble.
As for why the GG code entry screen is blank with MMC5 games, perhaps the MMC5 is in "fill mode" by default? A write to $5105 would fix that...
Well, It seems my older Gold GG is busted, but my newer black GG seems fine...
...Then I cracked it open to discover a single glop top...this is going to be tricky...
I've already found out that it's the PPU /A13 and VRAM /CE that are getting hijacked by the problem carts; Jumpering pins 57 and 58 allows the graphics to work, regardless of the cartridge (since I'd use it's own memory).
So the transistor trick may work...but only if a line goes and stays high when the game is loaded.
So:
Transistor needed is 2N3904
Collector to magic pin (goes high at cartridge)
Base to Pin 58 (PPU /A13)
Emitter to Pin 57 (VRAM /CE)
At this point I have a workaround that is acceptable to me. Jumpering 58+57 with a switch that runs out the GG.
Left on it can bug out carts that take advantage of that, otherwise allows the GG screen to be seen.
Interestingly enough, I always got the code screen to appear (at least with CV3) by starting the game, and then quickly power-cycling.
<sidenote>I have two scanners, and one is only sending green lines and one thinks it's return switch is busted...so I have to use a crappy camera</sidenote>
/A13 is passed verbatim and /WE is hijacked...If they both passed then sprites/atributes probably wouldn't work either and there'd only be a grey screen (and playing by sound sucks).