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