Hacker News Reader

Comment by kaoD | Hacker News Reader

I'm curious, is there any advantage to this over software emulation, besides "I did it because I could"? (which is of course cool in itself).

View on HN

The main disadvantage of software emulation is that really making the timing consistent with the original hardware is computationally expensive because it needs to account for things like bus arbitration and DMA interactions between the CPU and graphics hardware. This means that you can't get away with JIT translation, or even having your CPU emulation iterate over a bunch of instructions at once. For most games this doesn't make a big difference, but it matters in some edge cases, and also for accurate slowdown behavior (most old-school game engines let physics slow down when the CPU falls behind), which is important for speedruns and other high-level play on some games.

While it's not intrinsic to software emulation, modern PC and mobile operating systems tend to be somewhat bad about input lag by default. This can be overcome, but it's work, and vendors seem to invent an exciting new way to fuck it up every few years.

Similarly, a lot of old-school hardware ran at oddball frame rates that modern systems won't do without a bit of coercion (e.g. NTSC SNES runs at around 60.09 Hz in most modes), so you're usually forced to choose between running the system at a slightly inaccurate speed or allowing periodic stuttering. That being said, modern displays don't necessarily support the original refresh rates either, so FPGA-based systems have needed to make the same compromises, just less often than software emulators.

Interestingly, most 60hz monitors I've tested can tolerate the SNES/NES weird refresh rate without problems. In Windows you can create such a video mode with ToastyX's CRU, and with custom modelines on Linux. All you have to do is take your monitor's native modeline and multiply the pixel clock value by the ratio of 60.0988/your_normal_refresh rate. Within a thousandth of a frame or so is usually close enough, but if you mess with the blanking intervals a bit you can get exactly the same rate.

Monitors generally don't hit 60Hz exactly anyway. A lot of cheap monitors have really inaccurate default refresh rates, like 59.93Hz instead of 60. Some may use 59.94Hz to match NTSC's rate.

Latency.

It doesn't matter how fast your emulator is, throughput-wise. Your operating system (and other stuff) sits between it and output and input devices. And usually adds multiple frames worth of latency. There's ways to improve this, certainly, but you won't get that experience "out of the box."

Now, it's also possible to accomplish this by running emulators "bare metal" or "close to the metal" like my friend Randy did with his BMC64 project: https://github.com/randyrossi/bmc64

> Latency

As long as the correct output signals are generated before the clock edge, there is little meaningful difference between software or hardware implementations.

A cycle-accurate software emulator can actually replace a hardware CPU. Consider this example of a cycle-accurate software emulator running on a 600 MHz Teensy/ARM microcontroller board plugged into the CPU socket of an Apple II:

https://microcorelabs.wordpress.com/2021/01/08/mcl65-worlds-...

The 8088 version (an impressive achievement, though he had to overclock the microcontroller to 800MHz) apparently also worked as a drop-in replacement for MiSTer's FPGA implementation - he suggests that graphical bugs in the area 5150 demo were not due to the CPU but due to timing issues with MiSTer's PC XT peripheral implementations.

https://microcorelabs.wordpress.com/2022/08/12/area5150-runn...

No, that's not at all the case for what the poster I was replying is referring to. I think you misread them/me. They seemed to be talking about software emulation on commodity PCs.

Total time, from input to physical display on the screen is not under the user space programmer's control if you're running an emulator on a Linux or Mac or Windows system.

You can be cycle accurate all you want. That doesn't get you past the windowing system, GPU, display controller, HDMI interface, etc. any faster. All of that sits between you and pixels.

It is possible, on an FPGA (or under any hardware you control directly, really) to go straight from framebuffer to HDMI (or etc) signals without pauses inbetween. In some ways it's easiest on FPGA.

Your example is running on custom hardware. That is entirely feasible, yes. But isn't what was being asked about. That's similar to the BMC64 example I gave.

I think we're making compatible points. You noted that you can bypass the OS by running on bare metal. (True! You can also use real-time OS features, devote one or more cores entirely to running the emulator flat out, write directly to a frame buffer - or maybe even generate the actual video signal[1], etc..) Another nice thing about a microcontroller board like a Pi or Teensy is that you can easily get signals in (e.g. controllers, keyboards) and out (e.g. sound, video) of it.

Note that Linux (which I'm familiar with) makes it fairly easy to bypass much of the OS for real-time applications, but you can get most of the benefit by simply running a single process (i.e. just run the kernel and a single emulator process.)

My point is similar to yours actually: that as long as you calculate the output signals on time (e.g. before the clock edge) there is not a meaningful difference between hardware and software implementations.

[1] http://www.radanpro.com/Radan2400/mikrokontroleri/rtvideo5.h...

You can get the precise scanout positions easily. For direct scanout: Windows has fullscreen exclusive mode, X11 has unredirecting, and Wayland recently added direct scanout surfaces. There's major API extensions to query the vblank times, so you can set up the next frame to start scanout precisely when a console would. Now, you won't be able to modify the image when it's displaying--no racing the beam tricks, but consoles usually locked the vram outside vblank anyway.

This is interesting - are you saying it's possible with appropriate synchronization to race the scanout on a modern GPU/display to get true line-by-line display for an emulator and avoid the buffering delay (e.g. 1/4 frame at 120 Hz)?

Presumably native graphics and games already need to sync with fixed rate displays to avoid tearing (or buffer and pay a latency price.) The fact that tearing exists would seem to indicate that you can update a frame while it is being scanned out.

I imagine that racing the beam (or video signal scanout in the case of non-CRTs) might actually work, especially with VGA where you could set to an appropriate resolution.

Exactly. Mark Rejhon, the Blurbusters guy, wrote a lot about it and had a proof of concept. A couple emulators implemented it.

But it's only half the battle, if there's still high latency on the input stack.

A Raspberry Pi is a popular emulation platform. There's essentially zero latency to read a GPIO pin. Even on macOS or Windows 10 platforms, one way serial-to-USB latency seems to be less than a millisecond.

It's a good way to learn about FPGA's. Other thna that, the FAQ has a good example about where the Amiga software emulation falls short:

> Let's take a well-known emulator, UAE, emulating an Amiga. On a Raspberry Pi 3, you can run some Amiga CPU benchmarks and get crazy numbers like 100 times the original 68000 processor. So you may assume you have an emulated Amiga that is 100 times faster than real one. No, you don't. If you run different kinds of demos or games, you will see the video stutters sometimes. For example, if you play the well-known "State of The Art" demo by Spaceballs, you will notice video stuttering at some points, while a real Amiga 600 with 1x CPU speed plays the whole demo very smoothly.

https://mister-devel.github.io/MkDocs_MiSTer/basics/faq/#why...

If you want to eg add original ports and hardware interfaces that tends to be easier with an fpga: cartridges, midi etc. Of course you can do that in software/ bit bang. Though it’s complicated by emulator timing, they tend to run frame by frame and sync at the end of a frame.

It removes the need for a high-end CPU for accurate emulation, and potentially reduces video/audio lag.

Reply on news.ycombinator.com