Skip to content

Wait for 50ms after reset (fixes #7) #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
drfiemost wants to merge 1 commit into from
Closed

Wait for 50ms after reset (fixes #7) #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion exSID.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -557,7 +557,9 @@ int exSID_reset(void * const exsid)

xsdbg("reset\n");

xSoutb(xs, XS_AD_IOCTRS, 100); // this will stall
// This will stall and sleep for 50ms
// Reset needs some time to complete
xSoutb(xs, XS_AD_IOCTRS, 50000);
Copy link
Member

@f00b4r0 f00b4r0 Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK so I'm afraid I really can't make any sense of such a large delay. The internal delay routine executes in exactly 22 SID clock cycles, or 22µs. Nothing should require a 50ms delay.

; Reset IOCTL
; Trigger hardware SID reset
; Execution time: 1 SIDCLKs (+reset time)
; This will result in 1+20+1 SIDCLKs minimum total time (reset loop + rsync)

I can't reproduce this locally which doesn't help for debugging. Can you check if a more reasonable value works for you? Say start with a 10x increase on the current value, i.e. 1ms? That should be plenty enough already. If the delay length really helps then I wonder if we're dealing with a weird nanosleep() implementation that doesn't handle low values nicely?

I also do not understand how that fixes #7 since you mention there that the bug also occurs during init(), and reset() isn't called in init()? The provided backtrace doesn't involve reset() either. Can you elaborate? Thanks.


xs->clkdrift = 0;

Expand Down
Loading