Stars and mentions
Last 30 days, Oct 4 – Nov 2
Package downloads
Top repositories
mist64’s repositories ranked by new stars, as on trending.
Contributes to
Repositories outside mist64’s account where mist64 opened or reviewed pull requests in the past 365 days.
Who noticed mist64
Everyone who starred or forked mist64’s repositories since the archive began in 2011.
Notable accounts
Ordered by the stars their own repositories have received.
Biggest fans
Accounts that starred the most of these repositories.
Breakout weeks
Each repository’s best week of new stars, with the release published around it.
- Gold
- 01st place finishes
- Silver
- 12nd place finishes
- Bronze
- 13rd place finishes
- Awarded repositories
- 1Owned by mist64 now
Repositories
Ordered by gold, then silver, then bronze.
- xhyveBest: 2nd by stars, 301 stars011
Every award
Top-three finishes of these repositories in completed trending days and weeks, newest first.
A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.
Mentions
> Just glancing at the source you could do easy 100x performance improvements with simple fixes. Now that you said this you really are expected to do a proof-of-concept implementation that is 100x faster, but with the same low-level concepts ;) I think 2..3x might be achievable assuming the vibe-coded code quality is really badly optimized, but definitely not 100x. As far as I understand the simulation, it does the entire address decoding and memory accesses as a transistor-level simulation (which is the whole point!), e.g. everything that happens outside the CPU, CIAs, SID and VIC-II. That means every single memory access has significant overhead because it is essentially simulated from a transitor netlist similar to how visual6502.org simulates the CPU (which even in an optimized C simulation like mist64/perfect6502 is still about 30x slower than a real 6502 at 1 MHz). PS: Let's do some simple napkin math: the Antirez simulator is 3x slower than a real C64, 100x faster would mean around 30x faster than a real C64, e.g. like a C64 clocked at 30 MHz. That means on a 3 GHz host CPU you would have 100 host clock cycles to emulate a (30Mhz) C64 system clock cycle, and that's for 5 complex chips (CPU + 2xCIA + VICII + SID), so around 20 host clock cycles per emulated cycle for each chip, and that doesn't include address decoding and memory access (which is the expensive part in Antirez's simulator). And moving the chip emulators into threads won't help you much here, because you'd need to synchronise at least once per emulated clock cycle (maybe even twice per emulated clock cycle because of the C64's phi-1 and phi-2 'half cycles'). Good luck with that :) (e.g. squeezing a complete VIC-II clock cycle which renders 8 pixels and may have up to 8 active sprites into 20 host system clock cycles, even with perfect pipelining, SIMD, and no cache misses this isn't a lot of host CPU instructions compared to what a VIC-II needs to do each cycle). (disclaimer: I'm the author of the pin-based chip emulators used in this experiment)