This was a lot harder than it should have been. And not because of gcc or surprisingly ancient binutils.
I didn’t have much to go on, as ancient threads like this, or this end up unanswered or without any good conclusion. I guess it’s not surprising that all the attention is to MiNT & MINIX rather than the native platform. But I was not deterred.
The reason why this was so freaking hard was how so much of key parts of gcc for the ST have been purged and what remains being scattered to the winds. Amazingly the hardest thing to source is the include files. There is a GCC 1.30 file on all the usual GNU mirrors but to save a few kb it has no headers, instead it wants you to reuse the ones from the 1.25 binary distribution. Which is gone. There survives a pl95 binary and source package, but again no includes. Instead I got lucky with all three for pl98. Which has a lot of GCC2 hooks so I cheated on getting the 1.30 hello world by using the 2.5.8 pre-processor.
It’s kind of annoying how all these seemingly tiny files get purged to save a few kb. Just as I can’t for the life of me find the old original GNU libc.
Speaking of files, ZOO has to be the worst compressor ever. Not only is it just overall worse than ZIP, but there are 2 incompatible compression methods, like the introduction of LZD, which any of the good versions of UNZOO can’t deal with. And sure there is zoo210.tar.Z but despite being able to build it on multiple platforms it never does anything useful. All these ancient fileformats sure don’t help anything. And sure there is a MS-DOS version that the MS-DOS Player can run, but get ready for 8.3 filename renaming.
The one good thing that came out of this experience is that since I am building form i386 to 68000 I found that this setup uses the G++ linker which has endian swapping. So maybe I can complete the chain for Mint and MachTen.
I even got the 1987 Infocom interpreter running. Although I don’t know what the deal is, it seems the larger the GCC based program is the higher chance it’ll just crash on exit or force the next program to crash. Building anything native under emulation was an impossibility.
In the same effort, I’ve had the same luck with sozobon. It took way too long to find a working dlibs. I don’t know why people couldn’t either package them together or at least in the same directory. It took far longer just to find the libs… But it was still fun to get that one running as well.
It’s a far more manual process to compile as I have to invoke each stage manually, but at least I’m finally able to get things going.
One of the bigger issues is that I would always find libraries in this olb file format, that the linker from Sozobon wouldn’t recognize. And almost every attempt of trying to build the G++ linker would also fail on. It wasn’t until I was able to get the pl98 include files that I could finally get a linker to actually recognize this … seemingly different for no apparent reason format to actually link. After then I managed to finally find a build of this dlibs that would actually link with Sozobon, which naturally didn’t use olb at all.
So yeah that was an adventure.
I haven’t cleaned it up at all, and really wouldn’t expect anyone else to care, but all my mashed together work (source & binaries!) is here:
I started browsing more cd.textfiles.com and amazingly found a ‘home made CD-ROM set’ of Atari software, and buried in the gigabytes of stuff was 4 of the 5 disks of the original GCC-1.23! Namely the source & includes to the first GCC library. I didn’t think this article was going to get any traction, let alone downloads. So many people downloaded the above download.
Anyways I started to put together a better package on sourceforge since it’ll do the multiple GIT’s and nicer downloads.
The default download set is for GCC-1.30, with the headers & lib, along with source. It’s crazy small which just goes for how this old stuff is, and how impact full for losing a few kb.
Also the shell that you use apparently makes a BIG difference. The shell that I was using EmuCON doesn’t show any output from the GCC 1.x libs. However other shells most certainly do. I’ll have to do another update regarding shells/emulation.
Did you check http://tho-otto.de/crossmint.php or is this gcc too new for you? The binaries produced run on plain Atari STs.
I’d never seen that page before, although it certainly implies that its MINT only, not for GEMDOS/regular ST mode.
That said the MinGW built stuff is missing all the runtime DLL’s.
libmpc-3.dll libmpfr-4.dll libgmp-10.dll zlib1.dll
I downloaded: binutils-2.32-mint-20190223-bin-mingw32.tar gcc-4.6.4-mint-20170518-bin-mingw32.tar
And even then there is no crt0.o
I downloaded m68k-atari-mint-base-20190223-mingw32.tar.xz . I have the DLL’s for GCC 8, which did work for a simple hello world. I have been long under the impression that the MiNT libc / target stuff was strictly for MiNT.
That said, a few turns in the infocom player thing, and it crashed. Hard too as nothing else will run requiring me to reset. Meanwhile GCC 2.5.8 seems to run okay, I made it to the planet.
Completely unrelated but thought you might like to see https://github.com/leecher1337/ntvdmx64 which is a port of NTVDM (from RISC NT 4) to x64 Windows.
And while I think of it win3mu source has been released:
It’d been ‘opened’ last year but no source. So it’s finally happened. In that time WineVDM has made incredible strides, and at this point I can’t see anything else even coming close to it.
Sorry if I’m being a bit dense, but: I found what appears to be the source code to gcc 0.9 from 1987. I have no idea if this is helpful 6 months after the fact:
I just discovered your blog and have been enjoying reading stuff!
I touched on gcc 0.9 a while ago. Although you are right in that it supports VAX and 68020. I’m not sure if it’ll force down to 68000 only, and I suspect it may work fine with the assembler from the later versions.
I guess for me it was running down the ancient original stuff I could fine, not so much trying to redo/retrofit it myself from the older stuff.
But Im sure it’s entirely possible.
Great post! Did you ever manage to fix the missing GCC output?
It was some shell incompatibility from what I recall.
The Atari and x68000 despite having a 24bit address bus only have tiny areas for programs… As much shit as the pc gets for the 640k thing, at least the 286 maps 15 megabytes of linear memory (and its mmu can map 1GB!!!) just as the 386 boards of the era comfortably do 64MB/4 Gb.
Even the SUN-2 only maps 4MB of RAM, in the same 24bjt address space
What do you mean with “Atari […] only have tiny areas for programs”? I know of 0.9 MB binaries for the ST …
0.9MB is absolutely tiny. Even back then if you’d ever used GCC or Emacs.
For a 24bit address space having less than 12MB available is a damned shame.
The ST only had 4 MB max. RAM, and, as no PMMU was in there, no (UNIX-like) paging.
You can have 10 MB binaries with GEMDOS on the ST, I’m quite sure, although I never tried. Newer releases of RAM extensions can give you 14.5 MB of usable RAM in the ST, of which 10.5 MB are contiguous (“ALT-RAM”).
As the ST predates GCC by 2-3 years, I’m sure that wasn’t on their priority list. It wasn’t designed as a workstation killer.
THANKS for mapping out this rabbit hole!
Great… now I have one more rainy day project 😀
Yeah it was surprisingly involved! and not at all straightforward as many of the bits and information had bitrotted out of existance.
Good luck with your ST compiling adventure!