So what is the deal with A/UX anyways?

The year is 1983, and several Apple employees visit Brown University, and get some idea of what Universities want in a computer for the coming future. The big buzz of the era was the so called 3M machine:

  • 1 Megabyte of Memory
  • 1 Megapixel display
  • 1 Megaflop of performance

Naturally the Macintosh didn’t fill this void, instead leaving this to the new SUN-2 workstation. However seeing the opportunity, in 1984 the seeds were planted for the ‘Big Mac’ project. The hardware design was headed by Rich Page, which included new things like ADB, and dedicated video RAM, along with a 68020 processor, and 68881 maths co-processor. Additionally Big Mac was intended to run a UniPlus version of SYSV Unix, along with the MacOS Toolbox being ported to run directly on top of Unix.

All that I can find of the Big Mac project is this insanely low resolution image, along with the codename ‘Milwaukee‘.

However all this came to and end in 1985 with the ouster of Steve Jobs, who in turn took various people including  Bud Tribble, George Crow, Susan Barnes, Susan Kare, Dan’l Lewin, and Rich Page. Apple followed up with a $5MM USD lawsuit alleging that Jobs had done research for a next generation product and taken the key staff, namely Page from Apple to make it reality. The suit was eventually dismissed.

From there the race was on to build a 3M machine. NeXT would take the Big Mac concept further with the NeXT CUBE which included ADB, NuBUS and a 68030/68882 + SCSI + Ethernet setup. And for the OS, 4.3BSD Tahoe+Mach 2.5, along with a new Objective C language, and new OO frameworks.


Back at apple however the ‘Big Mac’ project seemed to have stagnated, and was slimmed down and eventually shipped as the Macintosh II in 1987. There no doubt was a re-awoken sense of urgency in the academic space for the 3M market, now that NeXT was making a 3M machine Apple of course didn’t want to be pushed out of the new space. Apple released a real 1.0 product (1.1.1 survives, although you have to run ( /etc/toolboxdaemon & ; term) to get anything fun from Shoebill with the ISO), what can barely be called a bare bones SYSV port with overlapping terminals at best..

A/UX 1.1.1 codename ‘Circle K’ running on the Shoebill emulator

Overwhelming, and interesting this is not.

This of course was more like a tech demo, running a single ‘Unix toolbox app’ at a time. Pricing according to usenet was around $500 for the software, keeping in mind of course that a Macintosh II would be far more expensive. Version 1 also started to add BSD features namely curses in 1.0, allowing you to port simple terminal ‘graphics’ to the OS. The trend of adding BSD features was only going to continue from here! But all of this is a large step up from the earliest known version simply labeled as 0.7 which despite it’s ‘Oreo’ appearance is strictly text mode only.

Oreo is text mode only.

Dawning of a new era

The real magic is in 2.0:

Sim City on A/UX 2.0 code name Perestroika, Space Cadet

Think of it more like the OSX of the 1980s. Finder has been ported over to the Toolbox on Unix API allowing A/UX 2.0 to run off the shelf MacOS applications. Under the hood however is the same UniSoft SYSVr2. However running MacOS on top of Unix gives it far faster disk IO, and of course the much vaunted memory protection, although with the massive catch that it’s only for Unix applications. You can still crash applications, and even finder. However you can telnet into the box and restart services, or perform a graceful reboot.

For Unix fans this was the first time you could get ‘off the shelf applications’ that didn’t cost a fortune, along with the standard Unix far. Amazingly both the C compiler and Fortran 77 compiler are included in the box. By 1990 many a company was making these only available for a separate purchase. Version 2.0 also brought along some BSD features with the big one being UFS support for longer filenames, and faster disk performance than the aging SYSV filesystem.

Of course it wouldn’t be all sunshine and rainbows as around this time Apple launched a lawsuit against Microsoft, and Atari over the visual iconography of MacOS (Oddly enough GEM on the ST was ignored). This so called ‘look and feel’ lawsuit lead to a boycott of the fledgling Unix from the FSF, which in turn hurt things like binutils/gcc/gdb etc being easily available to A/UX users.

So what went wrong?

Without even looking at the follow up version 3, and the products demise in the transition from 68000 to PowerPC, the writing was on the wall.

  • Price

The damned thing was just too expensive! From WikipediaWhen introduced, a basic system with monitor and 20 MB hard drive cost US$5,498” Version 1 was available on tape, and later CD-ROM, I think there was a floppy version, but without a doubt a 20MB disk is far too small. Just as anything under 4MB of RAM is not going to be realistic. Adding in these components you are going to be into the low end of SUN’s catalogue. And why would you take a chance on Apple when you could go to an established Unix vendor?

The other issue is that Unix being Unix you really needed a MMU, and Motorola MMU chips were expensive. Also A/UX had drivers for SCSI only. This prevented a ‘low end revolution’ as the low end machines like the 605 didn’t have SCSI, or full 68040’s. Even the end of the line Quadra 800, sold for an eye watering $4,679!

  • Direction

What was the heart of A/UX? It was a Unix with a one button mouse, and optional X-11.. with A ONE BUTTON MOUSE?! It was a SYSV Unix, not a BSD, but did include BSD TCP/IP, NFS & UFS filesystem. It was shunned by the FSF as a first tier platform so people had to fidget with code to get it to compile. It was GSA C2 certifiable, but did anyone actually use it in that role?

It was also a Unix with a version of Outlook, and Excel, AfterDark, Fortran 77, and a dead simple UI.

Even after all this time, answering what A/UX was seems to be an identity crisis.

Where did it go right?

One of the big deciding factors in getting workstations for government compliance was the so called C2. This meant things like enforced passwords, auditing and POSIX. It’s everything that the POSIX subsystem for NT was built for, to check just enough boxes, while for Apple A/UX just gave them an instant win. I have no idea if it ever happened but I’m sure somewhere someone was using a Quadra with Word Perfect and A/UX to be a super expensive and certified Mac. Obviously the MAE project dovetails into this, giving commercial MacOS applications to Unix users, but so many others have covered that, and the short version is that it’s incredibly fragile and not very robust at all.

I’m sure someone used it as a fileserver, heck even in the PowerPC generation there a straight port of AIX to a server along with AppleTalk modules.

The demise

Its easy to point to using UniSoft SYSVr2 as being a cost factor, but it really was the hardware requirements. Without any AUX for the LC it was doomed. This wasn’t going to be the Unix for Grandma. Transitioning to the PowerPC removed the braindead CPU problems of lacking a MMU or FPU, but I suspect that the tricks of the 68000 translator would not have run, and certainly wouldn’t pull off things like device drivers. Worse stil people just got used to System 7, and had hopes that the fabled Copeland / System 8 would bring about something strong enough like a Unix without any of the complexities.

Timelines, however slipped, Apple had flirted with MkLinux but didn’t fully commit. Indeed these were dark days, it’s like they were so dead set on going forward to not see a seemingly obvious solution to the OS problem in the past.

Looking at Carbon, and Toolbox32, it’s hard not to imagine a world pushing ISV’s to write for a protected MacOS, but they’d never had bought NeXT. As a matter of face, I would argue that without Steve’s media connections from Pixar, Apple would have slid away into irrelevance, as media outsells the PC tech anyways. Even in 2010 Jobs had called Apple clearly in the ‘post PC era‘.


On trying to extract files from a Texas Instruments S1500

So this started out as a weird thing that killed a day for me. I thought it was a little fun to look at but, ultimately I proved that I could extract files, but not from the requested image.

So let’s get into some more details, my failure, and well it’s been raised into another chance for some luck/fast knowledgeable hacker to get a payout to extract a single file.

As mentioned above the computer is the Texas Instruments S1500, the disk image was dumped on bitsavers years ago as s1505_cp3540/s1505_cp3540.dd.gz. As you may guess it’s a raw ‘dd’ of a disk.

Now looking at a few sources namely unix-ag the OS in question is TI System V, an AT&T SVR3.2 derivate. Running strings does reveal ‘SysVr3TCPID’ And this appears to be the Unix Version Banner:

(c)Copyright 1993 Hewlett-Packard Company,  All Rights Reserved.
(c)Copyright 1986-1992 Texas Instruments Incorporated,  All Rights Reserved.
(c)Copyright 1984-1988 AT&T, All Rights Reserved.
(c)Copyright 1979, 1980, 1983, 1985-1990 The Regents of the Univ. of California
(c)Copyright 1980, 1984, 1986 Unix System Laboratories, Inc.
(c)Copyright 1990 Motorola, Inc.
(c)Copyright 1989-1990 The Santa Cruz Operation. All Rights Reserved.
                         RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause in DFARS 252.227-7013.
                         Hewlett-Packard Company
                         3000 Hanover Street
                         Palo Alto, CA 94304 U.S.A.
Rights for non-DOD U.S. Government Departments and Agencies are as set
forth in FAR 52.227-19(c)(1,2).

Along with further extraneous info like:

TI Sys V
Hewlett-Packard 9000 Series 1500

Fantastic. Well digging around you’ll eventually find that SYSV filesystems have a magic number, and it’s 0xfd187320

So a simple search through the raw filesystem reveals some:

[email protected]:/mnt/c/temp$ xxd s1505_cp3540.dd | grep 'fd18 7e20 0000 0002'
0035b7f0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....
00f5b7f0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....
02f5bff0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....
04cc0bf0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....
0505bff0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....
1f1267f0: 0000 0000 0000 0000 fd18 7e20 0000 0002  ..........~ ....

And this fits the bill, as the next 32bit ‘word’ is the version, in this case 2 to indicate 1024k blocks ,and improvement added to SYSVr2. One thing is that the struct to read a super block is 512bytes (or is it always?), and the magic number is near the end, so from the above offsets, subtract 496 (decimal!) and you can get the start and sizes of each filesystem. Fantastic!

Speaking of SYSVr2, Do you know what is another SYSVr2? A/UX.

Shoebill was panned for not emulating the full Macintosh, rather it reads the kernel directly from the filesystem, and boots into it. That means Shoebill can read UFS/SYSV. Great start?

So I took the filesystem code from Shoebill, hacked it enough to let me build on Visual Studio, and point it to a raw filesystem and take a look. I put it here: filesystem.c

Now I’m impatient so it still needs a legit Apple A/UX virtual disk. Granted we don’t need it, but it made it easier to let the existing code fiddle with apple partitions, but when it comes time to read SYSV blocks, I closed the file handle and swapped things around. And that lead to this:

As you can see there is a LOT of zeros. However the magic & type align.

Meanwhile here is what an A/UX SYSV filesystem looks like. Notice far less zeros.

Additionally I was able to get another 68k based SYSV Unix disk, and yeah not all zeros. Also yes, using the Shoebill code it extracted files just fine.

However using my approach on the filesytem I always only get a directory with 2 enteries the ‘. ..’. I modified the source to just count inodes and write them to disk. And use inode 2 is just a tiny file. No doubt with all the zeros the disk is either very corrupted (backup superblocks?! where?! how?!) or the kernel implicitly knows these things, or finds them somewhere else.

I’ve been authorized to give a bounty of $200 USD to be able to extract arbitrary files from the 1505 disk image. I thought I’d give it a shot, but I don’t get how the super block aligns but the data doesn’t. Unless there is some other insane padding thing for a 1k superblock? The more I think about it, it’s probably likely as I know at some point I was skipping 3 blocks from an offset to get to a superblock, and 3 is just a weird number. 1 block header, 2 block superblock makes more sense.

Additionally this table may prove useful, especially for the ‘skip 3’ or pad to 1k:

Tape and disk utility is in progress...

26 partitions, 12-longword descriptors:
     Name    Start    Length   User  Comments
1  * LABL vl 0        2        FFFF
2  * PTBL pt 2        3        FFFF
3    SAVE sb 5        3        FFFF
4    FMT  fp 8        9        FFFF
5    TZON tz 17       296      FFFF
6  * unx1 lb 313      1024     0002  TI Sys V 3.3.2
7  * unx1 lb 313      1024     000A  TI Sys V 3.3.2
8  * unx1 lb 313      1024     0013  TI Sys V 3.3.2
9  * unx1 lb 313      1024     0014  TI Sys V 3.3.2
10   unx2 lb 1337     1024     0002  TI Sys V 3.3.2
11   unx2 lb 1337     1024     000A  TI Sys V 3.3.2
12   unx2 lb 1337     1024     0013  TI Sys V 3.3.2
13   unx2 lb 1337     1024     0014  TI Sys V 3.3.2
14   unx3 lb 2361     1024     0002  TI Sys V 3.3.2
15   unx3 lb 2361     1024     000A  TI Sys V 3.3.2
16   unx3 lb 2361     1024     0013  TI Sys V 3.3.2
17   unx3 lb 2361     1024     0014  TI Sys V 3.3.2
18 * cfg1 cb 3385     17       FFFF  TI Sys V 3.3.2
19   cfg2 cb 3402     17       FFFF  TI Sys V 3.3.2
20   cfg3 cb 3419     17       FFFF  TI Sys V 3.3.2
21 * root fb 3436     12288    FC02  TI Sys V 3.3.2
22   usr  fb 15724    32768    FC02  TI Sys V 3.3.2
23   jdis an 48492    2        FFFF  multi-volume file system anchor
24   pipe fb 48494    1024     FC02  pipe file system partition
25 * swap pb 49518    32768    0002
26   prt1 fb 82286    448972   FC02  part of jdis multi-volume

Did you know there is almost nothing left to document that this poor machine even existed?

Seriously look for “TI System V”

Heck even on the UTZOO archives..

AltaVista UTZOO search (

It’s like 5 posts, 3 being the same, someone who couldn’t dial out, and someone on the old UUCP map! Save me!

Missing link for Basilisk I found

Actually I held onto this, as I wanted to do something crazy for that Marchintosh thing but life got in the way it fell by the wayside, and well now it’s September, and I already have a Qemu instance running A/UX so my ‘at best’ hope of Basilisk II with MMU emulation is all but moot.

Captain, oh Captain!

While it may look like 2 very old emulators, which they are, the interesting thing here is that this old version of Basilisk that only has Macintosh Classic emulation is using the 68000 emulation core from UAE 0.6.8. It took a lot of downloading stuff, a lot of other nonsense, but I eventually found it, and was able to diff around to find the changes made were rather inconsequential, there by letting me rebuild UAE back on top of Basilisk.

My plan had been to either use far newer UAE cpu core, say from Previous as it has working MMU support, or Musashi.

I was building hard coded for TDM GCC 5.1.0 on MinGW. It doesn’t matter anymore but I threw it up on github since that is where all the cool kids are.

It’s absolutely pointless I guess, but maybe someone will find it interesting.

As reported a few days ago the Windows patches for FreeDOS were committed!..

a couple of weeks ago.

This will be the perfect follow up to the aptly named previous post FreeDOS running Windows 3.1.

I’ve haven’t built the FreeDOS kernel in a while and I have to say it’s pretty easy. I’m taking the easy way out here, so I’m using OpenWatcom v2, because I figured the tools should be both at least Win32/Win64 and halfway up to date. Don’t get me wrong, MS-DOS Player is a fantastic app but I don’t want to lean on it for 100% of the build.

I configured it for something in my mind generic with the following flags:

build fat16 wc 86 win

Naturally it had issues with 3 executables, two of which are generated as the project builds, and I just did some silliness to have MS-DOS player make ‘native’ versions: patchobj.c
        $(CLT) $(CFLAGS) patchobj.c
        msdos -cobj.exe
        -rm -f
        -ren obj.exe patchobj.exe

exeflat.exe: exeflat.c ../hdr/exe.h
        $(CLC) $(CFLAGS) exeflat.c
        msdos -cxeflat.exe exeflat.exe
        -rm -f exeflat.exe
        -ren xeflat.exe exeflat.exe

The same went for sys\bin2c.exe but it’s not rebuilt every time so it doesn’t matter.

And with that in hand it boots. YAY

And now for some absolutely unfair testing. Before anyone complains, yes this is absolutely unfair I mean hell if you bought Windows 3.1 in 2021, I guess get OS/2 or just keep digging at the yard sale and get MS-DOS. Anyways here we go:


Turning off InDOSPolling gives this lovely crash. Naturally then it’s still required.

My go-to test, Running Infocom/FASA BattleTech Crescent Hawk’s Inception in CGA mode in a Window hard locks the VM before anything is drawn to screen. Bummer. And that is pretty much the story of FreeDOS under Windows on this build. Again it’s 2021 who even needs Microsoft VDMs?

That said there must be some weird hook in MS-DOS that Win32s relies on. Just like before Win32s fails to run.

The holy trinity of ‘bad’ Windows 3.0 games, Sim City, Sim Earth and Sim Life work just as they did in the prior version, with Sim Earth instantly quitting. Not sure what is going on there. It does launch with virtual memory enabled, but then proceeds to corrupt all the file handles and Program Manager loses it’s mind. In the productivity front Excel v3, and Microsoft Word v2 run fine. Yay!

Windows 3.1 is serious business!

So in conclusion doing Win16 things in Windows 3.1 is seemingly fine.

AMD64 Pinball extravaganza!

With all the talk of 64bit versions of Pinball I thought I’d share simple script to extract Pinball from an XP x64 CD-ROM so you can take it with you. It’s portable so thats nice too, although it doesn’t use any wad/pak/zip files so all the assets are loose files:

expand f:\amd64\font.da_ font.dat
expand f:\amd64\pinball.da_ pinball.dat
expand f:\amd64\pinball.ex_ pinball.exe
expand f:\amd64\pinball.in_ pinball.inf
expand f:\amd64\pinball.mi_ pinball.mid
expand f:\amd64\pinball2.mi_ pinball2.mid
expand f:\amd64\sound1.wa_ sound1.wav
expand f:\amd64\sound104.wa_ sound104.wav
expand f:\amd64\sound105.wa_ sound105.wav
expand f:\amd64\sound108.wa_ sound108.wav
expand f:\amd64\sound111.wa_ sound111.wav
expand f:\amd64\sound112.wa_ sound112.wav
expand f:\amd64\sound12.wa_ sound12.wav
expand f:\amd64\sound13.wa_ sound13.wav
expand f:\amd64\sound131.wa_ sound131.wav
expand f:\amd64\sound136.wa_ sound136.wav
expand f:\amd64\sound14.wa_ sound14.wav
expand f:\amd64\sound16.wa_ sound16.wav
expand f:\amd64\sound17.wa_ sound17.wav
expand f:\amd64\sound18.wa_ sound18.wav
expand f:\amd64\sound181.wa_ sound181.wav
expand f:\amd64\sound19.wa_ sound19.wav
expand f:\amd64\sound20.wa_ sound20.wav
expand f:\amd64\sound21.wa_ sound21.wav
expand f:\amd64\sound22.wa_ sound22.wav
expand f:\amd64\sound24.wa_ sound24.wav
expand f:\amd64\sound240.wa_ sound240.wav
expand f:\amd64\sound243.wa_ sound243.wav
expand f:\amd64\sound25.wa_ sound25.wav
expand f:\amd64\sound26.wa_ sound26.wav
expand f:\amd64\sound27.wa_ sound27.wav
expand f:\amd64\sound28.wa_ sound28.wav
expand f:\amd64\sound29.wa_ sound29.wav
expand f:\amd64\sound3.wa_ sound3.wav
expand f:\amd64\sound30.wa_ sound30.wav
expand f:\amd64\sound34.wa_ sound34.wav
expand f:\amd64\sound35.wa_ sound35.wav
expand f:\amd64\sound36.wa_ sound36.wav
expand f:\amd64\sound38.wa_ sound38.wav
expand f:\amd64\sound39.wa_ sound39.wav
expand f:\amd64\sound4.wa_ sound4.wav
expand f:\amd64\sound42.wa_ sound42.wav
expand f:\amd64\sound43.wa_ sound43.wav
expand f:\amd64\sound45.wa_ sound45.wav
expand f:\amd64\sound49.wa_ sound49.wav
expand f:\amd64\sound49d.wa_ sound49d.wav
expand f:\amd64\sound5.wa_ sound5.wav
expand f:\amd64\sound50.wa_ sound50.wav
expand f:\amd64\sound528.wa_ sound528.wav
expand f:\amd64\sound53.wa_ sound53.wav
expand f:\amd64\sound54.wa_ sound54.wav
expand f:\amd64\sound55.wa_ sound55.wav
expand f:\amd64\sound560.wa_ sound560.wav
expand f:\amd64\sound563.wa_ sound563.wav
expand f:\amd64\sound57.wa_ sound57.wav
expand f:\amd64\sound58.wa_ sound58.wav
expand f:\amd64\sound6.wa_ sound6.wav
expand f:\amd64\sound65.wa_ sound65.wav
expand f:\amd64\sound68.wa_ sound68.wav
expand f:\amd64\sound7.wa_ sound7.wav
expand f:\amd64\sound713.wa_ sound713.wav
expand f:\amd64\sound735.wa_ sound735.wav
expand f:\amd64\sound8.wa_ sound8.wav
expand f:\amd64\sound827.wa_ sound827.wav
expand f:\amd64\sound9.wa_ sound9.wav
expand f:\amd64\sound999.wa_ sound999.wav
expand f:\amd64\table.bm_ table.bmp
copy f:\amd64\WAVEMIX.inf WAVEMIX.INF

Naturally you’ll want to substitute F:\ with whatever drive letter your CD-ROM/ISO file is mounted on.

And thanks to a long needed feature in Windows 10 you can verify that yes indeed it is a 64bit version.

Isn’t that awesome?! Obviously ARM64 users are left out in the dark, as far as I know there was no ARM64 versions of Windows XP. As a matter of fact, was there any public versions of Windows XP for ARM? Naturally the Surface RT shipped with 8.0

Anyways at long last we can have our 64bit pinball despite the weird bugs, and how the plunger is mostly hidden no doubt due to yet more weird floating point/integer size inconsistencies

Re-visiting Gopher on A/UX

Rather unintentionally some 7 years ago (to the day!) I was playing with an early gopher server on Linux, musing that one day it’d be cool to run it fully on A/UX (what is it anyways?!). And thanks to Qemu’s 68040 support the time is at hand.

First off I need to run this on Linux so I’ll need to build the appropriate branch myself. Thankfully Cat_7 has boiled it down to a really simple formula:

git clone -b q800.upstream q800-upstream
cd q800-upstream
./configure --target-list=m68k-softmmu --enable-gtk --enable-sdl

In my case I remove the gtk and sdl as I’m running this headless.

Now onto the OS itself. While I had numerous images built over the years for Shoebill there was one major issue when compared to Qemu, and that is Shoebill loads the kernel directly while Qemu emulates the hardware so it will boot MacOS 7 directly. While on the surface this is mundane that does mean however that none of my images will actually work on Qemu as they don’t include a blessed copy of System 7. Not that I care that much I could always do a simple dump/restore [ dump.bsd 0f – /dev/rdsk/c0d0s0 | (cd /mnt; restore xf -) ] of my A/UX stuff that I care about anyways. Luckily since I had added that SCSI file support to Cockatrice I could still partition out some disks and install from there.

Now for the further bit of bad news for me is that I found that the 68020 based Shoebill ran 3.0.0 far more stable than 3.0.1 or 3.1. So I’d built everything around 3.0.0. And of course trying to boot 3.0.0 on a Quadra 800 just gives you a hard lock up. I don’t have the setup disk for 3.0.0 but mounting the CD-ROM gives you access to the disk tool (the 3.0.0 version doesn’t check for the Apple string on SCSI ROMS so you can partition with that as well). Anyways too much time thinking I’d done something wrong until this had to be pointed out to me:

Compatibility matrix from penelope

That’s right, 3.0.0 doesn’t run on the Quadra 800. Much longer ago I had a Quadra 950, fantastic beast of a machine, and yes it ran 3.0.0 just great. So shockingly running the right versions got me up to a working system just fine.

Now of course back in the Shoebill days I got ‘3.0.1’ kind of working by cheating. The /mac programs didn’t work on Shoebill however I could copy them over from 3.0.0 to get a working system. Could I substitute a 3.0.1 kernel & /mac directory onto a 3.0.0 system?

So first up the System 7 install from A/UX 3.0.0 is too old for a Quadra 800. Obviously just use the one from 3.0.1. Great.

This lead to a problem where the root filesystem always needs to be checked in single user mode. Something that is shockingly hard to do when your Quadra runs so fast as you have less than a second to hit the ‘top’ button to halt the autoload.

Naturally the standalone runs fine, with no errors.

Thinking that it’s the start-up scripts I remove all the fsck’s and then get this message:

Great a kernel panic. ialloc: dup alloc. Thinking that maybe it’s confusing the UFS, I go ahead and format the disk in SYSV and restore the image onto that.

This gets me another kernel panic, this time no root filesystem. Surprise the SYSV filesystem was made optional in a default install. I run ‘newconfig sysv’ from 3.0.1 and copy that kernel back, and for good measure the shared libraries from 3.0.1. Now I get a different error:

Interesting, I try to hit restart, and instead I get dumped into text mode!


So here we are a 3.0.1 kernel with a 3.0.0 userland! I’m going to use this as a server anyways so I don’t really care about the Mac UI. Naturally so many twists and turns I’ll just skip to the end. Networking didn’t work correctly. Maybe I should have copied all the network stuff from 3.0.1 over but at this point it’s basically a 3.0.1 system so why even bother?

So the next thing of course is just to setup Qemu to listen on a loopback and add some disks. A lot of disks.

./qemu-system-m68k \
-L pc-bios \
-m 256 \
-M q800 \
-vnc \
-serial stdio \
-bios Quadra800.rom \
-net nic,model=dp83932,netdev=ne -netdev user,id=ne,hostfwd=tcp:,hostfwd=tcp:,hostfwd=tcp: \
-drive file=pram-aux.img,format=raw,if=mtd \
-device scsi-hd,scsi-id=0,drive=hd0,vendor="SEAGATE",product="ST225N",ver="1.0" \
-drive file=scsi0.vmdk,media=disk,format=vmdk,if=none,id=hd0 \
-device scsi-hd,scsi-id=1,drive=hd1,vendor="SEAGATE",product="ST225N",ver="1.1" \
-drive file=scsi1.vmdk,media=disk,format=vmdk,if=none,id=hd1 \
-device scsi-hd,scsi-id=2,drive=hd2,vendor="SEAGATE",product="ST225N",ver="1.2" \
-drive file=scsi2.vmdk,media=disk,format=vmdk,if=none,id=hd2 \
-device scsi-hd,scsi-id=3,drive=hd3,vendor="SEAGATE",product="ST225N",ver="1.3" \
-drive file=scsi3.vmdk,media=disk,format=vmdk,if=none,id=hd3 \
-device scsi-hd,scsi-id=4,drive=hd4,vendor="SEAGATE",product="ST225N",ver="1.4" \
-drive file=scsi4.vmdk,media=disk,format=vmdk,if=none,id=hd4 \
-device scsi-hd,scsi-id=5,drive=hd5,vendor="SEAGATE",product="ST225N",ver="1.5" \
-drive file=scsi5.vmdk,media=disk,format=vmdk,if=none,id=hd5 \
-device scsi-hd,scsi-id=6,drive=hd6,vendor="SEAGATE",product="ST225N",ver="1.6" \
-drive file=scsi6.vmdk,media=disk,format=vmdk,if=none,id=hd6
Yeah well… great!?

One nice thing is that since we are on Qemu I don’t have to use raw disk images, I can zero stuff out and use VMDK’s. Nice. I guess I could bridge the VM later, but for now NAT is fine enough as all I need is telnet & gopher. So I grab gopher2_3.1.tar.gz, rebuild and move over my gopher site from Linux into A/UX and I’m up and running in no time. It was shockingly easy. I update a few things to reflect it running on A/UX now.

Currently 2 days of uptime!

And just like that I took my semi popular gopher site, and moved it to A/UX seven years after thinking that this would be a ‘good idea(tm)’. I’m sure it won’t backfire spectacularly.

I don’t know if any of this is useful or interesting but it was to me. It’s been nice that Qemu has been able to keep uptime in several days, I had 3 days of uptime before I took it down to max out the storage so I could possibly do more with it.

Naturally it’s still available as gopher://

Qemu’s Macintosh Quadra in alpha usability! (runs A/UX!)

I’m being a bit unfair as far as Alpha’s go it’s rough to get going but wow it’s GREAT! For starters it’s a Quadra 800 so System 7.1 through 8.1 will work. Also this has full 68040 capabilities so yes that means MMU and YES A/UX (and NetBSD!) will run

As always you can find more on emaculation, the best source for news and info on emulating the Mac.

Additionally you can find the setup guide here.

Many of my Shoebill/Cockatrice III images didn’t work at all. Some at least were picked up as blank disks. I had less luck with freshly created raw/vmdk or qcow2 disks. Not sure at all. My minimal 7 2gb disk worked fine as a donor, and even converting to a vmdk was fine. Sooo YMMV. But hey it’s an Alpha and YES IT CAN WORK.

Another plus is that the idle loop works fine so it won’t burn 100% of your CPU. This could possibly be a great gopher server!? Time will tell.

The Gould SEL Concept 32/87

Despite Gould’s location being a few minutes drive from where I first arrived in America, I never had any idea they existed, were making their own exciting machines, or were even a Unix VAR. At a time during the Unix wars one was left to choose SYSV or BSD, but Gould had gone another direction with UTX with a ‘why not both’ approach. Truly an 80’s miracle of Unix.

Well as luck has it there is a SIMH emulator! James C. Bevier has a project on github where he’s building his SEL32 emulation on SIMH!

Even better he’s included tape images, and working INI files which I was able to make into a working system! (after some help with a tape bug)

File is COFF format
-> section (.bss) size (177960) clearing at (0xcbc18)
-> section (.text) size (724800) loading at (0x1200)
-> section (.data) size (105176) loading at (0xb2140)

Start 0x1200

UTX/32 2.1B (exp) #0: Mon Apr 10 19:46:05 GMT 1989
    [email protected]:/usr.POWERNODE/src/src/sys/obj

V6 CPUIPU(P) configuration (IPU not present)
top of system = 0x400000
real mem = 8388608
End of kernel map 0x218464
avail memory = 7356416
using 256 buffers containing 262144 bytes of memory
using 256 mirror buffer headers
ioi: channel iop0 at 7e00 online
ioi: channel dc0 at 800 online
ioi: channel dc1 at c00 not present, dci cc=2
ioi: channel dc2 at 400 not present, dci cc=2
ioi: channel tc0 at 1000 online
ioi: channel en0 at e00 online
swapping on the b partition
dmmax 512 mbswap 3576
dumplo 11776
Checking root filesystem
Check commented out, uncomment once you have edited /etc/fstab!
Automatic reboot in progress...
Mon Aug 30 05:35:46 CDT 2021
/etc/fsck -p /dev/rdk0d
/etc/fsck -p /dev/rdk0e
/etc/fsck -p /dev/rdk0f
File systems OK

Mon Aug 30 05:36:06 CDT 2021
Mounting file systems
/dev/dk0d mounted on /usr.POWERNODE
/dev/dk0e mounted on /home
/dev/dk0f mounted on /usr/local
Initializing loopback
Starting line printer daemon
Starting standard daemons: update cron.
Adding swap partitions
Standard setup functions
Invoke local rc file
Entering /etc/rc.local
dumpdirectory: No such file or directory
Starting Syslog Daemon
Starting local daemons: inetd.
Starting NFS/RPC daemons: portmap sund.
Mounting NFS filesystems
Leaving /etc/rc.local
Starting mail
Checking aliases file
Preserving editor files
Clearing /tmp - does not remove directories
Clearing pseudo terminals
Leaving rc
Mon Aug 30 05:36:07 CDT 2021

GOULD UTX/32 2.1B (noname) (console)


It’s very BSD feeling on the boot and in the /usr directory there is 5bin 5lib

Sadly transferring stuff by just pasting on the console reveals that there is some IO issues in the simulator:

syncing disks... done

dumping to dev 101, offset 11776
ioi: channel dc0 at 800 online
dump succeeded

As a matter of fact doing anything too fast can/will panic the simulator. That goes for Ethernet and additional serial ports.

Interesting highlights of the platform:

Produced by hard-params version 4.1, CWI, Amsterdam
Compiler does not claim to be ANSI C

Char = 8 bits, signed
Short=16 int=32 long=32 float=32 double=64 bits
Char pointers = 32 bits
Int pointers = 32 bits

Alignments used for char=1 short=2 int=4 long=4
Character order:
    short: AB
    int:   ABCD
    long:  ABCD

Obvious issues with the platform is a lack of GCC. The PCC compiler while standard for early 80’s non PDP-11/VAX machines is a bit lacking as the years went on. I was unable to build gzip due to the following error:

# gmake
cc  -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o
ld: warning: near subsegments too big for static base spanning
ld: gzip.o:
        no base for reloc of memref instruction at .nbtext+0x18 relative to symbol _progname
        1221 more 'no base ' errors
gmake: *** [gzip] Error 4

Sadly I don’t find much on Altavista other than this & this. It only offers this terse comment:

The constraints on address space on a Gould are quite severe.

Bummer. Additionally neither Hack 1.0/1.03 or PDP-11 Hack will build either. Surprisingly bash-1.14.7, make-3.75 and ircii-2.5 compiled. Obviously with no networking IRC is kind of pointless.

It’s an interesting time capsule of life outside of AT&T/CSRG or SUN, going in a different direction. It seems like a larger lost opportunity to take their ‘it runs both’ approach software and not have it available on different platforms. Granted for a hardware company once the software leaves the compelling reason to buy the hardware evaporates. Hello NeXT.

If anyone wants to try to re-create it, download and build the SEL32 emulator from github, and I put my vague instructions here.

Or for like minded OS tourists, you can give it a spin here: UTX32_2.1B.7z. I included a ‘9346-UTX-blank.disk’ file which is already prepared if you don’t want to go through the 15 questions to prep a disk. Likewise I made a ‘9346-UTX-biga-blank.disk’ image which is just a single large ‘a’ partition as it’s trivial to just add a bunch of big disks these days.

Full 32bit Unix machines from Ft Lauderdale! Who knew?