Fixing a Konami SNES classic 1

You know what's weird in the retro gaming community? All the flak Working Designs gets for changing the difficulty level of the games it localised. Fans across the internet cry bloody murder at the changes. As shown in previous articles, we love Working Designs at Time Extension. (Even though founder Victor Ireland no longer replies to our emails; we still want that interview Vic, call us! We want to be friends!)

Yet despite all that, fans will give Konami a free ride, despite it being far worse in terms of butchering its own games during localisation. Konami was infamous for making games harder for the American (and therefore also PAL) market.

The Adventures of Bayou Billy on NES was so made so difficult, fans fixed it not once, but twice! Contra III on SNES had cheat codes removed, infinite continues nixed, plus the secret boss was no longer accessible on Normal. Fans fixed that too with a restoration patch. Contra: Hard Corps on MD had the life-bar removed, to make it unnecessarily difficult - and that game was hard even with the life-bar! Again, fans fixed it. Castlevania III on NES, meanwhile, had so much ridiculous fiddling we don't know where to begin. Most changes just brute-forced the difficulty higher, but a lot of them simply dilute the original's intelligent design – why, for example, did they alter the unique damage each enemy inflicts, to a blanket damage value based on the stage? That just makes the gameplay shallow and uninteresting.

Ramping up the difficulty during localisation goes against the original team's vision. Why though? Why did American publishers make these changes? There's a lot of speculation online, but if we look at interview quotes, we find a recurring theme.

Ayano Koshiro, in an interview with Time Extension, said the reason for ActRaiser 2 being so difficult was due to the American publisher:

The reason for the different difficulty levels was, again, the US branch of Enix. They wanted us to make the game harder because, apparently, people were complaining that they took a whole week off to play the first ActRaiser and then reached the end credits after only two days. They bought it, and then took far less than a week. And those complaints ultimately caused the change in difficulty for the US version. These are simply very different values. We already made the game a bit more difficult than its predecessor. But then Enix came to us with feedback that it should be much harder. So we looked at the damage values of the hero and the enemies, tweaked them a lot, and at some point, we barely had any more overview ourselves. We were just paid to do it that way.

Kouji Yokota, designer and artist on Gaiares for Mega Drive, described to me during the Untold History of Japanese Game Developers project how Renovation Products in the US demanded greater difficulty:

Gaiares was originally intended for the overseas market, to begin with. But overseas, since there was a tendency for people to buy and play a game and then immediately sell it, as well as rental systems, the overseas publisher had asked us to make the game more difficult so that it would not be rented and completed easily. So we went over to the overseas publisher to show them the demo, and then they said, 'You should make it even more difficult!' We started getting concerned at this point, but we complied with their request. So ultimately the game became very difficult when it was released.

Victor Ireland (we're still waiting for that reply, Vic) of Working Designs reiterated this when explaining why Popful Mail was made harder during localisation:

The Japanese one was far too easy, and there was no real challenge or strategy to any of the bosses. In Japan you buy a game and you own it. In the US, especially at the time, return policies were extremely liberal. To leave the game as-was, would be to guarantee that a substantial portion of the games would be 'extended rentals' at our expense.

Masato Maegawa of Treasure said the same regarding Dynamite Headdy on Mega Drive:

In the US, there is a system for renting games, and if they get to the ending of a rental game, they won't buy it... I thought, 'Is that really true?', but I said, 'If you want to make it difficult, let's make it as difficult as possible,' so I made it as difficult as possible.

We don't have explanatory quotes for the specific Konami games listed at the start, but it's safe to surmise all these changes, for various games, were the result of concerns over American kids renting a title, finishing it, and then not buying it. In the minds of the American publishers, clearly, the way to encourage kids to drop $50 or more was by making a game so teeth-gnashingly punishing they'd struggle to get past the second level... Yeah, because that would totally make us want to spend our limited pocket money.

Anyway, if you dig through Konami's back catalogue you will find countless localisation trainwrecks - including Tiny Toon Adventures: Buster Busts Loose on SNES.

The Japanese release had two difficulties: Kids and Normal. The Kids mode truncated levels by around 60%, so by playing it, you wouldn't see the ending, and you'd experience less than half the game. However, Buster's dash move could defeat enemies, and it was easier. The Japanese version also had infinite continues and a password system, which worked on both difficulties. If you reached the credits on Kids mode, you just had a text scroll on a black background, while on Normal, you'd get the proper ending and a fun credits scroll over the in-game characters fooling around. It was balanced just right.

The US version (and, by extension, European releases) added a harder Challenge mode, where you only had one energy heart instead of three. It reduced the continues to 5 for Normal and 3 for Challenge. Worst of all, it disabled the passwords for Normal; inputting a password automatically defaulted you to Kids mode, which was garbage since you missed out on most of the game. It also disabled the level 5 password for Buster's Sky Jinks since it couldn't be played in Kids mode. Oh, and just to say "f**k you" to their customers, Konami USA locked the nicer credits scroll behind the Challenge difficulty! The entire thing was a travesty.

Some have said that losing the password system and being forced to play through the entire game in one sitting was fine since it was satisfying to beat it. This is the wrong attitude. Buster Busts Loose is a wonderful game, and having passwords after each level allows you to access later levels just for the joy of playing them. The American Football level, for example, is unusual and inventive in how it subverts traditional platforming. Every level is so different; they're worth savouring individually. The original Japanese team's vision for the game was to have passwords, and Konami USA be damned for thinking they could just mangle the game.

After its release in 1993, the press loved it. Super Play awarded it 89%. GamesMaster gave it 92%. GameFan scored it nearly as high as Star Fox. Total! magazine rated it 87%, stating the Challenge mode was so difficult it had to be Konami playing a prank. To any young enthusiast of the SNES (or the cartoon), the game was captivating. But something always felt off... Why did the password system default to Kids mode every time? Years later, discovering the import, the answer was revealed: Konami USA did its usual half-arsed job. Thanks guys.

While this won't matter if you're emulating (you could just save state each level), if you're playing on real hardware, it's going to be annoying. So we decided to fix things!

Originally we simply posted on the RHDN forum, in the "hack ideas" thread. That's where people with big ideas but limited skills go to make suggestions. Surprisingly, prolific hacker Bankbank sent a PM saying it would be easy to implement, and perhaps we should collaborate. He would do most of the heavy lifting, but as a tutorial to learn hacking assembly code. As we discovered, he's not only an extremely prolific hacker, but also a developer on Steam, creating games for legacy systems such as the Mega Drive (plus, he's an all-round cool person – thank you for the help).

It would turn out to be quite the adventure. Hopefully once you've read how it happened, you'll be encouraged to try some hacking yourself. It's easy with the right tools, is a lot of fun, and everyone who enjoys games should hack one at least once! We used the emulator Mesen as our primary debugging and hacking tool, since it's extremely versatile and quite straightforward.

Fixing a Konami SNES classic 1
Image: John Szczepaniak / Time Extension

First thing: finding out which work RAM (WRAM) value defines the difficulty and why the game forces itself into Kids mode when entering a password. If we can correct this, then passwords will work on Normal and Challenge. This was easy since you just change the difficulty in options and see what WRAM values change. Most emulators will alert you to values changing, and since you're doing nothing else in-game, it's easy to narrow down.

Turns out byte $6C holds the difficulty setting in WRAM. Keep that in mind, because $6C is going to crop up a lot - most of Konami USA's hamfisted meddling here revolves around this value. Once you know this, you can tell Mesen to alert you every time the game's code references this value. Every time the game checks to see if it's in Kids or Normal, or whatever, in order to alter something, it'll check the value of $6C, and the emulator will then tell you. Because then you can change the code there. Bankbank sent a screenshot showing how, after successfully entering a correct password, the game's code references the difficulty value, and there are two instructions: STZ and $6C.

The Mesen emulator actually explains assembly instructions if you hover your mouse, so it's super easy. But Bankbank reiterated that STZ means to store the value zero (00) in whatever comes next. Meaning after entering a password, the game turns the difficulty value to 00. Meaning that Normal is 01, and Challenge is 02. So these two little instructions (STZ and $6C) will change the difficulty to Kids. The solution? Replacing those two instructions with NOP, meaning "no operation". Or, if you're editing the hexadecimal code directly, you type EA for the same effect. With this knowledge, your author opened up Mesen, did a search for the address 91EA80 (as shown on the screen), and replaced STZ $6C with NOP NOP. The result? It no longer stored zero in $6C, meaning no more resetting to Kids mode!

If you're a veteran programmer, our explanation probably sounds like it's for preschoolers, but we want readers to see how simple this can be. You change one value and have the emulator track it, to find where it's stored in WRAM. You then have the emulator tell you each time the game code references this WRAM value. Then you can change the game code. Simple.

Fixing a Konami SNES classic 1
Image: John Szczepaniak / Time Extension

Now that we knew what value the game referenced for difficulty, we could also fix the end credits. Using Mesen, your author set about reaching the end screen on Normal and Hard, creating save states to compare WRAM values and reinstate the proper credits sequence. Bankbank did the tedious job of then going back and forth between saves, noting any differences. The credits are a fixed block of code, without lives or timers, or enemy placement. So the only differences should be the difficulty ($6C, being 00, 01, or 02) and the background.

Fixing a Konami SNES classic 1
Image: John Szczepaniak / Time Extension

The next bit was more tricky. Bankbank sent a screen explaining he'd found where it checks just before rolling credits. First it loads the $6C value, and then it compares to see if it's value is 02 (Challenge) or not, because the full credits only appear on Challenge mode. Next is a branching instruction - to branch to the full credits or not. How to fix this? Bankbank explained the next bit used STA, meaning it stores a value in memory. We could use NOP again on the three subsequent bytes after STA; that would brute force it. Or we could invert STA with LDA - meaning it'll do the opposite, loading a value from memory. We were a little shaky on the technicalities, but decided to try swapping STA for LDA, and it functioned perfectly. The full credits now rolled regardless of the difficulty. Granted, this deviated from the Japanese, but no one should play Kids mode anyway, since it cuts gameplay. Also we didn't want to mess about further – it worked, let's just move on.

Anyway, passwords work again, and full credits can be seen on Normal, job done. Right? Not quite.

When you die and choose "end" instead of continue, it's meant to show the password for that level. But this only happens on Kids, since the passwords are not meant to work on higher difficulties. But for an authentic playing experience, players need to be able to see the passwords.

Armed with some working knowledge, I was determined to figure this out myself!

Three save states on the continue screens (Kids, Normal, and Challenge). Have Mesen break every time it references $6C. Thus, we found another LDA (loading a value) and another BEQ (branch if it equals). At first trial and error was used, seeing if changing LDA to STA would work, or using NOP, or even STZ to revert the value to zero.

Fixing a Konami SNES classic 1
Image: John Szczepaniak / Time Extension

Nothing. The Normal mode still went straight to the title screen. There was partial success with changing $6C to $68 or $82, two values which at that specific moment were 00. This had the effect of tricking the game into thinking it was loading $6C as if it were 00, but you can guess the problem here. Without knowing what $68 or $82 specifically did, weird behaviour might crop up. It was possible to have the emulator break on those two values, to see what they did, but this would be tedious. The solution needed to be logical and elegant.

Then an idea formed – that branching instruction, what if that was changed? Looking up assembly instructions online revealed that BEQ has its own polar opposite, BNE, meaning Branch if Not Equal. You know what we did next, right? We swapped BEQ for BNE and now the password only showed if you were not playing on Kids mode. Again, this deviates from the Japanese version, but we figured Kids mode has had passwords for over 30 years now, so this is retribution! (Also, it was simple, and it worked.)

Except the password that popped up now was gibberish. Back to the debugger. It turns out the game references the difficulty ($6C) again afterwards, to call up the correct password. It was another BEQ, so we swapped for BNE again (twice now), and lo and behold – the correct password showed up when selecting end. But only when not on Kids mode.

Job done, right? Nope. Remember how we said that the Buster's Sky Jinks level could not be accessed in the US game? You put the password in, and the game just beeps as if it's wrong. This needed fixing, otherwise re-implementing the passwords was a waste of time.

Bankbank did the heavy lifting again finding the section of code which governed passwords. Your author was worried that since Konami deleted that bit we'd have to find a way of programming in a whole new section... Could we splice the code from the Japanese ROM? Was there even space to add it back?

Turns out the programming code was still there, highlighting what a cheap hack job Konami USA did on this. The game checks the Sky Jinks password, as it's meant to, but Konami shunted in a dirty line of assembly, where if the level accessed equalled 04 it would branch as if a wrong password was entered (it's the 5th level, but if the first is considered 00, then you can see why 04 is checked). They hadn't even bothered to delete the code checking for that password. Well, that BEQ was no good, we needed to stop that. NOP NOP on the addresses 91EA5D and 91EA5E, perhaps? Why yes, that works nicely. Konami's stupid shunt code was replaced with "no operation", and the Sky Jinks password worked again, as it should.

Fixing a Konami SNES classic 1
Image: John Szczepaniak / Time Extension

If you're curious, we found that the following codes represented the password characters:

  • 00 - Babs
  • 01 - Plucky Duck
  • 02 - Montana Max
  • 03 - Elmira
  • 04 - Lady Duck
  • 05 - Tweety Bird
  • 06 - Gogo Dodo
  • 07 - Bookworm
  • 08 - Coyote
  • 09 - Road Runner

So the Sky Jinks password would be read as 06 / 08 / 09.

Right, so passwords now worked on Normal, and Normal showed passwords when ending the game, and the credits were fixed, and the Sky Jinks password worked again. Phew!

Bankbank suggested we try to reimplement the ending graphics. In the Japanese version, there's a unique image of Buster or Babs, depending on difficulty, whereas the US version just re-uses the title screen. Honestly, we weren't even sure if the ROM data still held those graphics. In your author's opinion, we were close enough for a V1.0 release.

The end result wasn't quite a reversion to the Japanese release. We kept the Challenge mode, and Kids mode lost the password, and all modes now have the full credits. Could it be done better? Obviously yes, but for a first-time effort in hacking assembly, we're pleased with the result and intend to do more in future.

Hacking game code is supremely satisfying. It doesn't even need to be as complicated as this. If you find the X,Y coordinate of a player character, for example, you can force the values to place that character outside of walls, for fun experiments going off-grid. It could even be as simple as giving yourself extra lives by searching for a specific value.

In fact, it occurs to us that Bankbank's help was akin to the proverb of giving a man a fishing net. With a little guidance, it started to make real sense.

As Bankbank explained:

I think if more people got exposure to assembly / debuggers, they'd be into it. There's just not a lot of places where people can learn about it, besides that one Youtube video series 'Behind the Code'. If you analyse the code, make notes in the disassembler. Annotate it, understand how the execution works, try to label as much as possible. You can also label addresses in WRAM, for example right click on $6C and you can write 'difficulty'. Once you understand the execution flow, I'm only talking about a small section of code, maybe 10 lines, then you can figure out how you want to make modifications. Doing things in a guessy way isn't a good idea, there can be unintended consequences. Just take your time; you can use the semicolon to make notes in the disassembler while execution is paused, and you can right click and re-label the blue labels. Like it'll show 80A64E, and you can change that to something descriptive such as END_GAME_CREDITS.

Following all the advice, we created an IPS patch, submitted it online, and confirmed the project was ready for release. Bankbank replied: "Hooray! But it's bittersweet because it's been fun working on this, and now it's over <laughs>."

It is a little, but there's plenty more hacking ideas to tinker with. We might go back to it later, and maybe also see if there's any anomalies in the UK, Spanish, or Korean versions. In the meantime, you can find our hack on Romhacks, while the submission process for RHDN has it in the queue. Please enjoy.

Would you like further articles taking an amateur look at hacking? We recently hacked the NVRAM save file on Virtuoso for 3DO, and the results were really strange. We also discovered some PC Engine games that do not use hexadecimal under the hood! Plus, messing around with the WRAM values of selected weapons in some games revealed things players weren't meant to access. Post in the comments if you'd like more.