Pros and cons of cycle accurate N64 emulation

[mrmudlord]

1) BS: Only Sandy Bridge and higher can run the "accuracy" profile of BSNES properly.
2) I have every right to complain. Its my choice to complain: like it or not. Don't like what I say, **** off.
3) byuu's article is biased. Not every emulator developer CARES about accuracy. They ALL have thier OWN ethics on that they consider to be important in a emulator. What byuu is doing IS PREACHING.

Until byuu understands that people can code crap thier own way.............................................................

 

[dsx]

What do you mean by properly? My computer runs the accuracy profile fine (Lynnfield i7 860)

 

[mrmudlord]

Oh yes, overclocked i7.

Not exactly a weak CPU.

 

[dsx]

I thought sandy bridge would still be faster.

 

[MarathonMan]

Oh yes, overclocked i7.

Not exactly a weak CPU.

If you have the extra power, why not use it for something?

That being said, I'm currently able to simulate a basic pipeline at full speed. Granted, only a handful of instructions are simulated at the present time, but as most of the architecture is in place... I don't see things slowing down a whole lot. And that's all happening on a first-generation C2D!

 

[mrmudlord]

Nice work! I take you took care to optimize?

 

[MarathonMan]

Nice work! I take you took care to optimize?

Yes, absolutely. And there's a small chance things will get a lot faster if I can thread the code.

I currently have it setup so that each pipeline stage can run simultaneously (no race conditions or dependencies), with a very minimal amount of non-stage specific specific code (pipeline fault handlers, latch propagation, etc.). However, I haven't figured out a portable/clever way to synchronize the threads at every stage. If I can somehow figure out how to make that work, it'll really take off. However, outside of removing race conditions and leaving a multi-threaded pipeline open for possibility in the future, I don't intend to attempt to implement something like that until more functionality is in the pipeline.

 

[Rodimus Primal]

I've been using BSNES v073 since it still has the easier to use GUI and it plays every game I play just fine. I haven't bothered updating to the current version since I have no interest in merging emulators into one. I HATED manually going through all of my roms and putting them in folders since his system didn't at the time make folders for you. That was painstaking! But the reward was a very good working emulator that hasn't given me any issues since I moved from SNES9x and ZSNES.

For the N64 scene, I've tried them all. Currently I use Project 64 1.6 with Jabo's patch that resolved issues 1.7 was going to solve. I paid for the 1.7 beta and the settings where fantastic such as plugin settings PER rom but it was the most buggy emulator I've ever tried. All I ever got when I posted on their forums was SFTU and GTFO and to me that showed the project was dead.

Recently I popped Mario 64 and Zelda OoT into my N64 console which is plugged in with S-Video cables into my HDTV. The resolution is HORRID. It's virtually unplayable since the games were made to run on a CRT TV. This to me was IMO the BIGGEST reason why a better N64 emulator is needed. There are games I still want to go back and play and without emulation I would be in the dark unless I shell out money to download Wii Virtual Conole games for stuff I already own.

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. Maybe its the recent idea of a cycle accurate emulator that has spurred this resurgance but I absolutley think this necessary to move this console into as near perfect as possible emulation.

 

[mrmudlord]

I currently have it setup so that each pipeline stage can run simultaneously (no race conditions or dependencies), with a very minimal amount of non-stage specific specific code (pipeline fault handlers, latch propagation, etc.). However, I haven't figured out a portable/clever way to synchronize the threads at every stage. If I can somehow figure out how to make that work, it'll really take off. However, outside of removing race conditions and leaving a multi-threaded pipeline open for possibility in the future, I don't intend to attempt to implement something like that until more functionality is in the pipeline.

Ah yess, the exact same issues byuu is having and MG was having with N64 emulation in MESS, sync between CPUs and a fast enough method to do so..From what I know, increasing CPU/RSP sync was decimating speed in MESS....even on i7's, making it unplayable in cases. So, I am extremely skeptical pure cycle accuracy is even possible in today's age.

 

[MarathonMan]

Ah yess, the exact same issues byuu is having and MG was having with N64 emulation in MESS, sync between CPUs and a fast enough method to do so..From what I know, increasing CPU/RSP sync was decimating speed in MESS....even on i7's, making it unplayable in cases. So, I am extremely skeptical pure cycle accuracy is even possible in today's age.

I just simulated it. Even unlocking/locking a simple spinlock in a while (1) loop 93.75mil times takes a good 0.7sec on my 2GHz C2Q. So it's almost certainly not a viable option. :down:

 

[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.