Donkey Kong 64® didn't need the Expansion Pak™

[Fanatic 64]

Exactly what it says on the tin. Donkey Kong 64® could do all of it's graphics, sound and gameplay features with 4 MB of RDRAM. However, due to a weird bug that Rare couldn't ever figure out, the game would randomly crash during gameplay. Very strangely, the bug disappeared when adding another 4 MB of RDRAM, aka the Expansion Pak™. So, Rare had 2 options: rewrite the game from scratch or include the Expansion Pak™ for free. For Rare's lose and the customer's win, they went with the later.

How do I know all of this? http://www.nintendolife.com/news/20...ed_expansion_pak_to_prevent_game_breaking_bug

So the interesting news here is that Donkey Kong 64® wastes 3.9 MB of RDRAM, quite impressive with those graphics and gameplay. The good thing is that I got my Expansion Pak™ with Donkey Kong 64®, so I didn't have to pay for it (although I didn't know I was harming Rare/Nintendo that way ).

 

[ExtremeDude2]

Very interesting, I'm glad they did it tho so that the expansion paks are much more common :3

 

[NES_player4LIFE]

Interesting, hmm I wonder if the commentary is any good?

 

[Fanatic 64]

Interesting, hmm I wonder if the commentary is any good?

That video should clearly be marked as not appropriated for people less than 18 years old. We want to keep EmuTalk.net COPPA compliant, right?

But yeah, there's some interesting facts in that video. I recommend checking it out (if you are over 18 of course!).

 

[NES_player4LIFE]

That video should clearly be marked as not appropriated for people less than 18 years old. We want to keep EmuTalk.net COPPA compliant, right?

But yeah, there's some interesting facts in that video. I recommend checking it out (if you are over 18 of course!).

Hence the reason I didn't link to the video itself.

 

[PsyMan]

Now it all makes sense. So that's why DK64 is as unstable as f*ck on every emu. It's not the emu being bad, it's the game having self-crashing bugs.

 

[NES_player4LIFE]

Wow, that clears it up. Maybe someone can build a workaround.

 

[Fanatic 64]

Well, if it doesn't happen in the real N64 (which shouldn't happen with the Expansion Pack™ as mentioned), then it shouldn't happen on emus, so...

(What we need now is a patch to allow the game to run with 4 MB of RDRAM, even if it crashes randomly, for those who have the real N64 and a flashcart, but not an Expansion Pack™)

 

[NES_player4LIFE]

/\
However I have the real system and this game will not load without the extra ram installed.

 

[Fanatic 64]

/\
However I have the real system and this game will not load without the extra ram installed.

That's what I mean, make a patch so that the game loads even without the extra RAM (aka. disable the RAM size check and force the game to run), it shouldn't be hard to do since the extra 4 MB of RDRAM are (usually) unused anyway.

 

[NES_player4LIFE]

Hmm, sounds like a good theory.

 

[PsyMan]

Well, if it doesn't happen in the real N64 (which shouldn't happen with the Expansion Pack™ as mentioned), then it shouldn't happen on emus, so...

With that reasoning all emus would need to be cycle accurate and all emu developers should have 100% knowledge of the hardware in order to emulate hardware and software bugs (some of them being unknown even by the ones who made the said h/w and s/w).

Now, tell me how we can do that while keeping performance acceptable.

Not to mention that a random emu developer who has nothing to do with the game needs to find why the bug occurs, while the ones who made the original console and the ones who made the game had absolutely no idea and got so frustrated that they ended up using additional hardware as a workaround.

 

[Fanatic 64]

Hey, calm down! I never said anything about all emulators needing to be cycle-accurate or **** like that. I was just disproving NES_player4LIFE's statement that all (emulation) errors in this game (like polygons sticking out of the character, being send back to the beginning of the level, the DK Rap being out of sync, etc) were the game's fault and not the emulator's, which clearly isn't true if these errors don't happen on the real N64 or vary between emulators.

 

[Cyberman]

It's always interesting how bugs propagate and are fixed. Some bugs aren't easy too find, mostly because the lack of "bread crumbs" to find out what is going on.

The RDRAM is likely something like a buffer over run error. It really depends on how they managed the scene building in the game.
It also makes sense if the game halts to prevent the game from running without the 8M RDRAM as it "needs" to have the memory (to fix the bug).
It was hard to understand what they were saying due to accent and they seemed likely to be already inebreated (listening to their chat it seemed that way).
Erstwhile one of the biggest problems when you manage a limited resource is how you handle memory allocation for when you have none left.
None of these issues are technically impossible to fix however it may have been that it was cheaper for them to ship it with the cartridge than too fix the bug (as likely the person who worked on that part of the game was doing something else in the company).

Anyhow interesting to hear about. I can't remember if PJ64 has a the ability to dump the RDRAM contents when you pause the game. I know one of the PS1 game video plugins allowed you to snapshot the video memory (which was good for figuring out what a game was doing when loading texture data).

The only way I can think of making a patch to "see what happens" is to debug the game in real time and find where the 8M dram check is. Not sure if that is useful since you would then likely need to find where the original bug was and figure out how to fix it.

Cyb - another thing that makes you go HMMM.

 

[Fanatic 64]

I can't remember if PJ64 has a the ability to dump the RDRAM contents when you pause the game.

Pause, then Debugger/Memory/Dump.

 

[PsyMan]

I was just saying that replicating what causes games with many bugs work on a real console can be a pain. That's all.

It's not uncommon for stuff to work by accident on the real system. If you're not accurate up to a ridiculous degree (or make game-specific hacks) you can't make some of those problematic cases work... unfortunately.