It is a fun way to benchmark your system. I managed to get 4.1hz on my 13th gen i5 work laptop. Let's see an M-series chip blow that out of the water. ;) EDIT - It was 4.1Hz in advance mode. Actually runs at between 22Hz and 44hz depending on each time I run it. Odd to have such a wide performance variation. I will just blame Windows and some power management setting/thermal throttling.
The Visual 6502
21–27 of 27 posts
Re: The Visual 6502
#22Re: The Visual 6502
#23It is a fun way to benchmark your system. I managed to get 4.1hz on my 13th gen i5 work laptop. Let's see an M-series chip blow that out of the water. ;) EDIT - It was 4.1Hz in advance mode. Actually runs at between 22Hz and 44hz depending on each time I run it. Odd to have such a wide performance variation. I will just blame Windows and some power management setting/thermal throttling.
Re: The Visual 6502
#24- 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)
Re: The Visual 6502
#25It is a fun way to benchmark your system. I managed to get 4.1hz on my 13th gen i5 work laptop. Let's see an M-series chip blow that out of the water. ;) EDIT - It was 4.1Hz in advance mode. Actually runs at between 22Hz and 44hz depending on each time I run it. Odd to have such a wide performance variation. I will just blame Windows and some power management setting/thermal throttling.
So you're probably not far off. I can't imagine more modern chips than mine would run it significantly faster, none of the "tweaks" would help here.
Re: The Visual 6502
#26Shameless 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/visualz80…
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?
Re: The Visual 6502
#27Shameless 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/visualz80…
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 Visual65…
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.