Cross GCC from Windows to AmigaDOS

GCC 2.7 to AmigaDOS 2.04

GCC 2.7 to AmigaDOS 2.04

Yes, I know there are others.  Newer versions of GCC too!.. but I was more so curious to see if I could do it.  I know there were GCC 1.x ports to the Amiga but I can’t find source anywhere.  And for some reason the Amiga and Atari ST seem to have never been mainlined into GCC.  I would have thought 1990-1992 they would have had far more users than say SUN-2/SUN-3.

Some ‘fixes’ are described in this file:

Although it’s not 100%.

I downloaded the files mentioned on this GCC page, and started to massage stuff.  This was easier as GCC 2.7 & Binutils 2.8 both support Windows NT 3.5 (and much much higher!).

I may want to try to get an ancient Nethack to build, so I put it onto sourceforge…


I’ve just tested a hello world type executable.  I’m more so amazed that it linked and executed, ‘file’ detects the objects as

x.o: raw G3 data, byte-padded

But at least the executables look right:

hi: AmigaOS loadseg()ble executable/binary

I had to hack all kinds of crap compiling eamiga.c
and eamiga_bss.c as neither generated correctly, and both had all kinds of missing and undefined things.  I’m sure on bigger projects it’d just explode, but right now I’m just amazed the linker could pick up my object, plus the 21 year old objects + libraries from that aforementioned ancient GCC port.

Oh well I was entertained for a couple hours.

On the talk of Europe & Tapes…

I recently discovered this youtube channel by Kim Justice.  She does quite a few video documentaries about retro games, and the like.  I found these two quite interesting:

The history of US Gold was quite interesting, along with her documentary on Ocean

And of course this video about the ZX Spectrum tape wars.

I had a Commodore 64, and although I did have a 1541 disk drive first, I did later manage to get a datacasette, and on rare occasion I would pick up a Zzap64 and did quite enjoy the whole idea of a covertape.  The tradition continues in the UK & EU with cover discs, which I pick up on occasion in Hong Kong.

NOS clone datassettes!

New old stock, still in shipping boxes!

327 devices!

327 devices!

I found this eBay auction, and couldn’t believe what they had unearthed!  Boxes and boxes of these clone datassette!

New old stock

New old stock

Obviously the perfect thing for any retro Commodore user!  And as you may know in Europe most people used tapes, while us North Americans all used disk drives, namely the mighty 1541.

As of me writing this there is only ONE left!  It’s not my auction, and I have nothing to do with them, but this is your big chance to get one if you want one!


Well it turns out the last unit has just been sold.  Too late to post it seems.

Cross compiling to the Amiga with Sozobon

To start this fun voyage, I used HCC, the first usable port of Sozobon C to the Amiga I could track down.  From it’s description:

Amiga port of Sozobon, Limited’s C Compiler. Can completely compile
itself, supports 32 bit ints, and optimizer can ‘registerize’ variables.
Includes compiler, optimizer, tool for creating interface code for Amiga
system calls, startup code, C library, include files, and library routines
that work with Motorola FFP format. Uses assembler A68k, linker BLink, and
provided run-time shared C library CClib.library.

And isn’t that great?  It even supports 32 bit integers!  I had to massage things in Visual C++, as there was some weird instances of return codes missing, and the optimizer not actually mallocing it’s memory, but just blindly using pointers.  As always if you can see what is going on in a debugger it’s not too hard to make some wild guesses and get it running, and if you get lucky it may even work too…

Running the compiler

With the compiler and optimizer running (it is actually needed to run to further massage the assembly output into something the Amiga a68k assembler can read), it was time to look at an assembler.  For the heck of it, I did try a68k, and to my amazement it did actually work, once I had updated the file output call.

hcc\hcc -L hanoi.c
hcc: version 2.0 Copyright (c) 1988,1989,1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.

top\top -v hanoi.s h2.s
top Version 2.00 Copyright (c) 1988-1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.
Peephole changes (1): 8
Peephole changes (2): 1
Peephole changes (3): 0
Instructions deleted: 3
Variables registered: 0
Loop rotations : 0
Branch reversals : 0
Branches removed : 4

a68k\a68k -q100 h2.s
68000 Assembler - version 2.61 (January 11, 1990)
Copyright 1985 by Brian R. Anderson
AmigaDOS conversion copyright 1989 by Charlie Gibbs.

Assembling h2.s
PASS 1 line 59
PASS 2 line 59
End of assembly - no errors were found.
Heap usage: -w2047,80
Total hunk sizes: 94 code, 10 data, 0 BSS


wow wasn’t that fun! I haven’t seen the source code to the BLINK linker, so I just end up using a native linker, BLINK.

Towers of Hanoi

Towers of Hanoi

Much to my amazement, the a68k assembler functions just fine as a cross assembler, and I only had to copy the object file into the emulator, and I could happily link.

The syntax for BLINK was a little strange, mostly because I really don’t know what I’m doing.

BLink LIB:HCC.o+hanoi.o LIB LIB:HCC.lib+LIB:stubs.lib TO hanoi SC SD VERBOSE

Now to try something bigger, like the ancient 1987 vintage InfoTaskForce.  I had to add in the include files from the DICE compiler, and surprisingly, in no time, it was all compiled, and assembled the only step remaining was to run the BLINK linker.  This time it was slightly different as now we had a bunch of object files:

BLink LIB:HCC.o+fileo.o+funcso.o+infocomo.o+inito.o+inputo.o+interpo.o+ioo.o+jumpo.o+objecto.o+optionso.o+pageo.o+printo.o+propertyo.o+supporto.o+variableo.o LIB LIB:HCC.lib+LIB:stubs.lib TO infocom SC SD VERBOSE

Running that as a single line (or better in a command file) got me my executable.



And it linked without any unresolved externals.

InfoTaskForce cross compiled on Windows, linked on AmigaDOS 2.0

InfoTaskForce cross compiled on Windows, linked on AmigaDOS 2.0

Running under WinUAE

And even better, it worked. Here it is running Planetfall!

I can’t imagine it being all that useful for anyone, as Sozobon C is K&R C, and well this is for the Commodore Amiga, not exactly a mainstay in this day & age.

HCC_Sozobon_win32cross.7z This link will take you to the sourceforge page, and the archive contains both source, and executables.  As mentioned I didn’t see any Amiga linker that has source code, it seems everyone use BLINK, and the team that write BLINK went on to re-write all the ‘c’ commands in AmigaDOS from BCPL/asm into C.



I just discovered vlink after writing this, and now I can link a working executable under Windows 10! Since I made zero changes to vlink, and I’m not charging money, I am free to redistribute this so I’ve updated my archive, and included it.

Back onto HECnet

Connecting to MIM

Connecting to MIM

After much fighting, and apparently being blocked by one of my ISP’s, I got back onto HECnet!  Even better I was able to verify operation with HECnetNT!

Selective binding for DECnet

Like last time I was able to bind Pathworks 32’s DECnet onto a MS Loopback adapter, and then use the bridge to connect onto that loopback to a local Linux bridge (which is also hosting a virtual SIMH VAX instance).

The big problems I ran into is that I originally had setup SIMH to use a tap interface, and connect into a bridge, as mentioned on the forums, however the HECnet bridge program seems to have difficulty injecting packets onto the bridge interface.  I suspect the ‘correct’ thing to do is to remove libpcap from the bridge, and re-write it to be a tuntap client.  There is enough examples, I should be able to do this, but I just wanted the thing to work, so I didn’t want to tackle this just yet.

Instead I had SIMH attach to the Linux lo adapter (typically where lives), and the HECnet bridge program, and success!  Even better the interface has been up now over 12 hours since it was brought online.



Well wasn’t that fun?

Want to learn more about HECnet?  simply check it out!  But as the short order goes it’s a hobbyist DECnet of machines spread out across the globe running the ancient DECnet protocol on various legacy style systems.

Installing Windows NT 3.1 on a physical computer

I have this P4 I got for super cheap in Hong Kong, that came with Windows 98 of all things. Naturally I want to load something more useful like Windows NT 3.1 onto it, so I did have to do some tweaking first.


The first thing is the hard disk. I was lucky in that this machine came with a 40GB disk, the Hitachi Desktar IC35L060AVV207-0.

HGST Deskstar 180GXP IC35L060AVV207-0

HGST Deskstar 180GXP IC35L060AVV207-0

Now what makes this disk great, is that it can be jumpered down to act like an 8GB disk, so that things like MS-DOS and older OS’s like Windows NT can recognize the disk.  Even nicer that the jumper settings are on the disk!

Disk jumpers

Disk jumpers

My board supports booting from IDE, which is nice as I could paritition and format the disk from MS-DOS 5.00, and make sure things were working fine.

However it really doesn’t matter as over on Beta Archive, The has made an ATAPI driver available for not only Windows NT 3.1, but also various beta versions as well!  You can find the post, and the links to download here! (mirror here).  Now you can install from the boot diskette & a driver diskette and load the rest of the OS from CD-ROM.


You will have patch the INITIAL.IN_ and SETUP.IN_ files to allow installation on any new processor.


STF_PROCESSOR = “” ? $(!LIBHANDLE) GetProcessor


STF_PROCESSOR = $(ProcessorID_I586)

You can leave the files expanded, but this is needed if your CPU is newer than a Pentium (Yes a Pentium 60/66 type processor, so that is Pentium Pro, Pentium II, Pentium III, Pentium 4 and beyond…).  But yes, this is great!  No need to try to dig up old SCSI cards, SCSI disks, and SCSI CD-ROM drives.


And much like Qemu and VMware, the AMD PCnet is a great go to PCI card, and I was able to find this IBM 11H8130 Type 8-Z 10BaseT PCI Network Card which works!

IBM 11H8130

IBM 11H8130

The card works great with 11265315.exe set of drivers, OR disk image pcnet.7z .  But for sure the key is the in the chipset!


AMD AM79C970AKC PCnet(tm)-PCI II

As this chipset, the AMD AM79C970AKC is the one that is explicitly listed as compatible.  This IBM card provides an AUI port, along with a 10baseT port.

Post install, service packs

Of course when installing Windows NT 3.1, you’ll want service pack 3, the last update to the OS.

Also don’t forget to replace NTLDR & NTDETECT.COM from a later version of Windows NT to allow access to more than 64MB of RAM.


Windows NT 3.1 will allow you to install on FAT, HPFS, and NTFS v1 partitions and disks.  The TCP/IP is a 3rd party, from Spider that does not support DHCP.  Outside of doing it just because, it really is better to go with NT 3.5 or 3.51 as they have better SMP support, are much faster, and have a much more robust network stack.


EMX 0.9d rehosted on Win32

EMX on Win32

I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32.  The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2.  And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.

I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on.  I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure.  While it does compile fine using an older EMX 0.8h based release.

EMX 0.9d on Windows 10 x64

EMX 0.9d on Windows 10 x64

As you can see, it can compile the dhyrstone benchmark, and run the MS-DOS version via the MS-DOS Player.


SQL Server 6.5 on Windows 10 x64

SQL Server 6.5 running on Windows 10

In the same effort as getting SQL Server 4.21a running on Windows 10, I found that SQL Server 6.5 will run as well.  For what it’s worth, SQL Server 6.0 runs, but the enterprise manger will not run, giving this fun error:


The SQLOLE OLE object could not be registered.

And SQL 7.0 just bombs out with this:


Your SQL Server installation is either corrupt or has been tampered with (unknown package id).

Which clearly means I’m missing something in trying to transplant settings.  However for some reason SQL 6.5 I can register the SQLOLE type, and boom!

SQL 6.5 in action

SQL Server 6.5 running on Windows 10

SQL Server 6.5 running on Windows 10

On Win64 vs Win32 and COM objects

I should mention that when registering a COM object you typically run something like this:

regsvr32.exe \mssql\binn\SQLOLE65.DLL

Which picks up the one in the default path.  What about system32?

%SYSTEMROOT%\system32\regsvr32.exe \mssql\binn\SQLOLE65.DLL

Well it turns out that this ‘system32’ directory is actually the 64bit system directory!  And attempting to do this will just result in the error:

64bit regsvr32 on a 32bit COM object

64bit regsvr32 on a 32bit COM object

The module was loaded but the call to DllRegisterServer failed with the code 0x80040005. Well great.  This typically goes back to a permissions issue, or the wrong regsvr32.exe being called.

However on a Win64 based OS, you actually need to specify the Win32 version of regsvr32 which actually lives in the SysWOW64 directory, and run the command prompt at administrator!  So you would run it like this:

%SYSTEMROOT%\SysWOW64\regsvr32.exe \mssql\binn\SQLOLE65.DLL

And you should get:


32bit regsvr32 working

With this COM object registered, you can now launch the Enterprise manager!

Also I found a semi fun way to rename the SQL server:

sp_configure ‘allow updates’, 1
reconfigure with override
delete sysservers
sp_addserver YOURSERVERNAME,local

Running this and it renamed the local SQL instance, and shut it down.  Restarting and it connected to itself just fine.  Naturally change YOURSERVERNAME to whatever your hostname is.  SQL server always wants to be called whatever the actual hostname is, otherwise things break in strange and confusing ways.


Is this terribly useful?  Probably not.  But I think it’s kind of interesting to run 90’s era server software in the 21st century.  Sure I wouldn’t want to run any of it in any type of production environment, but it shows at it’s core how Win32 has not drifted.  However looking at the Microsoft Management console of SQL Server 7.0, and how it will not either run on Windows 10, nor will the snapin run show just how fragile the house of COM turned out to be, and meanwhile good old fashioned Sybase/Win32  code still runs from 1993 onward.

I suppose the next thing to do is to try it on Wine, or a fun enough debugger/syscall trace to see what on earth SQL 7.0’s problem is.  I don’t have any doubt that it’s nothing that can’t be fixed, although back to the root point, would you really want SQL 7.0 in 2016… or even SQL 2000 for that matter.