Fredrick Meunier

I think it's more likely to be mainly about the sound driver than estimation slips on reset.

I investigated this using a local image whose layout matches the report (236032 bytes, CRC32 684b0a6e, EDSK creator field “Moxon's Backup”). The evidence points to missing data in this image rather than unsupported weak sectors: Tracks 1–17 each contain a nominal 8192-byte sector with 6144 bytes stored. Tracks 18–20 are explicitly unformatted. Disassembling the loader shows it treats each track as 6144 usable bytes, advancing to the next cylinder as needed. All preceding 12 file payloads match their...

Document the full check-local test set in contributor notes

Applied in [040a36].

Document the full check-local test set in contributor notes (patch #532)

Hi Vic, I'm happy to commit them on a branch if it helps, which order do they go in?

Could you try this build to see if it fixes the problem? https://www.dropbox.com/scl/fi/thbczj1i217khx4mybg81/Fuse.zip?rlkey=ckwctb45xa60thkke6p8oinbj&dl=0

🤖 This is an automated response from Repo Assist. The speed spike after a machine reset comes from the speed estimator, not from the machine timing. machine_reset_from_snapshot() resets the machine and modules but leaves the timer's rolling speed-sample ring untouched. After a reset samples is still 10 and next_stored_time points at a recent pre-reset sample, so timer_estimate_speed() computes 1000 / (current_time - old_sample) — thousands of percent right after reset — and the displayed value decays...