Zilmar's RSP spec: two questions

[MooglyTwo]

That's the word: tradeoff. But in my opinion, we should try to optimize both speed and accuracy. A good emulator is an emulator that is as optimized as possible for a certain accuracy. I mean, even a perfectly accurate emulator can be optimized to some extend. It does not really matter if you start by an accurate emulator and optimize it step by step or if you start with a fast emulator and improve for accuracy step by step. The goal is the same in the end and it is unreachable: the 100% accurate emulator that is as fast as possible.

That's exactly what I've been espousing in the first place, but the simple fact is that unless you emulate both the RSP and the RDP on a low level, you can't achieve 100% accurate emulator.

Christ, I said that I plan on optimizing the hell out of the N64 driver in MESS and the Aleck 64 driver in MAME once the new dynamic recompiler backend comes online, do you people have some major problem listening or something?

Criminy. I'm sure this and the last post are just going to get me banned. No big deal, it's why I started my own forum for relevant emulator development posts.

 

[Hacktarux]

That's exactly what I've been espousing in the first place, but the simple fact is that unless you emulate both the RSP and the RDP on a low level, you can't achieve 100% accurate emulator.

Christ, I said that I plan on optimizing the hell out of the N64 driver in MESS and the Aleck 64 driver in MAME once the new dynamic recompiler backend comes online, do you people have some major problem listening or something?

Criminy. I'm sure this and the last post are just going to get me banned. No big deal, it's why I started my own forum for relevant emulator development posts.

Erm, you should really take a deep breath and calm down. Did i say anything wrong about your emulation work ? I don't think so. I was rather insisting on the fact that both accuracy oriented and speed oriented emulators are interesting and are usually moving toward the same goal. Well, i can't speak for other developers but at least i'm improving accuracy on each release of my emulator and i'm sure all n64 emu that are still in progress are moving towards better accuracy.

I would even say that both approaches are complementary and are helping the community to make progress towards the perfect fast accurate emulator.

And yea, emulating at a low level the rsp and the rdp is necessary if you want perfect accuracy. There are some rsp and graphic plugins that are emulating them at a low level (z64 and pj64 beta plugins for instance), so there's nothing in the current emulator structure that is preventing low level emulation except the details that we are discussing in this thread about the synchronization of the rsp with the main cpu.

 

[byuu2]

Dynamic recompilers are not hacks, they do not sacrifice accuracy, and anyone who tells you otherwise is an idiot.

I'm sure none of the below is news to you, MooglyTwo. But for others reading this thread ...

In theory, a dynamic recompiler can be just as accurate as an interpreter in every respect, but such an approach is usually infeasible in practice.

Take a processor where IRQs can be enabled or disabled, triggered or blocked within the middle of any single opcode, even based upon what exactly the opcode is doing. For instance, the second to last cycle could disable IRQs right before one was scheduled to occur.

To account for that, you must add native processor code to perform IRQ updates for you after each relevant bus access.

Further, a processor could communicate with another part of the system, in which case you must sync up that other component before the communication occurs, if it is behind. Given dynamically recompiled code can still perform indirect memory accesses (and hence you might not know if it will communicate with another component), this means your generated code must also perform these checks -- perhaps by calling specialized memory read/write functions.

In truth, to reach subcycle-level accuracy with a dynarec, you end up with so much safeguarding that you lose most of the speedup that dynarecs offer in the first place. And you still have to recompile all of the code, where caching only gets you so far. In the end, you end up with a lot of needless complexity for a very small speed gain.

Of course, there are cases where there is very little (or even no!) external communication with other processors, and there are not multiple independent logic units in the processor, such as interrupt request or DMA circuitry. There are also systems where subcycle-level accuracy is pointless outside of the domain of theoretics. Even the SNES gets pretty close there. I would say this level of precision on an N64 would be overkill, even for purists. Dynarecs can be used in these cases with no real downsides.

But you would be a goddamn fool to use a dynarec on a 6502 when aiming for subcycle accuracy as a means of gaining speed, for instance.

Typically, if a dynarec is more accurate than an interpreter, the fault lies equally on the fact that the interpreter is poorly written. It has nothing to do with dynarec being superior for achieving accuracy. And I'm not saying you suggested that, I'm just pointing that out for everyone else.

In fact, a dynarec is quite the opposite of something that helps accuracy. It adds another potential point of failure while providing no benefits to accuracy. They exist only as a means to gain speed. But with a talented enough programmer, he can avoid all of the potential pitfalls and still gain a nice speedup with one.

As I said before, I strongly admire those who are willing to attempt to maximize both speed and accuracy. That's clearly the hardest goal of all in emulation.

If you're not all about FR33 G4MEZ!!!!! at FULL SPEED on L33T PENTIUM THR33ZZZ!!!!!

Very depressingly, it goes with the territory. I hate it as much as you do, but that will never, ever change. And the majority of people will stick with the fastest emulator that gets them Super Mario 64 with the most additional, non-hardware related features, regardless of how it does it. To them, it's all about the ends, and not the means.

And yea, emulating at a low level the rsp and the rdp is necessary if you want perfect accuracy. There are some rsp and graphic plugins that are emulating them at a low level (z64 and pj64 beta plugins for instance), so there's nothing in the current emulator structure that is preventing low level emulation except the details that we are discussing in this thread about the synchronization of the rsp with the main cpu.

I'd be happy to lend a hand with synchronization techniques, if you wish. I have a good deal of experience with this.

If you want, we can discuss this here or in private. I'd just need to know how all the RSP and RDP can communicate and such (do they share an address bus? do they use a specific I/O port range?), at what clock speeds they execute at, and how willing you are to forego some degree of precision in return for speed. Obviously this also depends on how sensitive the games are.

 

[mudlord]

There are no arcade emulators that "completely smoke it in regards to accuracy". You're deluding yourself. MAME strives for accuracy, MESS strives for development just for fun, and accuracy eventually.

I guess what he means is the other systems MAME/MESS emulates, not just arcade systems, which I'm sure MAME does a nice job at emulating.

Christ, I don't even know why I bother. It's like talking to a brick wall. If you're not all about FR33 G4MEZ!!!!! at FULL SPEED on L33T PENTIUM THR33ZZZ!!!!! you're obviously not welcome on these boards.

Now thats just acting stupid and thinking completely irrational. No one in thier right mind would consider Pentium III's in this age "l33t". But I'm sure this relates to that rom kiddie remark earlier...but I'm not going to even bother rationalising over that, since thats obviously a sore spot with MAME ethics. And I really don't want this nice discussion turning into a flamewar.

What, and not supporting texture packs makes an emulator inherently shitty? What the fuck? There's a difference between an emulator that's designed for playability and an emulator that is designed for accuracy to the way the hardware worked. There's nothing inherently wrong with either of them, but you're deluded if you think that saying one is more correct than the other - with regards to the way the original hardware worked - is wrong.

Thats not what I see. I see one group ostracising the other over things like labeling people "ROM kiddiez", and thier consistant insistance that accuracy, no matter the cost is the way to go. But then MAME's insistance as a "documentation project" makes the point completely mute.

 

[PistolGrip]

Neither MAME nor MESS claim ultimate emulation of the NES or Atari. However, MESS is now one of the better Atari 2600 emulators with the exception of certain bizarre carts like Pitfall 2.

However, if you don't think that the developers of MAME aren't continually making strides toward accuracy, you're a retard. Ad-hominem attacks aside, you should really try looking at the numerous systems in MAME that have had their drivers rewritten over the past year to remove hacks and be perfectly accurate to the schematics. You should try looking at the numerous systems in MAME that have had discrete audio emulation added, eliminating the inaccurate use of samples. Just what drugs are you on for you to claim that the developers don't care about accuracy?

They may be "making strides" (I guess like we all make strides to improve stuff as time goes on), however they CLAIM quite often that MAMEs goal is accuracy over all else. My claim is that this isn't the case, the devs pick and choose when they want to be accurate, yet then have the audacity to take the moral high ground when it comes to other things like Pinball games, hacks, etc. Also if you go to the old mame forum, or the new one at mameworld you will find some of the main developers bad talking other emulators quite often. This mostly stems from the arrogance that the MAME base is "the best" and "most accurate".

Having dealt with NES games which count cycles (using instructions of known lengths) from a vsync and then triggering interrupts or messing with VRAM I know that a simple "cycle accurate" 6502 core like that found in MAME/MESS is inadequate to deal correctly with this problem.

What the fuck are you talking about? The only two dynamic recompilers that MAME has is a MIPS recompiler and a PowerPC recompiler, and both of them are more accurate than the interpreter counterparts.

Pretty much the ONLY reasons you will ever want to do a dynarec is such :-
1) when you are emulating millions (over 50mhz) of cycles per second and want to get rid of the "waste" cycles taken up in a traditional emulator loop. I submitted such a design/idea to the mame board a while ago which could use interpreter cores in a platform generic dynarec to remove this waste.
2) The system needs little coordination because the software doesn't need fine intervals to work. This is usually the case when you start going over 50MHz. HOWEVER if someone was to WRITE something which needed fine intervals it wouldn't work correctly.

If an inaccuracy is found in MAME and can be corrected in an accurate manner, it's fixed. Period. Dynamic recompilers are not hacks, they do not sacrifice accuracy, and anyone who tells you otherwise is an idiot. Incomplete system emulation is often submitted as a fundamental basis on which other people can work. Take Naomi, for instance - for months it could do nothing, but thanks to an external developer it can now, at least, boot the Naomi BIOS. This wouldn't have happened if a dev had just sat on the incomplete driver and never submitted it.

Anyone with some skill could easily write some software which wouldn't work correctly on those dynarecs.

Blow me. I'm on the private mamedev mailing list, that puts me as more of a dev than a number of external contributors.

Please, I've seen you blow up over any slight agitation, look at you come in this thread and attack people in your first post. How many times are you going to threaten quitting the "skene" before you actually do it? You must have burst a few veins in your head by now.

What, and not supporting texture packs makes an emulator inherently shitty? What the fuck? There's a difference between an emulator that's designed for playability and an emulator that is designed for accuracy to the way the hardware worked. There's nothing inherently wrong with either of them, but you're deluded if you think that saying one is more correct than the other - with regards to the way the original hardware worked - is wrong.

The problem is developers of MAME/MESS only care about the past when it comes to emulation, totally over looking the fact that maybe people want to WRITE SOFTWARE for those emulated systems TODAY. Not only that, modding games is also a part of GAMING, it has been since the start. So I do not understand why disallowing mods == good. People like you who are against it don't have to add the support, leave that to others who WANT to spend the time doing it, either way it doesn't HURT mame/mess to allow this stuff.

The complaint that "rom kiddies" are the bane of the scene is hilarious considering that 99% of MAME/MESS devs pirate to their hearts content. In every community you're always going to have people who act like idiots, you'll never correct this problem as it's a human problem, not a ROM/TEXTURE/HACK problem. Using this excuse is older than Jesus, with even less factual evidence.

 

[PistolGrip]

But you would be a goddamn fool to use a dynarec on a 6502 when aiming for subcycle accuracy as a means of gaining speed, for instance.

In fact, a dynarec is quite the opposite of something that helps accuracy. It adds another potential point of failure while providing no benefits to accuracy. They exist only as a means to gain speed. But with a talented enough programmer, he can avoid all of the potential pitfalls and still gain a nice speedup with one.

You're only going to get a "nice speed up" with a "very accurate dynarec" if there is a lot of waste in the typical emulator loop. This usually occurs when you're dealing with having to emulate say a 100mhz cpu and doing the usual CMP, CALL, JMP, multiply that by 100 million and you can see that you're going to save yourself 100 million x the cost of those common things in the loop each second. That may be around 500MHz to 800MHz of host cycles, maybe more.

However if you don't have an accurate dynarec (mostly because some systems don't *NEED* one) you can get pretty nice speed boosts at lowish MHzs. Problem is most low MHz systems require accurate emulators, usually cycle accurate at least, and in cases like this you're looking at negligible speed increases for massive complexity. I wouldn't like to see what a sub cycle dynarec looks like.

 

[Danny]

Wow this conversation sure is a great read

Thanks to all who posted for the insightfull read

 

[olivieryuyu]

Erm ...

Can we stick onto the subject of the thread please ? i mean the synchronization of the rsp with the main cpu.

Every emulator developers have its own idea of his work and how to do it. That is all: nothing to say more

And for people who complain, write your own emulator with your own ideas.

And what about the audio in Twisted Edge Extreme Snowboarding ? and some strange loop in some games (Yakouchuu II - Satsujin Kouru for instance)

 

[angrylion]

Audio in Twisted Edge Extreme Snowboarding is not fixed. The issue may well be unrelated to RSP.

 

[Azimer]

Audio in Twisted Edge Extreme Snowboarding is not fixed. The issue may well be unrelated to RSP.

It's been ages since I looked at it... but if I recall correctly it was something within the game code itself. I do believe it was the same result regardless of LLE or HLE audio.