Pros and cons of cycle accurate N64 emulation

[Toasty]

Todays computers are much more powerful so I don't see WHY we cannot see a N64 emulator that isn't buggy and riddled with issues to play games that will NEVER see release outside of the N64 console. I may not be an author, but I sure see PS2 and Gamecube/Wii emulators that are leagues ahead of N64 emulation.

I don't have extensive knowledge about the N64's software and hardware, so take this with a few pounds of salt. In many ways, the N64 is the worst of both worlds for emulator developers. Newer consoles are more powerful and hence require more processing power to emulate at reasonable speeds. Older consoles are much slower, but because of this, game developers had to exploit every single idiosyncrasy of the hardware to get the most out of it -- even hardware glitches that would never be encountered or anticipated under 'normal' programming practices. The N64 falls within the overlap of these two. It's old enough that game developers still used a lot of hackish tricks to achieve their ends, but it's new enough that imitating those corner cases accurately and at the speed that the original console could is very complicated and processor-intensive. (Hence this discussion on the pros and cons of cycle-accurate N64 emulation.) In some ways, newer consoles are actually easier to emulate, not necessarily because the underlying hardware is simpler, but because its usage is simpler.

[zoinkity]

I'd say it's more because of the undocumented dedicated video and audio processor they shoved in it.

Most of the issue is the 60vi/s target of emulation. People want to be able to play their games at full speed or above. The issue is that signal processors can't be emulated at their usual speed without seriously overshooting the specs. They're designed for speed. It's what they do. Compound that with emulating an overly complex video card that uses a different base concept than your typical PC card. Low level emulation on PC couldn't keep up with N64. They cut corners, and now it's time to do the opposite.

[dsx]

virtually unplayable

aw its not that bad

[Fanatic 64]

I've even seeing games that actually use lag to keep correct timing. Best example I can think of is The Legend of Zelda: Ocarina of Time credits. Just watch these videos:

TLoZ: OoT credits on the real Nintendo 64:


TLoZ: OoT credits on Project64 1.6:


Skip to 5:20.
In the real N64, you'll see the video runs at 8 FPS, trough audio goes at full speed.
In PJ64 1.6, the video runs at full 20 FPS... and the audio also goes at full speed.
By the end, you'll see the music is severely delayed from the video (and it's even cropped at the end), that's because the video goes way too fast (developers expected the console to slow down so audio can fully fit the credits scene). And even if you get PJ64 to slowdown to the correct speed, it also forces audio to slowdown to "keep sync".

Superman: The New Adventures also has similar issues (trough mostly related to video).

[MarathonMan]

I've even seeing games that actually use lag to keep correct timing. Best example I can think of is The Legend of Zelda: Ocarina of Time credits. Just watch these videos:

TLoZ: OoT credits on the real Nintendo 64:


TLoZ: OoT credits on Project64 1.6:


Skip to 5:20.
In the real N64, you'll see the video runs at 8 FPS, trough audio goes at full speed.
In PJ64 1.6, the video runs at full 20 FPS... and the audio also goes at full speed.
By the end, you'll see the music is severely delayed from the video (and it's even cropped at the end), that's because the video goes way too fast (developers expected the console to slow down so audio can fully fit the credits scene). And even if you get PJ64 to slowdown to the correct speed, it also forces audio to slowdown to "keep sync".

Superman: The New Adventures also has similar issues (trough mostly related to video).

Thank you for this. Another great piece of evidence why cycle-accurate simulation is needed.

[squall_leonhart]

I've even seeing games that actually use lag to keep correct timing. Best example I can think of is The Legend of Zelda: Ocarina of Time credits. Just watch these videos:

TLoZ: OoT credits on the real Nintendo 64:


TLoZ: OoT credits on Project64 1.6:


Skip to 5:20.
In the real N64, you'll see the video runs at 8 FPS, trough audio goes at full speed.
In PJ64 1.6, the video runs at full 20 FPS... and the audio also goes at full speed.
By the end, you'll see the music is severely delayed from the video (and it's even cropped at the end), that's because the video goes way too fast (developers expected the console to slow down so audio can fully fit the credits scene). And even if you get PJ64 to slowdown to the correct speed, it also forces audio to slowdown to "keep sync".

Superman: The New Adventures also has similar issues (trough mostly related to video).

erm, Zelda64 happens to be the poster child for SPU synchronisation, which btw, pj64 doesn't perform by default (notice the hyrule field bgm popping)

SPU synced, the video and audio end at the same point as the console.

the most obvious reason i can see, for the synchronisation defaulting to off, is the frame delay it adds is more excruciatingly obvious on a pc than it is on the console.

As deathdroid and Iconoclast (if he was unbanned) could tell you, the Playback rate on the n64 can change momentarily thus affecting the entire speed of the console, hence the reason why the frame rate suddenly drops while music remains at the correct rate on the console.

Iconoclast says (12:10 PM): *actually the DAC rate is calculated before the frequency, so a PAL game requesting 32 kHz would use an approximate DAC rate of 1551. but it could still be a different DAC rate than that even for PAL if the resulting requested frequency is different
Iconoclast says (12:11 PM): *and originally I used High School algebra to solve for the "correct" video clock numerator to divide by (DAC_rate + 1) to return 32,000 Hertz, but this only worked for games requesting just that frequency
Iconoclast says (12:12 PM): *in fact some of Nintendo's documentation suggests through the use of a function, that the game developer requests the "requested frequency" while the function returns the "actual frequency", so there is a chance that offbeat freqs like 32006 and 31995 might be correct in that context
Iconoclast says (12:14 PM): *currently, as an experiment just in case the correct behavior is to never have weird frequencies like that, I define a modulo base of fifty for rounding to the nearest frequency *from what I've seen, 50 is the greatest common factor of every requested Nintendo frequency I've seen written down, such as the min. and max. frequency limits Nintendo documented
Iconoclast says (12:15 PM): *there is another formula to calculate the frequency based on the audio bus half-period register, but it doesn't seem to be updated nearly enough as much as Nintendo says...the register is usually set to either 0 or 15, for a bitrate of 1 or 16 b/sample

[Zuzma]

I recall games on a real N64 had a lot of slow downs in game like perfect dark or golden eye. Do most of them happen in the correct spots in an HLE N64 emulator? I couldn't imagine them working properly if you're ignoring emulating an entire chip on the system even if it was synced properly to the audio / video. As I understand it HLE emulation just intercepts commands that are supposed to be sent to said processor (display / audio lists) then just turns it directly into something your PC understands with out any regards for chip / bus timing.

Please correct me if I'm wrong because I'm honestly just bsing this.

Edit: Nevermind, I was mixing up low level with cycle accuracy. I at least know there's very little people would actually notice in a cycle accurate emulator if all they're doing is playing games. I'm still happy people are working on accurate emulators though since it'll help out the faster HLE ones. It'd be nice to see a small number of graphical bugs fixed and a hand full of games that don't work at all working properly.

[zoinkity]

As another interesting note, the second word in a ROM contains an oft-unused override for the default clock rate. On occation you get a retail cart that intentionally slows down the rate, but it's admittantly rare.

Not sure how accurately 'low power mode' is emulated, but it should affect performance significantly. Not that you'd ever be playing a game like that, but you get the point.

One aspect of cycle-accurate emulation is emulating the delay for a DMA transfer. If you wanted to be a jerk and 'detect' emulators, one tricky way to do it would be to anticipate them using instantaneous DMA transfers. For instance, when the bootstrap loads ROM for the CRC check, check the cycle count before and after, using a loop to test for the flag set when the transfer is complete. The lower the difference in cycle count the more likely it's an emulator.

[Fanatic 64]

One aspect of cycle-accurate emulation is emulating the delay for a DMA transfer. If you wanted to be a jerk and 'detect' emulators, one tricky way to do it would be to anticipate them using instantaneous DMA transfers. For instance, when the bootstrap loads ROM for the CRC check, check the cycle count before and after, using a loop to test for the flag set when the transfer is complete. The lower the difference in cycle count the more likely it's an emulator.

Marshall/Retroactive actually does block emulators. Not sure which method he uses trough.