"FPGA is emulation"
You can have any number of issues with Mister, but this is just flat out incorrect if you know the definition of either of those words.
You can have any number of issues with Mister, but this is just flat out incorrect if you know the definition of either of those words.
It's a well-written article, and presents a balanced view. Its stance is against the idea that FPGA-based emulation is always better than CPU-based emulation.
The Mister SNES core has less accuracy like the software emulator bsnes, not all game work or there a bugs - they still "emulate" the hardware how they interpret it.
FPGA is just a different way of "hardware emulation" instead of traditional "software emulators".
The only real advantage of FPGA compared to software is the improved latency.
CPU based emulation will require a fairly powerful CPU just to emulate SNES. It's pretty expensive to emulate hardware in 180-190 ns increments.
At 13:43, he demonstrates a couple of snes games with effects that don't work well in software emulation (along with what the effects / game mechanics should be on original hardware). At 22:25 he shows these same games running on FPGAs (analogue pocket, mister) and behaving correctly, just like on original hardware.
As an aside, if this isn't the one you were referring to, it's still an awesome video by an amazing creator; I'm a big fan of this stuff after discovering it on accident. He gives a nice introduction to FPGAs in this same video.
An emulator accelerated by an FPGA is still an emulator and a CPU simulating a console at the circuit level is no different in accuracy than an FPGA doing the same thing.
The main difference is the experience, where the FPGA can offer an experience closer to the original than a CPU running an operating system can, especially for older consoles. Not because of a difference in emulation accuracy, but because the user experience is different.
If I have a black box chip that takes in 3 bits and spits out 3 based on the input. If I make a bit perfect implement of it, but my chip has additional outputs that correspond to unused input, hence never used. Is it still considered emulation? It differs minimally in a negligible manner.
Let's put that to the test, ok
https://www.merriam-webster.com/dictionary/emulate
1a: "to imitate by means of an emulator"
https://www.merriam-webster.com/dictionary/emulator
2: "hardware or software that permits programs written for one computer to be run on another computer"
Yup, FPGA recreating other hardware definitely fits the bill of emulation. Granted, Analogue has played up a marketing spin that boxes in "emulation" to mean "software running on some generic CPU" in order to claim "no emulation", but it's just marketing doing the work of marketing.
It really doesn't. The FPGA actually implements the target hardware, rather than using other hardware to produce equivalent behavior.
That's not to say that no emulation is involved, as not all of the functionality is actually achieved through the FPGA, but where it is, it's perfectly valid to distinguish it from emulation.
Even the original hardware “emulates” a game if you want to get down to it.
The FPGA is actually implementing the hardware. It's like using a newly manufactured edition of the original.
I think “emulation” fits as a reasonable description of this, personally - at least as something an average person will understand.
If it weren't emulation, they would decap the original chip and directly copy the chip, gate-by-gate. It could be done, but it hasn't been done that way anywhere to date.
That's what "implementing the target hardware" in an FPGA would consist of.
Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs - certainly not the cheap FPGAs MISTer and friends use.
I don't think anyone was doing that when iterating on the hardware back in the day, either. Dollars to donuts, the 65C02 was not based on a deep empirical analysis of the behavior of as-implemented 6502s, but was rather produced from modifications to the design spec that the original 6502 was itself implemented from, with the intent of maintaining compatibility with the original design.
Same thing here. An FPGA implementation of the original schematics of the hardware can be viewed as another instance of variant hardware built against the original design, whereas software emulation is simulating the outward behavior of the original hardware without any ability to be implemented directly from the original design at all.
> Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs
Which returns us to the original description of these solutions being mostly hardware implementation via FPGA, but not entirely, as some emulation is still needed.
FPGAs aren't magically more accurate. That is only up to the programmer and what effort they put in.
The main difference is efficiency and parallelism : it's much easier to reliably produce cycle-accurate parallel outputs in real time with an FPGA, compared to software running on a multi-tasking OS with many layers of abstraction and no deterministic real-time guarantees.
But, as a single-core processor can fake multitasking, by slicing time between processes (preemptive multitasking), software emulation can mimic parallelism if the host is beefy enough compared to the old school system it's emulating. The larger the performance / clock speed gap between the host and target, the more indistinguishable from a truly parallel FPGA an emulator can be.
Software emulation also has practical advantages for developers : while FPGAs force you to painstakingly implement every bit of functionality at the logic gate level, with software you can start off with a much higher level model of the target system that's much easier to implement, and mix & match that with more precise low level simulation where it matters. The time this frees up (+ the availability of various libraries) allows the developer to spend more time researching the original system and adding modern quality of life features that just wouldn't be possible otherwise.
Great article on the topic : https://archive.is/fWosI
If you combine Wine with Rosetta to run Windows programs on an M1 Mac, then it is definitely emulation by any definition. But then it's not Wine that's doing the emulation, it's Rosetta.