Analogue 3D

That is only true as the speed of the system performing the emulation approaches infinity ;-)

Yes, you can do all the same things in software, in fact it is trivial, just take the same output from you EDA tools and run it in a simulator. Of course that is so slow it cannot interface with (most) real external HW like CRTs and accessories, but in some technical sense it is software taking the exact same set of inputs as an FPGA, and generating the exact same outputs (just much, much slower).

If we accept that as the premise then then we can consider emulators an optimization where instead of using the simulated verilog we try to manually write code that performs equivalent operations, but can run fast enough to hit the original timing constraints of the HW we are replacing. The thing is that the code is constrained by the limits of the modern HW it is running on, and sometimes the modern HW just cannot do what legacy HW did.

An NES does not have a frame buffer (it does not even have enough ram to hold ~5% of a rendered frame of its output!). To cope with that the games generate their output line by line as that the video signal is being generated. What that means is that you click a button on the controller it can change the output of the scanline that is currently writing to the screen (and you can release it updating the output before the frame is being generated, changing subsequent lines). IOW, the input latency is less than a single frame of input. That is not true with modern computers where we render into a memory mapped frame buffer which is then transmitted to the screen with a complex series of of chips including the GPU and DC, and ultimately synchronized on the blanking intervals.

On an FPGA you can design a display pipeline that matches that of legacy consoles, and get the same latency. Of course you could also do the same thing in software emulation on a computer if you clock it so high that it renders and outputs one frame of video for each scanline of output on the original, but given the NES had a framerate of ~60 (59.94) fps and vertical resolution of 240p that comes out to a framerate of ~14,400 fps to hit the latency target for accurate emulation.

Now in practice most of the time it is a non-issue and emulation is more than sufficient, but some old games do very funky things to exploit whatever they could on the limited HW they run on.

It is also worth noting that FPGAs are a lot more interesting for older systems. Once you get to more modern systems that look more like modern computers the strict timing becomes less important. In particular, once you get to consoles that have frame buffers the timing becomes much less sensitive because the frame buffer acts as a huge synchronization point where you can absorb and hide a lot of timing mismatches.

Regardless of framebuffering and all that nonsense, at the end of the day, pixels have to be pushed onto the physical display, bit-by-bit. I've wondered if it would be possible for a screen to simulate CRT-style line drawing by exploiting that.

So, if the multiplexing is done line-by-line, for example, then one could simulate a CRT by driving the pixels directly, without a framebuffer. It wouldn't be easy, but that's partly why framebuffers are a thing - they're easier than not having one.

I get it though it just "feels" more real than running a piece of software, and it's cool to be able to play original cartridges and use original peripherals. But indeed, in the end it is a form of emulation, and even if someone is able to re-create the original hardware 1:1 including all the undocumented/buggy/unexpected behavior, I'll leave it open if people actually want that. A lot of us want modern amenities: HDMI/Upscaled output, Save States, better controller support, the ability to play ROM files instead of just the original systems, etc. Oh, and HD texture packs would be nice as well. Netplay over the Internet even for games that only have local multiplayer! Oh, and there's Achievements as well. Light Guns still won't work though.

I'm "guilty" of that myself: I ordered the Duo because I really want a PC Engine system, even though Mesen is a perfectly fine emulator and I probably don't want to play my original HuCards anyway out of fear to eventually break them.

I think the N64 might be in a bit unique situation because all the emulators for it are kinda crap, which is why I was surprised to see an announcement of an FPGA version. But I also saw a breakthrough recently in the MiSTer project, so I guess it's finally time - and if they really managed to re-create the Silicon Graphics GPU, I'm impressed, because even though it's 25 years old, a 3D Graphics Chip is still quite a feat.

One thing that FPGAs can potentially do better is to emulate the entire system without needing a crazy PC. Stuff like "A memory fetch takes two clock cycles, but actually, the first clock cycle leaves garbage on the bus, and if a Sound DMA triggers, it will fetch that garbage, and that is actually required for Game X to work well". (There was a GameBoy Advance emulator that found something among those lines being the reason why one of the Pokemon games doesn't work properly in an emulator. And I remember there being one SNES helicopter game where the shadow under the helicopter never showed up in emulators of the time, because it used some crazy exact timing to render it on original hardware).

Doing a cycle-exact simulation of an entire system is pretty hard (All the "How to write an emulator" tutorials just do a big switch statement of CPU opcodes and call it a day), and it's harder the more advanced the system gets. So an FPGA still has the _potential_ to be a better implementation overall, but it's always going to be that system that's "Accurate except where people want anachronism" but always limited in what kind of additional enhancements it can make (HD Texture Packs, CRT Filters, Retro Achievements, Local Multiplayer over the Internet, with matchmaking)

I’m the clone scene FPGA is synonymous with quality and accuracy, regardless of whether that’s true or not.

> That said, the software ecosystem side of these devices feels like a near total disaster; I think it's a combination of legal concerns around copyright for ROMs, and the company's DNA. The amount of work to play, say Zelda on an Analogue Pocket, is akin to jailbreaking an Android phone, circa 2013. Lots of sdcard downloads, firmware checks, custom software tools, arcane paths through the OS software. I think they could afford to make a cleaner and easier software path.

Huh what? That's absolutely not true. I just went to https://github.com/spiritualized1997/openFPGA-GB-GBC and followed the instructions: All you have to do is copying files onto a microSD card. Custom tools are not needed. You can skip firmware checks (wcgw).

All my Gameboy ROMs play without any issues so far. Yes, you have to pay attention to put the files in the correct directories, but I wouldn't call that a "disaster".