The FinalGROM 99

[Tornadoboy]

This may be a dumb suggestion as I don't know the tech involved, but people have mentioned providing cheat modes for games and this occurred to me. There used to be a gizmo (for which console I can't remember) called the Game Genie that went between the cartridge and the console that added cheats and saves to games that normally didn't have them, would it be possible to design the FinalGrom so someone could write a cheat program doing the same kind of thing except have it get loaded into memory, and then still allow whatever selected game to be loaded afterwards on top of it?

Edited February 3, 2017 by Tornadoboy

[ralphb]

I can spare a few... DSC01523_sm.jpg

 

Thanks , but it probably wouldn't have prevented this. I was picking up the cart just because I wanted to insert a SD card, and a fat finger touched the solder points of the µC, which fried the connected CPLD. It would have to be a very long strap that I could wear while rummaging around my lab.

[ralphb]

This may be a dumb suggestion as I don't know the tech involved, but people have mentioned providing cheat modes for games and this occurred to me. [..] would it be possible to design the FinalGrom so someone could write a cheat program [...]?

 

The Game Genie allowed you to override some values in ROM, and you entered codes for address to modify and their new value. That way you could modify the number of initial lives from 3 to 256, get invincibility, and so on.

 

The biggest problem is to find those codes. There's an article in the last RetroGamer about the Game Genie and how they trial-and-error'ed those codes. For example, they'd modify each memory location containing a 3, one by one, to see if the number of initial lives would increase.

 

But assuming we have those codes, since all images are modifiable, you could just change PARSECG.BIN (as an example) and load that into the FinalGROM. There'd be no codes, you can just use modified image files. But you need to know which addresses to modify.

[+OLD CS1]

 

Thanks , but it probably wouldn't have prevented this. I was picking up the cart just because I wanted to insert a SD card, and a fat finger touched the solder points of the µC, which fried the connected CPLD. It would have to be a very long strap that I could wear while rummaging around my lab.

 

And thus, ladies and germs, I present to you the anti-static leash

[AuTomato]

 

The Game Genie allowed you to override some values in ROM, and you entered codes for address to modify and their new value. That way you could modify the number of initial lives from 3 to 256, get invincibility, and so on.

 

The biggest problem is to find those codes. There's an article in the last RetroGamer about the Game Genie and how they trial-and-error'ed those codes. For example, they'd modify each memory location containing a 3, one by one, to see if the number of initial lives would increase.

 

But assuming we have those codes, since all images are modifiable, you could just change PARSECG.BIN (as an example) and load that into the FinalGROM. There'd be no codes, you can just use modified image files. But you need to know which addresses to modify.

 

The ROM values could be found with a modified emulator and then converted into a Game Genie/Action Replay style code that could be used on the physical board. Could also conceivably modify RAM values as well, I'd think but I'm not totally sure.

[Tornadoboy]

It would be nice to do it with one device/program with a selection menu that can be updated as new cheats are created, rather than having to mod each game individually.

Edited February 5, 2017 by Tornadoboy

[eightbit]

I will want one of these as well when available!

[brain]

I would try to convince ralph to add a capability in his uC code to load a .mod file, which has the following format:

 

<cmd><3><address><data>

 

where cmd is:

1: replace data at address with new value

2: increment/decrement data at address with signed data value

 

you can add more commands as the need arises, but the code can skip over them as it can use the "length" parm to know how far to jump.

 

That way, you don't have the patch the binary by hand, so you can try the game/util without mods, and make sure it runs, or mod the image before running.

 

:-)

[speccery]

I've been very busy lately and haven't had time work on TI stuff, but I just want to join the gang by saying that this is a very cool project! I think I will be able to mirror the resulting software in my FPGA system too; I just either need to plug in an AVR micro controller or implement another controller in the FPGA.

[+arcadeshopper]

It would be nice to do it with one device/program with a selection menu that can be updated as new cheats are created, rather than having to mod each game individually.

 

am I the only one that thinks this dreaming is off-topic and should be elsewhere?

[Tornadoboy]

 

am I the only one that thinks this dreaming is off-topic and should be elsewhere?

I said it in the context of if there's a way to add it or the future capability of later doing it to the new FinalGROM it might be something to consider, I'm not intending to steering things to another device or program

Edited February 5, 2017 by Tornadoboy

[+OLD CS1]

Ralph, will you be selling these direct like the FR99? If so, put me in for a built one, please.

[tuf]

I'll take one, and I haven't even tried my never opened FR99 yet

[Sinphaltimus]

Put me down for a kit. Why not? I put together my fr99 and it works like a champ.

[weirdocollector]

One for me too

Edited February 6, 2017 by weirdocollector

[ralphb]

Thanks for all your enthusiastic comments so far, but unfortunately I have to put a little damper on your expectations regarding completion of the project.

When I did the video above, the prototype did have some instability in reading data from the cart ROM space, of all things. More precisely, when running a ROM test program, every few minutes a wrong value is read, and then the error is gone until the next error (at the same or a different address).

I thought it would be just a matter of rewriting the VHDL code inside the CPLD, but it turned out I was wrong. Since that video, the cart has been driving me crazy.

What I found out so far is that the read errors follow a pattern. It's always the high byte of a word that is corrupt, and the bad byte value read isn't stored anywhere in the entire SRAM.

.

Expected        Actual
 >6F10           >3510
 >6F82           >2F82
 >6D00           >FD00

.

So I tried to find the error with my scope. This is what I got so far (start top left and read counter-clockwise):

These four diagrams are from different measurements/read errors, but they all show Bit 4 for a muxed word read. My test data in the cart is so that each address contains the address as value, i.e., >6100 stores >6100, >6102 stores >6102, etc. The errors shown in the diagram are all at addresses for which Bit 4 should have been 0 for both bytes, for all diagrams. As you can see, this only holds true for the bus address and RAM address. The RAM data is erroneous, but I still don't know why.

Two weeks ago I contacted Jim (brian) and later Erik (speccery) about these issues and asked for help. We've been discussing since then, but haven't found anything conclusive yet.

I still think this can be fixed, but please understand that the cart won't be done as soon as we all hoped.

[weirdocollector]

No problem! Take your time, and again, great work!

Edited February 6, 2017 by weirdocollector

[Sinphaltimus]

No worries. However long it takes is what it takes. Zero expectations just a whole lot of fan boy-ism.

[+OLD CS1]

No problem! Take your time, and again, great work!

 

 

No worries. However long it takes is what it takes. Zero expectations just a whole lot of fan boy-ism.

 

Me, three. Wizardry takes time and patience on all parts.

[+mizapf]

I still think this can be fixed, but please understand that the cart won't be done as soon as we all hoped.

 

Well, at least you should expect a frosty hearing with the forum management, and possibly a cut of your gratifications. Hey, we're not here for fun, are we? (Just kidding, of course! )

[ralphb]

Well, at least you should expect a frosty hearing with the forum management, and possibly a cut of your gratifications. Hey, we're not here for fun, are we? (Just kidding, of course! )

 

Fun sure feels like work sometimes.

[AuTomato]

This may be a dumb suggestion as I don't know the tech involved, but people have mentioned providing cheat modes for games and this occurred to me. There used to be a gizmo (for which console I can't remember) called the Game Genie that went between the cartridge and the console that added cheats and saves to games that normally didn't have them, would it be possible to design the FinalGrom so someone could write a cheat program doing the same kind of thing except have it get loaded into memory, and then still allow whatever selected game to be loaded afterwards on top of it?

 

The Game Genie was an unlicensed peripheral first for the NES. Nintendo attempted to sue Galoob over the device claiming that by overriding values in the ROM the device created derivative works, but thankfully the courts saw through that argument and Nintendo lost. In the next console generation the SNES Game Genie was still unlicensed, but Sega embraced the peripheral and in some cases encouraged developers to work with Galoob by providing them with lists of interesting/useful ROM addresses. I've never been able to confirm it, but I have reason to suspect that some Genesis/Mega Drive games actually included "features" which could only be accessed via a Game Genie cartridge. The only thing I've got to go with there is that there are some games which have Game Genie codes that result in the software behaving in ways that seem surprisingly sophisticated for a simple ROM value change. Sega did have one caveat, which was they didn't want the Game Genie to work with games like Phantasy Star that had save functionality, but I don't think that really stopped anybody.

 

They weren't the only cheat cartridge of that generation, there was also the Pro Action Replay which was actually significantly more powerful than the Game Genie, specifically it was able to modify ROM and some RAM values. The PAR was released in the PAL and Japanese regions, but as far as I know it never had a USDM release. The Game Genie didn't survive to the next generation (PSX/N64/Saturn) but the PAR did both under that name for both the PAL and Japanese regions and under the "Gameshark" brand in the US. The devices from that generation were pretty amazing, and if you had the "Pro" model and the accompanying software you basically had what amounted to a rudimentary debugger.

 

I think the PS2 saw some releases of a disc-based cheat application called "Code Breaker," but I don't know much about that. I assume that it worked through something approximately similar to a TSR but I'd have to look into it to be sure.

 

Cool devices, definitely helped me extend the enjoyable lifespans of my games back in the 90's which was a big help because they were pretty dang expensive.

[FDOS]

Please put me down for 2, but know that I will require all 8 GROM/GRAMs (write enabled) for TIB+ development. Keep up the excellent work.

 

fdos

[+Ksarul]

Welcome to the fun, FDOS! It is very good to see you online again.

[+Lee Stewart]

Please put me down for 2, but know that I will require all 8 GROM/GRAMs (write enabled) for TIB+ development. Keep up the excellent work.

 

fdos

 

It's about time you got back on here, Bill!

 

...lee