Pros and cons of cycle accurate N64 emulation

[mrmudlord]

Since Hacktarux got (explicative removed) with me intruding in his thread, why not here?

Pros:
* Documentation.
* Very high accuracy.
* Homebrew friendly.
Cons:
* Very slow to the point of unusability.
* Excessively high system requirements.

So far, going the bsnes way seems good, don't you (explicative removed) agree?

 

[DETOMINE]

Pros :
-In ten years (ok, maybe 20), being able to emulate every games...

 

[mrmudlord]

How the hell is waiting 20 years a pro?

 

[DETOMINE]

Pffff, why won't you understand that's not only about you or about playing now.
Your children will be able to, and that's a pro.

 

[mrmudlord]

You must be one of those "software preservation" nuts I have been hearing about. Which came into existance as soon as bsnes came mainstream.

The ones that think all hardware must be documented as musuem pieces. Well I tell you, I don't care about your precious consoles. I care about the software engineering challenge. Not for the brainless idiots who like software running at 0.001 FPS just so they can tout that they adore history. Not everyone cares.

Some people find happiness when things run. Who cares how they do it, its thier choice, not one common cabal's. Unlike what those losers at byuu.org think.

 

[DETOMINE]

You must be one of those people who can't sleep knowing that "someone is wrong on the internet".

As I say, I don't care about the console, I care about the games. Hardware can go to a museum or to hell for all I care, but being able to keep playing awesome (old) games way after the end of the supporting hardware is a good thing, not matter how you look at it.
Of course, if the code source of the good old games was available, it may be different.

 

[mrmudlord]

You can do that to some extent with MESS...so, the point being?

 

[DETOMINE]

As far as I know, the N64 implementation in MESS is far from complete...
And I don't know if it exploitable or not, if it is the best way (or at last a good way) of doing it...

And I believe MESS/MAME is crazy close to the hardware, while you can (maybe?) do a perfectly accurate emulator in a different way (don't ask me, I don't really know).
And what if you simply prefer to code in C++ while MESS is in C (example, I don't know the truth)?

Don't get me wrong, I prefer when there isn't many projects doing the same things, but sometimes it's for the best.

 

[dsx]

Perhaps cycle-accurate is a bit extreme, but sometimes it feels that there's an "it's good enough" attitude when it comes to Nintendo 64 emulators and plugins, and bugs and compatibility issues are ignored and left to rot. Not that I'm accusing anyone of having that attitude though, and it would make sense if it's due to the lack of documentation on the hardware or something like that.

 

[Clements]

In my opinion, it is worth having a cycle accurate emulator or two per system. The inevitable research that comes from creating them, such as weird edge cases that only affect a couple of games, filters into the more optimised emulators that most people will actually use. I don't use bsnes personally as I find it to be too slow, power hungry, and lacking in useful features for casual use, but I do follow its development with interest. I've seen how certain findings from bsnes have filtered into Snes9x.

Cycle accuracy does have great benefits, but does that mean we should dump our current emulators on our hard drives for totally cycle accurate ones? Should all current emu devs all move to cycle accuracy alone? I think not. I think more and more people are running emulators on netbooks, tablets and consoles etc., so portability and optimisation is important as well. But without the research that comes from 'accurate' emulators, these faster optimised emulators will have lower compatibility since updating them becomes prohibitively difficult and time consuming.

The Snes was pretty accurately emulated before byuu started his emulator, so the overall gains from his research seem pretty niche to the casual observer. However, current N64 emulation is still riddled with often game breaking bugs and has game specific hacks for pretty much everything akin to uosnes. Even the more popular titles, like Donkey Kong 64 and Banjo-Tooie have game-breaking core issues. As a fan of the system who has played about 40 of the most popular games on the real hardware, I can say with conviction that the current emulation is currently not there (even if you have all of the current best plugins and emulators, which I do have). z64 made good progress to alleviate some of the issues, but it can't solve all the problems inherent to the emulators that are currently doing the rounds.

So, research from creating a cycle accurate emulator with an excellent debugger would mean more research for the faster emulators (which are now all open source, so the means is there). Then we can all run more accurate fast emulators on our netbooks and tablets and not worry about battery life.

 

[Hacktarux]

Mame / Mess cpu emulation is far less accurate than the core i am currently writing, so it is not really the same thing rewritten another way. The point is really from which end would you like to start and which direction would you like to take for your improvements. As far as i can see, progress has been really slow during last years. My own mupen64 implementation was hard to improve: plugin api is very nice for flexibility but come with its own limitation, all kind of tricks were used to improve speed: it was not necessarily hacks or things that arm accuracy but their complexity made them hard to change. At some point i still wanted to improve emulation but had to restart from scratch something new and clean. Moreover, everyone know that i have already written another faster hle emulator, so it is really not a matter of knowing how to do it but a matter of preferences and strategy.

 

[mrmudlord]

Mame / Mess cpu emulation is far less accurate than the core i am currently writing

Have you bothered to check it lately? Angrylion made some rather significant RDP emulation improvements. And the core is miles better than what is there before in the past.

My own mupen64 implementation was hard to improve: plugin api is very nice for flexibility but come with its own limitation, all kind of tricks were used to improve speed: it was not necessarily hacks or things that arm accuracy but their complexity made them hard to change.

Solution? Don't use plugins. Code your own implementations.

Moreover, everyone know that i have already written another faster hle emulator, so it is really not a matter of knowing how to do it but a matter of preferences and strategy.

And you think cycle accuracy is the magical solution to all the world's problems? Just how (expletive removed) naive are you? Just as much as byuu?

Yes, accuracy is nice, but it doesn't have to be taken to (expletive removed) extremes because one OCD freak decided to make a SNES emulator (expletive removed), so you do so to get the same attention and love from everyone.

(Expletive removed.)

nesplayerforlife: dont you *dare* censor me. Ever.

 

[Fanatic 64]

Based on what I've read, basically you (Mudlord) want Hacktarux to stop developing his emulator. The thing is, if you disagree with what Hacktarux is doing, then simply leave it aside; you can't force him to quit his work.

mudlord: dont you *dare* insult me. Ever.

 

[Toasty]

@Mudlord: Please check your PMs before posting again.

All posts henceforth in this thread will be contain only objective remarks about the pros and cons of cycle-accurate N64 emulation, or this thread will be closed.

 

[mrmudlord]

Based on what I've read, basically you (Mudlord) want Hacktarux to stop developing his emulator. The thing is, if you disagree with what Hacktarux is doing, then simply leave it aside; you can't force him to quit his work.

No, I just feel its a complete waste of time, when the MESS people are doing *exactly* the same thing. Hacktarux could easily help MooglyGuy, Angrylion and co, but no, they had to start from scratch when the MESS people have exactly the same goal.

Sounds very inefficient to me. And doing cycle accurate emulation inefficiently is insulting. You can have your cake and eat it, just takes brains. Just look at Nestopia, blargg's works, Sinamas's emulator, Beware's GB/GBC emulator, Xeron's Oric emulator, etc. They are examples of cycle accurate emulation done *right*.

I have no objection to cycle accuracy, BUT when I see cycle accuracy being used as a excuse for anything else to be discredited? Thats just insulting to everyone who did work before.

 

[Hacktarux]

Have you bothered to check it lately? Angrylion made some rather significant RDP emulation improvements. And the core is miles better than what is there before in the past.



Solution? Don't use plugins. Code your own implementations.



And you think cycle accuracy is the magical solution to all the world's problems? Just how (expletive removed) naive are you? Just as much as byuu?

Yes, accuracy is nice, but it doesn't have to be taken to (expletive removed) extremes because one OCD freak decided to make a SNES emulator (expletive removed), so you do so to get the same attention and love from everyone.

(Expletive removed.)

nesplayerforlife: dont you *dare* censor me. Ever.

I was talking about cpu, you answer by talking about the RDP...
Well the thing with mame/mess is that it will never have any speed/accuracy tradeoff currsor given to the user as i plan to add later. And anyway, i am far from being concerned by the end result, i am not coding but i am doing research on all details of the n64. Coding the emulator is really 5% of the work once all informations are available.

 

[zoinkity]

The hacking world could sure use a cycle-accurate system that implements the full range of opcodes and COP0 registers. Do you know how few actually do that? Take the scummvm homebrew. The whole reason it won't work under most emulators is due to Trap OPs and some crazy (and strange) use of 'unused' COP0 registers as system variables. (albeit, they did write the worst possible controller read scheme ever) Count cheating to run games? Or, the worst culprit: emus accepting LW/SW to non-word aligned addresses.

As an extended problem, some games that use deteted rdram size to scale their memory allocations don't emulate remotely right. Perfect Dark is a great example, with every address over 8038???? something like 0x20 to 0xA0 off of hardware. (I'll look up the specifics if you really need them.) That might seem trivial, except that means any GS code used above that address range requires a console and emulator version, and it probably is a source of instability in the end. Was a bit of a nightmare for the people tyring to RE the game 5-6 years ago, since console debugging was limitted and emulation wasn't accurate to console.

When you go ahead with this, concider a built-in debugger. Hooking a debugger to an emu is messy; having one built-in is much easier for users.

As for LLE of the RDP: I know it's painfully slow, but occationally it is helpful to test a DL without uploading code to console. Even the most accurate of the HLE plugins don't emulate half the features, and others improperly. If you're testing display lists having something accurate to console would be a massive advantage. I'd go out on a limb and say even having a stand-alone DL interpretter accepting microcode and a binary as arguments would be handy.

As for working in unison versus in tandem with another project, the advantage to non-competitive development is that each can learn from the other's implementation. You see it often with compression algorithms. Instead of everyone pounding on a single algorithm they develop slightly different concepts or implementations from each other, eventually leading to one that's accepted--even if only for particular uses.
Along those lines, a no$N64 concept isn't even a bad idea. Coding an accurate emulator core entirely in assembly would be the smallest implementation, and theoretically could also be the fastest.

 

[mrmudlord]

fine, valid points.

so as it stands cycle accuracy > current instruction accurate emulation (and yes, even pj64 is not even that, its like nesticle).

Problem with a assembly only approach, some developers will most likely cry murder if you do so. Just like with the witchhunt certain people did with ZSNES.

And yes, I hardly see how ASM can be "bad". Its just another language, like C. Who cares if its "non-portable". If it does the job, who cares? Plus that "you can't beat the compiler" line people keep saying is BS anyway.

 

[mrmudlord]

Pffff, why won't you understand that's not only about you or about playing now.
Your children will be able to, and that's a pro.

Uh, I don't have kids or want them?

 

[willrandship]

Neither of your cons really apply to bsnes. Sure, it takes some guts to run it, but any decent modern PC can do so, full speed. (Mine can run it, and it only cost me ~$300 overall to build it) Which makes it, IMO (and that is very much opinion, on both our statements) not excessive. It's also not slow.

Why are you hating on someone for a project that, by the time it's finished, will probably run fullspeed on computers anyway? In fact, why are you hating on someone else's project at all? It's not like they're wasting your time. What right do you have to complain?

Of course, I'm not saying ALL emulators should be accurate. That's just stupid. When UltraHLE came out, no one complained about accuracy. I mean, it ran N64 games 3 years after the console came out!

Accurate emulators like bsnes and mupecan64, however, also have their place. Look at bsnes's "Why Accuracy Matters" page if you don't believe me. That's a lot of glitches, and there are tons more on the N64. OoT's start menu, for instance, takes FOREVER to load on any emulator I've ever tried, and MESS is still too glitchy to actually let me test it.