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.
