SNES emulation question.

[I.S.T.]

How are the SA-1/Super FX/SFX2 chips emulated right now?

[Gil_Hamilton]

Poorly?

[grinvader]

The length of a proper answer for that question would be stupidly long, so I'm gonna do as you did and sum up in one line:
Read the source(s).

You'll have to elaborate a bit on your question if you want us to answer in any other manner.

[I.S.T.]

*asks slightly different question*

Are they emulated in the same way ZSNES and snes9x emulate the SNES or like the DSP chips?

to quote Nach:

Our DSP emulation is also fundamentally broken in that we don't emulate the hardware at all, we just try to replicate the firmware functionality wise.

[grinvader]

SA1's mostly like the base 5a22, so we have the same 'lack of delay' for its mul and div.

SFX... does lots of math stuff. We probably do them too fast as well.

[I.S.T.]

SA1's mostly like the base 5a22, so we have the same 'lack of delay' for its mul and div.

SFX... does lots of math stuff. We probably do them too fast as well.

Thanks for the info. I'd have been clearer the first time, but I'm in a brain fog 24/7 due to medication.

[byuu]

Are they emulated in the same way ZSNES and snes9x emulate the SNES or like the DSP chips?

No, they're different categories of chips. I'm bad with the official names for these types of things, so I'll make the names up, as well as over-simplify:

Imagine there being two kinds of processors: one kind is where you give it a program that you yourself write, and it executes it; another kind is where you give the processor data, and it runs its own internal program on that data.

Power Fact: the N64 RDP (RSP?) is an example of a hybrid CPU / DSP. It allows you to upload your own programs, and then have it act like a DSP. N64 emulators mostly emulate each individual program by itself, so that they get the speed benefits of DSP emulation; but some are now working on low-level emulation, as it's somewhat more precise, and handles all games, rather than ones specifically researched. This is kind of what we want to do with DSP-1 emulation: we want to get the program ROM and emulate that. But the problem is that nobody has been able to dump the program ROMs from these chips to date.

The S-CPU and S-SMP are examples of the former, let's just call them CPUs for simplicity. The S-DSP, S-PPU1 and P-PPU2 are examples of the latter, let's just call them DSPs for now. Again, my labels are probably not technically correct.

The DSP-1/2/3/4 are DSPs: you write 5 to a memory address that goes to the chip, then read another from it, and the value read back is arctan(5).

The SuperFX and SA-1 are CPUs: you point them to your software program and tell them to start executing that code. Your code is simple instructions like add, multiply, shift right, etc.

Developers use DSPs because they're usually faster and cheaper when they're performing dedicated, optimized, specific operations. They use CPUs when they need something more general purpose. This is why the "3D" SuperFX works so well with the 2D Super Mario World 2, for instance. It's very flexible by being programmable.

Emulating a DSP is much easier when you bypass its timing and just treat it like an oracle that can immediately compute the end results. However, reverse engineering a DSP is infinitely harder. This is why the SNES CPUs were emulated so quickly, the SNES DSP took so long, and the PPUs are still pretty lousy.

But for a CPU, you can't ignore timing. Thus, it's a lot harder to emulate; but since you can run your own code on it and easily examine the results, it's easier to reverse engineer how it works.

And to be more specific, both ZSNES and Snes9x emulate both the SuperFX and SA-1 by executing one opcode at a time, same as they do the main SNES CPU, which is more than adequate for these two chips.

We wouldn't even know how to emulate the SuperFX per-cycle, and the SFX is actually more complex than the SNES' CPU: it has instruction cache (pretend it's like 256 bytes of L1 cache), at least a two-stage pipeline (probably more), and all sorts of other stuff that I doubt anyone sane is going to emulate.

The SA-1 ... it's basically just a faster SNES CPU with some bitmap <> bitplane stuff, and a few other misc utilities like that. We should be able to directly extend a standard SNES CPU class to support it, however at the cycle level it will be unmaintainably slow using methods that I use.

It will require more thought toward optimizations if it's to be pulled off, with things like time shifting and rollbacks. I'm not convinced it's worth the effort for the paltry selection of SA-1 games available, especially when none seem to need it.

Would it be nice? Sure, but there are more important things to work on at the moment.

If you're going to ask why SuperFX games run too fast in emulation or something, I think a lot of that will go away with improvements to the main CPU timing that are forthcoming. You can sort of see that now with Snes9X now, it's speed for those games is pretty solid, but ZSNESv2 should do even better.

[I.S.T.]

Thanks for the info. I'm fairly educated in how CPUs and whatnot work for a non-programmer or EE guy. I had forgotten the SA-1 was more than just a higher clockspeed SNES cpu(For the life of me I can't remember the fucking name.).

I was going to ask if the SFX and SA-1 were opcode emulated, but I couldn't remember if that was the proper term. >.<

[mudlord]

Power Fact: the N64 RDP (RSP?) is an example of a hybrid CPU / DSP. It allows you to upload your own programs, and then have it act like a DSP. N64 emulators mostly emulate each individual program by itself, so that they get the speed benefits of DSP emulation; but some are now working on low-level emulation, as it's somewhat more precise, and handles all games, rather than ones specifically researched. This is kind of what we want to do with DSP-1 emulation: we want to get the program ROM and emulate that. But the problem is that nobody has been able to dump the program ROMs from these chips to date.

Correction: its the RSP that compiles the graphics/audio microcode