[elipsitz]

Analogue makes some really cool, well-engineered products. But saying there’s “No Emulation” because it uses an FPGA is blatantly false. If it’s imitating original hardware, without being the original hardware, it’s an emulator.

[sbarre]

Words can have multiple meanings?

In the market space they play in, and the audience to whom they speak, "emulation" is well known to mean software emulation targeted at dumped ROMs.

And since there are lots of hardware devices out there that are generic compute devices with pre-installed software emulators that claim to play the same games (via said ROMs), they make the point to clarify that this isn't one of those products.

[elipsitz]

The issue I have is that they’re implying it’s inherently better than software emulation, perhaps because it more accurately reproduces the behavior. But an FPGA emulator isn’t necessarily any more accurate.

I think it’s dishonest marketing, and they know it. The low contrast, fine print at the bottom doesn’t make the same claim:

> 3. Analogue 3D is not designed using software emulation. It is designed using a specialty hardware chip called an FPGA, which operates on a transistor level implementation of its functionality.

[colejohnson66]

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.

[sbarre]

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).

[belthesar]

Personally, I dislike their use of language here because Analogue is standing on the shoulders of giants that have reverse engineered video game console architecture, largely to be used in software emulation. While an FPGA does not have an operating system, a non-native call stack, and other general purpose computing bits in-between it and the code programming the FPGA, Analogue products are indeed emulating the system.

> A software emulator can not run a physical ROM cart, right?

It absolutely can. The vast majority of emulators do not build this functionality in because some sort of cartridge tool to interface with a computer would be a largely niche device that is easily solved by running an existing dump. Software emulation competitors like those from Retron do include cartridge slots, and those work by dumping the ROM and then running it from temporary space in the emulator of choice. That said, your disc-based system emulators do generally have support for running direct from physical media, because for a good long while, we all had CD and/or DVD drives in our systems.

As for "more accurate", the Analogue Super Nt at release had a plethora of bugs in the FPGA firmware that caused issues with accurate play of titles. Meanwhile, counterparts in Snes9x had solved so many of those issues, albeit still being less "console accurate" than other emulators like bsnes. So, in many ways, the solutions Analogue provides still need more work to truly be better than emulation.

That said, plenty of more causal folks are fine with "good enough", to your point of Analogue being widely loved. The SNES Mini had a handful of games that ran well enough for the vast majority of players, and hyper-accuracy is more of an issue for certain games with esoteric software or additional chips on the cartridge to augment the console's functionality, or for folks that push a game system to the limit like speedrunners.

As a result, I don't think they are bad products by any stretch of the imagination, but I do take umbrage in their marketing tactics. It is both inaccurate, and to some degree disrespectful to those that did the work that made theirs possible.

[sbarre]

> > A software emulator can not run a physical ROM cart, right?

> It absolutely can.

Cool, I have bsnes running on my PC, where do I plug in the cart? ;-)

You misunderstood my point there, which is probably my fault for not being clear but I was comparing the software emulator to the complete hardware device provided by Analogue.

Someone else mentioned the Polymega which is a device that runs software emulators but has physical interfaces for carts, which is probably more in line with what you're thinking about.

Thanks for sharing the rest of the details, it was informative!

[ehaliewicz2]

>A software emulator cannot run a physical ROM cart, right?

Why not? There's the polymega which is using software emulation and has addons to support running games via cartridges.

[MenhirMike]

I don't know how the Polymega works, but for the example the Hyperkin Retron or the Atari 2600+ are "DOM Dumpers": You put in the cartridge, the system dumps the EEPROMs to RAM, and then plays them.

The issue is that if you have a cartridge with any custom chips in it, they won't work because the software doesn't actually connect the cartridge to the emulated system. It's possible to built in heuristics to detect a known game (e.g., if I detect Pitfall 2 on the 2600, I can tell the emulator to emulate the video/sound chip on the cartridge), but if I have a homebrew cartridge, I'm out of luck.

This is especially common on NES and SNES games, there were so many custom chips around, some used on only 1 game (e.g., the DSP2 chip on SNES Dungeon Master), though other consoles also occasionally used it (like Virtua Racer on the Genesis, or as mentioned, Pitfall 2 on the Atari 2600).

With a hardware-based emulation, it's possible to electrically connect the cartridge to the system and achieve full compatibility (assuming the hardware emulation is correct), but there's AFAIK no software emulator that can be fully coupled to a cartridge connector.

So, not sure what would happen if I grab a SNES cartridge with a DSP2 chip (aka. Dungeon Master) and flash my own EEPROM onto the game - would the Polymega work for that or not?

[MenhirMike]

It's a discussion that's been going on for a long time. Is it "Emulation" or is it more like "Simulation" or even "Recreation", and are those things actually different from each other or is it just wordsmithing.

In the end, it's a third party that's not the original hardware manufacturer trying to re-implement a hardware platform, so there's always room for errors and inaccuracies, so it's fair to say it goes into the realm of emulation. On the other hand, it has a lot more potential because you can configure an FPGA to behave like real hardware - and don't have to worry about an underlying OS and device drivers. (And even then, real hardware wasn't always the same, as anyone that ever tried to look into MegaDrive/Genesis sound emulation can attest: There's like six different versions of the MD/Gen that all sound differently. Or the PC Engine CoreGrafx I with it's HuC6280A being different than the regular HuC6280 in all other systems).

FPGAs is the closest you'll get to a modern revision of a classical console without having to get an old one, probably RGB mod it, probably recap it, and putting an upscaler behind it. (And arguably, at that point, you're no longer playing the authentic experience anyway since a CRT with all it's color-bleeding glory is the way it's meant to be played)

[elipsitz]

Yeah, I guess it's mostly just wordsmithing. But I don't think it's pedantry: by making the claim that their hardware isn't emulation, it implies that it's somehow better than software emulators. There's just an entirely different set of tradeoffs here, and FPGA emulators are not inherently more accurate than software emulators.

[MenhirMike]

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)

[tombert]

> I think the N64 might be in a bit unique situation because all the emulators for it are kinda crap,

I think most emulators are fine for the big "brand name" games like Mario 64 and Zelda Ocarina of Time. I played through both on an emulator without any issues as far as I could tell.

Where most emulators still kind of suck are the later N64 games that really exploit the hardware, like Resident Evil 2's FMV. As of about a year ago, RetroArch with AngryLion actually does emulate that correctly, and I managed to play through most of the game without any issues, it definitely pushes my relatively beefy laptop to its absolute limit, and the only cycle-accurate N64 Emulator that I'm aware of, CEN64, only runs at like 4 fps on my machine.

I too am interested in seeing if the MiSTer can pull it off, because that would definitely work in favor of proper preservation of a lot of the later N64 stuff.

[MenhirMike]

The "100% compatility in every region" is definitely one hell of a claim for them to make. I think I also saw some emulator issues with Mario Kart 64 where one of the track billboards was actually showing a real-time 3D scene, which didn't render in some emulators.

If they can pull it off, it would be a massive achievement, even though I personally can't think of a single N64 game I'd actually still want to play personally.

[tombert]

In regards to Mario Kart, I believe that was exploiting a trick in the N64 to effectively use the second buffer from double-buffering as an image on the billboard; honestly kind of clever. I haven't tested it myself, but I seem to recall AngryLion on RetroArch fixes that particular bug.

Honestly, I do think the N64 is definitely a mixed bag; there's some real gems on there (Super Mario 64, Zelda Ocarina of Time, Conker's Bad Fur Day, Banjo Kazooie, PilotWings 64, Perfect Dark), but I think pretty much all of the excellent games have more or less made it to the Virtual Console or Switch Online thing.

However, there are a few games on the N64 that never really made it to "legendary" status, and as such never got any real updates/modern ports, but are still worth checking out. Space Station Silicon Valley, for example, is a very unique and interesting game that's a lot of fun to mess around with, and the only "port" that got after the N64 was a terrible one on the PS1. The N64 was one of the earliest (popular) 3D-first consoles, and as such there's a lot of interesting experimentation going on that I do think is genuinely worth checking out.

That said, it's kind of hard to recommend the N64 to anyone; for every Mario 64 or Banjo Kazooie, you have three or four extremely bland mascot platformers (e.g. Gex 3D) or uninspired racing games. It's an extremely mixed bag.

[skyyler]

There's a pretty big difference between a 1-to-1 simulation of the real hardware and a software emulator. Look into what it took to get cycle-accurate emulation of the SNES with higan...

[elipsitz]

But it isn’t a 1-to-1 simulation of the real hardware. Unless they have the original designs for the chips used in the N64, they’re still implementing something with likely very different internals on an FPGA.

You can get the same accuracy in a software emulator. If they want to claim it’s better because it’s more performant, or because it can use original cartridges, or it can produce better analog video output, that’s fine. But that’s not what they’re saying— they’re saying it isn’t emulation at all.

[lgg]

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.

[elipsitz]

I'm not saying that FPGAs aren't interesting, or don't have the possibility of allowing one to produce highly accurate emulators. I think that FPGA emulators are really cool -- I've written one! Check the website linked from my profile.

I'm taking issue with how Analogue markets their products. If they want to talk about the specific benefits their products have (like low latency, or video output, or original cartridges, or accuracy), great! But the claim that they're making is that their work involves "No Emulation". And through that, they're implying that FPGA based emulators are inherently better. And they're not. It's a different set of tradeoffs, and they certainly have the possibility to have certain advantages, but that's still all up to the quality of the implementation. Which is exactly the way that software emulators work too.

[colejohnson66]

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.

[gcr]

When I hear "emulation," I think "in software, a la Turing-completeness."

It's like saying a Volkswagen "emulates" a Model-T. It drives on the same roads, but the internal implementation is quite different.

[elipsitz]

Whether it’s a program running on a CPU that interprets software written for the original device, or a configuration of look-up-tables in an FPGA that can interpret software written for the original device, it’s still a system that intends to exactly reproduce the behavior of another one. I’d call that emulation.

[tibbon]

I'm not sure I agree. Arduinos made by other companies aren't emulations. They can still be true implementations and feature compatible.

[mattl]

It's not emulation in software, it's hardware reproduction in software so the distinction matters for video games.

[elipsitz]

Sure, it’s not a software emulator, but it’s still an emulator. And Analogue’s use of “No Emulation” is dishonest: it implies that it’s somehow inherently better than a software emulator, which it isn’t. E.g. you can have an inaccurate FPGA-based emulator, and a highly accurate software-based emulator.

[mattl]

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.

[deelowe]

> If you program an FPGA to reproduce a system, there's no emulation...

Without seeing the code, it's impossible to know where Analog's implementation falls on the spectrum of software emulation vs hardware simulation. There is nothing magical about FPGAs that automatically makes anything developed with them a 1:1 representation of real hardware. In fact, there are plenty of instances where the FPGA version of a particular console is literally just a representation of a popular emulator only in verilog/vhdl. In many instances, even the best FPGA implementations of some systems are still only simulating system level behavior. Off the top of my head, one famously difficult case is audio, where many chips have analog circuitry that cannot be fully simulated.

> you might have bugs but there are bugs in hardware too.

Funny you mention this. "Bugs" are actually where this sort of thing starts to matter. Speed runners will exploit timing, precision, overflow and similar bugs which allow them to do all sorts of things. A system that has been fully simulated will exhibit the same hardware/software bugs as the original device. Another example would be fighting games where input and frame timing must be 100% accurate at high levels of play.

Going back to this particular case, I don't believe there is any possibility that this is a 1:1 reimplementation of the n64. Though I'm happy to be proven wrong.

[spicyjpeg]

If you program an FPGA using the same HDL that was used to manufacture the original system then sure, it will behave identically (at least to the extent permitted by the laws of physics). However, if you are reverse engineering the chips and replicating the HDL without being able to peek at their actual circuitry, it is no different from doing the same in a pure software emulator from an accuracy standpoint. The only advantage of FPGA-based emulation in this case is that it can interface in real time with no latency to physical hardware such as game cartridges containing additional CPUs and whatnot - useful for consoles like the SNES, but such cartridges were not really a thing on the N64.

[Balooga]

There are differences between the NMOS and CMOS implementations of the Z80. And an FPGA is neither NMOS or CMOS [1].

This is an interesting post describing the hoops one has to jump through to replicate an NMOS chip in an FPGA [2].

[1] https://sinclair.wiki.zxnet.co.uk/wiki/Z80#Differences_betwe...

[2] https://baltazarstudios.com/z80-ground/