MetalNES is by the author of NESticle. Like Visual2C02 and Visual2A03, presumably it runs at such a slow speed that games are unplayable. Like, it may have taken hours to reach the SMB menu screen, but I would love to be corrected :)
What does it mean to be a transistor-level simulation in this context?
I used to work with circuit simulators to design circuits (discrete and integrated) and there are many transistor models (mathematical models) depending on the use case. In spirit, not too unlike DFT for Schrodinger equations in quantum mechanics.
Most game emulators are looking at the instructions from a ROM file and then implementing those CPU instructions in code. Usually with those approaches there are inconsistencies due to the original game console's quirks (or bugs/flaws) that show up during gameplay, making the emulation not completely true to the original hardware.
In this context it means emulating "perfectly" by actually simulating the hardware in full instead of taking the aforementioned approach.
9000 cycles/s / 1.79 MHz = 0.5% of realtime.
The only time you ever see rendering a line at a time is single stepping through an emulator.
I wonder if this is how FPGA developers working in VHDL/Verilog see the world?
https://www.patreon.com/posts/37038491 here's a short clip of the VRAM of a PSX rendering about half of a completed frame of Final Fantasy 7's battle screen.
~9000 cycles/sec (displayed in the video), wow! For comparison, the NES ran at 1.8 MHz, or about 200x faster. From the number of frames drawn and time, I'm guessing this simulator is actually averaging much lower than 9 kHz.
I mean you can always use a server on digital ocean or something. That’s how I serve web sites. It’s still just a Linux machine and you can throw whatever content you want on it.
I mean, aside from the question of whether fpgas can truly accurately simulate everything at the transistor level, the truth is that most fpga emulation cores for this sort of thing don't. They are, afaik, still mostly 'just' cycle-level accurate emulations built off the same reverse engineering that accurate software emulators are. They can do it more efficiently for sure, but that doesn't mean it's worth it for them to go much farther.
Like, for an extreme example there's no world in which the in-development PSX mister core, running on a de10 nano, is particularly more accurate than a software emulator. The chips involved have too many transistors to completely simulate. But this will be true to some degree for everything above some complexity threshold. Maybe the Atari 2600 core is perfectly accurate.
I wouldn't be surprised if the most accurate software emulators are more accurate than the most accurate fpga cores, especially for anything newer than the NES, just because that's where most of the original work involved happens.
This idea that FPGAs are inherently more accurate seems to be rooted in marketing FUD from a company called Analogue.
I’ll 100% give you the marketing spin, but FPGAs provide an element of accuracy with frame delay. If you plug in a controller and use a CRT, there no more lost frames than the original hardware.
That’s the accuracy that’s above what an emulator on our Babel’s tower of a stack on Windows.
That's not because of the fpga though. You can also plug a CRT into a PC. You can even chase the beam if you're willing to go to a low enough level. People generally don't but this is a limitation born advantage. There's no OS (sort of) to get in your way and why would you put one there if it's not helping you.
(I say sort of because there usually is a system that could be described as an OS running somewhere on the fpga board, to load the fpga bitstreams, if nothing else, but also sometimes to supplement the fpga's abilities)
You will find projects that have zero-input lag with FPGA based emulators right now. You will not find PC-based emulators with zero-input lag at all. That this is the reality has no effect on whether a PC could do it or not.
The 6502 unfortunately relies on some effects that can't be described in FPGA synthesizable logic. You might get a lot of speed up over the extremely simplified spice style simulation you have to do that still might get you to real time, but it's not the slam dunk you might think.
It more or less falls under true classic highz buses with multiple drivers.
You have three options I can see
1) treat it as a spice simulation that aggressively optmizes to synthesizable logic most places other than the problem parts.
2) hand replace the problem parts with synthesizable logic sorta like how Nvidia replaces graphics shaders with had written replacements in their drivers
3) just throw the whole thing into a spice simulation
I think the decrement relies on open bus behavior I think - the 6502 uses it to cheat and set a value to FF in the same cycle which is then sent through the same path as increment or add, effectively adding -1 to a value.
It won't run at real-time speeds. Way, wayy slower. You could put this on a FPGA though, if you port it to one. Then it would run in real-time. I doubt it will run exactly as it is, with the limitations an FPGA provides. The logic should be fine though.
