4 ms·

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

> 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-fastest-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-running-on-mcl86-in-mister-pcxt/ https://microcorelabs.wordpress.com/2022/08/12/area5150-runn...

cmrdporcupine 4y ago
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.
- musicale 4y ago
  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.htm http://www.radanpro.com/Radan2400/mikrokontroleri/rtvideo5.h...
- BearOso 4y ago
  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.
  - musicale 4y ago
    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.
    - BearOso 4y ago
      Exactly. Mark Rejhon, the Blurbusters guy, wrote a lot about it and had a proof of concept. A couple emulators implemented it.
      - cmrdporcupine 4y ago
        But it's only half the battle, if there's still high latency on the input stack.
        musicale 4y ago
        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.

cmrdporcupine 4y ago

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.

musicale 4y ago
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.htm http://www.radanpro.com/Radan2400/mikrokontroleri/rtvideo5.h...
BearOso 4y ago
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.
- musicale 4y ago
  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.
  - BearOso 4y ago
    Exactly. Mark Rejhon, the Blurbusters guy, wrote a lot about it and had a proof of concept. A couple emulators implemented it.
    - cmrdporcupine 4y ago
      But it's only half the battle, if there's still high latency on the input stack.
      - musicale 4y ago
        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.