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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Actually, I just expect Pure C to work with Hatari like it does with a
real TT ;-). As far as saving the source is concerned I am doing
*everything* within the Pure C editor. I do not edit anything on the
host, it's all within the emulation.

Regarding the macOS build I was using the one from
http://download.tuxfamily.org/hatari/2.0.0/ on macOS El Capitan. I don't
know which SDL version is used here.

Regarding other users with the same problem I think Götz Hoffart also
mentioned it. Götz, not sure whether you are on this mailing list?

Best regards

Uwe

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