I'm a big fan of ModRetro's Chromatic. It played really well relative to software emulators I'd used and I didn't bother to learn why. They're taking orders for the M64, an N64 cartridge compatible console that uses a similar build philosophy, in a few days. This blog is about the build philosophy. FPGAs are the reason their consoles feel more true than emulators.

Emulation has relative deterministic behavior in the end and this can of course be done in software. In fact, every digital FPGA behavior can be simulated in software just fine. This is done during emulator development all the time.

Why even bother with FPGAs then?

Well, the more you want to emulate the parallel behavior of chips or functionalities inside a chip, the tighter the timing requirements are. The N64 does hundreds of things in parallel each clock cycle and to fully replicate that in software with full accuracy would mean to execute them all and sync up the different modules after each clock cycle.

This leads to the issue that even for an experience to fully and accurately emulate the N64, you would need a PC with a CPU that is so fast it doesn't even exist today. Because of that, software emulators have to optimize and sometimes cut corners of functionality or timing that is probably not important to the game. This is often required to keep playable execution speeds on common hardware. Ares is a popular and extremely accurate N64 software emulator, but even it has to resort to some clever tricks to get it close.

FPGAs on the other hand have the possibility to do all these things with true parallelism, like the original hardware did. They open up the possibility to even reach the "perfect" accuracy we all eagerly seek, assuming there's enough margin to perform all of the calculations and any constraints associated with it.

One example of accuracy mattering (which I learned from the blog) is that games often keep time by counting frames and by using clock time. While clock time is for most purpose accurate and reproducible on any hardware, frame rate is not.

In the intro sequence of Donkey Kong 64, there is a section that requires a specific timing for the events to happen. Donkey Kong will climb up a hill and then do some jumps over to another platform using three vines. With the timing of the N64, he will always jump and grab the vine successfully, reaching the other platform. If an emulator's timing is "wrong", DK will miss the vine and land in the water, as the jump is done at a position where there is no vine.

Now why is that even the case?

This sequence in the intro, like many other in-game sequences in plenty of games, is programmed via frame counting. Specific actions like turning around or jumping are done after a certain number of frames. The game's speed, however, is determined by time.

Anyway, there's lots of cool bits in there about memory choices and matching other quirks on N64's design using FPGAs.