It is. I did a Sega system on an FPGA in 2003 as a one-semester senior design project. Using a modern HDL (bluespec, or something like the proprietary language my company uses internally) on current FPGAs, you could probably do a much higher level implementation in 1/10th that time.

An SNES would be much more annoying to do, but probably no more than an order of magnitude moreso, so I doubt it would take more than a semester, even for someone who'd never touched an FPGA before.

> I did a Sega system on an FPGA in 2003 as a one-semester senior design project.

The article was about achieving extremely high compatibility by emulating hardware quirks. What advantage would an FPGA be? Easier synchronization?

The hardware quirks, by and large (ignore things like the behavior of undocumented/unintentional instructions on the CPU -- these are a separate issue and easy to deal with), are due to the impedance mismatch you have of emulating hardware on software. When you're emulating old hardware on an FPGA, you don't worry about synchronization, you just have the cycle timing be a multiple of the original timing. This gives you "synchronization" in the same way the old hardware did -- these components are all running in parallel and pushing/pulling data at specific times, which happens implicitly in hardware.

FPGAs make this a complete non-issue. Of course, FPGAs bring in a whole host of issues when you want to make such a thing practical. One thing I've been considering for a long time is a super high-level HDL specifically for emulation like this, which can either be run on the CPU (slowly), synthesized for FPGAs, or burned into an ASIC. You could have a whole catalog of components and put them together just like building a real console.

FPGAs don't solve all the timing problems. In some cases, you have to accurately emulate the stalls that occur on one processor as computation or interrupts occur elsewhere.

Synchronization and timing issues are two different things, though, and synchronization is implicit if you get the timing right, unlike emulating hardware on software. The timing aspect of it is just a matter of properly emulating the behavior of the chip; not easy, but significantly easier to get right than synchronization in software.

But that said, FPGAs are by no means a silver bullet. There are a billion problems with them, mainly due to the terrible development tools, at least the ones that someone not doing this stuff professionally can afford.

I wonder if you could solve some of the issues by building each component in an FPGA and wiring up as appropriate to simulate the timing/sync better vs. emulating the entire system at once.

http://www.youtube.com/watch?v=onBmiHoOxGs

Replicate each component of the original SNES hardware? That has been somewhat done: you can buy hardware clones of the SNES in many stores.

The majority of the clones are using "NES On a Chip" or "SNES On a Chip" - they have the same issues as the original minimal requirements based emulators and are generally quite quirky.

Though it looks like at least one person is attempting to create a better one using FPGA: http://cegt201.bradley.edu/projgrad/proj2006/fpganes/

Yes, or replicate all of the original SNES hardware in one FPGA chip (and perhaps a few external passive components).

Citation needed, but pretty sure I heard of compatibility issus that the clones had.

As mentioned in other comments, some SNES cartridges themselves contain coprocessors and other hardware. A clone console doesn't need to do deal with this since you're still playing physical cartridges (versus pure software ROMs).

But clone systems do have issues with many games anyway...

I agree. Plus, I think if the goal is really to 'preserve history', making chips that replicate the original hardware is a lot better (and more accurate) way than trying to software emulate it.