Feature request
Option to pin the emulated Mac's real-time clock to the
host clock, so wall-clock time inside the guest doesn't run fast while
fast-forward is active.
Current behavior
Fast-forward accelerates the entire emulated machine — which means clock time advances
N× faster than reality too. After a development session with fast-forward on
(I use it to speed up THINK C compiles on an emulated IIx), the Mac's clock had
drifted ~40 minutes ahead of the host.
The drift has knock-on effects outside the guest: every file the Mac writes to
a shared disk image gets a future timestamp. When you later start a new Snow session,
it's confusing to find some files might have Modified timestamps in the (near) future.
(In my particular case, this breaks some make-style workflows I built using hfstools to
keep some 68k C source files synced between my host and guest.)
'Limit fast-forward speed' and 'Dynamic fast-forward' (nice feature thanks)
reduce the rate of drift and probably fixes this issue for interactive games, but
don't elimiate it.
Proposed behavior
An option like:
Options -> Speed -> [ ] Keep clock in real time during fast-forward
When enabled, the RTC's one-second tick would fire on host wall-clock time
rather than emulated time, so the guest's clock stays correct no matter how
fast the machine itself runs. This should include Ticks and Time Manager checks so that
for instance an emulated process using _Microseconds (which presumably is trying
to run something e.g. a game based on clock time) runs at the proper non-fast-forward
speed, whereas code running in a tight loop runs as fast as possible under fast forward.
I think this is how Mini vMac and Basilisk II work, though admittedly that's just based on
anecdote, I haven't checked.
Environment
- Snow v1.4.1, macOS host
- Emulated Macintosh IIx, System 7.5.5
Happy to test a build. Thanks for Snow. This is suddenly my daily emulator of choice.
Feature request
Option to pin the emulated Mac's real-time clock to the
host clock, so wall-clock time inside the guest doesn't run fast while
fast-forward is active.
Current behavior
Fast-forward accelerates the entire emulated machine — which means clock time advances
N× faster than reality too. After a development session with fast-forward on
(I use it to speed up THINK C compiles on an emulated IIx), the Mac's clock had
drifted ~40 minutes ahead of the host.
The drift has knock-on effects outside the guest: every file the Mac writes to
a shared disk image gets a future timestamp. When you later start a new Snow session,
it's confusing to find some files might have Modified timestamps in the (near) future.
(In my particular case, this breaks some make-style workflows I built using hfstools to
keep some 68k C source files synced between my host and guest.)
'Limit fast-forward speed' and 'Dynamic fast-forward' (nice feature thanks)
reduce the rate of drift and probably fixes this issue for interactive games, but
don't elimiate it.
Proposed behavior
An option like:
When enabled, the RTC's one-second tick would fire on host wall-clock time
rather than emulated time, so the guest's clock stays correct no matter how
fast the machine itself runs. This should include Ticks and Time Manager checks so that
for instance an emulated process using _Microseconds (which presumably is trying
to run something e.g. a game based on clock time) runs at the proper non-fast-forward
speed, whereas code running in a tight loop runs as fast as possible under fast forward.
I think this is how Mini vMac and Basilisk II work, though admittedly that's just based on
anecdote, I haven't checked.
Environment
Happy to test a build. Thanks for Snow. This is suddenly my daily emulator of choice.