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.

Genesis

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‘.


Links:

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 https://www.gitlab.com/mcayland/qemu q800-upstream
cd q800-upstream
./configure --target-list=m68k-softmmu --enable-gtk --enable-sdl
make

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!

Victory!

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 10.11.0.1:35 \
-serial stdio \
-bios Quadra800.rom \
-net nic,model=dp83932,netdev=ne -netdev user,id=ne,hostfwd=tcp:10.11.0.1:42323-:23,hostfwd=tcp:10.11.0.1:40070-:70,hostfwd=tcp:10.11.0.1:40080-:80 \
-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://gopher.superglobalmegacorp.com

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.

New build of Shoebill available.

The big change is the new 68881 maths FPU emulation.  It’s completely new code in this version.  As the author, Pruten mentions:

it should be the “most accurate” 68881 emulator (with regard to chip behavior) ever written, as far as I can tell. I can’t find another open source emulator that even attempts to emulate FPU exceptions, probably because Motorora’s documentation is terrible. Rife with typos and errors, and lacking descriptions for lots of edge cases. It’s also a superset of IEEE 754, so it’s tricky to get softfloat, a strict IEEE 754 implementation, to implement all the weird extra behaviors in the 68881.

On the flipside however:

It will also be much slower than the old version, since the new FPU uses integer-based softfloat. The transcendental instructions will be emulated by running whatever the best natively available function is, and then blindly copying the result to the dest FPU register. Since the FPU is the last big piece of shoebill that requires x86, this should allow it to compile on other architectures, like maybe PPC

I’ve only recently rebuilt the emulator with only the addition of the SLiRP code that I’ve been able to debug from Cockatrice III (who said that I was wasting my time?  At a minimum I ‘fixed’ up SLiRP to make it more stable), and kicked out a Win32 build (source/binary).

I’ve just had it running doing a simple shell script after disabling the UI.  So far it’s 15 hours of uptime…

  8:43am up 15:02, 3 users, load average: 0.00 0.01 0.01

Which is nice.
I should add, to disable the UI in A/UX it’s best to edit the inittab and change

co::respawn:/etc/loginrc

to

co::respawn:/etc/getty console co_9600

And now you’ll get a “text” login.

Text mode login for A/UX

Text mode login for A/UX

I guess the real test will be to see if it makes it through the night.

(edit)

And yes it did!

5:40pm up 1 day, 2 users, load average: 0.00 0.00 0.00

I’ll let it run a little longer but this is like a new record.  Although at the same time, I’m not hammering the poor thing.

# netstat -ni
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ae0 1500 10.0.2 10.0.2.15 4232 0 3551 0 0
lo0 1536 127 127.0.0.1 157 0 157 0 0

Shoebill now has working Ethernet support!

Great news!  The excellent A/UX capable emulator Shoebill, now has working Ethernet support!  The sad news is that it only supports the TUN/TAP interface.  So Windows users are kind of left out in the fun.

Shoebill + Ethernet

Shoebill + Ethernet

Except, I’ve been here before with SIMH ages ago.  So I dusted off my source code, and injected it into Shoebill.  The first issue I had was that SLiRP was rejecting all the inputted frames, because of invalid frame length.  Even more weird is that ARP worked, and I could see the 10.0.2.2 and 10.0.2.3 virtual IP’s but TCP and UDP outbound wouldn’t work at all.

It took me longer than it should have but although this code worked great with GCC 2.7 and 3.0, 4.x breaks it.  And it’s the same reason why Shoebill originally didn’t work on Win32, the blasted packed structures!  So adding the ‘-mno-ms-bitfields’ flag to GCC is all it took, and now I could ping 10.0.2.2 for about 5-7 pings until SLiRP would crash.  I tried all kinds of stuff trying to see if there was an issue with SLiRP, but I should have payed closer attention to the debugger, with all those threads flying around.  It turns out Shoebill was trying to read & write a the same time, which caused SLiRP to crash as it is not re-entrant.  I tried to place mutex’s on every SLiRP call but that ended up having SLiRP not process any packets.  Very strange.  I then reduced it to where I read the frame out of SLiRP and pass it to Shoebill, and where Shoebill write’s a frame out the SLiRP.  And much to my amazement I can run ‘worms’ just fine!

So after a minute of worming and pinging I called it ‘good enough’ and rebuilt a production binary, and packaged up my source code.

For anyone who want’s to play, my Win32 EXE is here, and the source code I am using is here.

Shoebill ported to Windows!

Shoebill!

Shoebill!

Good news, as mentioned here, the Shoebill emulator was recently given some much needed SDL love, and ported to Linux.

Well that’s great and all, but the vast majority of people who run anything these days do it with Windows.  So I decided to try to get it to compile with MinGW to see how far I could get.

And the short version is that I got it working!

The long version is that in the first pass there is some SIGUSR2 stuff that is undefined.  And for a good reason, since it won’t work.  So I just commented them out.  The next minor problem was the lack of bzero.  Honestly I don’t know why bzero is missing from MinGW, but who knows why.

Shoebill also processes some internal macros with a perl script that for some reason was dropping in binary values into the source, making GCC mad.  I just commented out a line that was adding in more comments into the header.  This let me compile with a simple pass.

There was some issues reading the ROM file, since the 68000 is a BIG ENDIAN processor, and the 8086 is LITTLE ENDIAN, Shoebill makes extensive use of hotns and hotnl, ntohl, and ntohll.  These can be found in the winsock library, and even better they dont need any winsock initialization, they work right away.  I just have to make sure I include winsock2.h, and link against the winsock library.

However when trying to boot, the checksum was 0x00000000, not the expected value!   Luckily there was an assert to catch that and crash.  This led me to notice that in Linux files are opened in binary mode by default, while on Windows, they are opened in ASCII mode.  A quick change of all the fopen calls, and I was reading the ROM, but now crashing on the disk.

As it turns out newer versions of GCC go all crazy when it comes to structs, and try to automatically align to boundaries for quick access.  Which sound nice, until you try to read in some binary data, and expect things to be in certain locations and find out that your structure is larger than expected, and data is read in the wrong place.

The solution is to force the compiler to leave it alone with

__attribute__ ((__packed__))

HOWEVER as luck would have it, Microsoft apparently packs structures a different way, and you have to either make a macro to do a bunch of work to force it to make the structure 1:1 of what you expect, or use the CFLAG option of

-mno-ms-bitfields

And now MinGW’s GCC will build something along the lines of what it’d build on Linux.

Putting it all together, I amazingly got this!

Shoebill on Windows

Shoebill on Windows

Phew!  So for those interested, here is the source code drop(Use the updated one here!), and here is the binary.

If you ever wanted to see the “OS X” of the 1980’s, now is your chance!