Hi,

I've trying FPC on an Vampire 4 SA machine with ApolloOS/AROS m68k.

Whenever I try to compile a pascal program (simple "Hello World" style)
the compiler stopps with an interal error message "Error: 1980-0-0 is
not a valid date specification".

My guess this is something between the OS (AROS/ApolloOS) and FPC.

Can anyone give me a clue how to debug this issue?

Greetings

Carsten

Hi Carsten,

Carsten Strotmann wrote

I've trying FPC on an Vampire 4 SA machine with ApolloOS/AROS m68k.

Which version of FPC are you trying? Trunk, 3.2.0 stable, you built your own, or you downloaded one of the official Amiga releases?

No, this is most likely the Vampire 4 or more specifically its FPGA CPU implementation ("Apollo core") being incompatible with a true m68k. Are you trying to use the SoftFPU or the hardware FPU version? This matters, because the TDateTime type maps to "Double" (64bit float) in the run time library, and the most problematic part of that CPU core is known to be the FPU, especially with higher precisions. The error you're getting is definitely coming from one of the TDateTime helper functions in the sysutils unit. (Search in rtl/objpas/sysutils/dati.inc.)

Can anyone give me a clue how to debug this issue?

It's entirely a speculation from my part, but if I can judge it by my past experiences trying to investigate issues reported by Vampire users, I doubt there's anything to debug in FPC in this regard.

If you're using the hardware FPU version, try using the SoftFPU version (which should be the default on m68k-amiga, actually).

Cheers,

Hello Charlie,

thanks for your help.

it's the one that comes pre-installed with the Vampire 4 SA. I really
like the fact that FPC comes pre-installed. It identifies itself as
3.2.0 (2020/06/13) (fpc binary is 112808 bytes)

is there a way to get this information from the installed binaries? As
FPC was pre-installed, I have no idea which version the Apollo developer
used.

I've downloaded 3.2.0a (SoftFPU) from the FreePascal website, and that
version works fine. So it might be a HardFPU version.

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?

It would be good it we can find the issue and report back to the Apollo
team, so that they can fix the pre-installed version.

Greetings

Carsten

Hi Carsten,

The "fpc" binary is just a compiler frontend. The actual binary is called "ppc68k", it must be hiding in there somewhere. The question is, is the compiler binary uses the FPU or not. It's nice that they preinstalled FPC, but it hardly got tested it seems.

I think judging by the date, it's probably the 3.2.0 release, which should be with the SoftFPU actually. But there's no way to tell without disassembling the binary and see if there are FPU instructions in it... Or trying to execute with the FPU disabled.

I've downloaded 3.2.0a (SoftFPU) from the FreePascal website, and that version works fine. So it might be a HardFPU version.

Or might be not. See below.

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

Cheers,

Hi Carsten,

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.

Cheers,

Hi Charlie,

So the root cause is, Amiga follows the non-Unix codepath for DateTimeToFileDate inside the sysutils unit, which is artificially limited to dates between 1980 and 2099:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/sysutils/dati.inc?annotate=47808#l1260

This is super old code, it was already there 15 years ago, at the time of the SVN import... I guess the original intention was to keep us compatibile with MSDOS/old FAT file timestamps, which can actually represent dates between 1980 and 2107. (So no idea where 2099 comes from... Because Windows actually counts file dates from 1601 (fix me?), and more modern FSes no longer have the limitation mentioned above anyway.)

Anyway, this means FileAge function for Amiga will return zero for dates before 1980, which then causes various havoc down the line. More specifically, later the compiler calls FileDateToDateTime from (see globals.pas filetimestring()) to print a debug message into the verbose log (normally thrown away, actually, but available as fpcdebug.txt with the -vv parameter), which then blows up in sysutils/EncodeTime, because zero is an invalid file timestamp actually as far s the MSDOS timestamp format is concerned, because you get zero as day and month (and year too, just the code adds 1980 anyway... :) )

Yuck. :P What a nice juicy can of worms... Found just because someone used a buggy LhA to decompress Free Pascal on Amiga... :D

I'm not touching this for any other platform, because ... Just no. :D But as the FileAge return value and the FileDate format should be OS specific, on the mid-run I'll migrate the Amiga code away from the non-Unix codepath, to something custom. Probably to something very similar to the Unix codepath, but counting the Epoch from 1978-01-01 instead of 1970-01-01... Or a packed/smaller version of the AmigaOS DateStamp structure. This has other advantages, for example the Amiga RTL will no longer be limited to 2 seconds resolution when working with file timestamps, another MS-DOS/FAT legacy coming from the generic code paths.

Thanks Carsten, for this report. As much as we usually get invalid reports regarding the Vampire, this was genuinely useful.

For now, please use the workaround I mentioned in my previous e-mail, because this will take a while to fix. I'll also try to get a quick fix into the compiler, to make it not blow up with an exception at least, because the compiler code seems to be prepared to work with invalid timestamps otherwise.

Cheers,

Hello Charlie,

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.

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