|Re: [hatari-devel] GEMDOS HD vs. host timestamps (was: New Hatari release?)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On Dienstag, 6. Februar 2018 19:14:15 CET Eero Tamminen wrote:
I'm not Uwe, but i think i have to comment on it anyway ;)
> However, it seems that TOS reads RTC only at boot, so after
> that it will drift away from host clock.
That's not entirely true. It is read at boot, and on every Gettime() BIOS
call. It is not read however on Tgetdate()/Tgettime(). The Gettime() call will
update some private variables, which are incremented in the hz200 interrupt,
and returned by Tgetdate()/Tgettime().
> Case B:
> - 1) & 2) are both on host side
> -> everything works fine by default
And that is the case that is not working currently. Hatari reads the date/time
only once, then does its own increment. That will be updated much slower than
realtime, when using fast-forward. What happens is that the file is created on
the host filesystem (with the real date of the host). There is no explicit
Fdatime() call after that to set it to the current (GEMDOS) time, since it is
expected that this is already the case. The GEMDOS time however will be much
behind, and that is what every project management, be it PureC or make, will
Using --gemdos-time atari might fix that, but then you have files on the host
which you just created, but have dates in the past. That is actually nonsense.
No matter which setting you use, there will always be a discrepance between
current date, and timestamps of files just created.