6 ms·

On FPGAs (depending on the hardware mapping), you get the benefit of lower latency. I consider this to be timing accuracy. Say you have two implementations of

On FPGAs (depending on the hardware mapping), you get the benefit of lower latency. I consider this to be timing accuracy. Say you have two implementations of an LED controlled by a switch: one which uses an FPGA and one which uses a microcontroller. The uC implementation must continuously poll peripherals connected to its GPIO pins at a set frequency; it must check the state of the switch, and then change the state of the LED. The FPGA, on the other hand, physically wires the switch to the LED; there is no lag when the state of the switch changes. The FPGA implementation can be scaled to connect however many additional lights and switches you want (limited by the size of the fabric), with zero overhead lag. This is the parallelization benefit of FPGAs that you may hear about. For the uC implementation, you must add additional switches and lights to the polling loop, which brings down performance in linear time, O(n). This is the drawback of sequential processing.

klodolph 6y ago
Most game consoles don’t do any of this, though. The gamepad is polled by software. On the NES and SNES, the buttons are connected to a shift register (e.g. 4021). The CPU triggers a latch and then reads out the shift register one bit at a time.
- djmips 6y ago
  This was given as an example, not for you to straw man about the gamepad.
  - klodolph 6y ago
    Don’t know what you’re getting at. You seem to have taken offense, and I think it’s because you misinterpreted what I wrote.
    - kbenson 6y ago
      Your comment seemed to be positioned as a refutation of the prior comment (it could have been meant as an aside, but without something to indicate that it can be hard not to assume it's a counter). Unfortunately, if it was meant as a counter to the prior argument, countering just the example put forth does not actually address the argument put forth, so it it looks like a straw man argument itself (that is, addressing an example, even if it was presented by others, without making any attempt to address the position itself).
      - klodolph 6y ago
        > ... countering just the example put forth does not actually address the argument put forth ... The particular example put forth was a good example, and it's worth responding to. If you can come up with a better example, I'd love to hear it. My argument is that the timing of inputs and outputs to consoles is heavily quantized, which gives you a lot more freedom if you want to create an accurate software implementation--depending on whether your goals are to emulate existing games or serve as a platform for experimentation. For example, the NES has lots of "timing tricks" but they are internal to the console, and at the scales it takes to render a frame of video, you can do a lot of work in software. From https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > In Comments > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
        kbenson 6y ago
        > If you can come up with a better example, I'd love to hear it. I don't have a side in this discussion. I just stepped in to note one reason why you might have gotten the reply you did, since you specifically noted "Don’t know what you’re getting at." I was merely attempting to illustrate why I thought you might have received the response you did. > My argument is that the timing of inputs and outputs to consoles is heavily quantized... That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did. >> > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. That's as much a point against your comment as against the person that responded to you. Responding to a specific example instead of the position is not responding to the strongest possible interpretation. Then you get responses like you did. Again, I'm not taking a position on this. I only bothered to comment at at because you seemed to indicate you didn't know why you got the response you did. Honestly, I thought you were likely presenting it as a slight tangent, not an argument, since it's fairly common here for people to view any response as someone arguing the other side once they get slightly heated in an argument.
        6y ago
- mikepurvis 6y ago
  This would be less about a user peripheral like the gamepad (which is obviously going to be read out exactly once per frame anyway) and more about getting subtle interactions between the CPU, memory/DMA, and specialized systems for graphics/audio correct. And not just correct after thousands of hours of work to smoke out the exact sources of specific title bugs, but correct essentially for free. See for example the tale of an absolutely wild mGBA investigation that was posted here a while ago: "What happens if an interrupt gets raised between prefetch and the data load? Will it start prefetching the interrupt vector before the invalid memory access? I quickly mocked this up in mGBA, turned on interrupts in the test ROM, and sure enough it broke out of the loop. So I tried the same test ROM on hardware and…it did not break out of the loop. So there goes that theory. Eventually I realized something. You saw that asterisk earlier I’m sure, so yes, there is one thing that can happen in between prefetch and the memory access, but only if the memory bus gets queried by something other than the CPU between the prefetch and invalid memory access." https://mgba.io/2020/01/25/infinite-loop-holy-grail/ https://mgba.io/2020/01/25/infinite-loop-holy-grail/
  - klodolph 6y ago
    I don’t think that the FPGA based emulation will be “correct essentially for free”. The FPGA emulation itself is a lot more labor-intensive to create in the first place. In order to make it work equivalently to original hardware, you will need to accurately understand how the original hardware works, which is something you would need for software implementations too. In general, software has a much lower cost of development than the cost of developing something for FPGA, and if you had something like a Verilog implementation of your emulator, it is not necessarily true that you need to run it on an FPGA—you can run it in software, or use it to verify a software implementation. I think the real argument here for FPGAs is that some things are tricky to emulate with reasonable speed and accuracy in software. I don’t think the other arguments hold up—for example, arguments about latency—since the time scales involved are fairly generous (16ms to generate a frame of video).
  - boomlinde 6y ago
    > but correct essentially for free. Definitely not. Per your example, "what happens if an interrupt gets raised between prefetch and the data load" is not a question that the type of emulation can answer. You can implement hardware as well as software that gets details like this right or wrong. In both cases you usually need an extensive catalog of observations or a full description of the original hardware to correctly emulate it functionally.
- blihp 6y ago
  Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequency is necessary to reproduce the original behavior) of the original as necessary. Then you can run the original software without modification and get much closer to identical behavior and performance characteristics with much lower resource utilization. Granted, it won't be nanosecond perfect, but it will be a lot closer than you'll get on any current CPU.
  - klodolph 6y ago
    I don’t think reproducing the exact behavior here is necessary, useful, or even interesting. You could use a USB gamepad and get behavior that is close enough that humans can’t tell the difference.
    - Uberphallus 6y ago
      While I don't know the current status, with MAME in the mid 2000s, an update that added support for certain games usually involved changes... that broke a different set of previously working games. I remember having 3 MAME versions installed to play all the games that I wanted. That kind of emulation hell is greatly reduced when you simulate every bus and chip of the original hardware. To give you an example: I don't remember which game it was, but it was a platformer, and when the character jumped, the game put the starting pitch of the jumping sound effect in the sound chipset, with the DSP doing the loss and pitch change on each cycle. The game moved the character according to certain value in some register of the DSP, so the game was working normally until you jumped, then the DSP emulation code did something like returning the original value or 0 (because 99.9% of the games just write there), and the game crashed.
      - CmdrKrool 6y ago
        That's because MAME is distributed as a single executable which combines support for all the machines it emulates. If there was a mega 'multiple arcade machine FPGA core' that supported thousands of machines in one then you would need to do the same kind of installation management as different parts of that codebase matured. But when using FPGAs you normally have a seperate core for every machine being simulated. By the emulation analogy, you're actually switching between many different 'MAME versions', or single-game emulators when you switch between games on your FPGA.

klodolph 6y ago

Most game consoles don’t do any of this, though. The gamepad is polled by software. On the NES and SNES, the buttons are connected to a shift register (e.g. 4021). The CPU triggers a latch and then reads out the shift register one bit at a time.

djmips 6y ago
This was given as an example, not for you to straw man about the gamepad.
- klodolph 6y ago
  Don’t know what you’re getting at. You seem to have taken offense, and I think it’s because you misinterpreted what I wrote.
  - kbenson 6y ago
    Your comment seemed to be positioned as a refutation of the prior comment (it could have been meant as an aside, but without something to indicate that it can be hard not to assume it's a counter). Unfortunately, if it was meant as a counter to the prior argument, countering just the example put forth does not actually address the argument put forth, so it it looks like a straw man argument itself (that is, addressing an example, even if it was presented by others, without making any attempt to address the position itself).
    - klodolph 6y ago
      > ... countering just the example put forth does not actually address the argument put forth ... The particular example put forth was a good example, and it's worth responding to. If you can come up with a better example, I'd love to hear it. My argument is that the timing of inputs and outputs to consoles is heavily quantized, which gives you a lot more freedom if you want to create an accurate software implementation--depending on whether your goals are to emulate existing games or serve as a platform for experimentation. For example, the NES has lots of "timing tricks" but they are internal to the console, and at the scales it takes to render a frame of video, you can do a lot of work in software. From https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > In Comments > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
      - kbenson 6y ago
        > If you can come up with a better example, I'd love to hear it. I don't have a side in this discussion. I just stepped in to note one reason why you might have gotten the reply you did, since you specifically noted "Don’t know what you’re getting at." I was merely attempting to illustrate why I thought you might have received the response you did. > My argument is that the timing of inputs and outputs to consoles is heavily quantized... That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did. >> > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. That's as much a point against your comment as against the person that responded to you. Responding to a specific example instead of the position is not responding to the strongest possible interpretation. Then you get responses like you did. Again, I'm not taking a position on this. I only bothered to comment at at because you seemed to indicate you didn't know why you got the response you did. Honestly, I thought you were likely presenting it as a slight tangent, not an argument, since it's fairly common here for people to view any response as someone arguing the other side once they get slightly heated in an argument.
        6y ago
mikepurvis 6y ago
This would be less about a user peripheral like the gamepad (which is obviously going to be read out exactly once per frame anyway) and more about getting subtle interactions between the CPU, memory/DMA, and specialized systems for graphics/audio correct. And not just correct after thousands of hours of work to smoke out the exact sources of specific title bugs, but correct essentially for free. See for example the tale of an absolutely wild mGBA investigation that was posted here a while ago: "What happens if an interrupt gets raised between prefetch and the data load? Will it start prefetching the interrupt vector before the invalid memory access? I quickly mocked this up in mGBA, turned on interrupts in the test ROM, and sure enough it broke out of the loop. So I tried the same test ROM on hardware and…it did not break out of the loop. So there goes that theory. Eventually I realized something. You saw that asterisk earlier I’m sure, so yes, there is one thing that can happen in between prefetch and the memory access, but only if the memory bus gets queried by something other than the CPU between the prefetch and invalid memory access." https://mgba.io/2020/01/25/infinite-loop-holy-grail/ https://mgba.io/2020/01/25/infinite-loop-holy-grail/
- klodolph 6y ago
  I don’t think that the FPGA based emulation will be “correct essentially for free”. The FPGA emulation itself is a lot more labor-intensive to create in the first place. In order to make it work equivalently to original hardware, you will need to accurately understand how the original hardware works, which is something you would need for software implementations too. In general, software has a much lower cost of development than the cost of developing something for FPGA, and if you had something like a Verilog implementation of your emulator, it is not necessarily true that you need to run it on an FPGA—you can run it in software, or use it to verify a software implementation. I think the real argument here for FPGAs is that some things are tricky to emulate with reasonable speed and accuracy in software. I don’t think the other arguments hold up—for example, arguments about latency—since the time scales involved are fairly generous (16ms to generate a frame of video).
- boomlinde 6y ago
  > but correct essentially for free. Definitely not. Per your example, "what happens if an interrupt gets raised between prefetch and the data load" is not a question that the type of emulation can answer. You can implement hardware as well as software that gets details like this right or wrong. In both cases you usually need an extensive catalog of observations or a full description of the original hardware to correctly emulate it functionally.
blihp 6y ago
Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequency is necessary to reproduce the original behavior) of the original as necessary. Then you can run the original software without modification and get much closer to identical behavior and performance characteristics with much lower resource utilization. Granted, it won't be nanosecond perfect, but it will be a lot closer than you'll get on any current CPU.
- klodolph 6y ago
  I don’t think reproducing the exact behavior here is necessary, useful, or even interesting. You could use a USB gamepad and get behavior that is close enough that humans can’t tell the difference.
  - Uberphallus 6y ago
    While I don't know the current status, with MAME in the mid 2000s, an update that added support for certain games usually involved changes... that broke a different set of previously working games. I remember having 3 MAME versions installed to play all the games that I wanted. That kind of emulation hell is greatly reduced when you simulate every bus and chip of the original hardware. To give you an example: I don't remember which game it was, but it was a platformer, and when the character jumped, the game put the starting pitch of the jumping sound effect in the sound chipset, with the DSP doing the loss and pitch change on each cycle. The game moved the character according to certain value in some register of the DSP, so the game was working normally until you jumped, then the DSP emulation code did something like returning the original value or 0 (because 99.9% of the games just write there), and the game crashed.
    - CmdrKrool 6y ago
      That's because MAME is distributed as a single executable which combines support for all the machines it emulates. If there was a mega 'multiple arcade machine FPGA core' that supported thousands of machines in one then you would need to do the same kind of installation management as different parts of that codebase matured. But when using FPGAs you normally have a seperate core for every machine being simulated. By the emulation analogy, you're actually switching between many different 'MAME versions', or single-game emulators when you switch between games on your FPGA.