Atari m68k

[peters060]

I know ChainQ is aware of the problem but I wanted to make sure a wider audience was aware of it.

I did have a dig into the fpc code but couldn't identify where the units are loaded.

[marcov]

Try to remove tf_use_8_3,   in compiler/systems/i_atari.pas

[winni]

Hi!

There was never a Turbo Pascal  Version for the Atari ST. But you could run a MSDOS-Emulator and then use the DOS version of TP.

Pascal for Atari ST :

* UCSD Pascal, ported to Motorola 68000 by Focus, Hannover
* ST Pascal  from CCD (with the utils function EatSpaces )

The floppy disk layout was  the same as MSDOS but somewhere in the boot sector you hat to set a compatibility flag (bit).

Beware of using 8th bit for filenames: Beyond #127 Atari had its own idea where to put äüö and the others.

Winni

[MarkMLl]

There was never a Turbo Pascal  Version for the Atari ST. But you could run a MSDOS-Emulator and then use the DOS version of TP.

You miss my point. DR OSes, including CP/M-68K, didn't know about directories and that presumably affects the earliest versions of TOS. Software of that era including Turbo Pascal used fixed-length 8.3 filenames in FCBs and had no API for either changing directory or specifying that a file was in a particular directory.

Pascal for Atari ST :

* UCSD Pascal, ported to Motorola 68000 by Focus, Hannover
* ST Pascal  from CCD (with the utils function EatSpaces )

Plus Hisoft HighSpeed Pascal.

Beware of using 8th bit for filenames: Beyond #127 Atari had its own idea where to put äüö and the others.

Also some DR OSes and derivatives used the MSB of the 8.3 filename in the FCB to indicate special file access attributes. That's probably later than the TOS fork.

So I think what I'm really trying to say is that there are plentiful gotchas that can inflict any attempt to get something like FPC ported to an OS of that era... unless it really has been augmented with a unix-like (or at least MS-DOS v3 like) API. And I've done enough support etc. work to know just how difficult the OS imitation game can be.

MarkMLl

[peters060]

This is the error:

# ./fpc.ttp  -Wtmint -Sg  /usr/src/gemical/gemical.pas
Free Pascal Compiler version 3.3.1 [2022/03/13] for m68k
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Atari ST/STE
Compiling /usr/src/gemical/gemical.pas
Compiling /usr/src/gemical/mainical.pas
mainical.pas(86,5) Fatal: Can't find unit djLogOverSimpleLogger used by MainIcal
Fatal: Compilation aborted
Error: ppc68k.ttp returned an error exitcode


The src code is on ext2 partition and the filename is djLogOverSimpleLogger.pas

The fpc.cfg is:

-l
-view
#-Xs
-O2
-FDbin
-Fu/f/Applications/fpascal/units/atari/*

[winni]

You miss my point. DR OSes, including CP/M-68K, didn't know about directories and that presumably affects the earliest versions of TOS. Software of that era including Turbo Pascal used fixed-length 8.3 filenames in FCBs and had no API for either changing directory or specifying that a file was in a particular directory.

Hi!

Forget about DR and CP/M in relation with the Atari ST. The TOS was a simply clone  of MSDOS concerning  the file system. You could read and write MSDOS floppies if you set the compatibility flag. You could create, delete and rename directories. Either on the GEM desktop or on the TOS command line.

And you could allocate nearly all of your RAM (1 MB!!!) in one array which was a great progess. In opposite with the missdesigned 386 where you could only allocate chunks of 64 kB, which lead to lists of 64 kB chunks in Turbo Pascal on DOS.

Winni

[peters060]

  I'm running Freemint and it's on a 68060@60MHz.

[PascalDragon]

I know ChainQ is aware of the problem but I wanted to make sure a wider audience was aware of it.

A wider audience isn't helping if a person that needs to implement it is to be someone that has knowledge about Atari's long file name support and I'd wager that nearly everyone here does not have that.

I did have a dig into the fpc code but couldn't identify where the units are loaded.

The compiler is simply using what the RTL provides. You need to implement the correct handling in rtl/atari/sysfile.inc and rtl/atari/sysdir.inc and then the compiler will implicitely pick it up as well when it's rebuild with the adjusted RTL.

Try to remove tf_use_8_3,   in compiler/systems/i_atari.pas

That's not helping as long as the long file name support is not implemented in the Atari RTL.

[winni]

Hi!

If someone has old docs or filenames with the Atari-ST-homebrew 8th bit - here is the glyph table for all chars from #0 to #255. Between #32 and #127 it is ASCII

Winni

[peters060]

@PascalDragon

So fpc uses the rtl to find the units for compilation ?

It looks like the atari rtl uses the gemdos calls so maybe it would have to be extended with something freemint compatible.  I don't know how freemint handles long filenames.

I will see what I can learn.

Thanks

[PascalDragon]

So fpc uses the rtl to find the units for compilation ?

The compiler completely relies on the RTL for file access and directory iteration. So if you fix it so that long filenames work for normal applications they should also work for the compiler (aside from maybe some setting like marcov mentioned).

[MarkMLl]

So fpc uses the rtl to find the units for compilation ?

The compiler completely relies on the RTL for file access and directory iteration. So if you fix it so that long filenames work for normal applications they should also work for the compiler (aside from maybe some setting like marcov mentioned).

For OP's benefit, I think the important point here is that it doesn't rely on any external make program with its own path handling.

From the POV of somebody interested in the overall family of DR OSes, the documentation I've seen suggests that TOS/GEMDOS moved away from the FCB-based API fairly early but it doesn't explicitly document (i.e. in https://freemint.github.io/tos.hyp/en/gemdos_file.html#Fopen etc.) what the limitations are.

MarkMLl