Re: [hatari-devel] GEMDOS HD vs. host timestamps

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 02/06/2018 08:41 PM, Uwe Seimet wrote:
> 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,

I assume you mean saving source from host, while emulation is
running in fast-forward 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.

I assume you mean that it will re-compile the source even if it had
compiled the modified source already earlier.  If you're using
"--gemdos-time host", that will only sync file modification date
with the host.

However, if Pure-C doesn't check the object file timestamp, but
relies on internal clock time for when it compiled the object,
it cannot work.

Unless you *re-invoke* Pure-C, then it does need to check
the file timestamps for time comparison.


Btw. When I'm using host editor to edit sources that I compile with
Atari native compiler, I invoke Hatari separately for each compile.

Latest EmuTOS boots so fast with fast-forward, that doing a separate
Hatari invocation for building is fast.

Only issue is transferring the correct project file name to compiler
inside emulation.  I've been using a script that writes the Atari
command line to a (Gulam) shell startup script, and then asks Hatari
to run (Gulam) shell.

However, nowadays one could use just the hatari-prg-args.sh script
from Hatari tools/-directory for that.


There are also some other ways to automate that (e.g. scripting
Hatari hconsole).


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

Is that with SDL1 or SDL2 build of Hatari?

(SDL1 is known to be very slow on some MacOS versions.)


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

Has somebody else seen that?


	- Eero

> 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