Emulation catch-all

So with another hour or two of testing: I tried moving to 1080p internal res, and Super Paper Mario showed some trouble early on in Exclusive mode in OpenGL. (garbled sound, like the emulator wasn't quite keeping up.) Switching to Hybrid mode fixed it right up, and it runs gorgeously smoothly.

I can't believe I never tried upscaling in Dolphin before. Things look so much better. I always just ran at native res out of some idea of being faithful to the original. Man, that was dumb. Both Super Paper Mario and the earlier title, The Thousand Year Door, run flawlessly at 1080p; they even upscale their text and everything. Both play beautifully, and look so damn good, way better than the original console ever did.

I used to see hitching when TYD did the 'paper rollup' transition between scenes, and the elevator rides in SPM were usually hitchy. That improved a lot when I moved from the 2600K to the 4690K, but the hitching/garbling was still there a little. In Hybrid ubershader mode, the games are absolutely flawless, at least to my eyes. It's exactly like running the games on real hardware, except at much, much higher resolution.

This is a HUGE improvement, probably the biggest I remember in Dolphin.

I've always just used MameUI, which is a reasonable front end on the base binary. It's more or less a plugin into the main source tree, making a single unified program.

From a blurb at the bottom of the page, it looks like it may not be perfectly synced with the main releases, though. They make it sound like it's often slightly newer, and with the way the MAME team constantly adjusts ROM formats, that could give you some (probably minor) hassles.

I believe that IV/Play, on the same page, is a more traditional front end, in that it drives the console version for you. That should prevent the possible slight version mismatches, but I imagine won't be as nicely integrated. MAMEUI has its tentacles pretty deep into the MAME source code, where IV/Play would just be driving it from outside.

I hadn't heard about that; the mamedev file is 1.88, and so is MAMEUI, so if it's been discontinued, it's very recent.

MAME does have some kind of other UI now, although I haven't really used it.

It looks like that's using FPGAs, Field Programmable Gate Arrays.

As I understand it, this means that the chip has a dense grid of hundreds of thousands to millions of components. And, critically, each component can be changed, into one of several different types. This allows designers to build custom hardware circuits to accomplish particular tasks; in essence they're making a single-purpose chip. There are libraries available for different FPGA types, for instance, implementing a range of different processors; I'm aware of a Motorola 68060 emulator on FPGA, one that's vastly faster than any real chip that was ever shipped. (the Vampire V2 accelerator for the Amiga uses this, for instance, giving physical Amiga computers plugin CPU replacement boards that run about fifty times faster than any real 68K Amiga that ever shipped, while also offering a ton of very fast RAM and even HDMI output for some graphic modes.)

And because the components can be remapped into new configurations, sometimes even on the fly, you can "download" new components onto your FPGA. There's an FPGA Amiga emulator that can also be an Atari ST, for example.

However, just because it's an FPGA doesn't mean it's correct. Implementation quality can vary. For instance, there's an FPGA C64 emulator, but the SID implementation apparently isn't all that great, yet. It may look the same to the virtual 6502, but doesn't produce sound that's quite right compared to the original chips. It's being worked on, and the nature of FPGA boards means that improving the circuit is easy and free. However, it's much harder to write and debug an FPGA chip implementation than to emulate it in software. Once it's working, at least theoretically it can be very near zero latency, almost exactly like the original machines were. But getting it working takes a lot more effort than traditional software approaches.

The next step after an FPGA is an actual custom chip, an ASIC. But fabbing an actual 6502 or an actual SID chip would be ferociously expensive, because the tooling to do so costs a damn mint. It might cost hundreds of thousands or even millions of dollars to start production on new 6502s, and the market just isn't big enough to support the necessary volume.

So, they implement it in FPGA instead. It's quite wasteful in terms of power budget compared to ASICs, and the per-chip cost is very high (FPGAs are pricey), but they get almost the same performance and operational characteristics, and can support small-volume operations like emulation.

They can buy FPGAs in tens to hundreds, and sell them for $200 each or whatever. With an ASIC, they could sell them for $25 each, but they'd need to move like a million units to make back the tooling costs.