Comment by tediousdemise | Hacker News Reader

Comment by tediousdemise | Hacker News Reader

Parent Full thread

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.

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.

This was given as an example, not for you to straw man about the gamepad.

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.

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

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

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

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

> I was merely attempting to illustrate why I thought you might have received the response you did.

Oh, that's completely unnecessary. When I said, "Don't know what you're getting at," I was hoping that the commenter understood something that I didn't.

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

This is a good illustration of why the guidelines are there in the first place. Comment #1 was the weaker argument, comment #2 was the stronger comment. If you have a discussion with someone, you can get from comment #1 to #2 and beyond.

Telling me that if I had written comment #2 first is... not helpful! Because the process of writing comment #2 involved reading replies to comment #1!

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/

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

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

Okay, sure— that was sloppy. Obviously you're going to have bug fixes and unexpected side effects, behaviours, whatever which need to be tracked down in both cases.

But at least in the FPGA case you're directly simulating the behaviour of the discrete components such that their parallel, real-world interactions should tend toward accuracy. It should be similar to the step from HLE to LLE, where LLE is simpler, more accurate, and less hacky, but way less performant. LLE to FPGA would be a similar transition but without the performance penalty.

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.

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.

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.

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.

For me as an occasional hobby developer for old platforms it's interesting. Subtle differences in how emulators work compared to the original hardware has sometimes resulted in nasty surprises.

In the best world, I could use an emulator as a reference, but for now I have to keep the old hardware around for that reason and always make sure to test my code on it regularly. Even differences that have no impact on the entire software library are important in that sense.

For example, if I write an address to an OPL chip I normally have to wait a few cycles for the address change to be effected before I write a value. You can remove that limitation in an emulator and all software written for the original platform will still work, but the emulator will no longer be useful as a reference, because now I can write software that works in the emulator but not on the real system.

There's of course a use case for emulators that take these kinds of shortcuts for the purpose of running an existing software library, and that's how people were able to play SNES games on Pentium class hardware, but as a point of reference and complete functional preservation of the hardware platform itself, that isn't good enough.

Reply on news.ycombinator.com