I’m not much of modern gamer but have very fond memories of playing N64 as a kid. Just last night I was looking for an N64 hardware emulator which could connect to modern TVs that could play in a digital format. I came across Analogue in my search, but this hadn’t been announced yet. If the price is reasonable I would be interested in buying.
Are you seriously comparing a general purpose computer that was genuinely new at the time and had silly colors with basically the yearly reproposition of the same useless old repackaged emulator catered to nostalgic people?
I don't even get what you're trying to argue here, but I remembering that "I'm the kind of person who doesn't care much about the aesthetics of computing devices, and while this sentiment is common among SOME geeks and others, it's nowhere near universal. LOTS of people everywhere are into colorful stuff they can buy."
Enough people to make it worthwhile. It won't be a massive mass market product like the NES Classic but like their past releases they will sell what they make. N64 has pretty garbage video out sans mods with IIRC no RGB support on any model. Having a nice 4K N64 that works out of the box will definitely appeal to some retro collectors.
The french, not european, french n64 has almost RGB built in! The motherboard was designed to and the pads are there for a few resistors and transistors. If you do add them and use an RGB cable from, say, a french super nintendo, you get the best analog RGB output there is on original n64. Well, 50Hz RGB. I still love mine
What's funny is my immediate reaction is "Shut up and take my money!"
The people who have nostalgia for this sort of stuff happen to also be the people the age where nostalgia takes hold and disposable income becomes available.
Honestly, I’d be a total sucker for new fruit-iMac-inspired electronics by major manufacturers if they existed. I bought a 500 million edition DualShock 4 controller a few years ago simply because of its striking resemblance to the indigo iMac I used as a kid.
There has been some criticism of Analogue lately from the retro gaming community [1] for continuing to announce and release new products while they remain months behind on fulfilling orders already placed by customers. The consensus seems to be that their products are good but add 4-6 months to whenever you expect to get your order from them.
I'm still waiting for any news at all about the "Available in 2023" Duo that I pre-ordered Day 1, but yeah: They did always deliver in the past. Eventually. And it's generally been worth it, except that if you were hoping that "Future Analogue Product" support on the DAC means "Pocket Dock".
From what I did see, people did receive their pockets and some of the accessories, so yeah, it looks like they are actually working through the backlog. That said, I'll believe the Duo when it arrives at my doorstep :D
They were able to ship both my Mega Sg and Super Nt and a Pocket Dock a few months ago within a few days of each other. I think once they have the stuff in-stock from manufacturing its very quickly in the hands of customers.
> but add 4-6 months to whenever you expect to get your order from them.
I ordered their Analogue Pocket, with the dock, in October 2022 and it finally arrived in August 2023. So more like ~10 months.
At the time that I ordered they only had black and white options, but of course they announced some really cool transparent ones the month after I got my shipment. I guess that's the gamble of pre-ordering. Either way I'm very happy with my purchase even if it took many months to arrive.
It's much less risky for Analogue to do manufacturing this way. A lot of physical product companies fail because they have too much capital tied up in inventory. They make good products, charge a premium for them, and have no problem filling up a waiting list.
I think this is becoming fairly normal, it's similar to the Playdate; they don't take orders, they take pre-orders, and only once they have enough pre-orders will they actually file an order at the manufacturers. I'm sure this is how most "niche electronics" parties operate.
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.
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.
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.
> 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.
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.
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...
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.
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'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.
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)
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.
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 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.
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.
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.
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.
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.
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).
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?
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.
> > 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!
The details are scant from this product release, but for those who don't know, this company makes the "Analogue Pocket," an FPGA-implemented device capable of playing most Game Boy Color and Game Boy Advance games. There's no emulation happening here; everything is implemented in FPGA gates built onto the hardware.
Looks like they're advertising a similar implementation of the n64.
It is not just that details are scant. If you’re unfamiliar with the company, there is little to indicate what they are selling.
It kind of defeats the idea of viral marketing.
3D is one area where the FPGA model of emulation doesn't seem so good. The N64 is pretty low-resolution and low-FPS compared to modern devices, which is grating in 3D even though it has a nostalgic charm in 2D.
Maybe it's enough to be able to buy a "new" N64 for some, but I'm skeptical it will be able to overcome the N64's flaws.
Yeah... it's about the line where a software emulator (i.e. Dolphin) can be better than the original hardware. Probably a good stopping point for MiSTer (which thanks to some very hard work is making progress on PS1/Saturn/N64) and Analogue.
I have recently bought a `Miyoo Mini Plus` for about £70 (inc taxes) and it is able to run most old console games up to PS1 just fine and the build quality is good too.
It is linux based and community has made an alternate OS/UI https://github.com/OnionUI/Onion with custom scripts, webserver and support of many other systems etc.
I couldn't find the price for Analogue, but it will probably be too expensive in comparison.
Oooh, this is exciting. I have two Analogue pockets, and really like the device. For reference, the Analogue pitch is: frame accurate / CPU cycle accurate classic gaming device simulation using a hefty FPGA. The proposal is that this feels better / different from emulators. The pockets have some 'sugar' around simulating CRT colors and bleed for a more authentic experience.
All this is generally my experience with the devices. They feel very like my memory of childhood games, much more so than play in emulation. And I love it.
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.
At any rate, I will order an N64 capable Analogue console as soon as I can - the idea of having an N64/(PS1? Saturn?) device that will last in my house is irresistible.
I'm also very curious to see what they do on controllers - the N64 had a weirdo wing-shaped controller, and using other control layouts for N64 games seems tough to me. Should be fun!
The pockets accept og controllers by wire, since they read the pins as a side effect of the architecture. My son plays smash fairly competitively and he tells me high quality gamecube competition controllers cost as much as $500. Will be interesting to see what the 'optimal' aftermarket solution is.
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.
Can you elaborate on this a bit? I'm not too familiar with this scene but I'd like to get one, and not the crappy $14.99 version at the local big box retailer.
Sure. A $15 controller to an OEM (made by Nintendo) is probably the biggest jump in quality that a regular person will notice. The aftermarket controllers often feel cheaply made, skimping on things like replacing the rubberized stick caps with hard plastic. I've seen controllers where the plug was just a couple millimeters too large, causing it to be stuck in the console port. The stick boxes often sometimes feel coarse and wear out quicker than they should.
On the upper end of the spectrum, OEM controllers from Nintendo are generally considered high quality, but in a precise game like Melee there are a couple things that can cause hangups.
The analog stick might not be properly calibrated. The controller reports the position of the analog stick as its x and y coordinates from -1.0 to +1.0 in both axes. Pushing the analog stick all the way to the edge should result in a 1.0, but some controllers instead report a 0.9875. Completely unnoticable for 99.9% of players, but at the highest level it can make a difference. Sometimes fixed by shaving more plastic off of the controller shell, but custom PCBs let you calibrate the stick manually.
"Snap back" is a more common issue. Tilt the stick all the way to the edge, then let go. Ideally, the stick would return to the center, but oftentimes the momentum carries it past the center into the opposite axis, resulting in a small input in the opposite direction. For some techniques this can have bad consequences, such as Falco needing a neutral input to shoot his gun, but a small input in the opposite direction will turn him around and shoot the gun the opposite way. Common fix for this is soldering a small cheap capacitor to the output of the stickbox's horizontal potentiometer, very subtly smoothing out the directional output.
Fancier mods include things like reducing the travel distance of the gamecube controller's large shoulder buttons to allow for quicker inputs or replacing the shoulder Z button with a clickier button.
This youtube video goes over a popular custom PCB that people have started to use in place of OEM, and some of the reasons why it is desirable: https://www.youtube.com/watch?v=RGyQbXGr4Po
If you just want a decent controller, finding a normal Nintendo-made gamecube controller at a used games store or ebay isn't that hard yet. Odds are it'll still be in decent shape.
If you want to buy a custom one, I don't know if I have any great answers for you. It's a pretty grassroots community, so depending where you live, your best option might be to scour facebook/twitter/discord to find your local Melee players and ask for the guy that makes/sells controllers.
That's definitely an 8BitDo controller, although not of a make currently available. Analogue has previously used 8BitDo controllers, and it features the star and pixel-heart most of not all current 8BitDo controllers use. Hopefully 8BitDo will release a version that works with PC!
> 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".
I'm obviously super biased, but I think the core installation process is nearly as straightforward as it could possibly be without official support. All of the cores are distributed in a way that you can simply unzip the asset to the root of your SD card, and the core is set up and ready to go.
The only part I would really have to complain about is the folder names, particularly for ROMs. For SNES for example, ROMs are stored at `/Assets/snes/common/rom.smc`, where obviously `common` is an annoying addition to the path.
The renewed interest in the N64 is very interesting considering how relatively "unpopular" it was during its lifetime. There's also not a huge number of great games on the system (IMHO) compared to its competitors. A top-50 list is not exactly full of all-time classics until you hit maybe the top-15.
The aesthetic of the console also has aged very poorly, mostly due to the incredibly tiny texture memory leading to overfiltered smudgy blurry textures all over the place.
My understanding of things from the MiSTER project is that the FPGA hardware used there is just maybe enough to be a PS1, Saturn, and N64, but just barely, and maybe not at all. If this was a 3D 32-bit multi-system thing with upgraded texture support, and not only CRT emulation, but also rendering upscaling, we might be talking. Some PS1 games at 1080p with upgraded textures and fixes to the texture warping problem look almost as good as early-mid stage PS2 games and sharper. Some games like the WipeOut series absolutely shine in high-res and are more playable since you aren't trying to figure out if a blob of 6 pixels at 240i is another racer or a wall.
Yeah it seems like N64 is an odd choice considering that the disc drives in 32-bit consoles are getting up there in age and more failure prone than a cartridge system.
IMO, clock accuracy is less important for 3D games than it was for the handful of games that made me prefer the Analogue Pocket (Mother 3 for critical hits, etc.)
I imagine they will be hard-pressed to garner a ton of interest over existing solutions, but if the controller is unparalleled and the CRT filters are really good, who knows.
I also really hope they build support for microphone emulation. I'd love to play https://en.wikipedia.org/wiki/Hey_You,_Pikachu! again without having to secure the special hardware that came with it (have it lying around somewhere but it has not stood well to the test of time...)
82 comments
[ 3.5 ms ] story [ 99.3 ms ] threadBut the Super 64 + an Everdrive was so worth it.
And then I remember how wrong I was about e.g. the candy-colored iMacs. Let's see where this goes.
I don't even get what you're trying to argue here, but I remembering that "I'm the kind of person who doesn't care much about the aesthetics of computing devices, and while this sentiment is common among SOME geeks and others, it's nowhere near universal. LOTS of people everywhere are into colorful stuff they can buy."
https://web.archive.org/web/20190406032415/http://pakupakust...
The people who have nostalgia for this sort of stuff happen to also be the people the age where nostalgia takes hold and disposable income becomes available.
[1]:https://twitter.com/RetroGameCorps/status/171184720072736803...
Duo will ship in 2023.
Pocket Adapters are "on target to ship by end of 2023"
Analogue OS 2.0 will release by end of 2023. With display mode support for openFPGA cores.
They're going to have a busy Christmas holiday..
I ordered their Analogue Pocket, with the dock, in October 2022 and it finally arrived in August 2023. So more like ~10 months.
At the time that I ordered they only had black and white options, but of course they announced some really cool transparent ones the month after I got my shipment. I guess that's the gamble of pre-ordering. Either way I'm very happy with my purchase even if it took many months to arrive.
It's like saying a Volkswagen "emulates" a Model-T. It drives on the same roads, but the internal implementation is quite different.
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.
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/
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.
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.
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'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.
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)
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 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.
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.
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.
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.
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.
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.
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).
Why not? There's the polymega which is using software emulation and has addons to support running games via cartridges.
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?
> 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.
> 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!
Looks like they're advertising a similar implementation of the n64.
Check https://openfpga-cores-inventory.github.io/analogue-pocket/
Maybe it's enough to be able to buy a "new" N64 for some, but I'm skeptical it will be able to overcome the N64's flaws.
It is linux based and community has made an alternate OS/UI https://github.com/OnionUI/Onion with custom scripts, webserver and support of many other systems etc.
I couldn't find the price for Analogue, but it will probably be too expensive in comparison.
All this is generally my experience with the devices. They feel very like my memory of childhood games, much more so than play in emulation. And I love it.
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.
At any rate, I will order an N64 capable Analogue console as soon as I can - the idea of having an N64/(PS1? Saturn?) device that will last in my house is irresistible.
I'm also very curious to see what they do on controllers - the N64 had a weirdo wing-shaped controller, and using other control layouts for N64 games seems tough to me. Should be fun!
Here's a brightened and sharpened version of the controller's teaser image from their site:
https://i.imgur.com/iIpQzh6.png
So definitely no weirdo wing-shape :(
On the upper end of the spectrum, OEM controllers from Nintendo are generally considered high quality, but in a precise game like Melee there are a couple things that can cause hangups.
The analog stick might not be properly calibrated. The controller reports the position of the analog stick as its x and y coordinates from -1.0 to +1.0 in both axes. Pushing the analog stick all the way to the edge should result in a 1.0, but some controllers instead report a 0.9875. Completely unnoticable for 99.9% of players, but at the highest level it can make a difference. Sometimes fixed by shaving more plastic off of the controller shell, but custom PCBs let you calibrate the stick manually.
"Snap back" is a more common issue. Tilt the stick all the way to the edge, then let go. Ideally, the stick would return to the center, but oftentimes the momentum carries it past the center into the opposite axis, resulting in a small input in the opposite direction. For some techniques this can have bad consequences, such as Falco needing a neutral input to shoot his gun, but a small input in the opposite direction will turn him around and shoot the gun the opposite way. Common fix for this is soldering a small cheap capacitor to the output of the stickbox's horizontal potentiometer, very subtly smoothing out the directional output.
Fancier mods include things like reducing the travel distance of the gamecube controller's large shoulder buttons to allow for quicker inputs or replacing the shoulder Z button with a clickier button.
This youtube video goes over a popular custom PCB that people have started to use in place of OEM, and some of the reasons why it is desirable: https://www.youtube.com/watch?v=RGyQbXGr4Po
If you just want a decent controller, finding a normal Nintendo-made gamecube controller at a used games store or ebay isn't that hard yet. Odds are it'll still be in decent shape.
If you want to buy a custom one, I don't know if I have any great answers for you. It's a pretty grassroots community, so depending where you live, your best option might be to scour facebook/twitter/discord to find your local Melee players and ask for the guy that makes/sells controllers.
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".
The only part I would really have to complain about is the folder names, particularly for ROMs. For SNES for example, ROMs are stored at `/Assets/snes/common/rom.smc`, where obviously `common` is an annoying addition to the path.
https://emulation.gametechwiki.com/index.php/GBA_Tests
If you want to use ROMs, just download the pocket updater and let it do all work for you!
https://github.com/mattpannella/pocket-updater-utility
The aesthetic of the console also has aged very poorly, mostly due to the incredibly tiny texture memory leading to overfiltered smudgy blurry textures all over the place.
My understanding of things from the MiSTER project is that the FPGA hardware used there is just maybe enough to be a PS1, Saturn, and N64, but just barely, and maybe not at all. If this was a 3D 32-bit multi-system thing with upgraded texture support, and not only CRT emulation, but also rendering upscaling, we might be talking. Some PS1 games at 1080p with upgraded textures and fixes to the texture warping problem look almost as good as early-mid stage PS2 games and sharper. Some games like the WipeOut series absolutely shine in high-res and are more playable since you aren't trying to figure out if a blob of 6 pixels at 240i is another racer or a wall.
I imagine they will be hard-pressed to garner a ton of interest over existing solutions, but if the controller is unparalleled and the CRT filters are really good, who knows.
I also really hope they build support for microphone emulation. I'd love to play https://en.wikipedia.org/wiki/Hey_You,_Pikachu! again without having to secure the special hardware that came with it (have it lying around somewhere but it has not stood well to the test of time...)