> The timestamp of the file is not explicitly set by Pure-C when you save a
> file. Instead, it is assumed to be the same that Tgettime() returns. If
> Tgettime() returns something different (eg. because of fast-forward), those 2
> times will differ.
Correct me if I am wrong: Hatari uses the time returned by Tgettime()
whenever it updates a file in the Linux filesystem. Pure C does not
explicitly (later) set a new timestamp, i.e. the timestamp remains the one
set by Hatari based on Tgettime(). This is (with fast-forwarding) the
timestamp in the future.
If this is how it works, Hatari could (optionally) in a case where the
timestamp returned by Tgettime() is in the future replace this timestamp by
"now". That way in the Linux filesystem timestamps would never be in the
future. From the Atari (with fast-forwarding) perspective they would be in
the past, though. Maybe this would result in other issues?
I was thinking of something similar, the first thought was to start with year 1980,
the second was a command line year, then I saw your suggestion.
> I already mentioned that behaviour long time ago, thinking that a 200hz timer
> should always be 200Hz, regardless of emulation speed. But probably this would
> break lots of timing dependant tricks.
Having this behavior with a (non-default) option is useful IMO. I doubt that
regular programs (other than demos and games) use timing tricks, so users
that use Hatari for other purposes than running games or demos might profit
from such an option.