Effective emulator design.

[ArtVandelae]

Ah, one of those types.

and Moogly Guy is that much in trouble with Nintendo? Wow. I'll have to check out his blog again...

Not in trouble, but he works for one of those companies that has a policy of "any code you write technically belongs to us". Thus, to avoid trouble, he gets their permission before releasing the code to his works. Since he works for a game developer with ties to Nintendo his employer decided to ask Nintendo's legal department for the OK before giving him permission to integrate his N64 work into MESS. While Nintendo hadn't said "no", they haven't been expedient with a "yes" answer either.

[I.S.T.]

Yeah, I just read that.

Seems to me like a fucking stupid decision to join a company like that, but if he likes it there...

[powerspike]

There's a bigger chance of Ville Lindie coming back and finishing up the driver then him being able to release his changes legally. Seems kinda silly wanting to do it the legal way anyway. He could have just given his source code to another developer then had them release it under his name or been an anonymous contributor. Well it would have worked if he didn't setup a blog to talk about what he was working on that is, too late now I guess.

[Exophase]

Thanks for the clarification.

Its just I really don't want to step on your toes if I look at your code for some ideas. Plus, you seem adamant about it not being open source, so I really don't wanna be a bother like that other person was to you. And plus, I rather not face licensing issues.

Just for the record, you or anyone else who is willing to maintain open dialogue with me are welcome to have the source (if you agree not to fork it; approved ports on the other hand are fine if you work with me). Same policy I keep with Temper - a few people have asked and have received really easily. No problems with anyone forking it yet :>

Of course I support another open source GBA emulator 100%, especially if you can make it faster than VBA, which was the de facto choice of porting to handhelds but was never fast enough.

It'd be nice if one day I bothered to get a flashcart so I could do some timing tests and various other things. No$'s documentation is great but it leaves out some details like exactly how the prefetch buffer affects timing.

[Dullaron]

Imaging this.

bgba with open source from byuu.

I think it will never happen. byuu never get tired from working on bsnes.

[Exophase]

Imaging this.

bgba with open source from byuu.

I think it will never happen. byuu never get tired from working on bsnes.

Minimum requirements for fullspeed emulation: 64GHz Core 2 Duo

(actually, even though GBA is much more powerful than SNES, an emulator by byuu probably wouldn't be slower than BSNES since GBA has much less concurrency to worry about, he'd probably be doing everything in ~16MHz ticks which are even lower than SNES's master clock)

[byuu]

Not in trouble, but he works for one of those companies that has a policy of "any code you write technically belongs to us"

This is why you don't give out your real name on the internet, or your internet pseudonym to your employer. And no, I'd never sign an agreement like that to work somewhere.

Not to discredit his amazing work, but MooglyGuy should've made it more clear there was a bat's chance in hell he'd be able to release his work before showing it off to everyone at least :(

Just for the record, you or anyone else who is willing to maintain open dialogue with me are welcome to have the source

That's way more than completely fair, in my book. If you can't be bothered to ask permission, then what sense of entitlement can you possibly have?

bgba with open source from byuu.

I think it will never happen. byuu never get tired from working on bsnes.

And yet I've done almost nothing but work on frivolous GUI stuff for the last year and a half or so :/

My job takes up too much of my life to manage another emulator. If someone would buy me a house (~$150k) so I could retire from work, I could dedicate an extra 40-60 hours a week (from the 5-15 I get now), and easily make bsnes far greater, plus handle at least 2-3 additional emulators aiming for the same precision.

But yeah, good luck finding a billionaire philanthropist emulator fan for that. Maybe I should rebrand bsnes as a "historical file format archival device" and apply for a college grant. I hear some colleges are actually stupid enough to fall for that.

(actually, even though GBA is much more powerful than SNES, an emulator by byuu probably wouldn't be slower than BSNES since GBA has much less concurrency to worry about, he'd probably be doing everything in ~16MHz ticks which are even lower than SNES's master clock)

Given I won't ever be able to retire, in the off chance I made another emulator, it wouldn't aim for anywhere near the same level of precision. In fact my only idea at the moment was to make a fast SNES emulator with my current knowledge of what is and is not necessary, using hacks for the obscure games to get 100% compatibility whilst keeping requirements at ~800MHz tops.

Kind of sounds like ZSNESv2 at that point, so I'm waiting to see what that's like first.

[Panzer88]

I would shoot for the N64, It's the more insane undertaking but I have the upmost faith in you. Plus being the first system to use a graphics accelorator (first mainstream console right) I think that would be a good match for someone like you who knows a decent amount about that sort of thing.

Pretty sure the PS1 was the first home system with 3D hardware.
Not very GOOD 3D hardware, mind you, but... it had it.

right I said that wrong, I know full well about the PS1 and Saturn 3d capabilities, I was thinking of other gpu functions that were used exclusively on the N64 like texture filtering etc.

In fact my only idea at the moment was to make a fast SNES emulator with my current knowledge of what is and is not necessary, using hacks for the obscure games to get 100% compatibility whilst keeping requirements at ~800MHz tops.

Kind of sounds like ZSNESv2 at that point, so I'm waiting to see what that's like first.

if you ever did do that it would be fun to do some high level emulation, like filtering the audio better than it originally was. I love high level emulation, it's more applicable to 3D systems where you can raise the resolution, NullDC's "extra geometry" feature, etc. but there are still some intriguing possibilities with the SNES and other old systems.

[h4tred]

Just for the record, you or anyone else who is willing to maintain open dialogue with me are welcome to have the source (if you agree not to fork it; approved ports on the other hand are fine if you work with me). Same policy I keep with Temper - a few people have asked and have received really easily. No problems with anyone forking it yet :>

Nice

I checked your code out, quite nice. I was hoping of doing a dedicated Win32 port, instead of what looks like a SDL one currently. None of this MFC stuff. Plus, with your permission, I was hoping of also doing some shader work for filtering if that fits your goals of the code being clean. (since to be honest, I am primarily a graphics programming person. I'm not that much into sound stuff though, so my DSound knowledge can be very rusty sometimes....)

Maybe UPS patching support might also be a possibility?

It'd be nice if one day I bothered to get a flashcart so I could do some timing tests and various other things. No$'s documentation is great but it leaves out some details like exactly how the prefetch buffer affects timing.

That would be cool, to say the least

As for MESS.... Fuck 'em as long as they have Cowering supporting/working on it.

and don't get me started on MAME/MESSDev's philosophies....I really don't want another of those arguments. I'm sure Exophase knows what I'm talking about in regards to that >.<

In fact my only idea at the moment was to make a fast SNES emulator with my current knowledge of what is and is not necessary, using hacks for the obscure games to get 100% compatibility whilst keeping requirements at ~800MHz tops.

Kind of sounds like ZSNESv2 at that point, so I'm waiting to see what that's like first.

sounds kewl, and for the people wanting to play those obscure games, BSNES is more than enough.

[Thristian]

it would be fun to do some high level emulation, like filtering the audio better than it originally was. I love high level emulation, it's more applicable to 3D systems where you can raise the resolution, NullDC's "extra geometry" feature, etc. but there are still some intriguing possibilities with the SNES and other old systems.

High-res texture replacement? Yes, please!

[ShadowFX]

Given I won't ever be able to retire, in the off chance I made another emulator, it wouldn't aim for anywhere near the same level of precision.

Of course you are free to do whatever you see fit, but in my opinion it would be quite a shame if you'd throw away the idea to aim for a more accurate approach. I know this approach comes with a high price but on the other hand, there are lots of other higher level emulation projects out there already.

Like I said, it's just my opinion and I am already happy what's available here and there. A side note, I'm still hoping for a lower level N64 emulator (Core, GPU, SPU etc.) one day (kind of what pSX is for PS1).

[Nach]

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 ).

I don't remember such a thing. In fact I remember stating it has one of the best structured designs I've ever seen in an emulator.

My only complaints with it that some of its structure can only be rated A instead of A+.


I'd also like to see some new techniques used in emulation. Original ideas, or ideas that are hard to implement. I'd love if someone can come up with a brand new idea on how to handle concurrency. Anyone see Itanium's EPIC design? Sure it's a joke, and to really take advantage of it, you'd need to have an insanely smart compiler. But on the other hand, it sounds like it'd make a fantastic design to run emulators. If we could somehow design an EPIC layer for emulation on top of today's home multi core CPUs, we'd have a great framework for emulating hungrier systems. I'm thinking for it to work though, we'd need a custom OS

[Exophase]

I'd also like to see some new techniques used in emulation. Original ideas, or ideas that are hard to implement. I'd love if someone can come up with a brand new idea on how to handle concurrency. Anyone see Itanium's EPIC design? Sure it's a joke, and to really take advantage of it, you'd need to have an insanely smart compiler. But on the other hand, it sounds like it'd make a fantastic design to run emulators. If we could somehow design an EPIC layer for emulation on top of today's home multi core CPUs, we'd have a great framework for emulating hungrier systems. I'm thinking for it to work though, we'd need a custom OS

VLIW and multi-core are extremely different things, there's no way you could have a layer for one on top of the other. Actually, VLIWs basically just remove a lot of the work that modern CPUs do in hardware and put the burden on the compiler. EPIC is far from the only game in town, TI's relatively cheap line of C6x DSPs are 8-way VLIW and have been out for years. But its features are still as much ways of mitigating things out of hardware (to make room for a wider design) as they are useful in their own right.

I think that the best thing that people can do in improving issues with concurrency is focusing on CPU emulators (including recompilers, of course) that are good at determining instruction sequences that can be executed atomically. This could include memory partitioning that is capable of determining regions of memory that are local to each processor, and quickly trapping locations that are shared (to invoke synchronization) based on various rules.

Something that could help improve emulation is some assistance, either from OSs or from circumventing OSs, and possibly from CPUs, in providing quicker access to trapped sequences. With the advent of virtualization features in CPUs I imagine this has already become more of a reality. What we need are traps that go directly to our own handlers, make it quick to determine exactly what access has occured (so partial decoding into registers would be very useful, or even instructions that help you emulate the trapped instructions), let you quickly get back to the code, etc. Ideally it'd even be possible to not change CPU mode; at worst this could be about as costly as a mispredicted branch and not much more. Finer grained trapping capability could also be useful (something < 4KB pages that we have now), or even methods to trap directly into custom handlers based on location, via table.

[Nach]

I'd also like to see some new techniques used in emulation. Original ideas, or ideas that are hard to implement. I'd love if someone can come up with a brand new idea on how to handle concurrency. Anyone see Itanium's EPIC design? Sure it's a joke, and to really take advantage of it, you'd need to have an insanely smart compiler. But on the other hand, it sounds like it'd make a fantastic design to run emulators. If we could somehow design an EPIC layer for emulation on top of today's home multi core CPUs, we'd have a great framework for emulating hungrier systems. I'm thinking for it to work though, we'd need a custom OS

VLIW and multi-core are extremely different things, there's no way you could have a layer for one on top of the other. Actually, VLIWs basically just remove a lot of the work that modern CPUs do in hardware and put the burden on the compiler. EPIC is far from the only game in town, TI's relatively cheap line of C6x DSPs are 8-way VLIW and have been out for years. But its features are still as much ways of mitigating things out of hardware (to make room for a wider design) as they are useful in their own right.

I beg to differ. Imagine the so called 'compiler' running alongside the code to be executed, or an interpreter above it, and each long instruction is either broken into two for two cores, or two incoming instructions are combined for a long instruction for the underlying CPU.

I think it's quite doable if we have access to lower level components in the process.

Something that could help improve emulation is some assistance, either from OSs or from circumventing OSs, and possibly from CPUs, in providing quicker access to trapped sequences. With the advent of virtualization features in CPUs I imagine this has already become more of a reality. What we need are traps that go directly to our own handlers, make it quick to determine exactly what access has occured (so partial decoding into registers would be very useful, or even instructions that help you emulate the trapped instructions), let you quickly get back to the code, etc. Ideally it'd even be possible to not change CPU mode; at worst this could be about as costly as a mispredicted branch and not much more. Finer grained trapping capability could also be useful (something < 4KB pages that we have now), or even methods to trap directly into custom handlers based on location, via table.

Using virtualization features isn't a bad idea, although I think it would be less useful when the running VM is a radically different design.

[Exophase]

I beg to differ. Imagine the so called 'compiler' running alongside the code to be executed, or an interpreter above it, and each long instruction is either broken into two for two cores, or two incoming instructions are combined for a long instruction for the underlying CPU.

I think it's quite doable if we have access to lower level components in the process.

You cannot maintain instruction level synchronization over multiple cores. If you could do this then there wouldn't be a push towards multithreading at all - it would be possible to convert single threaded executables to be ran on multiple cores. Dependency chains usually don't let you get more than a few instructions apart and multi-core CPUs aren't design to be in lock step with each other (there are far too many unpredictable stalls that can occur that will throw them off).

Also, the cores don't share context like a single VLIW processor does. Without being able to communicate at the register level you won't be able to get very far, and doing it over L2 cache is much slower.

But even if you could do this, why is would writing VLIW code be advantageous for emulation?

Using virtualization features isn't a bad idea, although I think it would be less useful when the running VM is a radically different design.

That's why I'm only citing particular features rather than an entire VM architecture, but CPUs really have been moving in this direction. Look at Jazelle-RCT on ARM, which implements a few features that are aimed for recompiled code. Certain virtualization features fit this mold as well.

[Nach]

I beg to differ. Imagine the so called 'compiler' running alongside the code to be executed, or an interpreter above it, and each long instruction is either broken into two for two cores, or two incoming instructions are combined for a long instruction for the underlying CPU.

I think it's quite doable if we have access to lower level components in the process.

You cannot maintain instruction level synchronization over multiple cores. If you could do this then there wouldn't be a push towards multithreading at all

I'm pretty sure you can do this.

it would be possible to convert single threaded executables to be ran on multiple cores.

You can't convert them because you can't magically determine what can be concurrent and what needs to be atomic. And in the case of a normal app, many of them aren't advantageous to run anything concurrently when every single step requires the step before it.

Emulation on the other hand is vastly different where we do have multiple components that are already concurrent on the base system, and we want to bring that concurrency to our processors in emulation.

Dependency chains usually don't let you get more than a few instructions apart and multi-core CPUs aren't design to be in lock step with each other (there are far too many unpredictable stalls that can occur that will throw them off).

Which is fine.

Also, the cores don't share context like a single VLIW processor does. Without being able to communicate at the register level you won't be able to get very far, and doing it over L2 cache is much slower.

Yet our CPUs are faster than the ones we're trying to emulate.

But even if you could do this, why is would writing VLIW code be advantageous for emulation?

I never said we should write VLIW code.
We should have a system to run emulation in a VLIW-like manner. As it allows concurrency of the multiple CPUs we need to emulate at once.

[Exophase]

I'm pretty sure you can do this.

Explain how. Instructions take unpredictable amounts of time. A stall, such as a branch mispredict, cache miss, etc won't stall the other cores like they would in execution units on a VLIW.

You can't convert them because you can't magically determine what can be concurrent and what needs to be atomic. And in the case of a normal app, many of them aren't advantageous to run anything concurrently when every single step requires the step before it.

Emulation on the other hand is vastly different where we do have multiple components that are already concurrent on the base system, and we want to bring that concurrency to our processors in emulation.

So for the emulated code you can magically determine what is concurrent and what can be ran atomically? It doesn't matter if the degree is less, either you can or you can't. And if you were looking at VLIW code

Which is fine.

Fine how? Once you lose synchronization you are no longer running things in a "VLIW like" kind of way, and you lose any ability to maintain concurrency...

Yet our CPUs are faster than the ones we're trying to emulate.

What are we trying to emulate exactly? Eh, it's moot anyway. We could argue what is and isn't "faster enough" for some technique, but instead it's more straightforward to compare it to other techniques. And I don't think trying to keep constant lock-step synchronization over L2 cache is going to be a better expenditure of resources than going for less fine grained synchronization where possible...

I never said we should write VLIW code.
We should have a system to run emulation in a VLIW-like manner. As it allows concurrency of the multiple CPUs we need to emulate at once.

I'm sorry but I actually have no good idea what you're saying, because you're being incredibly vague. Do you really have a clear cut approach that demonstrates the viability of what you're talking about? I don't see how "VLIW-like" "allows concurrency", and I don't see how you get from "VLIW-like" to multicore...

[byuu]

Emulation on the other hand is vastly different where we do have multiple components that are already concurrent on the base system, and we want to bring that concurrency to our processors in emulation.

Nemesis is the closest person I know to pulling this off. Operating systems aren't there yet -- mutexes are too painful. At best, you can step two threads on a dual core that do nothing but increment a counter and wait, ~800k times a second on an E4500.

Our processors really aren't there yet, either. We have at best quad core, which probably isn't enough for the SNES, let alone something like the Saturn. Many chips would have to share a core. Thus, syncs between them would require a full kernel-level context switch.

There's also the down-side of requiring a quad-core or better for older systems. People wouldn't find that acceptable for anything short of a PS2+. Not that I'd personally care if it let me emulate things at a lower level.

As far as I can see, the best technique will be using mutexes that do not require kernel functionality. Processor opcodes similar to the Interlocked* wrappers that can atomically add/subtract/read/modify variables even if other threads are trying, with no performance hit. The above should be able to happen at least 200 million times a second, minimum.

Simply raise a flag lock when one processor is about to do something that might affect another, if it is currently ahead. Clear the flag as soon as the other processor catches up. That would be WaitForSingleObject + ReleaseMutex, which eats up far too much time to be useful now, even when emulating ~21MHz processors.

Example:

Code: Select all

int64_t counter = 0;

void processor_a() { while(true) {
  if(exec_will_affect_processor_b()) {
    while(atomic_read(counter) >= 0);  //DO NOT SLEEP NOW
  }
  atomic_add(counter, exec_a() * PROCB_CLOCKS_PER_SEC);
}}

void processor_b() { while(true) {
  if(exec_will_affect_processor_a()) {
    while(atomic_read(counter) < 0);  //sleep between emulated frames instead
  }
  atomic_sub(counter, exec_b() * PROCA_CLOCKS_PER_SEC);
}}

//no need for * PROCN_CLOCKS_PER_SEC if PROCA_CPS == PROCB_CPS

Exophase, you seem to be pushing the idea of using more advanced techniques / heuristics to avoid synchronizing wherever possible. It's a novel ideal; but very, very complex and error-prone. I would limit it to surface-level stuff:

Eg sync CPU to SMP if CPU accesses $2140-217f SMP register space. Sync SMP to CPU if SMP accesses $f4-f7 register space. Sync SMP and DSP on each non-I/O tick because the two share 64k SRAM.

Of course that hits on our typical disagreement on optimization vs code simplicity. Your technique would be faster overall, but would waste so much time that could be spent improving emulation instead.

[h4tred]

Of course that hits on our typical disagreement on optimization vs code simplicity. Your technique would be faster overall, but would waste so much time that could be spent improving emulation instead.

Which opens up the possibility of even more cans of worms. I'm just gonna leave it at that, since we know the debate of optimization vs code simplicity will go on all day if we got into that.

My only complaints with it that some of its structure can only be rated A instead of A+.

Hence you had some objections to it.

[blargg]

I never said we should write VLIW code.
We should have a system to run emulation in a VLIW-like manner. As it allows concurrency of the multiple CPUs we need to emulate at once.

I'm sorry but I actually have no good idea what you're saying, because you're being incredibly vague. Do you really have a clear cut approach that demonstrates the viability of what you're talking about? I don't see how "VLIW-like" "allows concurrency", and I don't see how you get from "VLIW-like" to multicore...

Scale VLIW up to an extreme and you have a multi-core processor.

Nach's point was perhaps to break an emulation task into separate calculations which can be carried out independently, in any order, with possibly regular calculations between which depend on all the results.

[Nach]

I'm pretty sure you can do this.

Explain how. Instructions take unpredictable amounts of time. A stall, such as a branch mispredict, cache miss, etc won't stall the other cores like they would in execution units on a VLIW.

Our own instruction set is predictable, what is going on underneath is irrelevant as long as we can sync it later when needed, and we don't have too much overhead to slow it down.

You can't convert them because you can't magically determine what can be concurrent and what needs to be atomic. And in the case of a normal app, many of them aren't advantageous to run anything concurrently when every single step requires the step before it.

Emulation on the other hand is vastly different where we do have multiple components that are already concurrent on the base system, and we want to bring that concurrency to our processors in emulation.

So for the emulated code you can magically determine what is concurrent and what can be ran atomically?

The very nature of multiple processing units is concurrent. Did you possibly think for a moment that when your Gameboy outputs sound, the screen goes blank?
All our systems have concurrent operations to a degree, especially when there is any kind of I/O involved. Yet we switch back and forth between emulating all these, and quite often in the process screw up.

Since we're already making dynamic recompilers for systems, we're already analyzing the code as we run it, and generally using JIT and other techniques. If we looked at the larger picture, and actually used code optimization techniques, we'd already be doing much better. Imagine a proper framework to actually take a system and merge its independent units together, and only force sync them (semaphores?) when the compiler deems necessary. If you think it sounds a bit nuts, just look at what LLVM is doing. We need that kind of stuff done for emulators.

Which is fine.

Fine how? Once you lose synchronization you are no longer running things in a "VLIW like" kind of way, and you lose any ability to maintain concurrency...

We don't need to synchronize the underlying cores, we need to synchronize "our instruction set".

Do you really have a clear cut approach that demonstrates the viability of what you're talking about?

If I was able to demonstrate would I have said:

If we could somehow design an EPIC layer for emulation on top of today's home multi core CPUs, we'd have a great framework for emulating hungrier systems.

Nach's point was perhaps to break an emulation task into separate calculations which can be carried out independently, in any order, with possibly regular calculations between which depend on all the results.

That is exactly how the compiler for EPIC is supposed to work. However practically, they found it too hard to actually make the compiler analyze all the code to that extent in advance. I would think run time optimization of that level might actually work though, since we'd have more of an insight into what is going on. For the Itanium though, making all native programs have to be interpreted by the compiler as they run seems ridiculous. But we're already doing that for emulation, and in our case, it's already inherently parallel, making it much easier on the compiler.

[Deathlike2]

it would be fun to do some high level emulation, like filtering the audio better than it originally was. I love high level emulation, it's more applicable to 3D systems where you can raise the resolution, NullDC's "extra geometry" feature, etc. but there are still some intriguing possibilities with the SNES and other old systems.

High-res texture replacement? Yes, please!

Just not on the SNES at the very least.

[kode54]

it would be fun to do some high level emulation, like filtering the audio better than it originally was. I love high level emulation, it's more applicable to 3D systems where you can raise the resolution, NullDC's "extra geometry" feature, etc. but there are still some intriguing possibilities with the SNES and other old systems.

High-res texture replacement? Yes, please!

Just not on the SNES at the very least.

Tile compare/replace may be possible. Although it would probably have to employ dithering of the original color palette, or else it would require replacements for every palette combination the game uses.

[Gil_Hamilton]

Do work on the Vectrex, where fancy image cheating actually results in a more realistic emulator.

The state of vector display emulation is sad. The state of Vectrex emulation is even sadder.

[h4tred]

Do work on the Vectrex, where fancy image cheating actually results in a more realistic emulator.

That sounds quite fun: a practical use for my graphics programming skills.

The state of vector display emulation is sad. The state of Vectrex emulation is even sadder.

Might as well start collecting documents on this.....