6

As most of you know, the N64 Donkey Kong game had a game breaking bug on the 4 MB memory version. They needed to include the expansion memory just so that bug wouldn't happen.

I can imagine in the age of computers and emulation, we should by now have a pretty decent idea as to why this bug happened. As in, limit ram to 4 MB, see what tries to access outside there and why.

Sadly it probably is hard to figure that out, and I can imagine that at the moment of the development switch to 8 MB, they actually started using more of that ram since it was there anyway.

Does anyone know what exactly, nearly got that game pulled at all?

11
  • I disagree with the "On Hold" flag. From what I understand, the question is searching for factual information on whether or not a bug on a product has been patched or not (though the latter paragraphs are off topic, but are a different question anyways). "Has the bug been patched?" and "What's the cause of the bug?".
    – user1337
    Mar 1 '16 at 12:42
  • 3
    Voting to reopen as per my usual principles, i.e. a mod closed it.
    – Studoku
    Mar 1 '16 at 14:11
  • @Studoku Aren't the questions like "what is the first to x?" Off topic?
    – ave
    Mar 1 '16 at 14:49
  • @ardaozkal this isn't a search for an unknown game with specific criteria, this is asking for information about a specific game. Mar 1 '16 at 15:58
  • @Studoku If you're voting to reopen for no other reason than you're throwing a fit it was mod closed, you really need to question your choices. Now, if you have other reasons, then I'd recommend you articulate those instead of mod closure pettiness.
    – Frank
    Mar 1 '16 at 16:25
6

Does anyone know what exactly, nearly got that game pulled at all?

Unfortunately, the actual issue will likely never be known, at least not any time soon. I will detail several technical reasons for this which I believe are objectively compelling enough to base my answer upon.

The primary issue preventing the diagnosis of that glitch is a fundamental matter of hardware architecture, and how using software to force one architecture to behave another will more often than not be extremely difficult and sometimes completely impossible. This is the reason why emulators in general are difficult to develop, highly difficult to develop well, and darn near impossible to develop so well that they'll run all games for a given platform without issue. This is why there's so many crappy/unfinished/abandoned emulator programs out there and so few fantastic ones.

The second issue is that emulators don't actually emulate the hardware components and chipsets of a console. They just duplicate enough of the high level functions of the components that they're able to play the games. Even the emulators regarded as "perfect" are only cycle-accurate (correct timing), which is plenty for playing games but still not 100% hardware simulation (chip-accurate emulation).

The Donkey Kong glitch had to have been the result of some freak error between the memory management coded into the game and the actual memory control unit of the N64, meaning that to try to debug it via emulation on a PC, we would need chip-accurate emulation to fully simulate each and every logic chip in the N64's ludicrously complex Reality Co-Processor, funky 9-bit memory bus, and every other component. Unfortunately, this is literally impossible with current technology.

Most people will think the idea of a modern PC being unable to simulate the hardware of a 20-year-old Nintendo seems crazy. However, an Intel-architecture PC and an N64 are so vastly different in how they process data that a PC's extra CPU cores, exponentially faster clock, and several-thousand times more RAM isn't even remotely enough computing power to 100% accurately emulate the internal logic of an N64. In fact, a top end PC wouldn't even come close to being able to do chip-accurate emulation for an SNES or even an NES. Intel CPU's just aren't built for it. Even the one cycle-accurate N64 emulator is known to get choppy on anything less than an i7.

Finally, just for funsies let's say those technical limitations magically disappear tomorrow and someone hands us a flawless emulator to use for testing and debugging. I'd still be willing to bet against the true cause of the glitch ever being found. You have to consider the fact that we're talking about Rare in its heyday. This game was programmed by arguably the most talented and competent developers to ever write software for the N64 and who would have been more intimately familiar with the tiniest details of the hardware itself than anyone else in the world aside from the engineers who designed it. They would have known every aspect of the game's memory management logic inside and out because they literally designed and wrote the code for it. For the mystery glitch to elude them so completely as to make Rare say 'screw it' and give away expansion packs, the root cause would have to be something unbelievably obscure and impossible to track down with logical troubleshooting.

If the people who are the world's foremost experts on the DK64 software couldn't fix it when it was literally their job to do so, I doubt anyone else will discover the cause unless they just happen to by total accident.

7
  • You make good points. We do not know the circumstances under which the decision was made however. I can only imagine another outcome if the developers ran into this issue during crunch time, unable to find the time to even start finding the root of this issue. Thanks for explaining it this detailed and i am looking forward to chip perfect emulation! Apr 26 '16 at 17:02
  • 1
    @Smileynator Actually, I think we can deduce exactly what the circumstances of that decision were; the same decision has to be made from time to time at most software companies, including the one I develop for. When an unexpected development problem (like Rare's glitch) jeopardizes the delivery date the company agreed to, you find a workaround (for them it was the expansion pack). Then it's determined which will lose the company less money; going with the workaround or pushing the release date to try to fix it. It's a purely financial decision. Obviously the expansion packs were cheaper.
    – Barkode
    Apr 26 '16 at 23:11
  • You seem to take it for granted that chip-accurate or at least cycle-accurate emulation is necessary to uncover the cause of the bug, when I think that's rather doubtful. The issue could be something as simple as a wild pointer in the game's code, which would be reproducible in even the worst emulators. Of course, it should be a simple matter to just play the game without the Pak (hacking to run if necessary) to see if the issue can be reproduced in an emulator. If it can, then the cause of the bug probably wouldn't be hard to identify. Nov 25 '16 at 22:54
  • As for why I think it would be easy for us amateurs to find it when Rare themselves couldn't, Rare didn't have the tools we have today. A cycle-accurate N64 emulator would have been a pipe dream back then. Nov 25 '16 at 22:56
  • 1
    Again, if it's just a wild pointer, accurate hardware emulation is not necessary. A few weeks ago or so I investigated why a glitch for TMNT for NES behaves differently in emulators than on hardware and found it was because emulators were assuming 8 KB of RAM in $6000-7fff that isn't present on the cartridge. In FCEUX, which is not at all a hardware-accurate emulator, I verified that the game was indeed reading from that range. Mystery solved, no hardware-accurate emulation necessary. After we've ruled out the possibility of a wild pointer, we can talk about the need for hardware accuracy. Dec 20 '16 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.