0 users browsing Discussion. | 14 bots
| joshua |
Posted on 20-08-21, 11:07
|
|
Post: #1 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
Since codes don't always work for unknown reasons, its possible that trying to use SNES Game Genie rom to enter cheats would be useful fail-safe, so why don't developers have an option to load actual Game Genie rom image they have -they are out there as I'm one of them. |
| funkyass |
Posted on 20-08-21, 18:09
|
|
Post: #151 of 202
Since: 11-01-18 Last post: 450 days Last view: 83 days |
if a game genie code works would depend on the game revision, and whether it survived the game of Chinese whispers over the years, and a game genie code is a just an encoded memory address and value. emulating the game genie rom wouldn't make it operate any differently. modern emulators give you the tools to actually fix the code if you wanted to. |
| tomman |
Posted on 20-08-21, 19:12
|
|
Dinosaur
 Post: #757 of 1285 Since: 10-30-18 Last post: 24 days Last view: 4 hours |
The only reason you would want to emulate the GameGenie itself is nostalgia, if you owned one back then. Has someone ever RE'd the actual device to know how their custom ASIC + ROM interacted? I guess there is stuff beyond simply "when CPU tries to read XXXX:XX, return XXXX:YY" or something, so actually emulating the GG is not just "run the ROM". Most emudevs would argue that by having native GG code support, there is no point on spending the research and development resources that such a task would require, for little (if any) gain. But then, the whole "software/hardware preservation" aspect kicks in, so... Full disclosure: I own a Genesis GameGenie, but I'm not even that sure I would ever want to see it emulated. (I bought it for software development purposes that ultimately led to failure for me, not for cheating in games - the seller even included the WRONG codebook, as I got the NES book!) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| joshua |
Posted on 20-08-22, 00:53
|
|
Post: #2 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
Well, actually...Tomman like reading an individual legal statute without contexts, you might be right technically, but the devil-in-the-detail is you seem to assume that rom's internal offsets define addresses that position any value, but there are Super Nes roms that took shortcut by only dumping the MAIN chip (usually on cartridges PRG-ROM -Sega CD is another thing), but skip onboard co-processors when available. This changes rom's size...and at least if put on "wrong end" of PRG-ROM (again usually) it would seem to shift the absolute address a bit (on PC memory in ultimate picture?), so even if you are both nerdy and savvy enough to change the cheat code or even try RAW hex codes it might not run same on other PCs - even with same emulator/game combo...and down the rabbit hole we go. Ideally, it seems safest bet to at least mitigate this lost-in-translation problem. True I used raw hex code for Batman Returns, but I don't know if it would work on YOUR PC-SAME-GAME-SAME-EMULATOR CONFIGURATION (Emu-hawk SEGA CD), so its just ideal to use a rom dump clone image of cheating device. EVEN WITH HOMEMADE CODES YOU SEARCH YOU CAN FIND OUT: "OOH! SEGA CD RAW HEX ADDRESSING IS A CONVOLUTED MESS...SOMETIMES ITS PRG-ROM...BUT OTHER TIMES ITS WORD-RAM!" BTW, I FOUND OUT AFTER WEEKS OF WONDERING WHY RETROARCH'S SEGA-CD-EMULATING GEN PLUS GX CHEAT SEARCH IN HOOK WON"T ACCEPT -WAS IT ADDRESS OR VALUE- GREATER THAN 7FFFF! IT WAS ROM SEARCHING...IT CAN'T DO RAM SEARCHING! SEGA CD RAM WAS GRAFTED INTO ROM COUNTING...WTF?! |
| Kawaoneechan |
Posted on 20-08-22, 01:28
|
|
Rated M for Mental
 Post: #511 of 598 Since: 10-29-18 Last post: 115 days Last view: 12 hours |
Watch the caps, friend. They make it less likely you'll be taken seriously. |
| joshua |
Posted on 20-08-22, 01:45
|
|
Post: #3 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
HUMOR IS THE ONLY WAY TO KEEP YOUR SANITY WITH THESE LAYERS UPON LAYERS! It's like Murphy's Law...ha-ha-ha. I'll be grateful if eithor my codes work "out-of-box" or if the genius with a stomache-of-iron just is so kind to all hardcore pc-emulating retro-gamers like me and does to SNES GAME GENIE what Genesis Plus GX did to Genesis port...and FCEUX did to NES port. That felt cathartic...ha-ha-ha! |
| Screwtape |
Posted on 20-08-22, 06:14
|
|
Full mod
 Post: #414 of 443 Since: 10-30-18 Last post: 891 days Last view: 88 days |
Game Genies should be emulated, because they're historically significant. However, if you actually want to use Game Genie codes yourself, emulating a Game Genie is strictly worse than using the emulator's built-in support: you can't copy/paste, you can't just type them on your keyboard, and you're limited to a handful of codes instead of thousands. > ...there are Super Nes roms that took shortcut by only dumping the MAIN chip (usually on cartridges PRG-ROM -Sega CD is another thing), but skip onboard co-processors when available. This changes rom's size...and at least if put on "wrong end" of PRG-ROM (again usually) it would seem to shift the absolute address a bit... Game Genie codes affect the addresses visible to the SNES CPU. On board co-processors aren't visible to the SNES CPU (or they would be included in the dump), so they don't have any effect on Game Genie codes. bsnes and higan allow the extra undumpable data to be stuck to the base ROM dump, but only at the end, not the beginning, and it's very careful to separate the two parts and treat them individually. If a Game Genie code works with one specific ROM dump on one PC in one emulator, it should work with that specific ROM dump on every PC in every emulator. Any emulator where it doesn't work is broken. The ending of the words is ALMSIVI. |
| CaptainJistuce |
Posted on 20-08-22, 07:49
|
|
Custom title here
 Post: #907 of 1151 Since: 10-30-18 Last post: 21 days Last view: 2 days |
Posted by KawaAnd also much harder to read. Incidentally, PRG-ROM is a fairly unique concept, and probably shouldn't be applied as a general term. Most systems don't have separate Program ROM and Character ROM buses. They just have ROM. Outside of arcades, only the Nintendo and NeoGeo spring to mind as systems with that sort of split cartridge architecture(SNK uses the terms PROG ROM and CHA ROM, incidentally). --- In UTF-16, where available. --- |
| joshua |
Posted on 20-08-22, 08:15
|
|
Post: #4 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
Sega CD though had many splitting of just ROM...and weirdly RAM was blurred together by an unified memory counting of addresses...SNES was less counter-intuitive by not having split-rom but still actually for addressing purposes didn't differentiate cartridge ROM (sometimes also onboard SAVE RAM) and SYSTEM RAM...unlike general-purpose PCs or maybe modern gaming generation of consoles, games (being analogously PC Firefox) have to fit into a rigid memory "hole" reserved for loading ROM to RAM mirror - like the say PC-BIOS or now UEFI, just higher level. |
| CaptainJistuce |
Posted on 20-08-22, 11:33
|
|
Custom title here
Post: #908 of 1151 Since: 10-30-18 Last post: 21 days Last view: 2 days |
Yes. Every system has a memory map, and only some portions of the address space are available for any given purpose. This is still true today, we've just got an insanely large address space and dedicate most of it to RAM. On older machines, especially fixed-purpose ones, the memory map is very important. Often, everything is mapped into the processor's address space at specific addresses, and reading and writing those addresses is how code interacts with those hardware devices. Also, most dedicated game machines are built to treat the software cartridge as an integral part of the system. The comparison to a PC BIOS is apt, as without the cartridge there's nothing to boot from. Essentially, when you plug Super Mario Kart into a Super Nintendo, the SNES BIOS is the game Super Mario Kart. However, the "loading ROM to RAM mirror" part isn't apt: most systems with software on ROMs actually run that software directly FROM ROM. The shadow RAM technique used by later IBM clones is a unique quirk to that platform. --- In UTF-16, where available. --- |
| joshua |
Posted on 20-08-24, 11:47
|
|
Post: #5 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
UPDATE After trying for a week to find bsnes-sx v.008 since I iniatially got rid of it, because I thought it was not working as far as loading routine code goes. The reason I was so interested in that was the cart "swap" emulated action, and thought maybe if I paused emulated after three pause-unpause timings...AT PRECISE BLACK SCREEN after emulating Start button on SNES, where it would go into game on real console...and then click "swap" of Batman Returns rom - I entered infinite lives code on entry screen. But the code had no effect as if swap just emulates litterly JUST that - 'hot swapping' cartridges! I'm throwing in the towel after three weks of this almost all day...but anyone out there wants to take over from here...BE MY GUEST...or if you know an emulator that supports native game genie emulation like Fceux nes emulator...joshua < > gnitecki <AT> hotmail.com. |
| funkyass |
Posted on 20-08-24, 19:49
|
|
Post: #152 of 202
Since: 11-01-18 Last post: 450 days Last view: 83 days |
emulating the game genie isn't going to make broken codes work. |
| CaptainJistuce |
Posted on 20-08-25, 02:33
|
|
Custom title here
Post: #909 of 1151 Since: 10-30-18 Last post: 21 days Last view: 2 days |
Wait... are you trying to load one game, enter cheat codes for it, and then swap to a diffrent gamewhile using the same codes? --- In UTF-16, where available. --- |
| joshua |
Posted on 20-08-25, 07:09
|
|
Post: #6 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
Yes, but it did not work...if you have any ideas let me know...but it looks like it won't be viable anytime soon. It was an interesting learning experience though. And of course, even if Funkyass is right, or either way, I thought I heard that even real Game Genie codes had issues when SNES games started having co-processor pins on sides...emulators maybe need to have option toggling between two major revised versions of Game Genie. Though I now remember also that infinite health code only froze health DISPLAY, not actual values...I had this very issue a year ago on -I think- SNES9X emulator...and I read recently that someone else had that issue and actually it is at least one counter example to assumption that co-processors had main code routines on main chip. I think only Action Replay or its Pro cousin worked on that Super-FX SNES game. So maybe SNES was unintentionally hostile to Galoob's cheating device implementation. |
| CaptainJistuce |
Posted on 20-08-25, 08:09 (revision 3)
|
|
Custom title here
Post: #911 of 1151 Since: 10-30-18 Last post: 21 days Last view: 2 days |
Posted by joshua It won't be viable EVER. Or even possible. A Game Genie code is little more than a memory address and a value to be substituted for reads from that address(albeit presented in an obfuscated manner). Different games contain different code and data at different locations. Using a code for one game on a completely different game is little more than toggling random bits in the cartridge to see what happens. That is, in fact, why different games have different infinite lives codes. Not because Galoob and Code Masters were desperate to sell updated code books. And of course, even if Funkyass is right He is. I thought I heard that even real Game Genie codes had issues when SNES games started having co-processor pins on sides...Some Game Genies did not have the sideport connections, this is true. No Game Genie affected those connections, but only some where capable of passing the signals through. emulators maybe need to have option toggling between two major revised versions of Game Genie. Emulating a Genie without the side connectors would be utterly pointless. Though I now remember also that infinite health code only froze health DISPLAY, not actual values...I had this very issue a year ago on -I think- SNES9X emulator...and I read recently that someone else had that issue That means you had a bad code that was altering the wrong value(and that behavior implies to me that it was an Action Replay code rather than a Game Genie code). and actually it is at least one counter example to assumption that co-processors had main code routines on main chip. We're still talking about Batman Returns, right? It doesn't have a coprocessor. I think only Action Replay or its Pro cousin worked on that Super-FX SNES game. No, Action Replay codes covered RAM addresses in the system instead of ROM addresses in the cartridge*. Rather than changing the game's behavior, they forcibly held values at a predefined point. That's really the only difference. Both devices work fine with SuperFX games, assuming the necessary connections are made. In fact, as I recall Galoob and Code Masters offered official codes for Yoshi's Island. So maybe SNES was unintentionally hostile to Galoob's cheating device implementation. It wasn't. The only issue was that Galoob cheaped out and didn't install a couple of contacts on some revisions. Those were a clumsy omission from Code Masters' original design, and I can't actually figure out why Galoob thought it was going to be okay. It was easy to fix at home though, since the devices without those contacts still carry the plastic molding intended to hold them. *Technically speaking, the Action Replay writes the value it was told that a given RAM address needs to contain into that given memory location on every screen refresh. The Game Genie intercepts reads to specific addresses in the cartridge and substitutes its own value for the value contained in the ROM. This makes Action Replay codes easier to develop, but they carry more unintended side effects and cannot be as powerful as Game Genie codes. The Pro Action Replays, to my understanding, merely expanded the address space they could handle so that in addition to rewriting values in system RAM they could also substitute values in cartridge ROM, giving them the ability to perform Genie-like feats. Neither device is capable of doing anything to the state of any coprocessors, whether they used the side connectors or not. Coprocessors have their own in-cartridge RAM that they work out of that no cheat devices can reach. And coprocessors don't go through the cheat device when they read a ROM, because they are inside the cartridge with the ROM. And bringing this back around to the beginning... Posted by joshua "Code was written for a completely different game" is not an unknown reason. --- In UTF-16, where available. --- |
| joshua |
Posted on 20-08-25, 09:26
|
|
Post: #7 of 9
Since: 08-21-20 Last post: 1322 days Last view: 1319 days |
"Neither device is capable of doing anything to the state of any coprocessors, whether they used the side connectors or not. Coprocessors have their own in-cartridge RAM that they work out of that no cheat devices can reach. And coprocessors don't go through the cheat device when they read a ROM, because they are inside the cartridge with the ROM." "Neither device is capable of doing anything to the state of any coprocessors, whether they used the side connectors or not. Coprocessors have their own in-cartridge RAM that they work out of that no cheat devices can reach. And coprocessors don't go through the cheat device when they read a ROM, because they are inside the cartridge with the ROM." https://www.romhacking.net/forum/index.php?topic=29487.0 ;second post that replies gets into the weird SFX-2 chip mapping of health value on game..."No, Action Replay codes covered RAM addresses in the system instead of ROM addresses in the cartridge*. Rather than changing the game's behavior, they forcibly held values at a predefined point. That's really the only difference. Both devices work fine with SuperFX games, assuming the necessary connections are made. In fact, as I recall Galoob and Code Masters offered official codes for Yoshi's Island." Actually, we both were wrong here I think: https://www.romhacking.net/forum/index.php?topic=29487.0 3rd post. I think Game Genie was more adaptive than Pro Action Replay in co-processor games like Doom...and if I'm right that after Sega Genesis 32X, Nintendo pushed co-processors being used in most SNES games to offer cheaper alternative to 32X add-on and avoiding its new system stress. I always wondered how Nintendo's SNES survived even during Fifth Generation birth of gaming. "Emulating a Genie without the side connectors would be utterly pointless." Probably, but would it be so much trouble to include that variation in case. "https://forum.digitpress.com/forum/showthread.php?155628-Game-Genie-SNES-Problems" 6th post at least makes me ponder the horrifying possibility of what is mentioned could happen (mid-game failure of Yoshi's Island). |
| CaptainJistuce |
Posted on 20-08-25, 09:57
|
|
Custom title here
Post: #912 of 1151 Since: 10-30-18 Last post: 21 days Last view: 2 days |
Posted by joshua I see that the game engine stores health inside the cartridge RAM and pushes it out to console RAM every frame. Which explains why the Action Replay codes are unreliable, as both the game and Action Replay are doing the same thing at the same time and it is anyone's guess who winds up winning on any specific frame. I don't see anything relevant to my statement. Note that emulator cheat functions typically offer a much wider range of addresses than an Action Replay or Game Genie could affect. "No, Action Replay codes covered RAM addresses in the system instead of ROM addresses in the cartridge*. Rather than changing the game's behavior, they forcibly held values at a predefined point. That's really the only difference. I don't see anything that disproves a word I said. Both devices work fine with SuperFX, assuming the necessary connections are made. Neither device is capable of altering cartridge-side RAM, coprocessor reads from ROM, or coprocessor reads from system RAM. That thread lines up EXACTLY with that statement. I think Game Genie was more adaptive than Pro Action Replay in co-processor games like Doom... Not really, except in that the Game Genie was more powerful in general. You're mistaking Doom's clever anti-cheat mechanism for a unique attribute of the SuperFX. and if I'm right that after Sega Genesis 32X, Nintendo pushed co-processors being used in most SNES games to offer cheaper alternative to 32X add-on and avoiding its new system stress. Coprocessors showed up much before the 32x. And later on Nintendo pushed the SA-1 coprocessor as a form of copy-protection. The SA-1 was between the system and ROM chips, so if a device didn't issue the SA-1 instructions to make the ROM accessible(as copiers wouldn't), most of the game was unavailable to read. Though quite powerful relative to an unexpanded Super Nintendo, it was greatly overshadowed by the capabilties of the 32x. And the 32x's problems weren't that "new system stress". They were 1. that it was an expansion for the Genesis, so a 32x game would always see fewer sales than a Genesis game, and 2. the Sega Saturn was announced by Sega Japan at the same time Sega America announced the 32x, Sega Japan hoovered up most of the developers available to make Saturn games, and few people could see paying new console prices for a Genesis add-on when a genuinely new console was just around the corner. I always wondered how Nintendo's SNES survived even during Fifth Generation birth of gaming. It didn't. The fifth generation ended with the Super Nintendo's launch, as that was the point at which the Nintendo and Sega Master System were both obsolete. I mean, assuming we try to force things that didn't release in a generational lockstep to fit into a neat set of generations in the first place. "Emulating a Genie without the side connectors would be utterly pointless." Probably, but would it be so much trouble to include that variation in case. Why would you WANT to emulate "exactly the same thing, only the SuperFX and SA-1 will never turn on"? Seriously, the hardware does not have access to those pins on either revision. One revision has them wired straight through, the other doesn't have them wired at all. Neither one has the Genie capable of actually viewing and modifying what little data is there. "https://forum.digitpress.com/forum/showthread.php?155628-Game-Genie-SNES-Problems" 6th post at least makes me ponder the horrifying possibility of what is mentioned could happen (mid-game failure of Yoshi's Island). That last post is very stupid(as are a few other posts in that very short thread). The SuperFX is live from the get-go, not just in boss fights. It is rather obviously in active use on the title screen. You cannot start the game without running SuperFX code. Also, game ROM is mapped behind the SuperFX. The SuperFX can turn access to the ROM on and off. To my recollection, if the SuperFX doesn't work, the ROM data is never made accessible. You cannot even BOOT the game. Which, incidentally, was my experience when trying to use the game with the official codes on my Game Genie with the incomplete cartridge connector. --- In UTF-16, where available. --- |
| funkyass |
Posted on 20-08-25, 16:56
|
|
Post: #153 of 202
Since: 11-01-18 Last post: 450 days Last view: 83 days |
am I reading this right, did joshua think that a life code for one game would work on another if he swapped cartridges? |
| Kawaoneechan |
Posted on 20-08-25, 17:19
|
|
A man of wealth and taste
Post: #512 of 598 Since: 10-29-18 Last post: 115 days Last view: 12 hours |
You're reading this right. |
| funkyass |
Posted on 20-08-25, 18:08
|
|
Post: #154 of 202
Since: 11-01-18 Last post: 450 days Last view: 83 days |
that would probably wreck stuff if tried on real hardware. |
