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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Sorry, I may have missed some mails.

I do not know which of the methods Pure C (this is where I observed the
timestamp problem) uses (I guess it's GEMDOS calls only), but the problem
is worst in fast-forward mode.
When I save a C source file in fast-forwared mode, Pure C's make does
not notice for minutes that the file was successfully compiled. I. e. I
can trigger the make process minutes after saving the file, and it will
still recompile the file.

By the way, I (also) don't think that this is important enough to block
the upcoming release. I stumbled upon something else, which I consider
more inconvenient: I recently used Hatari (latest binary version) on the
Mac, and noticed that the Atari mouse pointer is extremely out of sync
with the actual macOS mouse pointer.
I'm not sure, but the macOS binary distribution is not official, is it?
Anyway, I am not a Mac user, but if I were the out of sync mouse pointer
would be a big issue for me. Is the upcoming release going to provide a
better behavior?

Best regards

Uwe

> 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
> 
>