Re: [hatari-devel] GEMDOS HD vs. host timestamps (was: New Hatari release?)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 01/25/2018 10:25 PM, Uwe Seimet wrote:
> > by people before the release, and at some point take a better
> > look at how to handle GEMDOS HD vs. host timestamps.
>
> Yes, please do ;-).

You didn't reply to my other mails, so I'm commenting here.

You mentioned earlier that you're using TT, which means that
NVRAM RTC is active which already provides host clock inside
emulation.

However, it seems that TOS reads RTC only at boot, so after
that it will drift away from host clock.

Few of the programs I tried, didn't call any OS functions
to get time, so I assume they access system clock directly,
and it cannot be overridden when GEMDOS HD is enabled.


Problem is mixing programs doing:
1) file creation and
2) file timestamp checks

so programs doing 1) & 2) for given file aren't either:
- both on host, or
- both inside emulation.


Case A:
- 1) & 2) are both done inside emulation

-> everything works fine by default


Case B:
- 1) & 2) are both on host side

-> everything works fine by default

(from emulation point of view, file timestamps will be
in future after emulation is paused, and in past after
emulation is fast-forwarded.)


Case C:
- File creation is inside emulation
- Timestamp check is on host

-> everything should work fine after GEMDOS HD is told
to use host timestamps for files (--gemdos-time host).


Case D:
1. File creation is on host
2. Timestamp check is inside emulation, but gets
   clock through some OS functionality that can
   be overridden

-> should work fine if GEMDOS HD is told to use host
   timestamps for files

a) If 2) uses RTC directly, it works already fine

b) If 2) will use GEMDOS date/time functions, it
   could work fine with the patch I posted earlier.

Note: GEMDOS time functions have such a coarse
granularity that I think they're useless for
something like "make".


Case E:
- Program 2) uses uses something else for clock

-> Somebody wanting it to use host clock needs to
   debug what it actually uses for clock so that
   we can look whether it's feasible to support.

If not, only alternative is that somebody will
change that program to use OS functions for
timestamps.


	- Eero