On Samstag, 12. Februar 2022 12:51:11 CET Florian Klämpfl via fpc-devel wrote:
> I think it must be tried, in practice one hits also some strange obstacle
> one never things before ... I would also expect that the former works and
> is the better solution though it requires also that the CPU/FPU/AB
> Am 12.02.2022 um 11:46 schrieb Karoly Balogh :
>
> Hi,
>
> On Sat, 12 Feb 2022, Florian Klämpfl via fpc-devel wrote:
>
My config file has -Tatari set, so the LINUX define is no issue. But if
i invoke the compiler without excplicit -Cp, it will generate code
for 68000, but take
Hi,
On Sat, 12 Feb 2022, Florian Klämpfl via fpc-devel wrote:
> >> My config file has -Tatari set, so the LINUX define is no issue. But if
> >> i invoke the compiler without excplicit -Cp, it will generate code
> >> for 68000, but take the libraries from the 68020 directory. It works as
> >> inte
Am 12.02.2022 um 10:54 schrieb Karoly Balogh via fpc-devel:
Hi,
On Sat, 12 Feb 2022, Thorsten Otto via fpc-devel wrote:
I'm currently trying to set this up and have a problem with the
cross-compiler. Although that was configured for atari and 68000, it
still has LINUX and CPU68020 defined whil
Hi,
On Sat, 12 Feb 2022, Thorsten Otto via fpc-devel wrote:
> I'm currently trying to set this up and have a problem with the
> cross-compiler. Although that was configured for atari and 68000, it
> still has LINUX and CPU68020 defined while processing the config file.
That probably can't be hel
On Montag, 7. Februar 2022 14:09:00 CET Sven Barth via fpc-devel wrote:
> A FPC compiled for 68020 can generate 68000 code just fine and the other way
> round (assuming of course that it was compiled without bugs ;) ). It's just
> that you need to provide it with the correctly compiled units. You c
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > but going with this would probably mean giving up TOS support.
>
> Yes, that 8.3 restriction might be the worst that was ever made. But
> even unices of that time allowed only 14 character long filenames.
It is also the main reason w
On Montag, 7. Februar 2022 14:34:12 CET Karoly Balogh wrote:
> but going with this would probably mean
> giving up TOS support.
Yes, that 8.3 restriction might be the worst that was ever made. But even
unices of that time allowed only 14 character long filenames.
I think you should not care abou
Hi,
On Mon, 7 Feb 2022, Karoly Balogh via fpc-devel wrote:
> Not under mind, but going with this would probably mean
> giving up TOS support.
*Not under MINT, I mean, sorry for the typo.
Charlie
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > It's just that you need to provide it with the correctly compiled units
>
> Yes, i see. But that requires some manual fiddling with the library
> directories, and you need both 68000 and 68020 versions somehow.
>
> How do the Amiga fo
On Montag, 7. Februar 2022 14:09:00 CET Sven Barth via fpc-devel wrote:
> It's just that you need to provide it with the correctly compiled units
Yes, i see. But that requires some manual fiddling with the library
directories, and you need both 68000 and 68020 versions somehow.
How do the Amiga
Thorsten Otto via fpc-devel schrieb am
Mo., 7. Feb. 2022, 13:00:
> In the long term, it would be nice to have some automatic selection of the
> correct libraries. Otherwise it will not be possible to produce 68k
> binaries with a compiler that was compiled for 68020, since that will still
> pull
On Montag, 7. Februar 2022 13:39:49 CET Karoly Balogh wrote:
> Is the compiler binary itself a 68020 or a 68000 binary?
All i changed was using
make zipinstall OS_TARGET=atari CPU_TARGET=m68k 'CROSSOPT=-Cp68020 '
so i think that should be a 68020 binary?__
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
>
> > Nice, that's it. Compiling everything for 68020, and it works.
>
> Hm, or maybe not. A few hours later, installing a freshly compiled
> version, i get th
On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
> Nice, that's it. Compiling everything for 68020, and it works.
Hm, or maybe not. A few hours later, installing a freshly compiled version, i
get that internal error again. Damn. Must be some other kind of randomness
inv
On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
> because the default has changed only recently.
That reminds me of another problem: if i'm not wrong, the compiler does not
use different sets of libraries depending on whether your are compiling for
68020 or not. That m
On Montag, 7. Februar 2022 09:46:50 CET Karoly Balogh wrote:
> Does it also happen, when you compile everything for the 68020?
> (-Cp68020)
Nice, that's it. Compiling everything for 68020, and it works. Thats strange.
But that also explains why it worked a few days ago, because the default has
c
Hi,
On Sun, 6 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > - Running the same binaries in SingleTOS, they both give me "Internal
> > error 2004121202'. Then they both crash with a bus-error, too.
>
> That internal error is currently striking back. This happens both with
> my own compiled bina
On Freitag, 28. Januar 2022 18:04:12 CET Thorsten Otto via fpc-devel wrote:
> - Running the same binaries in SingleTOS, they both give me "Internal error
> 2004121202'. Then they both crash with a bus-error, too.
That internal error is currently striking back. This happens both with my own
compil
Hi,
On Tue, 1 Feb 2022, Thorsten Otto via fpc-devel wrote:
> On Dienstag, 1. Februar 2022 09:11:21 CET Pierre Muller via fpc-devel wrote:
>
> > thus you should use
> > -Aas-out
> > compiler option.
>
> Ah thx. Would make more sense to just use "as" like for other targets,
> but i see that this ta
On 2022-02-01 06:02, Thorsten Otto via fpc-devel wrote:
On Samstag, 29. Januar 2022 16:03:32 CET Tomas Hajny via fpc-devel
wrote:
does it return individual characters, or does it
return the whole line at once (the latter being the case for other FPC
targets as far as I know)?
Just tried with
On Dienstag, 1. Februar 2022 09:11:21 CET Pierre Muller via fpc-devel wrote:
> thus you should use
>-Aas-out
> compiler option.
Ah thx. Would make more sense to just use "as" like for other targets, but i
see that this target is also used for amiga.
___
Le 01/02/2022 à 06:28, Thorsten Otto via fpc-devel a écrit :
On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
> Then i tried -Aas, but then the compiler also complains:
>
>
>
> Warning: (treated as error) Assembler output selected "AS" is not compatible
>
On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
> Then i tried -Aas, but then the compiler also complains:
>
>
>
> Warning: (treated as error) Assembler output selected "AS" is not compatible
> with "Atari ST/STE"
>
> Warning: (treated as error) "VASM" assembler use
On Samstag, 29. Januar 2022 16:03:32 CET Tomas Hajny via fpc-devel wrote:
> does it return individual characters, or does it
> return the whole line at once (the latter being the case for other FPC
> targets as far as I know)?
Just tried with a small test program, and the behaviour is a bit stran
On 2022-01-29 15:05, Thorsten Otto via fpc-devel wrote:
On Samstag, 29. Januar 2022 14:55:30 CET Karoly Balogh wrote:
Yes, but changing this is not trivial in platform independent code,
It doesn't have to, if it can be fixed in fpc_readln_end().
Maybe Sven or someone can say more about the
On Samstag, 29. Januar 2022 14:55:30 CET Karoly Balogh wrote:
>Yes, but changing this is not trivial in platform independent code,
It doesn't have to, if it can be fixed in fpc_readln_end().
> Maybe Sven or someone can say more about the Windows analogy, I'm not
> familiar there.
Thats somethin
Hi,
On Sat, 29 Jan 2022, Thorsten Otto via fpc-devel wrote:
>> Again, this isn't a generic problem, but Atari specific.
>
> Yes, but theoretically, win32 should have the same problem. As far as
> i've seen, ReadFile() is used there. but fpc_readln_end() tries to read
> until it encounters a LF, a
On Samstag, 29. Januar 2022 13:41:24 CET Karoly Balogh via fpc-devel wrote:
> Additionally, for extending the OS interfaces, you probably also want to
> look into packages/tosunits.
Yes, thanks, i've seen that already. I has a few more functions than in rtl/
atari/, but still some functions missin
On Samstag, 29. Januar 2022 13:13:08 CET Karoly Balogh wrote:
> . I think this is the main issue, as
> I've seen GEMDOS has special calls for console I/O which are not being
> utilized now.
Yes, but when using standard handles 0 and 1, Fread() should work the same.
There should be no need to call
Hi,
On Sat, 29 Jan 2022, Karoly Balogh via fpc-devel wrote:
> > There are other parts that should be improved, and seem more important
> > to me (like ARGV support, completing the GEMDOS/BIOS/XBIOS interface
> > etc)
>
> Totally agree here.
Just one more note here, for the ARGV support, general
Hi,
On Sat, 29 Jan 2022, Thorsten Otto via fpc-devel wrote:
> On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
>
>> a fixed GAS/LD support would be nice, of course.
>
> Yes, but currently i'm a bit lost here. Since that combination currently
> does not support "smart linking", i gues
Am 29.01.2022 um 09:24 schrieb Thorsten Otto via fpc-devel:
On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
> a fixed GAS/LD support would be nice, of
> course.
Yes, but currently i'm a bit lost here. Since that combination
currently does not support "smart linking", i guess i'
On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
> a fixed GAS/LD support would be nice, of
> course.
Yes, but currently i'm a bit lost here. Since that combination currently does
not support "smart linking", i guess i'll stick to vasm for now. There are
other parts that should be i
Hi,
On Fri, 28 Jan 2022, Thorsten Otto via fpc-devel wrote:
> On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
>
> > i still want to try to figure out what's wrong when using gas/ld)
> I get the the feeling that there must be something else going wrong:
>
> - when i ru
Am 28.01.2022 um 18:04 schrieb Thorsten Otto via fpc-devel:
The error number comes from def_system_macro, when it is invoked with
an empty name. The crash seems to happen in system.o, during
initalization. The external name of the procedure is
'SYSTEM_$$_RECORDRTTI$POINTER$POINTER$TRTTIPROC'
On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
> i still want to try to figure out what's wrong when using gas/ld)
I get the the feeling that there must be something else going wrong:
- when i run the binary compiled by using vasm/vlink in mint, it works
- when i run
Now that vasm is the default, how do i switch back to gas (i still want to try
to figure out what's wrong when using gas/ld)?
I tried -Agas, but then the compiler complains about an illegal parameter (so
at least the help message seems to be wrong).
Then i tried -Aas, but then the compiler also
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> > And of course i have to find out what causes vlink to put that strange
> > program flags in the header.
>
> I think i found the reason for that. The offending lines in vlink/main.c are:
> (...)
> (at this point the option argument ha
On Dienstag, 25. Januar 2022 14:45:07 CET Thorsten Otto via fpc-devel wrote:
> And of course i have to find out what causes vlink to put that strange
> program flags in the header.
I think i found the reason for that. The offending lines in vlink/main.c are:
if (!strcmp(&argv[i][5],"
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 14:45:
> >If I'm not mistaken, GCC for
>
> >Atari used to have some tool like this? Brownout, maybe?
>
>
>
> Yes, but i never used that "brown" tool. For one, i don't like its
> confusing naming convention (depending on gcc version, it is
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> Yes, but i never used that "brown" tool. For one, i don't like its
> confusing naming convention (depending on gcc version, it is "brown",
> "extrabrown", "superbrown" etc). But more importantly, it needs an extra
> tool to be run afte
On Dienstag, 25. Januar 2022 14:07:52 CET Sven Barth via fpc-devel wrote:
> Can it be that you forgot to write some reply here, Thorsten?
Hmpf, dunno what happened, so once again.
>If I'm not mistaken, GCC for
>Atari used to have some tool like this? Brownout, maybe?
Yes, but i never used that "
Hi,
Am 25.01.2022 um 11:50 schrieb Thorsten Otto via fpc-devel:
On Dienstag, 25. Januar 2022 11:27:11 CET Marcus Sackrow via fpc-devel
wrote:
> hmm what do you mean? I wrote it, of course.
But is that a script that is stored somewhere, or is it just a setting
inside your Jenkins installation?
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 13:03:
> On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote:
>
> > Hi,
>
> >
>
> > On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
>
> > > Yes, a.out support (which is used on Atari) has been dropped in 2.31.
>
> > > Bu
On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote:
> Hi,
>
> On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> > Yes, a.out support (which is used on Atari) has been dropped in 2.31.
> > But i've added it back in, and cross-binutils of 2.34 can be found at
> > http://tho-otto.d
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> Yes, a.out support (which is used on Atari) has been dropped in 2.31.
> But i've added it back in, and cross-binutils of 2.34 can be found at
> http://tho-otto.de/crossmint.php#binutils
Won't really help. As you found out already, sec
On Dienstag, 25. Januar 2022 11:27:11 CET Marcus Sackrow via fpc-devel wrote:
> hmm what do you mean? I wrote it, of course.
But is that a script that is stored somewhere, or is it just a setting inside
your Jenkins installation?
>newer ld support that but they can't be compiled for m68k anymore
Hi,
Am 25.01.2022 um 11:37 schrieb Thorsten Otto via fpc-devel:
On Dienstag, 25. Januar 2022 11:07:35 CET Sven Barth via fpc-devel wrote:
> For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then
Thanks. I'm sure that i already tried that, and it did not work. But
maybe i did s
On Dienstag, 25. Januar 2022 11:07:35 CET Sven Barth via fpc-devel wrote:
> For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then
Thanks. I'm sure that i already tried that, and it did not work. But maybe i
did something wrong, trying it again (without the symlinks) seems to work
Hi Thorsten,
Am 25.01.2022 um 10:54 schrieb Thorsten Otto via fpc-devel:
> yes the Atari version is compiled by Jenkins every commit
> https://build.alb42.de:8081/job/FPC_m68k-atari/ (to make sure the
> changes does not break the target) it uses the command line:
Yes, i saw the console outpu
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 10:54:
> > the prefix $CPU-$OS is just the default prefix for every cross
>
> > compiling, if you need an other, you can supply it with e.g.
>
> > -XPm68k-atari-mint-
>
>
>
> Yes, found that already. But there is also at least one assembl
Hi Marcus,
thanks for your answers.
> yes the Atari version is compiled by Jenkins every commit
> https://build.alb42.de:8081/job/FPC_m68k-atari/ (to make sure the
> changes does not break the target) it uses the command line:
Yes, i saw the console output already. What i could not figure out ye
Hi,
Am 24.01.2022 um 11:03 schrieb Thorsten Otto via fpc-devel:
(I'm new to this list so please forgive me if i'm asking questions
that have already been answered elsewhere, and just point me to the
right direction)
very unlikely, since we implemented that atari interface there was
little fe
Hi
(I'm new to this list so please forgive me if i'm asking questions that have
already been answered elsewhere, and just point me to the right direction)
Inspired by some thread on the atari-forum (https://www.atari-forum.com/
viewtopic.php?f=16&t=41476&sid=cd858e109f7cd4f1cae6c597ea35b66f )
i
55 matches
Mail list logo