Since the CPU is emulated by an FPGA, FDD is emulated, then why not save all the money and just use a software emulator?
It’s not harder to do in software. It’s just hard to get the timing correct, regardless of whether you are using software or hardware. There are certain cases where it’s hard to get good performance out of a software emulator, that’s really the main difference.
You will have problems running BSNES on a Raspberry Pi, though, although I've heard the RPi 4 can do it.
I'd also like to think that it's more efficient, since at least in theory it could be (cutting down on all the extremely superfluous software overhead for the task), but sadly I don't actually know how common FPGAs really perform in that specific case against reasonably efficient modern CPUs.
But if you want actually correct timings in the real world, i.e. to wall clock, a modern software environment will make it harder for you in practice. If you don't have an OS with any real-time capabilities, that's your first problem: You have no (good) guarantee when and for how long your threads are scheduled, how long allocation and system calls will take and block you, and generally whether you can reliably meet any of your deadlines.
On Linux with VICE, I would not be shocked at all if I occasionally observed VICE stuttering for a millisecond.
With baremetal (or an OS with sufficient real-time capabilities), you can make your deadlines meet with some care. You will still have some (possibly negligible) amount of jitter: Superscalar CPUs and caches are just some of the culprits.
Does the jitter, or even the lack of deadline guarantees on plain Linux with VICE, matter in practice? Maybe not. With a fast enough machine you might not notice at all. Is it easier, and to some extent more efficient, to just sidestep those issue with an FPGA implementation that is guaranteed accurate to wall clock (not just emulated clock)? Probably. Comes at the cost of having FPGAs, though. On the other hand, a real NTSC/PAL output is going to be pretty real indeed!
As said, not that simple. How hardcore you are on your wall clock accuracy requirements probably depends on how much of a "preservationist" you are.
I am disagreeing with this.
I'm not trying to be clever here to win an argument, I really just think that good relative timing is implied by "accuracy", and good wall-clock timing is not--that's "performance". It makes sense to me that these terms are separate, so I can say something like "I have a cycle-accurate emulator that runs at 25x realtime".
For stuff like game systems, you generally don't need a ton of wall-clock accuracy anyway. You're going to be plugged into some kind of LCD panel, and you just need to make sure that it gets fed with the correct data every 16 ms or whatever the correct update rate is. The fact that your input controller isn't getting probed at the exact right time relative to the screen update is kind of a non-issue.
As for how much wall-clock accuracy you need... Eh, as said, it depends on how much of a preservationist you are. If you plan to actually generate an NTSC or PAL signal on a low level (including actually performing the quadrature amplitude modulation), it can well become relevant, and phase noise affects color.
Otherwise maybe not, though again I'm not surprised if some standard Linux on some RPi actually shows visible glitches from time to time. Irrelevant for most users, but then again most users may also just want to play the game on a rudimentary emulator, or even a more modern version of the game. This is all either for fun or for preservation, after all.
If you do need (video signal) or want (anal retentiveness) high wall-clock accuracy, an FPGA then also has the advantage that whatever ARM core or whatever you have next to it can implement UI and control in whatever is most convenient, on any non-RT run of the mill OS, without any risk to negatively affect the rock-solid, cycle-locked emulation in the FPGA. On an overall weaker overall SoC at lower frequency, even.
An FPGA does make things easier, is my point.
Emulation in software (and the virtual space in general), on the other hand, is close to perfect these days. In fact, material things get boring pretty fast (and tend to end up in the attic) whereas virtual reality (like games) remain a source of perpetual joy.
A replicate but with new board and new chips for buyers to solder their own hardware would be really interesting and educational.
On the other side, I already have some retro hardware collecting dust so tonight I'm going to get one out to play CD music I just bought. Only vintage laptops have CD players installed.
Extending your thought, what if the journey of building/acquiring/configuring the meatspace thing was also emulated?
Also, software emulation on a non-real-time OS such as Windows, macOS or Linux can result in lag when the OS is busy with other things. You never get that on FPGA simulation.
It’s all emulation—either in hardware or software, in parallel or in series.
I used to work on simulation software professionally. The idea that simulation is parallel while emulation is serial is completely foreign to me, and I suspect foreign to others as well.
There's no formal distinction between the two, but conventionally emulation is more faithful whereas simulation is more high-level. Still, the two are used fairly interchangeably.
Both terms are a little arbitrary, but logic on an FPGA is not a simulation, for most definitions of "simulation." Perhaps more accurate than either term is "implementation," since it is an honest-to-God implementation in a digital circuit of the logic.
Think of it this way: software tells a computer what to do, gateware tells an FPGA what to be.