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!
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
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!
Infocom '87
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.
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.
A while ago I had chased FrontVM to moretom.net and found 2 links. One from 2003 which is a dead link, and the 2004 version which was archived by the wayback machine!
It was an interesting build, as it still used 68000 emulation from Hatari/UAE this pre-dates the 68000 to C or i386 ASM. However since it ran (mostly) the original code, it was more ‘feature complete’, although loading save games is broken for some reason (I think the decryption was not disassembled correctly). It was actually a stupid file mode setting. I just updated the source & put out a new binary, testing save games between Linux &Windows.
Anyways, it originally built on Cygwin, so I filled in the missing bits, and have it building on both MinGW & Visual C++
Parked outside Willow in the Ross 154 system
So yeah, it’s Frontier, for the AtariST with the OS & Hardware calls abstracted, still running the 68000 code under emulation. I think it’s an interesting thing, but that’s me.
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.
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.
I came across this hefty box, “the easy way bundle”, as it bills itself, the easy way to save over $1,000 on four popular software packages for your new Macintosh computer. Clearly the box has seen better days over the last 27 years but amazingly the contents are just fine.
$399.00 USD
It’s amazing how much more cheaper software has gotten over the years. Software used to be super expensive on the PC level, it really wasn’t until the office bundling with new machines that drove the price down. Back in the 80’s and early 90’s it wasn’t uncommon to pay upwards of $500 USD for a single application, like a spreadsheet or word processor.
bundle contents
Inside the box is more boxes, and inside those boxes is a rare sight, manuals! Actual printed manuals! That is how you know this is something of near museum quality. I kind of like being able to read a physical book from time to time, and it’s really great.
Oh and incidentally the disks all worked, much to my amazement. I just needed to get a working Macintosh with a drive that can read 800kb disks and an Ethernet card.
4 great programs!
Although it does list four packages, it really is 3, featuring:
WordPerfectÂ
Lotus 1-2-3
SoftPC
AccessPC is simply a FAT driver for MacOS to read MS-DOS floppies & removable media.
So let’s take a quick look!
An actual software license
I haven’t seen something like this in a long while, an actual license printed on nice stock certificate stock paper (remember those?!), with a hologram tag. Does WordPerfect even exist anymore? Can I mail this in for an upgrade? Does it even matter?
Install options for WordPerfect
While the install options give the impression that WordPefect is a really full featured word processor once loaded up for some reason it really felt barren.
Although it does have the important proofing tools, don’t expect a dictionary or thesaurus to have anything more than the words, no definitions or anything like a style guide. It did ship on floppy and I guess I’ve just become so spoiled living in the future with terabytes of storage and an overwhelming supply of deference media.
Going back to 1992 is a real trip to not only how clean some of the UI elements feel, but just how seemingly feature sparse the more advanced applications feel.
Personally I never really liked WordPerfect so I more so installed it as a curiosity, much like when I had WordPerfect for Unix. I’m the crazy one that likes MS Word.
Lotus 1-2-3 1.00 for the Mac
With that said, I went ahead and installed Lotus 1-2-3, and I was really surprised, that the installer was not only really appallingly bad, requiring you to copy the contents to the HD before installing it (so you need a lot of free space), but there was no copy protection at all either on the disks, or in the form of a certificate/serial code. In school I did start with 1-2-3, but with the onslaught of Microsoft Office had quickly moved to Excel, and after 30+ years I really don’t remember much of the slash commands, let alone how to use if effectively. Luckily the menu is okay to walk through, and of course there is Macintosh style menus so you don’t even have to deal with the slash menu if you don’t want to.
SoftPC
SoftPC didn’t come with a box within the box, just the two manual sets & the disks shoved into the manuals. I doubt it came like that, but this is all I have.
SoftPC licensing stickers
Compared to the WordPerfect certificate, the stickers hidden in the folds of the SoftPC manual just feel cheap. And the years have not been kind as you can see with the discoloration, and the cheap adhesive on them has completely dried off. After I had scanned this they have all fallen off the backing paper. Although I also have version 3.1, I didn’t want to lose this so I’ll just save it for prosperity.
And SoftPC is a great program, although it really is an absolute crutch, allowing you to run PC software on your Mac. Flash forward 30 years, and the industry continues with VMware & Parallels. What is more amazing is how so many leaders in PC emulation completely missed the virtualization market. But most people would think you were a little strange to run a PC on a PC. Or more than one at the same time.
The SoftPC platform
SoftPC emulates a really barebones PC, it only supports a maximum of 640kb of RAM, and the CGA graphics adapter. For anything more advanced you really need to get SoftAT, which supports more options. Or even better, get a copy of SoftPC 3.1, which not only allows more memory but bundles a copy of MS-DOS 5.0 and Windows 3.1
SoftPC 2.52 CGA running Space Quest 1
I found the emulation of the CGA kind of lacking when compared to version 3.1Â Although some games like BattleTech render just fine, Space Quest just looks horrible in version 2.52.
SoftPC 3.1 CGA running Space Quest 1
Although to be fair it doesn’t look so much better in version 3.1 either. However 3.1 emulates both EGA & VGA (along with expanded & extended memory) giving a far more richer 286 based emulation solution
SoftPC 3.1 EGA running Space Quest 1
As you can see there really is no comparison to the EGA version.
Although there are far more better solutions today to do PC emulation, for some reason there is always something cool to have an emulator running an emulator.. Sadly the 80386 based emulation didn’t come to the 68000 based platform, instead the later generation emulation was only available to the PowerPC.
I guess it goes to show, but of all the applications I have for MacOS, I enjoy SoftPC the most. I suppose I need better softwares.
I found this fun page over on retroweb.maclab.org What is interesting is that it encorporates PeerJS and WebRTC to allow for a virtual network, letting you play multiplayer AppleTalk.  Just enable the network, and scan for other users.
It’s pretty cool, in a zero config kind of way!
PCE-MacPlus
And for coolness it’ll embed in a snazzy picture of a Mac Plus. Â Although you can magnify the screen, so you don’t have to squint so much.
For anyone who is interested in classical 680×0 based NeXT emulation, I build the latest snapshot of Previous for Windows. Â You can find it here:Â Previous-1.6_build_767.7z
When I had a cube, I was like everyone else, without a working magnetic optical disc. And I was a (and still am) a diehard 3.3 fan, but it’s still fun loading up version 0.8 under emulation.
1.0a
The problem was several fold, from the drives turning out to be VERY sensitive to dust, the NeXT’s sucking air through the MO drive, trapping quite a bit of dust in the drives, mechanisms breaking, the optics being sensitive to heat, and of course our old friend, bad capacitors. Â The build disk application warns it can take upwards of 3 hours to create a MO of the operating system. Â They clearly were not fast either. Â I think it took 30 minutes under emulation.
Oops!
At the end of the day, I guess it didn’t matter. Â Optical discs came and went in the 80’s , and re surged with CD’s and re-writable discs up until this decade. Â Now we’ve pretty much gone either all solid state, or only large capacity disks with moving parts.
Oh well, I was looking for sample code, to see if there were other driver examples for the driverkit. Â I didn’t think there was anything far back when NeXTSTEP was a black box, 68030 thing, but it never hurts to look.
telnet
It is cool that TCP/IP won out in the protocol wars. Â It’s very convenient to have a current 2017 desktop, being able to communicate with operating systems nearly 30 years old. Â Especially when it comes to things like NFS, making it even better for mapping drives, and sharing data.
And much to my surprise, with the bad reputation the SLiRP code has, I’m able to mount my Synology’s NFS share just fine from my virtual cube.
mount -t nfs -o fs,mnttimeout=1,retry=1,rsize=512,wsize=512,retrans=1 192.168.1.3:/volume1/Data /mnt/data
I had just added some parameters to lower retry times, and resize the blocksize to be much smaller than a single packet so I don’t have to worry about any issues with MTU resizing. Â Maybe it’s not optimal, but being able to copy data in and out is all I want to do, and it’s been reliable.
Oh yeah, since it was burred in the messages, for people who like old dmesg’s
Remote debugging enabled
msgbuf at 0x73fe000
NeXT Mach/4.3 #5.1(XM13): Thu Dec 1 13:03:37 PST 1988; /sources/projects/mk-0.8.26e0.8/RELEASE (photon)
physical memory = 15.99 megabytes.
available memory = 14.97 megabytes.
using 16 buffers containing 0.12 megabytes of memory
odc0 at 0x2012000
od0 at odc0 slave 0
od1 at odc0 slave 1
SCSI 53C90 Controller, Target 7, as sc0 at 0x2014000
IBM DORS-32160 !# as sd0 at sc0 target 2 lun 0
Disk Label: NeXT_0_8
Disk Capacity 2063MB, Device Block 512 bytes
en0 at 0x2006000
en0: Ethernet address 00:00:0f:00:22:09
dsp0 at 0x20000d0
np0 at 0x200f000
sound0 at 0x200e000
root on sd0
master cpu at slot 0.
setting hostname to NeXT_0_8
network_init.gethostbyname fails, errno=2
network_init failed: no network
Network Server initialised.
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.
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.
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.
From the readme
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.
hanoi.c:
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.
hanoi.s:
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
linking
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
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.
Linking
And it linked without any unresolved externals.
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.
***
Addendum
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.
DooM is without a doubt one of the most popular PC games of all time. Â And thanks to it being written in C is also an incredibly portable game. Â One platform that mysteriously was lacking DooM was the SHARP x68000.
After a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the x68000, I thought I would take a stab at trying to compile DooM. Â Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. Â So the first phase was to convert all the comments.
In order to convert the comments, I came across this great tool, uncrustify. Â The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file…
uncrustify.exe --replace -c 1.cfg cl_main.h
you get the idea.
The key thing is the configuration file that tells uncrustify what to do. Â To convert C++ comments to C is quite simply:
cmt_cpp_to_c = true
And away we go. Â Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. Â I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. Â After it was running with minimal changes, it was time to start the real fun.
Starting the actual port aka platform issues
The first error I hit was:
Error: Couldn’t realloc lumpinfo
For some reason the SHARP/Hudson LIBC has issues doing a realloc.  I have no idea why.  Over on nfggames Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further.  I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware.  Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress.  I could then get from failing malloc to this:
startup errors
And from there after trying different assemblers, flags, and all kinds of other things we could finally get null DooM running on the x68000 via 68030 emulation on XM6 TypeG.
null DooM running on the x68000
DooM comes to life
From there, Neko68k was able to do something amazing, add in system support! Â Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:
There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted!
Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!
And then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port!
Issues while cross compiling
Around this time I had noticed that when I built a cross compiled version the video for me was garbled. Â After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!
 .dc.l $00000000,$40f00000
instead of:
.dc.l $40f00000,$00000000
I tried re-building, re-configuring my host setup, and I still had the same issue. Â I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. Â Maybe it’s a bug in GCC 1.x cross compilers? Â I don’t know, but since the procedure is small enough, it was easier to just have the native GCC produce an assembly version which I just assemble and link without issue.
Behold! DooM on the x68030!
Yes, there is no audio, but wow it’s playable! Â I do need to map the keyboard better in the emulator, but the key layout in the source is fine.
Downloads
For anyone who cares you can follow more of the porting adventure here:
