We’ve linked videos in this series many times before, but it’s wuite a doozy this time. Final Fantasy is known to have a number of combat bugs. Critical Hit chances are determined by the index of the weapon in the weapon table, not the stat in that table; weapon special properties just don’t work, regardless of what the Nintendo Power Strategy Guide says; and more.

This isn’t just an explication of those bugs though, it goes through all of how basic (non-magic) combat works in the game, explaining the value of all the stats. That’s one of the things about RPGs: you’re told items are “+4 better,” but often those values don’t match up to what they’d mean in D&D, where a plus is usually either a one-point increase in damage, a 5% improvement on odds for something, or both. Final Fantasy’s attack roll turns out to be a 1-in-200 die, so, a mere +1 is negligible to attack odds.

They probably didn’t elaborate on what these numbers mean in the manual because, at the time, Square and Nintendo were keen to get players hooked on Final Fantasy and other JRPGs, and nothing would dissuade them from picking up the game than to be confronted with battle formulae in the manual. Looks too much like school work! But they could have at least mentioned something about relative chances?

If you really want to know what the numbers mean, the video is there waiting for you. You can just let your eyes glaze over during the math if you want. I won’t tell the teacher!

rodneylives

G&G was implemented by popular early NES anonymous developer and target of player recrimination Micronics, but Commando can’t use them as an excuse, as it was developed in-house at Capcom. They were still learning the ropes of the NES at the time (Strider has no such excuse), and it shows. Displaced Gamers thinks that the game was shipped while the programmers were still working on optimizing it. As they do sometimes, DG implemented their own optimizations, improving the game substantially. You can see the product of their work in a 31-minute video they made about it, here. There is a substantial amount of 6502 assembly code involved, but if you skip around I think you might be able to get the gist of why the glitches happen, and how Displaced Gamers fixes them.

As was often the case with your jankier NES games, the scroll stutters and character chaos were caused by the game failing to make its VBLANK timing targets. Thing is, despite the glitches, NES Commando is arguably the best version of the game! Characters sometimes disappear from the screen and backgrounds turn into garbage, but there’s so many cool secrets and things to find in it that I can forgive Capcom for it.

Note that Displaced Gamers doesn’t release patches with their fixes, preferring to focus on making videos. Their code is presented on-screen though, so it’s possible for others to insert the changed programming on their own. I hope someone does this soon, as a fixed version of NES Commando would be nice to play.

rodneylives

Here’s the video. If you enjoy this sort of thing, we’d probably get along very well in person!

rodneylives

Most of the differences were superficial: they changed the cover art slightly and added a ® symbol replacing a on the Official Nintendo Seal. On the rom itself, they changed the names of the lands in the ending, from a flavorful set of localized names to just Adjective Land eight times in a row.

But there were other changes, and one of them was a substantial difference in the code, one that required moving much of it around by seven bytes to make room for it.

What was it? In brief, there’s one level in the game, 7-3, that uses a vertical-only scroll instead of a horizontal or multi-directional scroll, and it writes the images of the cards in the status window to the wrong place. So in the original release, on that one level, the card images are mysteriously blank during the vertical section.

That was fixed in the revision, which meant a check for what kind of scroll the level was using, and which changed the pointer to where to write them. Code needs space, and that space came out of a section of unused bytes at the end of the rom, with all the code between the change and that section shifted to account for it. If you had a Game Genie code that relied on data in those memory locations, too bad! You’ll need a modified version of that code.

Here’s the full low-down, which goes into much greater detail:

rodneylives

• Contra Force (why is it slow?)
• Mega Man 3 (glitches)
• NES Tetris (why does it crash at extremely high levels?)
• Dr. Jekyll & Mr. Hyde (wherefore the jank?)
• Also Dr. Jekyll & Mr. Hyde (mo jank mo problems)
• Strider (the hideousness of its code)
• Strider Again (more hideousness)
• A primer on the NES’ sprites
• A deep dive into Punch-Out’s enemy boxer engine

Well here’s another, and it actually is a follow-up to a video that I don’t think we linked to before. So here’s that video first, on Micronics’ port of Ghosts n’ Goblins to NES. (32 minutes)

Pretty long already, exquisitely geeky! Well its successor is even more geeky, as they actually reprogrammed the game to have a more optimized sprite engine. Although it’s a shorter video, at 24 minutes!

Ghost n’ Goblins is designed around being a 20fps game, so no amount of optimization will change that, it requires more substantial modification. But the time visualizations they use indicate that it may be possible to change that to 30fps, and with other changes 60fps may be possible. Mind you, the logic for the player, enemies and weapons all assume 20fps, so unless they’re changed to account moving to 60 frames per second will triple the speed of the game, so that obviously would need to be changed as well. I look forward to seeing the next chapter in this retrocoding saga.

rodneylives

Here is their video on the coding problems with Konami’s Contra Force (24 minutes):

Watch the video for the full spiel, but here’s a summary.

Once upon a time, in the waning days of the Famicom, Konami planned to release a game called Arc Hound in Japan. It was going to be another of their trademark run-and-gun shooters, along the lines of Contra. It even received coverage in enthusiast magazines in Japan, and it probably would have used one of Konami’s bespoke mapper chips like the VRC6 that the Japanese version of Castlevania III used.

Arc Hound was likely far into development when the decision was made to not release it in the Japanese market. Producing a game cartridge requires a substantial investment in parts and marketing, of course, and they must have judged that they couldn’t make enough of a profit off of it in their home territory: the Super Famicom was already out, as well as Contra III on that platform. But the NES still had a little bit of life left in it in the US, so they decided to give the game a shot over here, as a title in the Contra series

A big problem there was Nintendo’s policies towards manufacturing NES games. Nintendo demanded the right to build all the licensed software for the NES, and further restricted most (although not all) publishers to using Nintendo’s own family of mappers. Konami had been forced to revise their games to use Nintendo’s mappers in other games: Castlevania III famously used a different mapper in Japan, one that offered greatly expanded sound capabilities that worked through the Famicom’s sound channel pass-through, but was incompatible with the NES.

Extra sound channels are nice, but the primary use for most mapper chips is bank switching, swapping different sections of a cartridge’s data into the Famicom/NES’s 6502-workalike’s 64K address space, and also potentially making different sections of the game’s graphics data visible to the PPU graphics chip.

Behind the Code’s examination of the game program reveals that a large portion of the time of each frame is spent in setting up bank switches. Whether it was coded poorly, or just that Konami didn’t want to pay to include a mapper with more a more efficient bank switching mechanism, the game wastes a lot of time just pulling in different banks of data to be visible to the NES’s hardware. So it is that Contra Force could have run a lot better, but Konami either didn’t want to expend the coding effort, or pay for the the mapping hardware, to allow it to do so.

Presumably, somewhere in Konami’s archives, there is a version of Arc Hound that uses a VRC chip to handle mapping, and that runs much more smoothly. Maybe someday it’ll come to light, although I wouldn’t lay any bets on it. More likely perhaps is that someone will hack up the code and make such a version themselves. Who knows?

rodneylives

Game graphics in the 8- and 16-bit ages often came down to tricky hardware manipulation. The art of doing raster effects, changing the registers in the video hardware so as to divide the screen into different sections, ultimately comes down to timing. On the Atari VCS/2600, nearly all the graphics had to be done that way, but it was still a useful technique for over a decade after that.

A lot depends on the specifics of the video chip, a custom-built piece of silicon developed for the express purpose of taking graphics defined in memory and folding it, like electronic origami, into a shape that the TV would perceive as a broadcast signal. At that time, while it might still have been possible with clever coding, CPUs weren’t nearly fast enough to do that job themselves and still produce acceptable graphic quality and run game logic. (If you want to see what it would be like, I refer readers interested in doing it the very hard way to the amazing Freespin demo, which runs on a 1541 disk drive, and no video hardware at all.)

Older NES games used a supported bit of hackery called the “Sprite 0 Hit,” a signal the PPU would send at the moment the first of the system’s 64 sprites began to be drawn. By watching for it, games could do rudimentary raster effects on a system not designed for them. The issue there was processor time: the Sprite 0 Hit feature wasn’t hooked up to an interrupt line, so the program had to continually watch for it, checking a memory location repetitively over and over until it changed. Some games spent large portions of their runtime in a tight loop checking for the Sprite 0 Hit. Since, from the program’s perspective, the signal might come at any time, the loop needed to be tight, meaning the game couldn’t spend that time doing other work or else it might be delayed in responding to the extremely time-sensitive signal.

The MMC3 mapper had a special function though that could time out when a programmable scanline was reached, and send the processor an interrupt request at that time, greatly freeing up the processor for doing other things with that time. But not all programmers understood the best way to use it, which is why Mega Man 3 has some scanline glitching in a couple of very visible places, in the pause window and on the level select screen.

Displaced Gamers’ Behind the Code series, which we’ve linked to multiple times in the past, has done an exposé looking into how Mega Man III’s glitches happen (28 minutes), and even wrote some code that erases all trace of them. As usual for Behind the Code, the explanation is fairly technical, especially of the fix, but the first half of it is fairly comprehensible. No one says you have to watch the whole thing. Or, indeed, any of it, but I always enjoy them!

rodneylives

Another fact about J&H: the Japanese version had two full levels that were cut from the U.S. version, which replaced them with replays of other levels. It made a bad game even worse!

Now, because of Behind The Code, you know more about the Dr. Jekyll and Mr. Hyde game than many much better NES titles. Congratulations!

rodneylives

It’s 19 minutes long, and is even geekier than is usual for us, going into a disassembly of the game’s machine code in its quest to make the game marginally less awful.

As long as we’re on the topic, here’s Jeremy Parish’s NES Works episode on Dr. J & Hyde, which is also 19 minutes, and also covers the somewhat better (but not hugely so) game Amagon:

While we’re on the subject, did you know that Jekyll & Hyde has a secret ending? Both endings are shown here (4 minutes):

The “bad” ending is the normal one, and shorter, but is arguably a happier conclusion to the story. To get it, all you have to do is get to the end of Stage 6 with Jekyll. That’s all.

To get the other ending, get to Stage 6 with Jekyll, then turn into Hyde and get to the end of his version of the stage. Usually, if Hyde gets as far into his level as Jekyll has gotten into his, he’s struck by lightning and dies. But in this level he’ll be allowed to reach the end of his version of the level for some reason, where there’s a boss! Beat it, and when you return to Jekyll’s world the enemies will be gone, and he’ll be free to finish the level without harassment. However, ending events will be different….

rodneylives

We linked to their last video examining its malformed construction. Well, Strider is the well of crap that keeps on gushing, and so Displaced Gamers has another video on the subject of the flaws in its programming, this time about its player physics. Walking into walls causes Strider Hiryu to shudder in place; jumping beneath a low ceiling causes him to bump his head repeatedly as his jump continues even though there’s no room to ascent; and his infamous “triangle” wall jump is so wonky that it literally requires a frame-perfect input to pull off, and not even the right frame. You have to jump the frame before you contact the wall!

Here is the new video, which explicates the entire cruddy system. It goes into exquisite/excruciating detail, including tracing the code and examining Hiryu’s X and Y coordinates on a frame-by-frame basis. It’s the kind of deep geekery that I just know you love/hate! Enjoy/despair!

The Physics Nightmare and Bizarre Jumping of Strider (NES) – Behind The Code (19 minutes)

rodneylives

A company that usually did a lot better with their internally-developed games was Capcom, makers of Mega Man, 1943, Bionic Commando, and all the Disney Afternoon games from the time, all of which have slick 60 fps update rates and smooth animation. One game they made of which that is definitely not true, however, is NES Strider.

If you’re only familiar with Strider from the beautiful arcade version, you might wonder what even NES Strider has to do with it. It’s not proper to say Famicom Strider, because Capcom never released it in their home territory, perhaps because they were too embarrassed to.

Other than the first stage being set in generally the same fictional location in Russia (even if it doesn’t look at all the same), its story has absolutely nothing to do with it. Jeremy Parish looked at it (and remarked on its glitchiness) in an episode of Metroidvania Works from a couple of weeks ago. Some people, like Kid Fenris of the self-titled blog, actually likes it, although acknowledges its many issues.

Behind the Code, one of the best game internals series on Youtube, had a look at the implementation of NES Strider. It’s an interesting 15 minutes to my taste, but if you want a tl;dr, NES Strider often doesn’t make its framerate target, and instead of slowing the game down as most games do, it plows ahead forward into the next frame, leaving the incomplete data in its update buffer to be copied into the PPU. This causes the individual hardware sprites that compose enemy characters to sometimes have only one of their coordinates updated, or even causing data remaining from previous frames to be copied over.

Why does it does this instead of just slowing the game down? Possibly the coding was so crappy that it would have caused excessive slowdown; the scene chosen as an example in the video has the problem occur when there’s only two basic enemies on the screen in the game’s first area! Not the best engine on the system there Capcom.

The Garbage Sprites in Strider (NES) (Behind the Code on Youtube, 15 minutes)

rodneylives

The gist: while each scanline is being prepared for display, the NES’ PPU looks through the entries for the machine’s 64 hardware sprites in order, finds the first eight that will display on the current line, and copies their attribute data to a small area of internal RAM. There is only space there for eight sprites, so, the NES cannot display more than eight sprites in a single scan line. Any later sprites in the primary attribute data won’t have room to be copied, and so the PPU won’t be able to display them.

One thing it notably doesn’t cover, however, is how games implement priority shuffling to cause sprites to flicker instead of not display at all. The video suggests that that might be coming in a future video….

NES Sprites, OAM, and the Battle for Priority – Behind the Code (Youtube, 19 minutes)

rodneylives

Not so with the Punch-Out!! games. They are essentially entirely different kinds of games from that. You have certain things you can do moment to moment, and opposing boxers do too. Each of those opponents basically runs a big script, made out of byte code, that determines their behavior throughout each round of each fight. I am struck both by the simplicity (no need to simulate gravity) and the complexity (boxers take all kinds of things into account) of the system.

One of the interesting things shown is that the engine can affect more than just the boxers, but can also subtly affect the crowd, which is how the previously-revealed fact that a specific camera person in the crowd uses his flash right at the moment the player must counter Bald Bull’s charge move. It turns out that this isn’t the only instance of this happening in the game!

You don’t need to know 6502 assembly code to get what the narrator is talking about, but a lot of code is shown, so those of you who understand it may get a bit more out of it. Here are a few basics to help you follow along.

The 6502 has only three registers (bits of memory internal to the CPU that can be accessed quickly), the Accumulator (sometimes called just A), the X register, and the Y register. Each is only one byte long. The Accumulator is by far the most flexible, but all three are general-purpose registers. The most common instructions are Loads (LDA, LDX, LDY), Stores (STA, STX, STY), Transfers between registers (TAX, TAY), Incrementing and Decrementing (INX, INY, DEX, DEY), Adding (ADC), Subtracting (SBC), Comparing (CMP), Branches (some of them, Branch Not-Equal to Zero: BNE, Branch Equal to Zero: BEQ, Branch of Carry Set: BCS, Branch on Carry Clear: BCC), Jump (JMP), Jump to Subroutine (JSR), and Return from Subroutine (RTS). While some instructions are just one byte long, the longest any 6502 instruction can be is three bytes, and the opcode (the command itself) is always just one.

(I wrote all of that from memory. I figured, I have all of this in my head from my coding youth, I might as well use some of it.)

The 6502 can only address 64K of memory, so often systems will use bank switching to connect various memories to it within that space. The great majority of NES/Famicom games had to do this. Punch-Out!! was unique on the NES in that it was the only game to use Nintendo’s MMC2 chip. (I wonder if the chip was designed ahead of time, and they made this game as an excuse to use it?) Punch-Out!! uses MMC2 to bank in each boxer’s large data script as needed.

Behind The Code: How Do Boxers Work in Mike Tyson’s Punch-Out!!? (Youtube, 20 minutes)

rodneylives