Hello Charlie,
Karoly Balogh (Charlie/SGR) <char...@scenergy.dfmk.hu> writes:
> Hi Carsten,
>
>>> I also see that the pre-installed version was installed with > the clock
>>> in the system was set to the start of the Amiga Time > (1.1.1978). Might
>>> that create a problem?
>>
>> Actually, yes. If I reset the timestamp of the system unit to 1978-1-1,
>> 00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my
>> system and installation (which is a real '060 + AmigaOS 3.1). So this
>> needs a two layer fix, first we need to fix it in our RTL, and second, it
>> would be nice if the Apollo people could not screw up the timestamps as
>> they install FPC into their distro. (They probably used a broken, older
>> version of LHA to extract the package, which is know to cause exactly this
>> issue. Or some Unix tool to package the OS install/image, which freaked
>> out from the Amiga timestamps.)
the Vampire 4 SA does not have a RTC build in, so the machine always
starts with the clock set to 1.1.1978. It is possible to add a 3 Euro
RTC via I2C, but that needs to be done. My guess is that the Apollo team
had used a machine with a clock not set when creating the Apollo OS
image.
>
> As a workaround/local fix on your system, you can try to just reset all
> file dates under the units/m68k-amiga/ to the current date. You can do
> this with the "SetDate" command. If you don't give it a date argument,
> only a file name (which can be a wildcard) it will reset the files'
> timestamp to the current time/date.
That worked. I've used the Unix approach with GeekGadgets/ADE Shell:
find FPC -exec touch {} \;
I will report this to the Apollo team and ask them to fix this issue on
the pre-installed CF-Card.
Thanks for your support.
Greetings
Carsten
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
