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