Analogue 3D

So 3 backordered products launching in the next 2 months?

They're going to have a busy Christmas holiday..

I have a lot of familiarity with competitive controllers for Melee, and $500 is definitely the highest end of the field. At that point you're buying a made-to-order controller with a custom PCB, specially calibrated analog components, shell, and other bits of personalization. $40-$100 is about average for a "good" controller.

Where's the emulation? If you program an FPGA to reproduce a system, there's no emulation... you might have bugs but there are bugs in hardware too.

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.

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)

That's probably not even correct. Unless they've decapped the chip and reverse engineered the physical transistors (like Visual6502 did), it's not a "transistor level implementation". I have no reason to believe they did so because it wouldn't be reasonable. It's almost certainly an HDL-level implementation.

Unless they're stretching the definition of "transistor level" to mean "we use transistors to simulate the original transistors", but that would also include software emulation that runs on CPUs. It reads like marketing copy written by someone who doesn't even know what an FPGA is.

Analogue's devices seem to be widely loved and well regarded both by consumers and reviewers.

Are you really just mad about their choice of words?

I think it's pretty clear that Analogue's offerings are significantly different than most of the rest of the "retro games" market, and I don't blame them for calling out that difference in a way that's easy for the audience to understand, and to play to their strengths (i.e. works with real physical carts), particularly given the legal grey zone around ROM hacks and console emulation in general.

If you look at the entire device they're selling, and not just the software part, I think it's totally fair to say they are more accurate. A software emulator cannot run a physical ROM cart, right?

If you have boxes of SNES or N64 carts in your basement, and you want to use those, there's no software emulator out there that can help you (without additional steps or equipment).

what difference does it make that it's an FPGA?