x86/x64 emulating the N64's CPU

[Anarchist420]

Guestimate the max percentage accuracy of emulation that's possible using the features of a SB CPU for me. If 100% accuracy is not possible, then tell me why the Sandy Bridge architecture couldn't emulate an N64's CPU with 100% accuracy.

I was hoping that someday there would be an N64 emulator that was completely software-based and 99% or more accurate with every microcode and the expansion pak.

 

[Revolution 11]

Well, according to this excellent article by ArsTechnica and the developer of bsnes, a truely accurate emulator for the Super Ninetendo would take a 3 GHz processor by itself. The N64 is considerably more advanced and thus harder to emulate accurately.

Accuracy vs. speed is the main tradeoff with emulators. For more technical reasons, read the article.

Probably only a N64 emulator core developer could guess the accuracy of emulation. Architecture, I think, has nothing to do with accuracy but rather the speed of emulation. Accuracy is determined by the emulation code itself.


http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/

 

[Ferzerp]

100% accuracy is always possible, the question is can you do it fast enough to run full speed.

 

[tynopik]

Architecture, I think, has nothing to do with accuracy but rather the speed of emulation. Accuracy is determined by the emulation code itself.

Correct, except to the extent that certain hardware features make accuracy EASIER to implement

But you could accurately emulate an XBox 360 on an 8-bit microprocessor.

It might take a year or two to render a single frame, but you could do it

 

[Revolution 11]

Correct, except to the extent that certain hardware features make accuracy EASIER to implement

But you could accurately emulate an XBox 360 on an 8-bit microprocessor.

It might take a year or two to render a single frame, but you could do it

Which is why I stated that architecture (hardware features) helps with emulation speed, not accuracy. Accuracy is a goal determined by the developer, hopefully before the coding actually starts.

Accuracy probably does depend on access to the source code of the platform that is being emulated. If the developer does not know how the code works, it would be hard to emulate it.

 

[Anarchist420]

But you could accurately emulate an XBox 360 on an 8-bit microprocessor.

How could an 8 bit microprocessor have enough data precision?
Thanks to you and everyone else who for replying

 

[cytg111]

How could an 8 bit microprocessor have enough data precision?
Thanks to you and everyone else who for replying

an 8 bit processor can have infinite data precision given infinite storage and time.

 

[ericloewe]

an 8 bit processor can have infinite data precision given infinite storage and time.

Next thing you know, someone will actually implement x86 on a Turing machine...

Seriously though, the N64 is a particularly difficult console to emulate for a few reasons:

• It's way more complex than anything before it (as in, previous generation)
• If you were to emulate the hardware exactly instead of just interpreting the software, you'd have a slow-as-hell emulator. The only realistic way to render the graphics is by using a GPU. DirectX/OpenGL are pretty different from the Silicon Graphics chip used. What is usually done is that instead of emulating the GPU, you interpret the stuff that has to be drawn and use DirectX/OpenGL commands to draw it.
  First example that comes to mind - the SGI chip had a somewhat different clipping algorithm than DirectX, which leads to textures that should still be visible in-game not being drawn.
• The GPU needed microcode. Two basic versions produced by SGI (one extra-accurate and painfully slow, one fast but painfully inaccurate) were used by most developers, however, the good ones (essentially Rare and Factor 5) developed their own microcode, optimized for their games. That's painfully hard to emulate (must be as bad as writing it was) - the microcode tools were very poorly documented, had no debugger and were generally crap. Good luck finding the chip's design team or reverse-engineering it.
• This is mostly a non-issue if you keep the whole game image in RAM, but many games depend on extra-fast load times to load textures quickly into RAM. A number of tricks to get around the 4KB texture limit were also related to the way memory was managed

That's what comes to mind at first. So my guesstimate is that true accuracy is impossible at the moment, at least for all games. It may be possible to do it with those that use the normal microcode.

As for speed, we may be at a point where common desktop processors can do the rendering and game logic without help from a GPU, but I wouldn't expect 60fps. Something like 10-30 fps.

 

[cytg111]

"Next thing you know, someone will actually implement x86 on a Turing machine..."
- Hehe, but basicly that is the gist of this thing is it not?

The story you're telling is that given the complexity of the target to be emulated 'accurately', you would problary need close to infinite this and that.. EVEN with current many-core-uber-ghz-very-ipc mainstream chips, you're not close.

 

[Fox5]

I don't see why the n64 couldn't be emulated accurately, at least for the cpu portion. Integer ops are integer ops. Heck, the gpu wasn't particularly powerful, you could probably brute force graphics on a modern multicore cpu at this point, so long as you used JIT recompilation.

 

[Revolution 11]

I don't see why the n64 couldn't be emulated accurately, at least for the cpu portion. Integer ops are integer ops. Heck, the gpu wasn't particularly powerful, you could probably brute force graphics on a modern multicore cpu at this point, so long as you used JIT recompilation.

Read the article. Accurate emulation is much more demanding than that. There's not a CPU out there that can emulate the N64 hardware completely in software. Even bsnes, a emulator for a older console, requires recent CPUs for (almost) complete emulation.

 

[SonicIce]

you can emulate the actual integrated circuit and individual transistors of the original hardware for perfect emulation. but at this level of accuracy you cannot play even Pong at full speed on our current fastest CPU's. as far as N64, it may not be in our lifetimes

http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/

great article

 

[Cerb]

How could an 8 bit microprocessor have enough data precision?
Thanks to you and everyone else who for replying

The same way you can calculate to an arbitrary precision number a single base-10 digit at a time...just at no greater than base-256 per digit, instead of base-18,446,744,073,709,551,616.

 

[Puppies04]

Well, according to this excellent article by ArsTechnica and the developer of bsnes, a truely accurate emulator for the Super Ninetendo would take a 3 GHz processor by itself. The N64 is considerably more advanced and thus harder to emulate accurately.

Accuracy vs. speed is the main tradeoff with emulators. For more technical reasons, read the article.

Probably only a N64 emulator core developer could guess the accuracy of emulation. Architecture, I think, has nothing to do with accuracy but rather the speed of emulation. Accuracy is determined by the emulation code itself.


http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/

Interesting read, thanks.

 

[lamedude]

No problems here getting full speed on Mario64 using the CPU interpreter on a i930. Don't think any N64 games need more accuracy than that from the CPU. Using LLE video on top of that brought me down almost full speed but that still has some issues with some games. I guess software rendering is needed for good enough accuracy. PCSX2's software renderer is actually usable so the speed is there.

 

[Revolution 11]

Good enough accuracy is the desired goal for emulators but it is not the same as perfect accuracy, which can not be accomplished with modern consumer-grade CPUs for N64.

I follow project64 and Dolphin irregularly and I have noticed that both emulators have increased their hardware requirements over time as CPUs have improved (as they should). Instead of strictly improving speed, they are focusing on better accuracy as there are still serious bugs that come with speed hacks. Well, at least for Dolphin.

 

[kernelc]

Next thing you know, someone will actually implement x86 on a Turing machine...

Seriously though, the N64 is a particularly difficult console to emulate for a few reasons:

• It's way more complex than anything before it (as in, previous generation)
• If you were to emulate the hardware exactly instead of just interpreting the software, you'd have a slow-as-hell emulator. The only realistic way to render the graphics is by using a GPU. DirectX/OpenGL are pretty different from the Silicon Graphics chip used. What is usually done is that instead of emulating the GPU, you interpret the stuff that has to be drawn and use DirectX/OpenGL commands to draw it.
  First example that comes to mind - the SGI chip had a somewhat different clipping algorithm than DirectX, which leads to textures that should still be visible in-game not being drawn.
• The GPU needed microcode. Two basic versions produced by SGI (one extra-accurate and painfully slow, one fast but painfully inaccurate) were used by most developers, however, the good ones (essentially Rare and Factor 5) developed their own microcode, optimized for their games. That's painfully hard to emulate (must be as bad as writing it was) - the microcode tools were very poorly documented, had no debugger and were generally crap. Good luck finding the chip's design team or reverse-engineering it.
• This is mostly a non-issue if you keep the whole game image in RAM, but many games depend on extra-fast load times to load textures quickly into RAM. A number of tricks to get around the 4KB texture limit were also related to the way memory was managed

That's what comes to mind at first. So my guesstimate is that true accuracy is impossible at the moment, at least for all games. It may be possible to do it with those that use the normal microcode.

As for speed, we may be at a point where common desktop processors can do the rendering and game logic without help from a GPU, but I wouldn't expect 60fps. Something like 10-30 fps.

Good points. Moreover, emulating the quirks and errata of the various hardware is exceptionally difficult... but, without these errors, some games will not run properly!

Regards.

 

[Anarchist420]

No problems here getting full speed on Mario64 using the CPU interpreter on a i930. Don't think any N64 games need more accuracy than that from the CPU. Using LLE video on top of that brought me down almost full speed but that still has some issues with some games. I guess software rendering is needed for good enough accuracy. PCSX2's software renderer is actually usable so the speed is there.

Much more accuracy is needed than what any N64 emulator currently provides, at least for a lot of games.

I follow project64 and Dolphin irregularly and I have noticed that both emulators have increased their hardware requirements over time as CPUs have improved (as they should). Instead of strictly improving speed, they are focusing on better accuracy as there are still serious bugs that come with speed hacks. Well, at least for Dolphin.

Yes, Dolphin is a pretty damn good emulator although I'm wondering if Rogue Squadron II and III can only be run accurately via software. As for Proj 64, it hasn't been updated in over a year.

I'm guessing the shaders of a GPU could be used and with the workload split between those and the CPU, but using ROPs to emulate the N64's blending just doesn't give enough accuracy.

 

[kernelc]

I'm guessing the shaders of a GPU could be used and with the workload split between those and the CPU, but using ROPs to emulate the N64's blending just doesn't give enough accuracy.

Hi,
I think it is quite difficult to split work between a CPU and GPU and the resynchronize all with the level of accuracy needed by a good emulator. :|

What about ROPs? In OpenGL at last, they can be used with quite different operands (add / multiply / ecc). N64 blending was so special?

Thanks.

 

[Revolution 11]

The unfortunate truth of all emulators is that 100% hardware accuracy is (almost) impossible, which is why it's called a "emulator" instead of something like a "replicator".

GPUs have limited functions for emulation code. Most of the workload is restricted to the CPU. I am hoping that AVX2 will be adopted by Dolphin if possible since current builds only use SSE2.

Project64 is being worked on but slowly. The developers are ready to cease work after the 1.7 update, the current version is 1.6. ZSNES is also in hiatus but Snes9x and bsnes are still going. The more emulators, the merrier, I say.

 

[KingFatty]

Just build the N64 emulator in Minecraft, run Minecraft on your PC, overclock your PC, done!

 

[ericloewe]

Just build the N64 emulator in Minecraft, run Minecraft on your PC, overclock your PC, done!

Minecraft's the new Universal Turing Machine.

I didn't know Rogue Squadron II and III were difficult to emulate, but the original is notorious for the programming tricks it uses.
Custom microcode, unusual memory tricks, on the fly texture loading from the cartridge, custom audio compression...

 

[Cerb]

Hi,
I think it is quite difficult to split work between a CPU and GPU and the resynchronize all with the level of accuracy needed by a good emulator. :|

What about ROPs? In OpenGL at last, they can be used with quite different operands (add / multiply / ecc). N64 blending was so special?

Thanks.

I don't think the blending itself was special, as far as inputs v. outputs, as much as it is that the graphics processor was an 8-bit MIPS DSP with special firmware, and the firmware was often called directly, probably with known-safe race conditions and other nasties you'd never want outside of a game console. Some very late games even altered the firmware.

You might be able to pull the same thing off with an extra buffer or two and pixel shaders, but creating a program than can properly reverse-engineering that from an optimized game binary that just uses two CPUs is not likely feasible.

 

[kernelc]

I don't think the blending itself was special, as far as inputs v. outputs, as much as it is that the graphics processor was an 8-bit MIPS DSP with special firmware, and the firmware was often called directly, probably with known-safe race conditions and other nasties you'd never want outside of a game console. Some very late games even altered the firmware.

You might be able to pull the same thing off with an extra buffer or two and pixel shaders, but creating a program than can properly reverse-engineering that from an optimized game binary that just uses two CPUs is not likely feasible.

Oh yes, I understand.

Thank you for clarifications.

 

[slayernine]

I'm just happy my dual core android tablet can play N64 relatively well as well as PS1 games.