Forums  /  Who Framed Roger Rabbit? (NES)  /  Emulation Problems

During my research for this game I learned quite a bit about the state of NES Emulation in 2017, particularly the problems related to this game.

The initial observation was that no emulator with a TAS editor was able to sync with the outcomes of original hardware. I first thought that this had to do with the Initial RAM State either a pattern of 00 or FF which is default in Bizhawk, or alternating 00 and FF every four addresses which is default in FCEUX. When I changed the Initial RAM State in these emulators they would produce the same outcomes no matter what. So the Initial RAM State was not a factor in differing outcomes since the game initializes the memory. In fact it initializes so well that I have observed that whether you use an Everdrive, Powerpak, original cart, top loader, or front loader all of these were in sync with one another and the same input manipulation could be used to achieve a desired outcome. Unlike emulators which would not even sync with one another. Therefore using Bizhawk(quicknes), Bizhawk(NesHawk), FCUEX(Old PPU), and FCEUX(New PPU) would each yield different results one from the others.

The main difference in outcomes between Bizhawk and FCEUX is due too: "BizHawk and FCEUX set the RNG on different frames because FCEUX (erroneously) delays PPU startup by an extra frame." - Alyosha

This has been true for this game, in Bizhawk the first frame where I see PRNG populate in addresses $12-$14 is on frame 15, while it is frame 16 in FCEUX.

RNG in Who Framed Roger Rabbit changes every frame, and different inputs change it as well. Every input/input combination effects it differently. Buffered inputs on the title screen such as holding down from before power on/reset, continue to hold this input, press and hold start when you are able on the title screen, and continue to hold these two inputs until you see the X3 Lives screen, since the address for where the items will be located populate with values during the previous screen transition.

In the game code there is a block of code that cycles maybe 40 times per second, it is in an infinite loop until an NMi interrupts it.

Read more about non-maskable interrupt (NMI) here:

"This just runs being called over and over in an infinite loop until an NMI interrupts it and eventually manipulates the stack to get it out of that infinite loop. This is setting up the 24-bit PRNG seed. It maybe runs 40 times per frame... this random seed loop is broken only by the NMI, so this will require precise PPU emulation to get correct. If it's even one cycle different, the PRNG seed could be changed." "Even one cycle difference in the specific timing of the NMI can also alter the seed. That last one in particular is one that emulators might easily behave differently on, especially reset/warmup behaviour of the PPU. It's also possible that on hardware the variability of PPU alignment might mean you only have a 1 in 4 chance of getting a consistent alignment on reset/power-up too, even if you could get that frame-perfect START every time."

- Rainwarrior

More about PPU Alignment here:

As a result even when frame perfect inputs are used to manipulate the RNG, there are still other factors that influence it that require multiple attempts with frame perfect inputs in order to eventually see the desired outcomes.

Emulators, unfortunately only produce one outcome per frame, meaning if you did a one frame start input on frame 534 in FCUEX, you would always see the exact same item values, while on original hardware there is a greater variability which may yield four different outcomes even when frame perfect inputs are used.

In general the state of NES Emulation is not yet accurate enough in order to run this game in a way that syncs with original hardware

1) The most accurate emulators at this time, in 2017, do not mimik the PPU Alignment variability of original hardware.

2) The game is not ran properly as a result of this difference, especially influences upon RNG.

3) Input manipulation would be more effective on Emulators since it yields only one outcome per frame, instead of four.

4) Therefore, Emulators offer an unfair advantage in terms of RNG manipulation.

As a consequence, at this time it is highly advisable to only allow gaming performances for this title which were done on original hardware.

Conclusion: While it would have been nice to be able to thoroughly and meticulously examine input variations in a concise and expedient manner with an emulator and TAS editor, at this time there only exists a rom hack of the game that will show outcomes on original hardware. While you will be able to sit and do the same input manipulation over and over for 15-20 min watching outcomes, you will only know what frame it is if you do a direct feed and de-interlace to 60 fps, this will assist in establishing a good visual/timing cue.

catsonurheadcatsonurhead, stormcrow56kstormcrow56k and Toad22484Toad22484 like this. 

I'd like to run this game but I only have an emulator available to me. I understand the distinction between emulator and console in terms of RNG manipulation. Would it be possible to get an "Emulator any%" or something equivalent so I, and potentially others, could participate?


That sounds reasonable to me. Now that non-emulator can be mapped out (even if it's a bit painful,) I'm not sure if there's still a reason to disallow emulator. I'll let Chambers decide that, though. 🙂

If you submit an any% on emulator we'll decide then if it should be it's own category / subcategory or what, it won't be removed.


The Any% Emulator track has been created. Please read and follow the rules precisely.


Correct. It really constitutes its own version since how the game runs is vastly different. Similar to how NES does it but does not involve PPU/CPU alignment variability. Its really unfortunate.