4 ms·

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

by kaoD 4y ago

stbenjam 4y ago
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-use-fpga-when-other-proven-solutions-exist-such-as-raspberry-pi https://mister-devel.github.io/MkDocs_MiSTer/basics/faq/#why...
layer8 4y ago
It removes the need for a high-end CPU for accurate emulation, and potentially reduces video/audio lag.
foft 4y ago
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.
cmrdporcupine 4y ago
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 https://github.com/randyrossi/bmc64
- musicale 4y ago
  > 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...
0xcde4c3db 4y ago
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.
- BearOso 4y ago
  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.

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

by kaoD 4y ago

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

stbenjam 4y ago

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-use-fpga-when-other-proven-solutions-exist-such-as-raspberry-pi https://mister-devel.github.io/MkDocs_MiSTer/basics/faq/#why...

layer8 4y ago

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

foft 4y ago

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.

cmrdporcupine 4y ago

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 https://github.com/randyrossi/bmc64

musicale 4y ago
> 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...

0xcde4c3db 4y ago

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.

BearOso 4y ago
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.