Taking dynarecs one step further: Just-in-time assembly?

[blargg]

You're proposing to change the goal from emulating hardware to emulating (a subset of) software. The way to tell is if you're considering only hardware behavior that software commonly triggers. Also, you seem to assume that the only games that depend on these nuances are those whose programmers intentionally did so, when a game could depend on it unintentionally.

[byuu]

(observe for example, GBA emulator compatibility is far higher compared to the SNES).

Very impressive, I didn't realize it was possible to get compatibility far higher than 100%.

[Deathlike2]

This thread is heading into disaster.

[I.S.T.]

You mean it wasn't one already?

[funkyass]

he's stuck in a polling loop.

putting IRQ's at the bottom of the list is a sure fire way to make things not work. You are forced to deal with them correctly even to get this idea of your s running.

[grinvader]

Wait until he realizes how the emulation flag can turn weeks of work on dynamic recompiling into a bulky pile of wasted bytes.

[Rashidi]

tech-y talks escapes me...

does he thought that snes emulation can going into HLE or something?

[blargg]

Or until the reality of the profile kode54 posted sinks in. Most time not spend in CPU emulator = lots of hard work on dynamic recompilation makes no noticeable difference in speed. I don't think the goal is to speed things up, rather it's to do dynamic recompilation regardless.

[tcaudilllg2]

Or until the reality of the profile kode54 posted sinks in. Most time not spend in CPU emulator = lots of hard work on dynamic recompilation makes no noticeable difference in speed. I don't think the goal is to speed things up, rather it's to do dynamic recompilation regardless.

That's not it at all. Taking out the switches by precomputing them WILL improve performance. The way I see it, you can hardcode most of the actual effects of the hardware. Nor am I convinced that the PPU code can be substantially improved at all. It seems to me you've already cut every code corner there is, just about.

What else could you do?

[tcaudilllg2]

(observe for example, GBA emulator compatibility is far higher compared to the SNES).

Very impressive, I didn't realize it was possible to get compatibility far higher than 100%.

Way to mince words....

[Deathlike2]

(observe for example, GBA emulator compatibility is far higher compared to the SNES).

Very impressive, I didn't realize it was possible to get compatibility far higher than 100%.

Way to mince words....

I think that's because you haven't bothered tracking the state of SNES emulation.

That's besides the point, GBA emulation was far ahead since the first emu debuted IIRC before (if not before, but approximately the same time) the actual handheld came out. This is a poor and flawed comparison to begin with.

[byuu]

Way to mince words....

Oh? In that case, please clarify what you meant. GBA compatibility is far higher in what regard? Do these emulators play more games? Do they emulate the hardware itself more faithfully? What? What did you mean? Please cite specific, real-world examples.

[tcaudilllg2]

Way to mince words....

Oh? In that case, please clarify what you meant. GBA compatibility is far higher in what regard? Do these emulators play more games? Do they emulate the hardware itself more faithfully? What? What did you mean? Please cite specific, real-world examples.

How many games aren't running on GBA emulators (such as VBA) due to timing issues? I've kept track of the compatibility... the situation is dire enough that a game as simplistic as Der Langrisser cannot run on ZSNES (with sound) without crashing. And wait, yes we've got a problem with the Fire Emblem SNES patch not running on ZSNES versions lower than 1.51. Why is that?

Name a GBA game that has the same issue.

I guarantee you that GBA games aren't using arcane timing tricks to improve their performance. (for that matter, GBA games aren't even written in ASM, except maybe for a handful of performance critical tasks).

Oh wait a second now... I think I'm starting to understand. There IS a reason earlier Der Langrisser patches ran with stereo on earlier versions of ZSNES, isn't there? Yes, the reason could only be... that it's the translators who are making most of these timing critical hardware exploits. Now I see the problem.

As for earlier uses of these methods, I'm gonna check out Death and Return of Superman to see if it works nowadays. (and did you guys ever fix the Chrono Trigger battle flash?)

[franpa]

the superman game works fine (afaik) in zsnes 1.51 and in bsnes (bsnes is what you should compare vba to.

[mudlord]

(bsnes is what you should compare vba to.

Uh...no.

BSNES is a SNES emulator. VBA and its derivatives are GBA emulators. Its like comparing apples to oranges here.

Well, you should be comparing No$GBA to VBA here...

[tcaudilllg2]

the superman game works fine (afaik) in zsnes 1.51 and in bsnes (bsnes is what you should compare vba to.

OK then, that's a bad example.

Actually I don't know any games right off, but I do know that you guys keep talking about games that require special timing to run, and since the translations have been becoming more and more technical compatibility with those games is declining in my estimation.

[Deathlike2]

Certain older translations were not tested against the SNES, and if that was inaccessible, whatever the emus+info was available at the time.

That's still not a proper comparison anyways. The comparisons you are making are flawed, even if emu is producing said bugs. Emulation inaccuracy has nothing to do with speed hacks/deficiencies. It has more to do with the information that was available/accessible/known at the time. Since that information has improved, to the point where BSNES now exists (though the performance implications of doing so seems a bit exaggerated in BSNES IMO). It's still about optimization, and not about thinking outside the box.

Please don't use GBA in the comparison, because it is flawed from the start. When a near-complete emu comes out at the same time the handheld comes out, and trying to compare how GBA emulation is easy.. maybe because it isn't as complex as the SNES. It's not rocket science, but the comparison between the emulation of different systems is flawed nonetheless.

[byuu]

How many games aren't running on GBA emulators (such as VBA) due to timing issues?

Excluding a small number of special chips (that have nothing to do with the base hardware unit), how many aren't running in bsnes? (hint: zero.) And including special chips, how many aren't running in any emulator? (hint: two Shougi games that nobody cares about.)

Besides that, ZSNES v2.0 will likely have similar compatibility to bsnes (plus SuperFX/SA-1 support), and will be out this summer. Other emulators are already very close, such as Super Sleuth.

I've kept track of the compatibility... the situation is dire enough that a game as simplistic as Der Langrisser cannot run on ZSNES (with sound) without crashing.

You said: "(observe for example, GBA emulator compatibility is far higher compared to the SNES)."

Not: "(observe for example, VBA emulator compatibility is far higher compared to ZSNES)."

Hence, I wasn't mincing anything with my words. If the latter was what you meant, how was I to predict your misspoken statement?

Oh wait a second now... I think I'm starting to understand. There IS a reason earlier Der Langrisser patches ran with stereo on earlier versions of ZSNES, isn't there? Yes, the reason could only be... that it's the translators who are making most of these timing critical hardware exploits. Now I see the problem.

We've been reporting the Der Langrisser issue to the ZSNES dev team for the past seven or eight years now. I'd be surprised if any version of ZSNES that had sound output ran the game without crashing.

And the Japanese game crashes, too. It has nothing to do with our fan translation. In fact, the situation is the reverse: fan translators keep hacking games in ZSNES, and they end up not working properly in any other emulators or on hardware (Ys 4, Dual Orb 2, Dragon Quest 1&2, Sailor Moon: Another Story, etc etc etc.)

Its like comparing apples to oranges here.

They're both fruits, and of similar size and mass. Both have an outer layer of skin, and both have seeds inside :)

Otherwise, agreed. GBA doesn't have to deal with dozens of complex special chips.

(though the performance implications of doing so seems a bit exaggerated in BSNES IMO)

They definitely are. You could get the same accuracy at roughly twice the speed. With ZSNES v2 requiring ~800MHz and getting pretty close (no bus delay / subcycle emulation), and bsnes w/PGO and range-test IRQs getting full speed on my old ~1.67GHz Athlon XP, I think you can agree with that estimate.

There's a very good reason for the speed difference of course, but that discussion belongs in another topic. Suffice to say, ZSNES <v2.0's biggest problem was extreme optimizations (exactly like tcaudilllg2 is discussing now) in place of simplistic, readable code whose only aim is to perfectly reproduce hardware results. But of course, there was also a very good reason for that as well; and it's the reason ZSNES+Snes9X comprise >98% of the SNES emulator userbase even today.

[tcaudilllg2]

@byuu: sorry for not being more specific. I'll endevor to be more precise from here forward. (though sometimes a concept is so complex that I find it easier to convey it by way of the context of its usage. Nor am I good at being wordy, never have been).

As far as dynarecs go, it would seem to me that one would have to insert the switches that are a part of an emulator's code into the dynarec to allow the emulator access to its flags.

Consider for example horizontal flipping. It's one bit for every sprite on the SNES. If you are reading the bit, then you have to have to link its setting to a boolean variable whenever the flag write for horiz flipping is made -- if you are porting to a non-sprite based platform. (you'd also have to instruct the program to perform the flipping operation on the image). Say you were translating to another sprite-based platform, such as GBA or PS1. In that case, you'd only have to invoke the native platform's functionality and not have to mention it in code at all aside from setting the bit.

[byuu]

@byuu: sorry for not being more specific. I'll endevor to be more precise from here forward. (though sometimes a concept is so complex that I find it easier to convey it by way of the context of its usage. Nor am I good at being wordy, never have been).

No worries. I wasn't trying to give you a hard time, for what it's worth. I'm just very direct most of the time is all.

In that case, you'd only have to invoke the native platform's functionality and not have to mention it in code at all aside from setting the bit.

As impractical and as many unsolvable problems as that could bring up, I must admit that it would be a real blast to try emulating a tilemap/sprite system on another tilemap/sprite system :)

[tcaudilllg2]

@byuu: sorry for not being more specific. I'll endevor to be more precise from here forward. (though sometimes a concept is so complex that I find it easier to convey it by way of the context of its usage. Nor am I good at being wordy, never have been).

No worries. I wasn't trying to give you a hard time, for what it's worth. I'm just very direct most of the time is all.

In that case, you'd only have to invoke the native platform's functionality and not have to mention it in code at all aside from setting the bit.

As impractical and as many unsolvable problems as that could bring up, I must admit that it would be a real blast to try emulating a tilemap/sprite system on another tilemap/sprite system

I conceive of it as being testable by the following method:
- write a PPU unit "software" that is compatible with the SNES, but features only the bare basics for image/sprite presentation. (along with the sprite flags for demonstration).
- write in ASM a program that flips a sprite horizontally.
- translate the program to GBA, using the GBA's PPU system instead of the SNES'.

Should be well doable. On the other hand, making it useful for just the thrill of corresponding two consoles is something I find internally disquieting. For me to commit to something it must have a larger purpose. (my immediate goal by creating this translator is to increase the number of programs available for my Dell Axim handheld. But of course it could ultimately translate to just about anything given a sufficiently flexible engine. I've got a lot of resources available to the task).

I respect your work on SNES emulation and there is no doubt you've created progress in the field by it. You've certainly shifted the debate towards accuracy... now we just need to see it shift to a middle ground between accuracy and performance. There is never enough time to craft a perfect model... nor the resources...; instead one does one's duty to the era and circumstances one sees around oneself, and leaves the rest to later circumstances.

I will say I don't understand how you guys withstand the pressure from Nintendo, Sony, etc.. I believe what you are doing is right -- it's making creative information available and closing the creativity gap between cultures which is manifest in the storylines of the games (for too long has the promise of irrational success captivated the industry) -- but I also see it as somewhat of a risk.

I will say that it is idle to surmise that there is not correlation between some of the more... exceptional releases we've seen in the West, and the translation efforts we see at romhacking.net. As I say, I admire what you're doing but I don't see how you people take the pressure.

On the other hand, there is no proof that these companies are genuinely losing money. (if anything they are getting free advertising) Nor are you offering anything that the people performing the translation. The question is one of this: does a company have a right to information as a part of its copyright? The companies argue that they do... but apparently the courts (or more specifically, those who prize access to knowledge above all else) disagree.

I would argue this though: a strategy is needed by emulation enthusiasts against those who would calculate legal expenses as a weapon.

[creaothceann]

I guarantee you that GBA games aren't using arcane timing tricks to improve their performance. (for that matter, GBA games aren't even written in ASM, except maybe for a handful of performance critical tasks).

[citation needed]

Btw. - Not games, but still some nice software: http://pouet.net/prodlist.php?platform[ ... er=thumbup

[Thristian]

As impractical and as many unsolvable problems as that could bring up, I must admit that it would be a real blast to try emulating a tilemap/sprite system on another tilemap/sprite system :)

I believe goomba, the Gameboy emulator for Gameboy Advance, does exactly that. In fact, for the longest time it didn't emulate the Gameboy Color because the GBA had some stricter hardware limitations than the GBC (number of tiled background planes, I think). The fact that Goomba now emulates the GBC well enough to run many commercial games is quite impressive, even if it'll never be possible to get 100% compatibility.

See also PocketNES for the GBA.

[Tallgeese]

I guarantee you that GBA games aren't using arcane timing tricks to improve their performance. (for that matter, GBA games aren't even written in ASM, except maybe for a handful of performance critical tasks).

[citation needed]

Btw. - Not games, but still some nice software: http://pouet.net/prodlist.php?platform[ ... er=thumbup

It's well known Mother 3 used a very bad C compiler.

[I.S.T.]

(bsnes is what you should compare vba to.

Uh...no.

BSNES is a SNES emulator. VBA and its derivatives are GBA emulators. Its like comparing apples to oranges here.

Well, you should be comparing No$GBA to VBA here...

franpa was actually semi-right(TEH SHOCK). He was referring to accuracy in the emulators. What he was wrong about what comparing VBA to bsnes. The more accurate comparison would have been no$GBA to bsnes.