Multiplayer Macintosh Plus via Javascript/

I found this fun page over on  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!


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.

MachTen 2.2

MachTen console

Not that I need another UNIX, but I came across this fine thing googling around for some Mach based OS’s running on the 68000, and well here is MachTen.  Perhaps the most notable thing about MachTen is that it is capable of running in usermode under MacOS.  Without a MMU.

# cc -v hi.c -o hi
gcc version 1.40
 /usr/local/PMtools/cpp -v -undef -D__GNUC__ -Dunix -D__MACHTEN__ -DMACHTEN -DTENON -D__unix__ -D____MACHTEN____ -D__MACHTEN__ -D__TENON__ -Dmc68000 hi.c /var/tmp/cc000093.cpp
GNU CPP version 1.40
 /usr/local/PMtools/cc1 /var/tmp/cc000093.cpp -fno-builtin-alloca -fno-defer-pop -quiet -dumpbase hi.c -version -o /var/tmp/cc000093.s
GNU C version 1.40 (68k, MIT syntax) compiled by GNU C version 2.3.3.
default target switches:
 as -mc68000 -o hi.o /var/tmp/cc000093.s
 ld -o hi -x /usr/lib/crt0.o hi.o -lc
# size hi
text    data    bss     dec     hex
11220   400     1672    13292   33ec
# ./hi

And yes, it even supports TCP/IP with it’s own TCP/IP stack.  It can even operate as a router of all things!  From a users point of view it is a little sparse, but it’s 4.3BSD, and thankfully includes the C compiler, so unlike of UNIX of the era on ‘small hardware’ this one isn’t crippled.

configuring TCP/IP

TCP/IP is configured through the MacOS via the control panel.  As you can see it can use AppleTalk, Ethernet and TokenRing interfaces.  For my simplicity, I’m just using SLiRP on the Ethernet, so it’s the old setup.  I re-compiled my BasiliskIII to redirect a port into the VM so I can telnet into it.

To install System 7.0.1 you need to set Basilisk II / Cockatrice III as a IIci. I went ahead and used this ROM.  The ROM however does expect there to be a FPU.

rom Mac-IIci.ROM
modelid 5
cpu 2
fpu true

Running however, I’ve been able to set the CPU to 3 or 4 (68030/68040) and it’s fine, I think the major thing is the modelid.  If I try this under System 8 which needs a 68040, then it’ll crash in spectacular ways.  You don’t need MacTCP as again MachTen is a 4.3BSD kernel with Mach 2.5, so it has it’s own.

MachTen also includes support for NFS!  This greatly eases getting data in & out of the system.  To mount my Synology I just need the following command:

mount -t nfs -o timeo=1,retry=1,rsize=512,wsize=512,retrans=1 /mnt/data

And I’m good to go!

Reading .toast image files

Well I put out a cry for help all over the place, looking for Darwin 0.3

And much to my amazement, when I woke up, I not only got a reply but a link to a toast image.  Great, what is toast?  Well simply put toast is a format made popular by then Adaptec Toast.  Obviously the sane thing to do is to find Toast, install it, and mount the disk image inside of a Macintosh.

Adaptec toast 4.0

But, honestly, where is the fun in that?

Instead let’s have Cockatrice III do it!  Now I never did get around to writing proper CD-ROM emulation, nor integrating it, but that doesn’t matter!  Instead I’m going to rely on Daemon tools Lite, to do all the heavy lifting.  DTL will create a virtual SCSI adapter, add in a SCSI CD-ROM device, and mount the image.  Needless to say, I’m on Windows and that is where that part of the adventure ends, as Windows 10 cannot read HFS.

Now back to Cockatrice!

All I had to do was assign the SCSI 6 position to the mounted drive letter, and I’m set!  Just add this to the CockatriceIII_Prefs file:

scsi6 \\.\e:

And now I can mount the image from within Cockatrice III

Darwin 0.3 toast mounted

And there we go, now I can copy the files of just like having a real Mac.


GCC 1.37 on MacOS

I didn’t even know there was such a thing!

But sure enough, the file GNUMPW.SIT, and the later gcc-1.37.1r15-all.sea.bin are the real thing!  The file GNUMPW unstuffs to GCC 1.37.1r7(All), although Stuffit 5 and higher won’t unpack the file, I’ve converted it unpacking with version 4 & repacking with 5.5.

The readme from r7 is dated November 2nd, 1990.  I found some history on this port on the archives of the GCC mailing list here.  The port was done by Stan Shebs, while working for Apple.  As he states the port started in 1989 and was first used in an abandoned m68k based project, and later a possible replacement for the Apple compiler for OS 7.

For this experiment I was using the r15 version, as I didn’t find anything out about the prior versions until after I had written this.

GCC on MacOS needs the MPW environment, which for me is incredibly awkward to work with. While some people may love it, it is very strange in that you have to highlight commands in the window, then hit clover+enter to run them.  Like a mainframe, you can input commands wherever in the screen.

The next hardest thing was finding a version of MPW that will work with this.  It needs the MPW C compiler for it’s includes, and libraries.  The 3.5 stuff didn’t seem to work for me, however doing a LOT of searching, and I did find a ‘toast CD-ROM’ image‘ of 3.1 that includes all the C, and Assembler tools that I need to build an executable.

I also don’t know why, but running make just shows me what needs to be done, it never actually makes anything.  I’m probably doing something wrong, but for such a long dead tool, trying to find out how to use it, or how do you interrupt a “stream” like manually running cc1 is beyond me.  I just have to force quit the emulator.

But beyond that, running make gives me the steps, and I manually select and run the steps, and I was able to get a program to run!



I know it may not look like much, but getting it to actually run something was quite monumental for me!

I thought for the hell of it, I’d try to build the InfoTaskForce 1987 interpreter, but it seems to get confused at the whole input method.

Planetfall on MacOS

Planetfall on MPW

There were some issues compiling input.c, as it didn’t like the external table, so I made it’s own local table.  It also didn’t like some pointer arithmetic, but making GCC happy only gives me a program that can’t recognize any verbs.  And from there it won’t quit, basically hanging the system.

I’m sure I’m doing something wrong, but at the same time it was interesting to see GCC on MacOS, during the whole GNU boycott of Apple for the ‘look and feel’ lawsuit against Microsoft.  No doubt it let a lot of people sell other C compilers on the Mac Platform during this window of time.

GCC requires a 68020 processor, as GCC’s native 68000 based target would be SUN-2 hardware.  While it can compile with the -m68000 flag, I haven’t tested with a 68000 based emulator to see if that’s even true.  In the off chance someone wants a combined MPW+GCC I made a disk image here: MPW 3.1 with GCC 1.37.img.gz.  Disk Copy 6.3 should be able to mount it OK, or any emulator that likes HFS disk images.

More fun with GCC 6.1

So after looking at the -Ofast flags in that utterly unfair GCC 1.4 vs GCC 5.1, and 6.1 , I thought I’d try to build Cockatrice III with it.  Everything went well, and I had a build in no time.

I always hated how I had to massively downsample the audio so I could at least hear things, so I thought I’d try to put them back to 44100Khz, 16bit stereo.  And while compiling, older GCC runs fine, while 6.1 throws this run error!

../SDL/audio_sdl.cpp:57:43: error: narrowing conversion of '-1404829696' from 'int' to 'uint32 {aka unsigned int}' inside { } [-Wnarrowing]
 uint32 audio_sample_rates[] = {44100 << 16};
makefile:104: recipe for target 'obj/audio_sdl.o' failed
make: *** [obj/audio_sdl.o] Error 1

Well it turns out that it’s getting truncated as the audio_sample_rates are defined as an unsigned int, but it really want’s to be a regular integer.  So I changed the type, and now I have high def audio!  While I was in there, I fixed some stupid typos in the keyboard so I can actually use vi in MacMiNT.

It’s still in 256 colors, I’m missing something fundamental as to why it’s not working but I just don’t have enough time to mess with it today.

For anyone who cares, the Win32 binary package is on sourceforge.




The NeXT community has been about this old Mac emulator, daydream making a comeback onto NeXT hardware.  Branded as darkmatter it runs on the bare metal of the NeXT cube/stations and can run MacOS in much the same way that Basilisk II does.

System 7.0 running on a NeXT cube!

System 7.1 running on a NeXT cube!

What makes this interesting is that the 68040 is cycle set, and uses a much more mature CPU emulation core than Basilisk II, so it should give more accurate emulation. However it will run at 68040 25Mhz speeds, so it won’t win any speed records.

Naturally programs (Space Quest I) that blit directly to the display probably expect Mac/Plus/Se dimensions so the NeXT display won’t be ideal.  But good old SoftPC for MacOS runs great!

SoftPC 3.1 for MacOS

SoftPC 3.1 for MacOS

And again, being set to 68040 speeds, it’s nowhere near as turbo as Basilisk II/SheepShaver.

For anyone interested, you’ll want Previous, the latest build and a test disk.  Set the emulation for either a NeXT Computer (68030), or NeXTcube (68040), add the test disk as SCSI disk 0, and either type in ‘bsd’ at the firmware prompt, or have it automatically boot in the options.

WinDooM on SoftPC, on SheepShaver

So I was hammering out something with SheepShaver (more on that later!) and I thought a quick test of just how fast SheepShaver is vs a real PowerMAC would be interesting.  So I was playing with my old copy of SoftPC, which is 68000 based, but There were PowerPC versions, years ago when I bought a G4 to run OS X to only find out that it wasn’t supported (the dark days of OS X Server 1.0, before the 10.0 public beta) I used to run Windows NT 4.0 on SoftPC on MacOS 8.6.  Ugh, dark times indeed!

So with some luck, I got SoftPC 3.0 up and running on MacOS 7.5.3 using SheepShaver for Windows. Then I noticed that unlike SoftPC for the 68000, SoftPC for the PowerPC emulates a 486!  So how does DooM run?  A little slow, it’s kind of dream like.

But since there is Windows and a 32bit processor, I thought this would be a great time to load up Win32s, Video for Windows, WinG, and WinDooM!

WinDoom on SoftPC

WinDoom on SoftPC

And much to my amazement it runs!  And I was further impressed that there is a shim sound driver, and it works!

So I made a quick video to compare DooM for Windows vs DooM for MS-DOS on this setup.

Yes it’s pointless, but I kinda think it’s really cool.

As a bonus, here is E1M1 under MacOS 8.0.  The MIDI support in 8.0 is MUCH more stronger than 7.5.3!  And I should add, it actually feels faster on 8.0 than 7.5.3

Making MacMiNT self hosting

Compiled in 2015!

Compiled in 2015!

One thing that always bothered me about MacMiNT is that I never could compile JET or MacMint itself.  It requires the headers from MPW 3.2, or better known as the Macintosh Programmer’s Workshop, along with a single library again from MPW 3.2

MPW 3.3 won’t work, which is the only version I’ve had when I bought an extraordinarily heavy FORTRAN compiler for the MAC, Language Systems FORTRAN.  I tried to get dungeon to work with that, but no dice.

But thanks to macgui, they have links to the 3.2 headers & libraries!

It took me a little longer than I’d like to figure out how to build the cross libraries, as I kept running the script from the script directory, not from /mint as I should have (is there any documentation?!).  But I finally built the libmac16.olb and libmac.olb needed for MiNT programs to call the MacOS toolbox!

So now I’m able to compile Hoshi’s 1999 JET and MacMiNT!

For anyone interested, I’ve built a disk image here, that includes everything all ready to go.  It runs great on my latest build of Cockatrice, although I haven’t made any Win32 builds just yet….  I suspect it’ll run on emaculation’s build of Basilisk II it really should only need a 68000 with 8MB of RAM or so.  The disk image is 8MB, and uncompressed onto a hard disk takes up 35MB of space.

I’ve also made a small (100MB) mirror of the umich MiNT & MacMiNT install archives I could find right here.

Also, it runs dungeon,and with a lot of finagling, it’ll even run f2c dungeon! (needs a 68030 or higher).

For those who insist on running this on SheepShaver / Or PowerPC based machines, I’ve found that System 7 and an OldWorld ROM run it best.  System 8.0 and System 8.1 can run it (assuming they were installed as a PowerPC install), but System 8.5 and higher are not very cooperative when it comes to MacMiNT.

MacMiNT on SheepShaver MacOS 8.1

MacMiNT on SheepShaver MacOS 8.1

I suspect it must be the re-write of the nanokernel that PowerPC MacOS is based on.

GSOC bringing MacOS 9 to Qemu

It's some progress!

It’s some progress!

I know it may not look like much right now, but Cormac O’Brien is working on bringing MacOS 9 support to Qemu!  This is really great news as Sheepshaver has painted itself in a corner with it’s CPU code that requires memory access to 0x00000000 which more and more operating systems deny.

So you can download the snap and follow the instructions here. And you too can watch it fail.

Screen Shot 2015-07-20 at 9.57.16 AM

Starting to boot

During the boot you’ll see a message from MacOS on the CLI that it is unable to find a NVRAM partition.  During this time you will either see a bunch of CUDA and IRQ messages, and there is a good chance from here it’ll progress to loading the New World ROM.  If it gets stuck you’ll see tonnes of the following messages:

CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30
CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30

From here the screen should turn grey, and again it may or may not go to a happy mac, or again get stuck on the CUDA read 30/00 thing above.

New World ROM loaded

New World ROM loaded

Once it goes New World happy mac, it’ll load MacOS then bomb over one of the extensions.

I tried some OpenBSD for the heck of it, the good news is the kernel loads and starts the boot, but it has some issues with either memory or mapping the PCI bus.

Screen Shot 2015-07-19 at 6.03.43 PM

OpenBSD 5.7

Screen Shot 2015-07-19 at 6.08.31 PM

OpenBSD 3.3

Screen Shot 2015-07-19 at 6.16.02 PM

OpenBSD 4.0

And for the heck of it, Debian 5.0.0

Debian 5.0.0 installer

Debian 5.0.0 installer

I didn’t bother installing but nice to see the installer CD runs fine.