Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Atari » Atari ST » Eureka 2.12 is 30 years old
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Eureka 2.12 is 30 years old [message #337641] Fri, 17 February 2017 17:00 Go to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

The principal software that I'm developing since 1987, is 30 this year.

30 years ago, Michael Jackson releases his hit album "Bad" etc. I had an
ATARI 1040STf, followed by a MegaSTe4 (91), a Falcon030 (93) and a
Hades060 (96) that was the first in France - I still have the 2 latest -
I mainly used those computers for developing since 2003, when I had a
PowerMac G4, because I'm concerned by the ARAnyM GNU/GPL developments
to continue my activities.

Nowadays, the evolution of ATARI developers' world, implies that I can't
continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
old sources in C language. The hope will come from the AHCC compiler,
thanks to its PURE C compatibility, and Coldfire code generation ...

In order to really understand that, the ATARI company is 45 years old.
ATARI begun to sell computers that we know, only 30 years ago. I
started programming 35 years ago, because I first have a Sinclair.
I bought an ATARI ST knowing the personal information technologies.

I still have it <http://www.flickr.com/photos/le_coat/6412802499/>

Because Eureka 2.12 was germinating on my former ZX81. It was the
very beginning of individual information technologies. The amount
of very different computer models was really vast. We only have
one computer today, that was promoted by the richest man on Earth =(
Can somebody be fully satisfied with this evolution ? I'm not really.

Do you still run ATARIs ? I do it, even for professional usage =)

Best regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338096 is a reply to message #337641] Wed, 22 February 2017 17:40 Go to previous messageGo to next message
Miro Kropáček is currently offline  Miro Kropáček
Messages: 23
Registered: November 2012
Karma: 0
Junior Member
> Nowadays, the evolution of ATARI developers' world, implies that I can't
> continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
> old sources in C language.
You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?

Either fix your code or use the older gcc versions, you're free to continue your programming. ;)
Re: Eureka 2.12 is 30 years old [message #338097 is a reply to message #338096] Wed, 22 February 2017 18:21 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Miro Kropáček writes:
>> Nowadays, the evolution of ATARI developers' world, implies that I can't
>> continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
>> old sources in C language.
>
> You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
>
> Either fix your code or use the older gcc versions, you're free to continue your programming. ;)

What worries me the most, is that there's no 16bits integer type. The
C language is inappropriate for 16/32bits ATARI machines. It would have
been convenient if Motorola had maintained the 68k processors series,
but it was abandoned. There's no need to renew the C semantic, because
the machines didn't evolved. I don't want to put all my code up-side-
down because it's 30 years old, and I began learning Kernighan and
Ritchie in 1987.

So, of course I will continue using GNU/GCC 3.3.6, but it's not
maintained for ATARI old sources like mine. There's no cross-tools.

The situation where I'm arrived has a name : programmed obsolescence.
That means that all is done for the younger generation to forget what
was done before them. The information technology has no history, no
memory, no past !

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338470 is a reply to message #338097] Sun, 26 February 2017 07:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Michael Schwingen

On 2017-02-22, Francois LE COAT <lecoat@atari.org> wrote:
>> You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
>>
>> Either fix your code or use the older gcc versions, you're free to continue your programming. ;)
>
> What worries me the most, is that there's no 16bits integer type. The
> C language is inappropriate for 16/32bits ATARI machines.

Huh?

Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.

cu
Michael
Re: Eureka 2.12 is 30 years old [message #338471 is a reply to message #338470] Sun, 26 February 2017 07:47 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Michael Schwingen writes:
> Francois LE COAT wrote:
>>> You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
>>>
>>> Either fix your code or use the older gcc versions, you're free to continue your programming. ;)
>>
>> What worries me the most, is that there's no 16bits integer type. The
>> C language is inappropriate for 16/32bits ATARI machines.
>
> Huh?
>
> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
> (4.6.4) - it is called "short", just like expected.

Replacing integer type (int) by short type (short) in my 30 years old
sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
4.2 and later don't have this 16bits int type. This is a cruel lack =(

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338485 is a reply to message #338471] Sun, 26 February 2017 10:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Michael Schwingen

On 2017-02-26, Francois LE COAT <lecoat@atari.org> wrote:
>>> What worries me the most, is that there's no 16bits integer type. The
>>> C language is inappropriate for 16/32bits ATARI machines.
>>
>> Huh?
>>
>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>> (4.6.4) - it is called "short", just like expected.
>
> Replacing integer type (int) by short type (short) in my 30 years old
> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
> 4.2 and later don't have this 16bits int type. This is a cruel lack =(

Huh?

"short" *is* an integer type, so gcc has what you need. If using "short"
does not work, your code is buggy in other areas and simply needs to be
debugged/fixed - this is not gcc's fault.

I can accept that you don't want to do that work, but again: that is your
decision and not gcc's fault.

cu
Michael
Re: Eureka 2.12 is 30 years old [message #338486 is a reply to message #338485] Sun, 26 February 2017 11:00 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Michael Schwingen writes:
> Francois LE COAT wrote:
>>>> What worries me the most, is that there's no 16bits integer type. The
>>>> C language is inappropriate for 16/32bits ATARI machines.
>>>
>>> Huh?
>>>
>>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>> (4.6.4) - it is called "short", just like expected.
>>
>> Replacing integer type (int) by short type (short) in my 30 years old
>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>
> Huh?
>
> "short" *is* an integer type, so gcc has what you need. If using "short"
> does not work, your code is buggy in other areas and simply needs to be
> debugged/fixed - this is not gcc's fault.
>
> I can accept that you don't want to do that work, but again: that is your
> decision and not gcc's fault.

If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
or later, I would appreciate de retro-compatibility with the ATARI ST.
But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12
software. The retro-compatibility with the ATARI ST is not maintained.

The problem is really with the "programmed obsolescence" with GNU/GCC 4,
and people developing the ATARI target. They forget that ATARI ST is
a 16/32bits architecture, and the "integer" type should be proposed as
a 16bits type. This is a matter of adequacy from the language with the
target. A 32bits integer type is far too demanding for an ATARI 520ST
with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.

Please notice that my software Eureka 2.12 runs on the early 520ST =)
Most of the ATARI software produced today are not, you can check it.
The software generated with AHCC have more chance to run with ATARI ST.

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338506 is a reply to message #338486] Sun, 26 February 2017 17:22 Go to previous messageGo to next message
Miro Kropáček is currently offline  Miro Kropáček
Messages: 23
Registered: November 2012
Karma: 0
Junior Member
Do you realise you're mixing gcc, mintlib and mint issues into one bag?

There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.

So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.

I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.

Anyway, your blaming of developers/applications is totally off.

Dňa pondelok, 27. februára 2017 2:00:28 UTC+10 Francois LE COAT napísal(-a):
> Hi,
>
> Michael Schwingen writes:
>> Francois LE COAT wrote:
>>>> > What worries me the most, is that there's no 16bits integer type. The
>>>> > C language is inappropriate for 16/32bits ATARI machines.
>>>>
>>>> Huh?
>>>>
>>>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> (4.6.4) - it is called "short", just like expected.
>>>
>>> Replacing integer type (int) by short type (short) in my 30 years old
>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>
>> Huh?
>>
>> "short" *is* an integer type, so gcc has what you need. If using "short"
>> does not work, your code is buggy in other areas and simply needs to be
>> debugged/fixed - this is not gcc's fault.
>>
>> I can accept that you don't want to do that work, but again: that is your
>> decision and not gcc's fault.
>
> If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
> or later, I would appreciate de retro-compatibility with the ATARI ST.
> But these 16bits versions of MiNTlib, GEMlib etc. are not still
> maintained ... You would say that it is "buggy" or something else,
> but it is simply 30 years old, such as the sources of my Eureka 2.12
> software. The retro-compatibility with the ATARI ST is not maintained.
>
> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
> and people developing the ATARI target. They forget that ATARI ST is
> a 16/32bits architecture, and the "integer" type should be proposed as
> a 16bits type. This is a matter of adequacy from the language with the
> target. A 32bits integer type is far too demanding for an ATARI 520ST
> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>
> Please notice that my software Eureka 2.12 runs on the early 520ST =)
> Most of the ATARI software produced today are not, you can check it.
> The software generated with AHCC have more chance to run with ATARI ST.
>
> Regards,
>
> --
> François LE COAT
> Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
> http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338507 is a reply to message #338486] Sun, 26 February 2017 17:49 Go to previous messageGo to next message
Henk Robbers is currently offline  Henk Robbers
Messages: 27
Registered: September 2012
Karma: 0
Junior Member
Op 2/26/17 om 5:00 PM schreef Francois LE COAT:

> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
> and people developing the ATARI target. They forget that ATARI ST is
> a 16/32bits architecture, and the "integer" type should be proposed as
> a 16bits type. This is a matter of adequacy from the language with the
> target. A 32bits integer type is far too demanding for an ATARI 520ST
> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.

I disagree. I always considered 16 bit integers too small for
a computer as modern as the ATARI ST having loads of ram.
(1966 mainframes are my objects of reference where ram was payed
by the kilobyte).

That's why I replaced all occurences of int in AHCC and its libraries
by short and created the sinclude folder of header files.
Still works like a charm.

--
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: Digger; http://digger.atari.org
A Home Cooked C compiler: AHCC; http://ahcc.atari.org
Re: Eureka 2.12 is 30 years old [message #338508 is a reply to message #338506] Sun, 26 February 2017 18:00 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

I'm currently using GNU/GCC 3.3.6 with the following configuration :

<http://eureka.atari.org/gcc3.3.6SDK.zip>

I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
the "-mshort" option and 16bits versions of the required libraries.

The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
the linker from GNU/GCC (ld), and the library format (.a) changed.

I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
compilation option, and link with my versions of the 16bits libraries ?

Can you explain ?

Thanks,

Miro Kropáček writes:
> Do you realise you're mixing gcc, mintlib and mint issues into one bag?
>
> There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
>
> So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
>
> I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
>
> Anyway, your blaming of developers/applications is totally off.
>
> Francois LE COAT writes:
>> Michael Schwingen writes:
>>> Francois LE COAT wrote:
>>>> >> What worries me the most, is that there's no 16bits integer type. The
>>>> >> C language is inappropriate for 16/32bits ATARI machines.
>>>> >
>>>> > Huh?
>>>> >
>>>> > Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> > (4.6.4) - it is called "short", just like expected.
>>>>
>>>> Replacing integer type (int) by short type (short) in my 30 years old
>>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>>
>>> Huh?
>>>
>>> "short" *is* an integer type, so gcc has what you need. If using "short"
>>> does not work, your code is buggy in other areas and simply needs to be
>>> debugged/fixed - this is not gcc's fault.
>>>
>>> I can accept that you don't want to do that work, but again: that is your
>>> decision and not gcc's fault.
>>
>> If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
>> or later, I would appreciate de retro-compatibility with the ATARI ST.
>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
>> maintained ... You would say that it is "buggy" or something else,
>> but it is simply 30 years old, such as the sources of my Eureka 2.12
>> software. The retro-compatibility with the ATARI ST is not maintained.
>>
>> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
>> and people developing the ATARI target. They forget that ATARI ST is
>> a 16/32bits architecture, and the "integer" type should be proposed as
>> a 16bits type. This is a matter of adequacy from the language with the
>> target. A 32bits integer type is far too demanding for an ATARI 520ST
>> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>>
>> Please notice that my software Eureka 2.12 runs on the early 520ST =)
>> Most of the ATARI software produced today are not, you can check it.
>> The software generated with AHCC have more chance to run with ATARI ST.

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338537 is a reply to message #338507] Mon, 27 February 2017 12:18 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Henk Robbers writes:
> I disagree. I always considered 16 bit integers too small for
> a computer as modern as the ATARI ST having loads of ram.

Well, nowadays the Mathematica application on my computer is
4785606192 bytes. That makes me curious, because Eureka 2.12
is contained in a 720kb floppy, and runs entirely in 1Mb of RAM.

> (1966 mainframes are my objects of reference where ram was payed
> by the kilobyte).

That was my birth. At this period there was a Univac at the university
that was occupying an entire building, and worked with perforated cards.

> That's why I replaced all occurences of int in AHCC and its libraries
> by short and created the sinclude folder of header files.

That's how I use AHCC, with short includes compatible with PURE C.

> Still works like a charm.

For the moment, I can entirely build Eureka 2.12 with AHCC 5.5. But
it is not working exactly as expected. That gives me hope !

Best regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338553 is a reply to message #338537] Mon, 27 February 2017 16:31 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Michael Schwingen

On 2017-02-27, Francois LE COAT <lecoat@atari.org> wrote:
>
>> (1966 mainframes are my objects of reference where ram was payed
>> by the kilobyte).
>
> That was my birth. At this period there was a Univac at the university
> that was occupying an entire building, and worked with perforated cards.

Kilobytes are not gone - my current target (STM32F103) has 64kBytes of Flash
and 20kBytes of RAM, and works fine using gcc (yes, with 32-bit ints).

cu
Michael
Re: Eureka 2.12 is 30 years old [message #338566 is a reply to message #338508] Mon, 27 February 2017 17:14 Go to previous messageGo to next message
Miro Kropáček is currently offline  Miro Kropáček
Messages: 23
Registered: November 2012
Karma: 0
Junior Member
Now you're mixing binutils and gcc. :-)

I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.

Dňa pondelok, 27. februára 2017 9:00:32 UTC+10 Francois LE COAT napísal(-a):
> Hi,
>
> I'm currently using GNU/GCC 3.3.6 with the following configuration :
>
> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>
> I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
> the "-mshort" option and 16bits versions of the required libraries.
>
> The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
> the linker from GNU/GCC (ld), and the library format (.a) changed.
>
> I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
> compilation option, and link with my versions of the 16bits libraries ?
>
> Can you explain ?
>
> Thanks,
>
> Miro Kropáček writes:
>> Do you realise you're mixing gcc, mintlib and mint issues into one bag?
>>
>> There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
>>
>> So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
>>
>> I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
>>
>> Anyway, your blaming of developers/applications is totally off.
>>
>> Francois LE COAT writes:
>>> Michael Schwingen writes:
>>>> Francois LE COAT wrote:
>>>> >>> What worries me the most, is that there's no 16bits integer type. The
>>>> >>> C language is inappropriate for 16/32bits ATARI machines.
>>>> >>
>>>> >> Huh?
>>>> >>
>>>> >> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> >> (4.6.4) - it is called "short", just like expected.
>>>> >
>>>> > Replacing integer type (int) by short type (short) in my 30 years old
>>>> > sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>>> > type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>>> > 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>>>
>>>> Huh?
>>>>
>>>> "short" *is* an integer type, so gcc has what you need. If using "short"
>>>> does not work, your code is buggy in other areas and simply needs to be
>>>> debugged/fixed - this is not gcc's fault.
>>>>
>>>> I can accept that you don't want to do that work, but again: that is your
>>>> decision and not gcc's fault.
>>>
>>> If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
>>> or later, I would appreciate de retro-compatibility with the ATARI ST.
>>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
>>> maintained ... You would say that it is "buggy" or something else,
>>> but it is simply 30 years old, such as the sources of my Eureka 2.12
>>> software. The retro-compatibility with the ATARI ST is not maintained.
>>>
>>> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
>>> and people developing the ATARI target. They forget that ATARI ST is
>>> a 16/32bits architecture, and the "integer" type should be proposed as
>>> a 16bits type. This is a matter of adequacy from the language with the
>>> target. A 32bits integer type is far too demanding for an ATARI 520ST
>>> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>>>
>>> Please notice that my software Eureka 2.12 runs on the early 520ST =)
>>> Most of the ATARI software produced today are not, you can check it.
>>> The software generated with AHCC have more chance to run with ATARI ST..
>
> Regards,
>
> --
> François LE COAT
> Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
> http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338633 is a reply to message #338553] Tue, 28 February 2017 16:40 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Michael Schwingen writes:
> Francois LE COAT wrote:
>>> (1966 mainframes are my objects of reference where ram was payed
>>> by the kilobyte).
>>
>> That was my birth. At this period there was a Univac at the university
>> that was occupying an entire building, and worked with perforated cards.
>
> Kilobytes are not gone - my current target (STM32F103) has 64kBytes of Flash
> and 20kBytes of RAM, and works fine using gcc (yes, with 32-bit ints).

My Hades060 has 40Mb of RAM, and I can't use virtual memory because
it's only possible with 68030 processors. I use GNU/GCC 3.3.6 with it.
This amount of memory is just enough to build Persistence Of Vision.
POV-Ray in its 3.1g version is very large C language sources, and it
requires a lot of memory to be built. It's the largest software I
ever built with an ATARI machine. POV-Ray doesn't require so much
memory to launch it, but GNU/GCC does because it's very big sources.
At the period when I built it, I had no cross-compiler. I had to
use the native GNU/GCC. All is simpler when you cross-compile, today.
I still don't have GNU/GCC 3.3.6 cross-compiler, that _really_ miss !

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338634 is a reply to message #338566] Tue, 28 February 2017 17:43 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

What I tested with GNU/GCC 4, is to replace `cc1.ttp` in

<http://eureka.atari.org/gcc3.3.6SDK.zip>

with the more recent one from the version 4.x. Doing that, I have
GNU/GCC 4, in a 3.3.6 environment. This works pretty good ! I still
have the same includes and libraries, but the compiler is in v.4.
There's no need to adapt includes and libraries, because it's the
same. The problem is that GNU/GCC 4 semantic is so different from
GNU/GCC 3, that the generated binary doesn't run as expected.

GNU/GCC 4.2 and later, are not convenient compile tools for 30 years
sources like mine. It's not compatible with PURE C. It doesn't have
16bits variants of the libraries, which most of the old software
like mine requires. It's only compatible with itself. No real interest.

What really miss me, is cross-tools with GNU/GCC 3.3.6. I could build
a cross-compiler, but the problem with today's libraries, is it
doesn't still support 16bits mode compilation. What should be done,
is to rework what was done by Patrice Mandin :

< http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333 .html>

but, with the versions of binutils, mintlibs of the same generation.

Miro Kropáček writes:
> Now you're mixing binutils and gcc. :-)
>
> I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
>
> Francois LE COAT writes:
>> I'm currently using GNU/GCC 3.3.6 with the following configuration :
>>
>> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>>
>> I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
>> the "-mshort" option and 16bits versions of the required libraries.
>>
>> The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
>> the linker from GNU/GCC (ld), and the library format (.a) changed.
>>
>> I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
>> compilation option, and link with my versions of the 16bits libraries ?
>>
>> Can you explain ?
>>
>> Miro Kropáček writes:
>>> Do you realise you're mixing gcc, mintlib and mint issues into one bag?
>>>
>>> There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
>>>
>>> So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
>>>
>>> I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
>>>
>>> Anyway, your blaming of developers/applications is totally off.
>>>
>>> Francois LE COAT writes:
>>>> Michael Schwingen writes:
>>>> > Francois LE COAT wrote:
>>>> >>>> What worries me the most, is that there's no 16bits integer type. The
>>>> >>>> C language is inappropriate for 16/32bits ATARI machines.
>>>> >>>
>>>> >>> Huh?
>>>> >>>
>>>> >>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> >>> (4.6.4) - it is called "short", just like expected.
>>>> >>
>>>> >> Replacing integer type (int) by short type (short) in my 30 years old
>>>> >> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>>> >> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>>> >> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>>> >
>>>> > Huh?
>>>> >
>>>> > "short" *is* an integer type, so gcc has what you need. If using "short"
>>>> > does not work, your code is buggy in other areas and simply needs to be
>>>> > debugged/fixed - this is not gcc's fault.
>>>> >
>>>> > I can accept that you don't want to do that work, but again: that is your
>>>> > decision and not gcc's fault.
>>>>
>>>> If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
>>>> or later, I would appreciate de retro-compatibility with the ATARI ST.
>>>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
>>>> maintained ... You would say that it is "buggy" or something else,
>>>> but it is simply 30 years old, such as the sources of my Eureka 2.12
>>>> software. The retro-compatibility with the ATARI ST is not maintained.
>>>>
>>>> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
>>>> and people developing the ATARI target. They forget that ATARI ST is
>>>> a 16/32bits architecture, and the "integer" type should be proposed as
>>>> a 16bits type. This is a matter of adequacy from the language with the
>>>> target. A 32bits integer type is far too demanding for an ATARI 520ST
>>>> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>>>>
>>>> Please notice that my software Eureka 2.12 runs on the early 520ST =)
>>>> Most of the ATARI software produced today are not, you can check it.
>>>> The software generated with AHCC have more chance to run with ATARI ST.

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338675 is a reply to message #338633] Wed, 01 March 2017 17:10 Go to previous messageGo to next message
Miro Kropáček is currently offline  Miro Kropáček
Messages: 23
Registered: November 2012
Karma: 0
Junior Member
> My Hades060 has 40Mb of RAM, and I can't use virtual memory because
> it's only possible with 68030 processors.

I don't know who told you that but I assure you FreeMiNT does support memory protection on 040/060 for ages.
Re: Eureka 2.12 is 30 years old [message #338676 is a reply to message #338634] Wed, 01 March 2017 17:12 Go to previous messageGo to next message
Miro Kropáček is currently offline  Miro Kropáček
Messages: 23
Registered: November 2012
Karma: 0
Junior Member
You're a lost cause, François. Please re-read this thread again, perhaps it will help. You're constantly mixing unrelated things together and mark them as "gcc problems".

Dňa streda, 1. marca 2017 8:43:55 UTC+10 Francois LE COAT napísal(-a):
> Hi,
>
> What I tested with GNU/GCC 4, is to replace `cc1.ttp` in
>
> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>
> with the more recent one from the version 4.x. Doing that, I have
> GNU/GCC 4, in a 3.3.6 environment. This works pretty good ! I still
> have the same includes and libraries, but the compiler is in v.4.
> There's no need to adapt includes and libraries, because it's the
> same. The problem is that GNU/GCC 4 semantic is so different from
> GNU/GCC 3, that the generated binary doesn't run as expected.
>
> GNU/GCC 4.2 and later, are not convenient compile tools for 30 years
> sources like mine. It's not compatible with PURE C. It doesn't have
> 16bits variants of the libraries, which most of the old software
> like mine requires. It's only compatible with itself. No real interest.
>
> What really miss me, is cross-tools with GNU/GCC 3.3.6. I could build
> a cross-compiler, but the problem with today's libraries, is it
> doesn't still support 16bits mode compilation. What should be done,
> is to rework what was done by Patrice Mandin :
>
> < http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333 .html>
>
> but, with the versions of binutils, mintlibs of the same generation.
>
> Miro Kropáček writes:
>> Now you're mixing binutils and gcc. :-)
>>
>> I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
>>
>> Francois LE COAT writes:
>>> I'm currently using GNU/GCC 3.3.6 with the following configuration :
>>>
>>> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>>>
>>> I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
>>> the "-mshort" option and 16bits versions of the required libraries.
>>>
>>> The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
>>> the linker from GNU/GCC (ld), and the library format (.a) changed.
>>>
>>> I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
>>> compilation option, and link with my versions of the 16bits libraries ?
>>>
>>> Can you explain ?
>>>
>>> Miro Kropáček writes:
>>>> Do you realise you're mixing gcc, mintlib and mint issues into one bag?
>>>>
>>>> There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2..
>>>>
>>>> So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
>>>>
>>>> I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
>>>>
>>>> Anyway, your blaming of developers/applications is totally off.
>>>>
>>>> Francois LE COAT writes:
>>>> > Michael Schwingen writes:
>>>> >> Francois LE COAT wrote:
>>>> >>>>> What worries me the most, is that there's no 16bits integer type.. The
>>>> >>>>> C language is inappropriate for 16/32bits ATARI machines.
>>>> >>>>
>>>> >>>> Huh?
>>>> >>>>
>>>> >>>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> >>>> (4.6.4) - it is called "short", just like expected.
>>>> >>>
>>>> >>> Replacing integer type (int) by short type (short) in my 30 years old
>>>> >>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>>> >>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>>> >>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>>> >>
>>>> >> Huh?
>>>> >>
>>>> >> "short" *is* an integer type, so gcc has what you need. If using "short"
>>>> >> does not work, your code is buggy in other areas and simply needs to be
>>>> >> debugged/fixed - this is not gcc's fault.
>>>> >>
>>>> >> I can accept that you don't want to do that work, but again: that is your
>>>> >> decision and not gcc's fault.
>>>> >
>>>> > If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4..2
>>>> > or later, I would appreciate de retro-compatibility with the ATARI ST.
>>>> > But these 16bits versions of MiNTlib, GEMlib etc. are not still
>>>> > maintained ... You would say that it is "buggy" or something else,
>>>> > but it is simply 30 years old, such as the sources of my Eureka 2.12
>>>> > software. The retro-compatibility with the ATARI ST is not maintained.
>>>> >
>>>> > The problem is really with the "programmed obsolescence" with GNU/GCC 4,
>>>> > and people developing the ATARI target. They forget that ATARI ST is
>>>> > a 16/32bits architecture, and the "integer" type should be proposed as
>>>> > a 16bits type. This is a matter of adequacy from the language with the
>>>> > target. A 32bits integer type is far too demanding for an ATARI 520ST
>>>> > with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>>>> >
>>>> > Please notice that my software Eureka 2.12 runs on the early 520ST =)
>>>> > Most of the ATARI software produced today are not, you can check it.
>>>> > The software generated with AHCC have more chance to run with ATARI ST.
>
> Regards,
>
> --
> François LE COAT
> Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
> http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338700 is a reply to message #338675] Thu, 02 March 2017 15:47 Go to previous messageGo to next message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Miro Kropáček writes:
>> My Hades060 has 40Mb of RAM, and I can't use virtual memory because
>> it's only possible with 68030 processors.
>
> I don't know who told you that but I assure you FreeMiNT does support memory protection on 040/060 for ages.

freeMiNT abandoned the support of virtual memory since a very long time.
The only solution remaining is Outside from Uwe Seimet, only for 68030.
I wasn't speaking of memory protection, but about "virtual memory".

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
Re: Eureka 2.12 is 30 years old [message #338758 is a reply to message #338676] Sat, 04 March 2017 15:51 Go to previous message
Francois LE COAT is currently offline  Francois LE COAT
Messages: 225
Registered: August 2012
Karma: 0
Senior Member
Hi,

Please consider that I'm concerned by ATARI (old) applications. I'm
not a "system" developer, I've never been, like you are. Some of the
historical applications like Calamus, Cubase, Chrystal ATARI
Browser (CAB), Papyrus, Photoline, Rainbow Painter, XnView are
really famous today. freeMiNT doesn't have the fame of GNU/Linux.
I've always been shocked by the supremacy taken by OSes in
peoples' mind. Sorry, I'm not an expert from freeMiNT mailing list.

Miro Kropáček writes:
> You're a lost cause, François. Please re-read this thread again, perhaps it will help. You're constantly mixing unrelated things together and mark them as "gcc problems".
>
> Francois LE COAT writes:
>> What I tested with GNU/GCC 4, is to replace `cc1.ttp` in
>>
>> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>>
>> with the more recent one from the version 4.x. Doing that, I have
>> GNU/GCC 4, in a 3.3.6 environment. This works pretty good ! I still
>> have the same includes and libraries, but the compiler is in v.4.
>> There's no need to adapt includes and libraries, because it's the
>> same. The problem is that GNU/GCC 4 semantic is so different from
>> GNU/GCC 3, that the generated binary doesn't run as expected.
>>
>> GNU/GCC 4.2 and later, are not convenient compile tools for 30 years
>> sources like mine. It's not compatible with PURE C. It doesn't have
>> 16bits variants of the libraries, which most of the old software
>> like mine requires. It's only compatible with itself. No real interest.
>>
>> What really miss me, is cross-tools with GNU/GCC 3.3.6. I could build
>> a cross-compiler, but the problem with today's libraries, is it
>> doesn't still support 16bits mode compilation. What should be done,
>> is to rework what was done by Patrice Mandin :
>>
>> < http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333 .html>
>>
>> but, with the versions of binutils, mintlibs of the same generation.
>>
>> Miro Kropáček writes:
>>> Now you're mixing binutils and gcc. :-)
>>>
>>> I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
>>>
>>> Francois LE COAT writes:
>>>> I'm currently using GNU/GCC 3.3.6 with the following configuration :
>>>>
>>>> <http://eureka.atari.org/gcc3.3.6SDK.zip>
>>>>
>>>> I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
>>>> the "-mshort" option and 16bits versions of the required libraries.
>>>>
>>>> The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
>>>> the linker from GNU/GCC (ld), and the library format (.a) changed.
>>>>
>>>> I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
>>>> compilation option, and link with my versions of the 16bits libraries ?
>>>>
>>>> Can you explain ?
>>>>
>>>> Miro Kropáček writes:
>>>> > Do you realise you're mixing gcc, mintlib and mint issues into one bag?
>>>> >
>>>> > There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
>>>> >
>>>> > So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
>>>> >
>>>> > I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
>>>> >
>>>> > Anyway, your blaming of developers/applications is totally off.
>>>> >
>>>> > Francois LE COAT writes:
>>>> >> Michael Schwingen writes:
>>>> >>> Francois LE COAT wrote:
>>>> >>>>>> What worries me the most, is that there's no 16bits integer type. The
>>>> >>>>>> C language is inappropriate for 16/32bits ATARI machines.
>>>> >>>>>
>>>> >>>>> Huh?
>>>> >>>>>
>>>> >>>>> Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
>>>> >>>>> (4.6.4) - it is called "short", just like expected.
>>>> >>>>
>>>> >>>> Replacing integer type (int) by short type (short) in my 30 years old
>>>> >>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
>>>> >>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
>>>> >>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
>>>> >>>
>>>> >>> Huh?
>>>> >>>
>>>> >>> "short" *is* an integer type, so gcc has what you need. If using "short"
>>>> >>> does not work, your code is buggy in other areas and simply needs to be
>>>> >>> debugged/fixed - this is not gcc's fault.
>>>> >>>
>>>> >>> I can accept that you don't want to do that work, but again: that is your
>>>> >>> decision and not gcc's fault.
>>>> >>
>>>> >> If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
>>>> >> or later, I would appreciate de retro-compatibility with the ATARI ST.
>>>> >> But these 16bits versions of MiNTlib, GEMlib etc. are not still
>>>> >> maintained ... You would say that it is "buggy" or something else,
>>>> >> but it is simply 30 years old, such as the sources of my Eureka 2.12
>>>> >> software. The retro-compatibility with the ATARI ST is not maintained.
>>>> >>
>>>> >> The problem is really with the "programmed obsolescence" with GNU/GCC 4,
>>>> >> and people developing the ATARI target. They forget that ATARI ST is
>>>> >> a 16/32bits architecture, and the "integer" type should be proposed as
>>>> >> a 16bits type. This is a matter of adequacy from the language with the
>>>> >> target. A 32bits integer type is far too demanding for an ATARI 520ST
>>>> >> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
>>>> >>
>>>> >> Please notice that my software Eureka 2.12 runs on the early 520ST =)
>>>> >> Most of the ATARI software produced today are not, you can check it.
>>>> >> The software generated with AHCC have more chance to run with ATARI ST.

Regards,

--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org/
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: ATARI WANTLIST:
Next Topic: atari falcon wanted
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Mar 19 09:59:12 EDT 2024

Total time taken to generate the page: 0.05569 seconds