GCC from ’87 on the 68000

Years ago I found the ‘first’ released version of GCC, and had built it for the VAX. And things were… fun.

While digging around on bitsavers for new and interesting things, I saw some newer stuff from MIT, and stumbled into the GNU directory and rediscovered the early GNU software depot.

And I re-built the early GCC to target the 68000 which I’d imagine primarily was for the SUN target.

simple program

Using a simple program I can run it through the pre-processor, and the compiler to get the following assembly:

assembly from ’87 GCC

Then it’s a matter of running it through the cross assembler, uuencoding it, and sending it to the target.

I used the cross assembler from the AtariST cross ‘project’, to get an object file. I fired up MachTen, pasted my object file to the VM, and uudecoded the object.

And yeah, much to my surprise the object file linked fine, and I got my native EXE.

It’s not much of a cross toolkit, and honestly it’s kind of useless… but I thought it was maybe worth a bare paragraph to show the other available target available for the 1987 release of GCC.

Also on the MIT archive is TRIX, the MIT Unix work alike that almost became the GNU Kernel, until Mach stole their hearts, and basically lead them on a wild goosechase.

I haven’t bothered uploading binaries or patches or anything yet, I don’t know if people are interesting in such a fringe thing……

Living with ARM for a week

So after the crazed purchase I made a few weeks ago, I returned from Japan, and was able to unbox and use the machine I’d been wanting for a while, a non x86 Windows laptop!

The NovaGo has a Snapdragon 835, and my phone, the ASUS ROG phone has the 845. Yes for this week, my cellphone actually has the stronger processor than my computer. Honestly this is almost an unthinkable situation! Although I haven’t been using my phone as a desktop substitute this week. It’s amazing how MS screwed up 10 on the phones, and Continium.

By default it comes crippled with this ‘S’ mode Windows, which hearkens back to the Windows RT launch, with the difference that it’s a quick trip to the application store to unlock Windows 10 Professional. It’s a free download as it should be, and it doesn’t even require a reboot!

Build quality isn’t so bad, the screen folds all the way back to make the machine into a ‘tablet’ although I don’t like that mode so much, it just feels wrong to wrap a keyboard around a monitor. However if you have rambunctious young kids, it’s great as when someone went running by me flailing their arms around like a while animal, when they struck the laptop the screen could easily fold back 180 degrees. Yay.

My first thing to do after setting up Office and VMWare VDI was to install the Linux subsystem, and Ubuntu. it’s exactly the same as it is on x86_64, which is great. And this let’s me have the best of both worlds, just like x86_64. As much as I dislike stumbling around with that aborted child of Pascal & Fortran (Python) at least I can run it under (mostly) Linux to get something close to like the production environment.

The C/C++ compiler is actually all cross tools. I wanted CLI only stuff because I like torturing myself, and it required a few GB of downloads. The good news is that the latest Windows 10 SDK does support GDI/CLI apps, so no crazy SDK hacking required, unlike back in the Windows RT days. Oddly enough the Taskforce 87 interpreter runs fine, but nothing else does.

I did a horrible job at hacking up SDL 1.2 to at least run (kind of, the audio doesn’t work, and it’s all WinDB *EDIT I got it fixed!!!) I got a few things up and running, including DOSBox and FrontVM. One thing that greatly helps is that i386 binaries ‘just work’. Honestly you wouldn’t even know you are running them when you are. Which made hunting down the ARM64 version of Chromium Edge kind of difficult to find. There really needs to be a more apparent way to tell them apart, if anything for battery efficiency.

As pictured, SQL Server 4.21a runs just fine, again you wouldn’t even notice. Same for Visual C++ 1.0 & FORTRAN PowerStation 1.0.

Again the audio in my crap SDL build doesn’t work, so DOSBox is silent, and without Direct X, the text mode is tiny. Oh also, there is no OpenGL in this version of Windows dev kit for some reason. Running ssystem is ungodly slow. Also the default optimizations seems to be Os, optimize for space, and on this ASUS I have to say /Ox is way way faster. DooM is quite playable on DOSBox when build with /Ox, unlike /Os.

For me, I spend most of my day to day in Office, and VMWare VDI, connecting to secure networks. So I’m just one step above a terminal. Which I guess is kind of sad, but this machine more than fills that roll for me. The 120GB of storage is tight. This isn’t a development machine persay, nor is it something to download tonnes of data to, it’s a lightweight machine where it’s strength is the built in 4G modem, and when running ARM software the longer battery life. To me the biggest drawback is that the keyboard isn’t backlit. Even though I touch type, I didn’t realize how much I’d grown used to it for casual use.

I guess it’s a hard toss up from this and a PINEBOOK Pro, I think most readers here would prefer the Pinebook, for all it’s openness, although I still like the idea of being able to copy over the Win32s version of Lemmings, and it just running. For me I kind of like this thing, although once I switch back to an x86_64 with more memory, better GPU and disk options, maybe this just feels like some kids toy.

Neko98 ARM!

I don’t know how I didn’t think of this, but I also ported Neko98! Although the STL is having an issue with the ‘control panel’ so Neko is on autopilot.

This app can’t run on your PC

As for the emulation, it is 32bit only, so expect to see this stupid message quite a bit. The neckbeard is a nice touch though.

Also built into the thing is a cell modem. I guess it’s really not a surprise as the 835 really is a cellphone SOC. I have a ‘wifi egg’ as they are called here, a WiFi hotspot with unlimited internet from CLS, which is on the old 4G network. I popped the SIM in, and it picked up the APN settings on it’s own and I was connected in under a minute. I have to say that it’s about time that SIM cards have this stuff programmed into them for a plug & play experience. And thankfully the ASUS is unlocked, although from what I understand these were sold in the USA bundled with some cell service plans.

For anyone with one of these rare machines that cares to play along you can find my built stuff on my ‘vpsland’ archive:

https://vpsland.superglobalmegacorp.com/install/Windows10-ARM/

And the f2c/dungeon build along with the C/C++ compiler is in the aptly named dungeon-2.5.6-ARM(32bit)-win32.zip file.

Cross compiling to the Atari ST

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: MinGW-AtariTOS.7z

UPDATE

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.

Download crossAtariST

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.

68000 and i386 C Compiler Version III on Windows

While looking around for simple compilers to see how easy it is to modify their assembly output syntax, I ran across this tiny file, cc68iii3.zip which bills itself as:

This compiler consists of various modules that build up a
front end — these modules are common to all versions of
this compiler — consisting of parser, analyzer and optimizer,
of modules that are specific for the target processor,
namely *68k.c (for the 68000) and *386.c (for the i386),
and of assembly language output modules that are further
dependent on the (syntax of the) target assembler.

Well isn’t that interesting! So instead of doing something 68000 based, I setup the i386-gas compiler, and tried it with MinGW. And amazingly a hello world program worked!

C:\temp\ccc\cc\infocom>type hello.c void main(){printf("Hello World!\n");} C:\temp\ccc\cc\infocom>..\c386gas hello.c hello.s C:\temp\ccc\cc\infocom>gcc hello.s -o hello C:\temp\ccc\cc\infocom>hello Hello World! C:\temp\ccc\cc\infocom>type hello.s .file "C386GENERATED" .version "C386 V 1.0" .optim c386_compiled.: .text L1: .byte 72,101,108,108,111,32,87,111,114,108,100,33 .byte 10,0 .align 2 _main: pushl %ebp movl %esp,%ebp pushl $L1 call _printf popl %ecx leave ret .globl _main .globl _printf C:\temp\ccc\cc\infocom>

Well that was unexpected, but great! So I thought I’d modify the simple Infocom interpreter to build with this. I came up with this as a block for gnumake to read in a Makefile

%.o: %.c $(CC) $(CFLAGS) -E $< -o $*.i c386gas $*.i $*.s as $*.s -o [email protected] rm -f $*.i $*.s

The key substitute is $* which is the 'root' of the file being passed in. Although it's lame doing it this way but it works in a nice automatic enough fashion.

The compiler must be K&R only as it doesn't like standard includes, so I built file.c/io.c/term.c using GCC but all the rest were able to be built just fine. And even better it works!


Although I'd never recommend using something like this in a place that matters. If anything GCC 1.x is probably a better choice, but it's still kind of neat.

Messing with the Monitor

The 68000 Microprocessor (5th Edition) Hardcover – Nov 25 2003
by James L. Antonakos (Author)

So I was trapped in the Library for a bit, and spied this book. It’s not every often in 2019 you are going to find books about the 68000, as I’m sure any good library will have removed stuff like this, and have it pulped ages ago. But the amount of current technical books in English here is pretty damned slim to none, so I was all to happy to pickup this book for a week.

The poor thing has been checked out 4 times in the last 15 years. I guess the kids don’t know what they are missing.

Anyways what was interesting in this book is that it has a CD-ROM, and on there is some lesson code from the book, along with an assembler that outputs to S-records of all things, and a small emulator that is meant to be compiled under MS-DOS. It was trivial to isolate the passing of DOS interrupts from Unix/MinGW and get the simulator running on something modern.

In Chapter 11 there is a brief walkthrough on building a board, which sounds like fun although I’m sure in 2019 finding parts will be.. challenging, along with a simple monitor program.

The built in assembler can happily assemble the monitor, but it’s geared for talking to the obsolete hardware as specified in the book. I just made a few small changes to instead have it’s console IO hook to the simulator’s TRAPs and I had the monitor running!

I then took the echo test program, and modified it to run at a higher location in memory, along with exiting via the RTS instruction, so that it will exit when you press Q back to the monitor. Then for the heck of it I further extended the monitor so you can Quit it, and return to the simulator.

Is this useful? I’m pretty sure the answer is absolutely not.

The CD-ROM is tiny, I thought it would be packed with goodies, but it’s 250kb compressed.

The68000MicroprocessorFifthEdition.zip

If anything people using this book will probably have lost the CD-ROM and want the programs.

  • ISBN-10: 0130195618

And my horrible changes here.

Gopher kills the LC

Macintosh LC

The LC isn’t a strong Macintosh.  It is after all, a low cost model.  And what I’m doing isn’t even slightly fair to it.

Since it has a mere 68020 running at a blazing 16Mhz with no 68881 nor any MMU running something like A/UX is simply out of the question.  However MMU less Mac’s can run MachTen.

Although I did make a backup of the disk to find out that this thing had been in Harvard of all places, apparently once belonging to Mark Saroyan.

Although there was nothing even slightly academic or useful on the disk.  I wonder if the software was even pirated as the last owner sure enjoyed all the various SIM games (city/earth/life/ant) it seems more than anything else.

I formatted the massive 50MB SCSI disk, put on a fresh copy of MacOS 7.0.1 along with the network driver and MachTen 2.2.

System 7.0.1

And as far as LC’s go, this one isn’t too bad, it’s loaded up with the maximum 10MB of RAM, although it seems the VRAM is pretty sparse as it’ll only go to 16 colours.  But since we are playing UNIX here, I didn’t see any need for that, and set it to mono.

I thought it’d be fun to install a gopherd server onto this machine, and that is where the fun started.

Granted it’s been a long time since I used a machine with no real L2 cache, let alone running at a whopping 16Mhz, and using a compiler like GCC is just incredibly slow.

So I thought I could just ‘cheat’ the system by taking the source code to GCC-1.42 and tweaking the SUN3-Mach configuration into a SUN2-Mach configuration but keeping it targeting a BSD like OS, along with setting it to compile to a 68020 without a 68881.  Oddly enough getting a cross compiler wasn’t so difficult, but the assembler on the LC, a modified GAS wouldn’t assembler the files. So I went ahead and built a68 from GAS 1.38 and now I can cross assemble from Windows. However I couldn’t get the linker ld from binutils-1.9 working.  I guess it was an endian issue somewhere, but my attempt at byte swapping files it was reading just led to further confusion.  And I figured linking on the target host wouldn’t be the end of the world, as compiling sure feels like it is.

I can’t see like anyone would care, but here it is: 
MachTen-crossgcc-1.42-nolinker.7z

So fighting the source and in a matter of a 30 minutes of on/off work I had it compiled.  All I needed to do then was FTP the objects to the machine, link and run.   Surprisingly this proved to be pretty simple.

gopherd running!

I managed to get a few pages out of it, and suddenly my telnet sessions dropped.  Looking over at the console and MacOS was busy being MacOS.

error of type 3

And that was that.

I tried another program to cross compile and upload phoon!

phoon cross compiled, natively linked.

It took a while to set the clock to the right year, as my minimal System 7 install doesn’t have the time control panel, and advancing 1 year at a time from 1999 takes time, by advancing the date to New Years Eve every minute 19 times to get us to 2018 with the old date syntax:

date 12312359

Lessons learned?

Obviously if I want to do something like this, I’m going to need a better Macintosh.  Or just not do things like this….

I’m kind of on the fence as to whither 68k Unix is really all that useful in the age of Ghz x86.  

So while out today I found a Windows RT Surface for $25

I had to pay another $15 for the charger.  I should have run away, but I’m a sucker.

Yes, there are basically NO apps, but thanks to this little guide

QuakeWorld on Windows RT

I was able to port over some trivial stuff, the usual things like hello world, Infocom Interpreter, a f2c build of Dungeon, then I went with something I’d been messing around an old GDI driver for WinQuake that builds with the NT 3.5 SDK (finally got it!).  So with a few minor tweeks here it is cross compiled from my x86_64 to the surface.

Last time I talked about the Surface was nearly 6 years ago…  The platform’s fate was pretty much sealed on day one.  With no open Win32 API it shunned traditional devs, and with some completely new and insane model it was such a hurdle for new devs, why put so much effort into such an old tired company like Microsoft?

I figured for the price of a good lunch it’d be a fun toy.

Too bad the speakers don’t work though.

I know the window on Windows 8.1 apps is closing soon.  I should put something together for the dead platform.  Maybe for phone too.  But for tonight, it was kinda fun doing a copy/paste attack to then run unsigned EXE’s on the device.

I might upload the tool chain later, but at the moment getting Visual Studio 2012 Ultimate is a breeze.

Building MAME 0.1 for MS-DOS / DJGPP

So as promised, a while back I had built a GCC 2.7.2.3 / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME.  Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.

Why not use a more up to date version of both GCC/Binutils?  Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too.  And it was easier to just get the older tool chain working.

It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.

So for our fun, we will need my cross DJGPP v2 tool chain for win32, MAME 0.1, Allegro 3.12 and Synthetic Audio Library (SEAL) Development Kit 1.0.7 .

Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.

Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable.  And the best part is checking via DOSBox, it runs, with sound!

MAME 0.1 on DOSBox PACMAN hiding

Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.

More cross compiler assertion fun

undefined reference to `___eprintf'

Got this fun one in dwarf.c (and probably many others) while building an ELF toolchain from Linux to run on Windows to target.. Linux.  Anyways I think this is a symptom of Canadian Cross compilers.

So a little digging and ___eprintf turns out to be from the assert.h as macros for assert depend on this being in libgcc.a .. And yeah, MinGW uses something else.  So just copy the assert.h from MinGW, and re-build and away it works.

D:\elfgcc\bin>cc1
int main(){printf("hi!\n");return 0;}
        .file   "stdin"
        .version        "01.01"
gcc2_compiled.:
 main.section   .rodata
.LC0:
        .string "hi!\n"
.text
        .align 4
.globl main
        .type    main,@function
main:
        pushl %ebp
        movl %esp,%ebp
        pushl $.LC0
        call printf
        addl $4,%esp
        xorl %eax,%eax
        jmp .L1
        .align 4
.L1:
        leave
        ret
.Lfe1:
        .size    main,.Lfe1-main
^Z
        .ident  "GCC: (GNU) 2.7.2.3"

time in parse: 1.155000
time in integration: 0.000000
time in jump: 0.000000
time in cse: 0.000000
time in loop: 0.000000
time in cse2: 0.000000
time in flow: 0.000000
time in combine: 0.000000
time in sched: 0.000000
time in local-alloc: 0.000000
time in global-alloc: 0.000000
time in sched2: 0.000000
time in dbranch: 0.000000
time in shorten-branch: 0.000000
time in stack-reg: 0.000000
time in final: 0.000000
time in varconst: 0.000000
time in symout: 0.000000
time in dump: 0.000000

Well, wasn’t that fun?