Hacker News new | ask | show | jobs
by flohofwoe 5 days ago
Shameless plug: I wrote a 'remix' a couple of years ago over a Christmas break using WASM+WebGL+DearImGui with better rendering performance, integrated assembler and a couple visualization tools (using the visual6502 team's original reverse engineered netlist data, and https://github.com/mist64/perfect6502 as simulation loop):

- 6502: https://floooh.github.io/visual6502remix/

- Z80: https://floooh.github.io/visualz80remix/

- 2A03 (this was contributed): https://floooh.github.io/visual2a03remix/

- source code: https://github.com/floooh/v6502r

(the simulation generally runs throttled to 1 half-clock-cycle per frame, so don't use it as any sort of benchmark)

1 comments

The link to Perfect6502 is interesting. It says that it supposedly gets speeds of 1/30th of 1MHz - i.e. ~30KHz - on high-end 2025 CPUs. Which is very slow of course, but still ~1000x faster than what people are reporting in this thread.

Of course it's in JS rather than C, but V8 is really good, well within an order of magnitude - not three - of native, at least with well-written code. I profiled the original Visual6502 and at a glance it sure does look like it's losing a ton of performance to rendering (so good call there).

I have to wonder what the limit is. Even Perfect6502 looks like it's all single-threaded and CPU-driven, which really isn't making the most of modern machines. But I don't know if this is a task that could be efficiently split across cores or dispatched to the GPU (and I can't even begin to know whether SIMD might be useful); of course hardware itself is fundamentally parallel, but the synchronization might kill you?

The core of the simulation are these two functions:

https://github.com/mist64/perfect6502/blob/09fc542877a843182...

As far as I understood it, this basically re-evaluates the state of a 'dirty list' of transistors though all their connections, and loops until the node list has 'settled' again into a stable state (e.g. state changes from the last loop didn't cause trigger new state changes). Haven't thought about how this could be threaded or simd-ified.