Effective emulator design.

[h4tred]

Hello,

I've been thinking a lot about what blargg said and am deeply considering doing a decent emu entirely from scratch to satisfy that. That is:

* everything comes from proper research
* no "hacks" (depends on what you consider a hack)
* everything is neatly laid out in terms of its design.....

Which is the problem: coming up with the design. I want something that is modular, easy to maintain when I improve it or add support for something that is essentially a evolution of the original CPU, and something that isn't huge.

There's different ways to do it, but I want a design that just works and is portable, not overly complicated, yet it fits the task at hand. I figure brainstorming about the product is important as effective design right from the start makes it better than something as half-baked, filled with hacks, or generally shite like VBA.

I know people might have objections to a library style core interface, but where do you set the middle ground. Or do you do a ala bsnes design? As for the style of core, cycle accuracy would definately kill it for sure, but accuracy while preserving speed would be nice. Stuff like I/O (video output, sound output, and input) I got figured out, or I could use a ruby-style lib for that (and btw, ruby is cool )

So, if people could share thier experience with decent emulator design, that would be most insightful.

[byuu]

FWIW, I probably would've went with a design like libgambatte if I were starting off with what I know now. Much better if you ever want to emulate more than one system in the same app.

Do an SNES one, we need more active devs there; and some real competition to ZSNES v2 :D

[h4tred]

FWIW, I probably would've went with a design like libgambatte if I were starting off with what I know now. Much better if you ever want to emulate more than one system in the same app.

I had a look at libgambatte for some ideas, surely seems very nicely abstracted with all its components in seperate classes. I remember though Nach had objections to such a style for core (can't remember the reasons though ). Personally I was leaning towards one that was less involving in design, yet still offered a clean interface to allow for easy portage as well as the code being clean.

Do an SNES one, we need more active devs there; and some real competition to ZSNES v2

Was thinking about doing that, plus another couple of systems. Personally, I feel there are enough open source SNES ones as is o:. Though something like SNESGT that has open code would sure rock my boat.

[Exophase]

I, on the other hand, find parts of gambatte completely unreadable for a variety of reasons. Is it really worth getting really worked up over structuring the code just right when it's such a subjective thing? Why not go with what works well for you?

You want everything to come from proper research, but this is pretty external to how you're coding your emulator - either your information is verified or it isn't, and either you implement things based on non-verified or otherwise incorrect information (which a lot of things can be without you realizing it) or you don't implement it at all, which is usually not going to get you as far. The only thing you can do to improve this is to research the platform yourself.

Not wanting hacks and so on is a pretty simple to follow criteria, which I think most emulators tend to follow these days.

I understand the want of future proofing development and making things easy to reuse, but I think that with emulation it's not that hard to do so without having to come up with elaborate abstractions. On the other hand, it's pretty much inevitable that there's going to be some work down the line, so it might not be worth it to put an awful lot of energy into trying to avoid it.

[h4tred]

Is it really worth getting really worked up over structuring the code just right when it's such a subjective thing? Why not go with what works well for you?

To me it is, because I prefer developing a product/emulator that has proper foundations from the start. I really would not want anything unplanned. Doing things messily just creates maintainability issues. With VBA, this is exactly the case. With VBA-M, because of the core foundation (VBA), to fix some bugs, would involve rewriting the entire core. And so, I learned from that emulator while doing things to improve it, that a solid base is paramount and that nothing can be unplanned.

but this is pretty external to how you're coding your emulator - either your information is verified or it isn't, and either you implement things based on non-verified or otherwise incorrect information (which a lot of things can be without you realizing it) or you don't implement it at all, which is usually not going to get you as far. The only thing you can do to improve this is to research the platform yourself.

Exactly, and program your own test cases to verify behaviours in the emulator against real HW. Doing things entirely from documentation is not the best way to do things.

I understand the want of future proofing development and making things easy to reuse, but I think that with emulation it's not that hard to do so without having to come up with elaborate abstractions. On the other hand, it's pretty much inevitable that there's going to be some work down the line, so it might not be worth it to put an awful lot of energy into trying to avoid it.

I see, but I rather not have to reinvent the wheel each time when I add a component to my emulator. Having a basic framework and design in my mind would at least alleviate some of those hassles.

[Exophase]

To me it is, because I prefer developing a product/emulator that has proper foundations from the start. I really would not want anything unplanned. Doing things messily just creates maintainability issues. With VBA, this is exactly the case. With VBA-M, because of the core foundation (VBA), to fix some bugs, would involve rewriting the entire core. And so, I learned from that emulator while doing things to improve it, that a solid base is paramount and that nothing can be unplanned.

I think a large part of that could have been because you all were working with an emulator that you didn't write. I don't really like various things about VBA's source either but the results also rather speak for themselves.

I am curious about what bugs couldn't be fixed, though.

Exactly, and program your own test cases to verify behaviours in the emulator against real HW. Doing things entirely from documentation is not the best way to do things.

But a lot of the documentation out there IS coming from people who did exactly that. If they made a mistake then you're liable to make the same mistakes. Most emulator authors don't have the time (not to mention money for hardware, sometimes rare) to sit down and verify every last fact about a platform, if you want to spend years doing so then that's certainly your prerogative but I'd rather obsess over details like that after I find out it's being done the wrong way.

I see, but I rather not have to reinvent the wheel each time when I add a component to my emulator. Having a basic framework and design in my mind would at least alleviate some of those hassles.

"Reinventing the wheel" is taking things way too far. Even if you do absolutely nothing to make your emulator "modular", ripping out a component and retooling it slightly for another platform is going to be much, much less work than writing it in the first place was. Framework is good, sure, but I think what you're going to find is that what works best for you in the future is going to depend on what you feel comfortable working with more than what other people dictate is the "right" design. And you're also going to find that you don't really know what works best for you until you find out what doesn't. What's more is that your design tastes are liable to change over time, and you might end up disgusted with how you wrote something years ago now matter how much thought you put into it. Just things to consider.

[I.S.T.]

Right now, I think an open source GBA emulator or a GB/SNES emulator that actually supported Super Gameboy properly would be the best thing.

VBA(And most of the derived emulators) can't even regulate its' speed right a lot of the time, and the only other GBA emulator that works properly on 90% of games has had its' author disappear(no$GBA). I've got like two or three bugs to report to that guy. -_-

and, well, we all know the Super Gameboy situation...

[Exophase]

My GBA emulator's open source too you know ;P

(although if I release another version it won't be...)

[I.S.T.]

It's also only on the PSP, correct?

[Exophase]

It's also only on the PSP, correct?

It's not only on the PSP, binaries are out for various archs. There's no release of an x86 build but you can still build one.

Of course, if you're looking for any real amount of timing accuracy then you're going to be out of luck.

[gllt]

Well, this is a totally unrelevant after-the-fact of building the base emulator and interface thing but

its been bugging me in my mind lately that the menu driven command system found on the wii emulators needs to be found in some pc emulators so that when you want to do things to the game from your joystick you dont have to have support for hotkeys in the emulator and crap, just a menu button and set the up/down/left/right confirm/back buttons and you can save or load, change video settings and stuff from comfort :V

I just posted this here to avoid starting a new thread lawlwlw

[ShadowFX]

Hello,

I've been thinking a lot about what blargg said and am deeply considering doing a decent emu entirely from scratch to satisfy that.

Like some of the others guys said, why not do a 'proper/accurate' GBA emulator from scratch? It may fill the gap between no$GBA and VBA. Of course, with your mastering of all those shaders and filters, you could probably create an awesome feature emulator to boot.

Also, I still don't understand why one would consider to compete with ZSNES v2.0 when it's not even officially out (if ever).

[Squall_Leonhart]

VBA(And most of the derived emulators) can't even regulate its' speed right a lot of the time

Explain?, many games which happen to be ports from the snes, just don't work properly on the GBA hardware period.

[I.S.T.]

I've had this happen on many GBA exclusive titles(Castlevania: Harmony of Dissonance being the one that comes to mind). Besides, the GBA doesn't have that many SNES ports...

[Exophase]

Hello,

I've been thinking a lot about what blargg said and am deeply considering doing a decent emu entirely from scratch to satisfy that.

Like some of the others guys said, why not do a 'proper/accurate' GBA emulator from scratch? It may fill the gap between no$GBA and VBA. Of course, with your mastering of all those shaders and filters, you could probably create an awesome feature emulator to boot.

Also, I still don't understand why one would consider to compete with ZSNES v2.0 when it's not even officially out (if ever).

It's awfully easy to trust No$GBA as being more accurate when the source isn't out. VBA definitely makes a very significant attempt at accuracy - no, it doesn't emulate things like prebuffer coherency or VRAM bus contention but I doubt you'll find it makes a difference for anything whatsoever (save for demos written solely to show an emulator isn't correct, ie the equivalence of pissing contests in the emulation world). The funny thing with GBA emulation is that getting much closer to accurate timing can actually make the emulation worse. A rule of thumb for platforms like this is to be generous in timing so that you give at least as many cycles as a real GBA would, but potentially more. Games are almost always okay with this, although as a side effect a good number of them run better than they do on a real GBA. I think you'll find that most people are okay with this. Yes, there's always the issue of people doing homebrew needing to verify their code, but fortunately that's really easy to do on a real GBA, and sane coding practices will prevent you from running into problems like this in the first place.

I think the heavy promotion of "accuracy oriented" emulators has caused a lot of misconceptions about what are and are not the causes of bugs in various emulators.

[I.S.T.]

I know no$GBA at least tried to emulate timing related stuff properly. I know a guy who used to work at Vicarious Visions. Martin regularly contacted people who worked there when he found a game of theirs that didn't work on no$GBA. Apparently, most or all of the problems were due to timing issues.

That's all I can say, as I don't know anything else really about no$GBA.

[byuu]

Stuff like I/O (video output, sound output, and input) I got figured out, or I could use a ruby-style lib for that (and btw, ruby is cool Razz)

Kind of disappointing that I haven't managed to convince a single person to use it yet, but whatever :P

Though something like SNESGT that has open code would sure rock my boat.

I was going to mention that it's still not up-to-par with Super Sleuth, but looking at the latest WIP, all the common buggy games are working fine except Battle Blaze. F1 Grand Prix, Mecarobot Golf, etc are all great. Though HDMA timing is still off a bit, so MG is working due to something else running too fast.

Still, it's very, very good. Much improved over the last official release.

(save for demos written solely to show an emulator isn't correct, ie the equivalence of pissing contests in the emulation world)

I do resent the implied notion that this is why we write these demos. In fact, other people using them for exactly that reason is probably the main reason I don't release my demos. The other being that I'm too lazy to document them properly to be useful to others.

And honestly, you'd be really surprised by how often the obscure corner case you didn't think mattered ends up fixing a few random games you didn't even know had problems. But yeah, some of mine are just inane. Like the last write to VRAM before vblank ends will write the MDR (open bus register) instead of the value you want. 1:10 million chance of doing that accidentally.

The funny thing with GBA emulation is that getting much closer to accurate timing can actually make the emulation worse.

True, on the lowest end, falling back on emulation running too fast will get a lot more software working. I've had games break for being six clock cycles off @ 21MHz per frame. Very few games fail when running too fast, and they honestly probably should be declared broken even if they work on the real hardware.

Another thing people fail to realize is that the accuracy vs compatibility trade-off is exponential, whereas accuracy versus speed is linear:

For "Phantom System X":
95% compatibility can be done with 300MHz - 500MHz
99% compatibility at 700MHz - 1.4GHz
99.5% compatibility at 1.6GHz - 2.4GHz
99.8% compatibility at 3GHz - 4GHz
99.90% compatibility at 6GHz - 10GHz
etc.

Again, I think both approaches should be taken: first, one that aims to get maximum compatibility with the lower-end spectrum of modern hardware; and second, one aiming to document and preserve information about the system for the future when the low-end hardware is 10-50x faster than it was a few years ago.

This is especially important for older / rarer systems as developer hardware becomes increasingly uncommon. Sure, a GBA linker is easy to get, but try finding a Vectrex flash cart or a Wonderswan Color Wonder-Magic Linker.

A rule of thumb for platforms like this is to be generous in timing so that you give at least as many cycles as a real GBA would

It also gets better and better with future systems. As clock rates increase, the chances of games breaking from not being perfect decreases. Good thing, too. Just the pipelines + caches alone are getting near impossible to emulate perfectly.

Given GBA software is largely written in C, I suspect the SNES will be the last system that really cares about low-level details to get hack-free 100% commercial software compatibility. I don't even think it's feasible for a human being to get full cycle-level perfection of something as complex as the N64, anyway.

I think the heavy promotion of "accuracy oriented" emulators has caused a lot of misconceptions about what are and are not the causes of bugs in various emulators.

You may have a point. Though it's hard to say how many bugs are due to timing issues, and how many are due to logic bugs.

It's awfully easy to trust No$GBA as being more accurate when the source isn't out.

Thank you. I wish it didn't take another emulator author to have the guts to say that. I'm sure no$gba, Kega, pSX and SNESGT are all great, but without the source how can I really be sure?

[creaothceann]

Isn't that what tech demos are also good for?

[Exophase]

I do resent the implied notion that this is why we write these demos. In fact, other people using them for exactly that reason is probably the main reason I don't release my demos. The other being that I'm too lazy to document them properly to be useful to others.

Sorry, I shouldn't have implied that the demos themselves are bad or useless. Just that I've seen people who have made demos then broadcasted how every emulator but theirs fails them and thus they have the best emulator. Sometimes emulators just aren't going to care about certain things (not necessarily timing related) that they know no game is ever going to rely on, but it's still easy to write a test case that breaks this apart. Of course this gives demo coders a "detect emulator" method, whether or not this is a good or bad thing I don't really know.

This is especially important for older / rarer systems as developer hardware becomes increasingly uncommon. Sure, a GBA linker is easy to get, but try finding a Vectrex flash cart or a Wonderswan Color Wonder-Magic Linker.

If you're going to reverse engineer these things then better get your hardware together while you can.

The funny thing is, the less available real hardware is, the more the emulators (whatever becomes the de-facto standards) are going to replace it. And carry over their own quirks, if any. This notion probably deeply upsets some people ;p I can see the argument in wanting to preserve games, but for game development purposes (if someone is reallly going to develop a game for the platfrom 100 years from now) at that point all that's going to matter is how it runs on the emulators, not how it would have ran on hardware that no longer exists.

Although I'm kinda waiting to see if technology reaches the point where we can decap and optically scan chips, build them back into a synthetic form, optimize, and program FPGAs with the results, automatically. This would be pretty authentic. Would also completely supercede a lot of "preservation only" emulators, if indeed that is all they were ever intended for.

Given GBA software is largely written in C, I suspect the SNES will be the last system that really cares about low-level details to get hack-free 100% commercial software compatibility. I don't even think it's feasible for a human being to get full cycle-level perfection of something as complex as the N64, anyway.

Actually, I would say that the problem is exposed with systems that do per-scanline effects (and don't have ridiculously fast CPUs). GBA is probably the last of the platforms that do this - there's still a pretty small cycle window for hblank and if it misses the ball then it could ruin the entire frame (I'm sure you've encountered this one before >_>). But like I said, I didn't see these problems when giving too many cycles, only when effectively giving too few by making recompiled code not update external events for too long spans (causing entire scanlines to come and go, assumedly. I haven't looked into it too heavily). Having thrown in more stalls where they accurately should be probably exasperates this rather than helps it.

Interestingly, the CPU on a platform like N64 isn't that complex timing-wise. The pipeline is simple and statically scheduled so you know exactly when stalls and interlocks occur within it regardless of what happens during runtime, and it's not very hard to detect. Cache state and misses are also pretty easy to track since it only has direct-mapped cache. I don't think there's a preload buffer, so so long as you fetch from emulated icache and load/store to/from emulated dcache (where applicable) you should be fine in maintaining coherency and timing. What is really going to kill you in trying to get a cycle accurate emulator done is emulating bus contention over RDRAM, since several chips are all tied to it. That, and the reverse engineering necessary to find the timing data for the RSP and RDP (emulating the RDP low level is a much greater ordeal than emulating a 2D platform, IMO.. even a really featureful one like SNES or Saturn)

Now, throw in superscalar and out of order CPUs and we've got issues.

[Squall_Leonhart]

Actually, I would say that the problem is exposed with systems that do per-scanline effects (and don't have ridiculously fast CPUs). GBA is probably the last of the platforms that do this - there's still a pretty small cycle window for hblank and if it misses the ball then it could ruin the entire frame (I'm sure you've encountered this one before >_>). But like I said, I didn't see these problems when giving too many cycles, only when effectively giving too few by making recompiled code not update external events for too long spans (causing entire scanlines to come and go, assumedly. I haven't looked into it too heavily). Having thrown in more stalls where they accurately should be probably exasperates this rather than helps it.

that cycle window might actually be why FF4 screws up on the GBA port so much.... slow downs, corrupt text / frames.

[byuu]

Just that I've seen people who have made demos then broadcasted how every emulator but theirs fails them and thus they have the best emulator.

Wow ... someone actually said their emulator was the best because it passed their own test(s)? In those words? Mind if I ask who in private? I mean, I've bragged about my IRQ timing being virtually perfect (no known issues anyway -- when you spend two years writing several hundred tests you can't help but be at least a little boastful), but damn. I'd say every emulator gets at least one thing right that I don't.

I think the tests are amazing, myself. I actually like it when I fail them, because they document what's wrong and how to fix them quickly. Much easier than searching through a 300MB tracelog of some Japanese golf game looking for potential problems.

I wish more people made them. Overload's S-SMP one helped me out early on, and blargg's S-SMP cycle one helped me to quickly get that perfected with little effort. I used his S-DSP test to make sure I didn't screw anything up when I (re-)ported it to my C++ class design. Awesome stuff.

Of course this gives demo coders a "detect emulator" method, whether or not this is a good or bad thing I don't really know.

d4s did it with Breath of Fire 2, but I gave him a hint by telling him the one feature likely to never be emulated correctly (for exactly the reasons you state, which are true): mul / div unit calculation processing.

Who knows if it's a good thing. I hit a bug in ZSNES where using DMA-only $4308 as a scratch register (for a fastROM jmp indirect without corrupting RAM) that was corrupting unrelated HDMA channels. I can see myself detecting that and warning users if FEoEZ is finished before it's fixed.

I can also see console game writers starting to use it, especially for 'quickly emulated' systems like the NDS. But what's the point, they'll be hacked around in short order.

If you're going to reverse engineer these things then better get your hardware together while you can.

Yeah, I'm definitely hording it now. Still need to get my act together and make those SNES serial cable clone parts already ...

The funny thing is, the less available real hardware is, the more the emulators (whatever becomes the de-facto standards) are going to replace it. And carry over their own quirks, if any. This notion probably deeply upsets some people ;p

I don't want to make it seem like my life revolves around getting emulation perfect, but we all have our hobbies. Mine is trying to preserve hardware, so yeah the more I can minimize the above, the better. You're ultimately right that we'll never get things perfect and emulation will completely replace the real thing.

It isn't going to kill me to not get things perfect, but at the same time I don't accept that as an excuse to not try even harder while I can.

And really, really long-term, even C / C++ are going to be 'dead' languages, and we'll run into new issues when we port emulators over to new languages. I'll probably be near-dead when that happens anyway, so oh well.

Although I'm kinda waiting to see if technology reaches the point where we can decap and optically scan chips, build them back into a synthetic form, optimize, and program FPGAs with the results, automatically.

I really, really, really, really doubt it. But we'll see. At the best case, it will only work on 30+ year-old hardware (you aren't going to make a 32nm cloning process using 32nm parts), and it may be too late for anyone to care about old hardware by then.

I really doubt we're going to see modern PCs start to use programmable FPGAs. Best you'll get is probably stuff like multi-core CPU + GPU coding. And I will point you to the infamous Pong circuit simulator for a full-software approach.

... you should be fine in maintaining coherency and timing

I really feel we're on completely different levels, because that sounds really difficult to me. Seriously, if you ever want to team up on a PC emulator, look me up :D

(emulating the RDP low level is a much greater ordeal than emulating a 2D platform, IMO.. even a really featureful one like SNES or Saturn)

Oh come on, seriously?? I wouldn't know, but wow. RDP is more complex than 2xSH-2 + SH-1 + 68k + Z80 + 2xVDP (one is a 3D processor) + five other processors?

[Exophase]

RDP is more complex than the 2D in Saturn (VDP2), not the whole Saturn ;p

[I.S.T.]

Thank you. I wish it didn't take another emulator author to have the guts to say that. I'm sure no$gba, Kega, pSX and SNESGT are all great, but without the source how can I really be sure?

If you read the sprites mind forum, you'll see actual evidence of Kega being accurate. How accurate is, of course, up in the air, but still...

[byuu]

If you read the sprites mind forum, you'll see actual evidence of Kega being accurate. How accurate is, of course, up in the air, but still...

Yeah, and I totally 100% respect the authors' choices to keep the source closed. Especially after seeing what happened to Exophase.

All of those authors have very high integrity and I'm certain they're all honest with what their emulators do.

But I'm sorry, I just don't like keeping things secret. I can't verify what's really happening -- you can say you emulated this right, and you may even really believe you have, but say you miss a subtle bug and the game just so happens to look correct. It's like security through obscurity. The best crypto algorithms are the peer-reviewed ones.

And if said emulator dies, it ends up as a waste of time as soon as another emulator surpasses it. Eg what did all of the time testing games in ePSXe do for pSX?

Why should two people have to figure out the same thing, when each could figure out something different and share info? Just release the core emulator files. No headers, no UI, no drivers. Something that'd take months to compile at all. That's more than enough to enable community reach and prevent forking / casual theft.

(I should also mention a lot of these authors freely share code with other devs when asked, GIGO included. That negates the above entirely.)

The talentless leeches that just want their two minutes of fame will target easier GPL emulators where they can regex_replace their name in all the credits, screw up one or two critical functions and pretend they 'fixed' them, and boast about how much better their fork is.

It's one of those philosophical hypocrisies of mine that I can't balance. My desire to share info conflicts with my belief that it's the author's right to do whatever they want with their work. Even my own license is a half-way point between these two extremes.

[blargg]

But I'm sorry, I just don't like keeping things secret. I can't verify what's really happening -- you can say you emulated this right, and you may even really believe you have, but say you miss a subtle bug and the game just so happens to look correct. It's like security through obscurity. The best crypto algorithms are the peer-reviewed ones.

Peer-reviewed and extensively exercised. As the author of my own emulators, even I can't verify that it's doing things right by looking at the source code. I may think it's working, but that's not reliable. Test programs are the only reasonably-reliable of verifying an emulator's operation (and they can be re-run anytime you change the source code). OK, I take that back; source code is a good way to determine an upper bound on an emulator's complexity, hence how in-depth the test programs need to be. For example, an emulator which caches lots of things will need more extensive tests than one that doesn't. A CPU test for an interpretive emulator can be much simpler than one for a dynamic recompiling one, where combinations of instructions can fail in obscure ways, even though the individual ones work in isolation.

My point is that for the most part, determination of an emulator's accuracy doesn't require its source code.