Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My mind is blown but I'm also wondering if this isn't some kind of incredible over-engineering? Surely CPUs are fast enough to emulate these kind of devices in software. If they aren't, they must be an order of magnitude simpler in complexity.

I wouldn't ordinarily care about emulators, but actual hardware emulators is the craziest thing I've heard in a while. All that for a small handheld console?

If only I was not so broke...



The benefit of FPGAs is you can get nearly gate perfect emulation of an old games system. We've had emulators for years that get most things right but some games and minor things in old games require specific software patches to ensure the odd why they used the chips available produces the same output. There's a great old article from 2011 about the power required at the time to get a nearly perfect emulation of a NES. [0] The goal with the Pocket and all of Analogue's consoles isn't to be just another emulation machine but to run as close as possible to the original at a hardware level. That's their whole niche, hardware level 'emulation' of old consoles.

[0] https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...


Software is orders of magnitude simpler in complexity, yes. The difference between a software emulator and a logic level emulator are immense.

But take the example of the difficulties with a software NES emulator:

In hardware, there is one clock that is fed into the 3 main disparate systems; the CPU, APU (audio), and PPU (picture). They all use different clock dividers, but they're still fed off of the same source clock. Each of these chips operate in parallel to produce the output expected, and there's some bidirectional communication going on there as well.

In a software emulator, the only parallel you get is on multiple cores, but you can approximate it with threading (i.e. preemption). For simplicity, you stick with a single thread. You run 3 steps of the PPU at once, then one step of the CPU and APU. You've basically just sped through the first two steps, because who will notice those two cycles? They took no "real" time, they were performed as fast as the software could perform them. Probably doesn't matter, as no one could tell that for 10ns, this happened.

You need to add input. You use USB. That has a minimum polling interval of 1000Hz, plus your emulator processing time (is it going to have to go in the "next frame" packet?), but controls on systems like the NES were practically instantly available the moment the CPU read.

Now you need to produce output. You want to hook up your video, but wait, you need to feed it into a framebuffer. That's at least one frame of latency unless you're able to precompute everything for the next frame. Your input is delayed a frame, because it has to be fed into the next batch, the previous batch (for this frame) is already done. You use the basis of 60fps (which is actually slightly wrong) to time your ticking of your emulator.

Now you need to hook up audio. Audio must go into a buffer or it will under/overflow. This adds latency, and you need to stay on top of how close you are to falling outside of your bounds. But you were using FPS for pacing, so now how to you reconcile that?

----

Cycle accurate and low latency software solutions are certainly not easy, and it's impossible for true low latency on actual OS running CPUs. Embedded-style systems with RTOSes might be able to get pretty close, but it's still not going to be the same as being able to guarantee the exact same (or as near as we can tell) timing for every cycle.

I want to be clear that none of these hardware implementations are actually that accurate, but they could be, and people are working hard to improve them constantly


> You need to add input. You use USB

When using a dock, is it possible to get around this delay?


Analogue could support a SNAC type adapter with the Dock (I highly doubt it, those USB ports are almost definitely wired directly to a real USB chip). Users could develop a cart slot adapter (someone has, he's just lazy and hasn't finished it), but this won't work with any OS features, just the cores themselves.


Sure it would probably be cheaper to chuck a cortex-A* or similar mid-range MCU in there. One advantage of FPGAs that it can achieve "perfect" emulation of a Z80 (or other) since it's running on the logic gate level. No software task latency, no extra sound buffering, etc. It can re-create the original clock-per-clock.


It's impressive as well


Emulating “accurately” is so difficult that not even Nintendo’s Game Boy emulator on the Switch does it properly. I’ve been replaying old games and comparing some questionable moments with my original Game Boy, and the timings are not quite right in some cases.

For example in Link’s Awakening, there’s a wiggle screen effect done by writing to OAM during HBlank. On the Switch it lags very differently than my GB (try it by getting into the bed where you find the ocarina). Or with Metroid 2, the sound when you kill an Omega Metroid is different too. It pitch shifts along with the “win” jingle.

These have almost zero impact on playability. But for purists and emudevs it’s a popular pursuit.


> Emulating “accurately” is so difficult that not even Nintendo’s Game Boy emulator on the Switch does it properly.

The NSO emulators on Switch are particularly terrible, worse than past iterations on Wii etc. at least for some systems, for no obvious reason other than Nintendo being lazy and/or not preserving past emulation work on other systems and not wanting to reuse open source solutions.

There's a few good comparisons on Youtube such as youtube.com/watch?v=ounQZv1MFNA that go a bit more into the development history


They have a huge impact if you want to play light gun games on CRT, where timing being out by a few micro seconds prevents your light gun from registering at all


Has anyone made a light gun replacement that would work with modern LCDs? Or is the frame delay too inconsistent for such a thing to work?


You cannot make 80s lightguns work on an LCD. When you pulled the trigger, the system drew out a few white boxes where the targets are, and how long it took the gun to "see" white told you which box you were aiming at, because of the raster functionality of the electron gun. LCDs always output an entire screen at once, so that cannot work.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: