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

[ Thread Index | Date Index | More Archives ]


On 02/08/2018 09:24 AM, Uwe Seimet wrote:
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.

Oh, I think that's first time you've mentioned that...

In that case, I guess the problem is that Pure-C doesn't
set Atari timestamp to the files, but does check their
modification timestamp against Atari time.

Can you verify with "--trace gemdos" whether Pure-C does
Fdatime() calls for the edited files or not?

GEMDOS HD emulation cannot itself call TOS to get TOS
clock value, so I guess I need to do something like this:

* When GEMDOS is initialized, get host time (as time_t)
and Atari _hz_200 values.

* Whenever file is created or changed through GEMDOS HD:
  - calculate how much host time and _hz_200 values have
    drifted apart
  - adapt file modification timestamp for that difference

	- Eero

Regarding the macOS build I was using the one from 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


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



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

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

	- Eero

Mail converted by MHonArc 2.6.19+