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

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.

WinUAE 3.0.0 released!

The biggest feature of course is…

  • PPC CPU emulation. CyberStorm PPC and Blizzard PPC boards emulated using QEMU PPC core, on-board SCSI supported.

I’ve never used the PowerPC stuff before, I had a 68030 accelerator in my Amiga 2000 going back some 15 years ago, and I never could justify the cost for the board vs a new PC as the Amiga was so super fringe back then.

But for those who want to give it a shot, the installer is here, along with the PowerPC pluggin

All of the additional features are with the announcement here..

SheepShaver with pcap support

It "works", just incredibly slowly

It “works”, just incredibly slowly

so I got it to “work” on OS X….. well 10.6 in VMWare. I have no idea if this means it will work on your setup.

  • If AppleTalk packets get passed early in the boot stage, it will crash.
  • If JIT is enabled, it will crash
  • Performance is horrible, I’m getting 150k/sec on my LAN, Basilisk II with no JIT blows this thing away.
Honestly I feel kind of hesitant releasing this, but I know it was desired, and I guess it’ll help someone somewhere being able to have an easier conversation… So I’m going to upload my source tree, including binaries built with GCC 4.0 & 4.2 with either O2 or Os flags. I’m not sure which is more stable/faster…So here is my source tree. Sorry you still have to deal with the changing password thing, but cancel it, and it’ll tell you the password.Other lessons learned… SheepShaver’s segfault model only works when the CPU thread is the main thread. Even though you “can” stuff the CPU into a subordinate thread, it doesn’t play nice once it segfaults, it’ll just spin waiting for something that clearly isn’t going to happen.In config.h I added in USEGLOBALvideo as a way for main to call the screen update to end the vast majority of pool leakage. I also added SHEEPSHAVER_CURSOR to enable the hardware cursor. I was having some issues installing OS 8.x when the ‘hand’ was drumming the fingers waiting for the OS to install it crashed many times, while disabling the hardware cursor made it play nicer. Maybe it’s my setup, I’m not sure.

Also in this version I don’t read .sheepshaver_prefs but rather sheepshaver_prefs in the current working directory. I didn’t want to trash any other prefs. I have to test again but I think this should work on 10.10 … As I found out the hard way x86_64 binaries can no longer mess with the zero page, so this is a 32bit only build, but I was running it with my SLiRP fixes ok on my macbook air.

This hasn’t been extensively tested. I hate to even call it tested, I just copied a few MB of stuff over an NT server running AppleTalk,a nd viewed some flash video with Internet Explorer 5.1 …. I’m sure there are PLENTY of things broken. JIT should work with these binaries (Quake 1 is quite playable), but DOOM crashes hard (isn’t it a 68k binary?). DOOM runs ok on Basilisk II so does it matter?

If you want speed, JIT + SLiRP is the way to go. Since this is basically the same as the version I was using with BasiliskII I think it’s more stable than the generic version as I could at least run all kinds of programs with some of my fixes vs the ‘stock’ github version.

I should add that I’ve been primarily testing with that PowerMac 9500 v1 ROM, along with MacOS 8.6. I found 8.0 and 8.1 too unstable, 7.x & 9.0.4 uninteresting.

To get around the early crashing while booting 8.6, I rigged it to drop the first 30 packets. I’ve successfully booted 10/10 times, so I’m almost OK with that. I’d rather know when the OS is ok, and go with that, but I’m not sure. I thought about a timer, and say ignore the network for the first 30 seconds, and maybe that is the better way to go. When you launch this you’ll see some message updating about packets and “wait for 30->” and a number… once it reads “wait for 30->30” , the message will no longer update, and it’ll start to forward packets into the machine. You probably will have to disable and re-enable AppleTalk from the chooser to see the network (or I had to). You may have to get creative to generate the needed packets on your network to get it over 30, as those are packets received. Broadcast packets work too, so maybe you can work with that… As long as Sheep Shaver isn’t alone something should be looking for other devices.

Phase one on a SheepShaver rebuild complete

SheepShaver on Linux

SheepShaver on Linux

Only because people were asking for it.  The first thing I did for Basilisk II was to get it building on Linux, so here we are.  I only tweaked the config process to let me build it with GCC 4.7.2 .

So this will be in the same effort of removing features, and trying to place in my SDL drivers, network and SCSI stuff.

Im starting with SheepShaver v2.2, which is pretty old.  But 700kb compressed is a good starting point.  As you can see it boots MacOS 8.0 which is also good enough for me.

The other questions will be, can this build under Windows with MinGW configured like this, and can it build with OS X.  It looks like all the stuff is there so this may be kind of easy. I hope.

Also SheepShaver does something funky with it’s memory space, it does some direct mapping to the user area.  I’ll have to see if I can disable that, performance be damned (well I turned off JIT as it won’t compile with 4.7 either) so this won’t be fast, but I’m just patching stuff up, not re-implementing the wheel here.

Qemu 1.7.0 released!

The main qemu page hasn’t been updated yet, but the download page has the source to the new version of Qemu.

I’ve gone ahead and built binaries for OS X, both a full version, and  a i386 minimal version.

As always testing is very minimal, all I’ve done is installed MS-DOS 6.22 & Doom 1.1, and tested the SoundBlaster 16 emulation.  And as with the pre-release versions, the adlib code is still broken.  And Ive done the ‘better’ fix in this code regarding that.

I haven’t run anything else, including fun things like the PowerPC & OS X emulation, MIPS with Windows NT, or even trying anything x64 based as I’m sure it is still broken from back in the Qemu 0.90 days.

OS X 10.2 on Qemu PowerPC

Blast from 2002

Blast from 2002

So yeah, I got 10.2 to install.  Well from my standpoint as a user it worked ok, but it is SLOW.. Then again my MacPro is a tad old, it is a 2006 model with 2 x 2 Ghz Dual-Core Intel Xeon processors…. I hope to upgrade to the new MacPro when it finally launches later this year.

So yeah, On my computer this runs slower than my first 333Mhz iMac that I ran OS X on.  Needless to say a 450Mhz G4 blows this thing away, although I don’t think that is a fair comparison.

Even with all the screwed up colours, it is kind of neat going back into time to see where OS X, was with AIM & Internet Explorer.  How things changed with Apple carving out their own niche territory in both regards.

All in all it was an interesting time back then, with Apple making the leap from the dated OS 9, to the NeXT inspired OS X.  And as they say the rest is history.

OS X PowerPC on Qemu

In the latest release notes, I saw that Qemu can now run OS X!

Screen Shot 2013-08-14 at 9.35.57 PM

Language selection

Screen Shot 2013-08-15 at 12.12.08 PM



The installer for 10.4 will run, but it’ll then freak out saying that this model of mac is not supported.  The ‘working’ cli I’m using is:

ppc-softmmu/qemu-system-ppc -L pc-bios/ -m 256 -M g3beige -hda osx1046.vmdk  -cpu G3 -cdrom Mac\ OS\ X\ Install\ DVD.toast -boot d

Sure the colours are off, and it is kind of pokey, but still the more guest OS’s on Qemu, namely for something like the PowerPC.  If anyone has any better idea of how to fully run OS X on Qemu drop me a note!  Plus there is additional information on the mailing list.

reviving a G5

This has to be one of the more convoluted things I’ve ever done.

So basically it starts like this, I left my quad G5 mac in storage, some 1,600 miles away.  I wanted to see if I could get a cheap mac, and I managed to get a $100 mac out here in Vegas.  Part of the reason it was cheap is because the OS was screwed up.. You’d be surprised how many people ditch good machines, because the OS is messed up.

So I figure I’d just pop in a 10.4 or 10.5 DVD set and boot up, format and all will be well right?  Well it turns out the DVD drive doesn’t work properly.  And I don’t have any old ATA/parallel style DVD drives on me.  So I’ve basically got a $100 paper weight.

Until I decide to try something insane, so I get the great emulator PearPC, and install 10.4 into that.  Sadly PearPC doesn’t support raw disks, otherwise my original plan of popping in the disk to my PC, running PearPC and having it install to \\.\PhysicalDrive2 didn’t work so well.  But at least I could create a small install of 10.4.6 which will boot on a G5.

Next I dug out the ancient ancestor of all the hackintoshes, the deadmoo 10.4.1 image, and got it running on VirtualBOX (set the IDE to P3 mode, otherwise its SLOW!), after converting the raw 6GB image into a VMDK.  I then could use Qemu’s disk image conversion program to convert the 10.4.6 disk I installed with PearPC into a VMDK which I could then mount under the deadmoo image.

With that setup, I could then use the diskutil program on OS X deadmoo, and create a compressed disk image of the PowerPC 10.4.6 .  Then VirtualBOX will let you link to a physical drive, with a command something like this:

VBoxManage internalcommands createrawvmdk -filename drive2.vmdk
-rawdisk \\.\PhysicalDrive2

With that done, I then could boot back into deadmoo with the G5’s disk attached, remove all the files/directories from the G5 disk (I didn’t format as I wondered if I format from an intel machine, would the endian be backwards making the filesystem unnecessarily slow?), doing the ‘repair permissions’ shuffle from the diskutil program, and then finally I could restore the PearPC compressed image of 10.4.6 onto the G5’s hard disk.

It worked.

Its a shame the PowerPC machines cannot boot from USB disks, otherwise there may have been an easier way…  Well that or order a DVD drive, but that’d take time…

So thankfully with emulation, disks that can work between machines, I was able to get the box up and running.

Mini vMac II for OS X (PPC)

Emulators in Emulators..

I wanted to run some old 68000 programs on OS X, but as luck would have it, OS X 10.5 doesn’t support the classical environment, and the 10.4 discs that I have won’t boot on a G5.  So I don’t have a good way to get there from here.  However I did remember the great mini vMac is very portable, runs 68000 code great, and even can run 68020 programs with the experimental branches.. So I had to install OS 7 on a Windows machine with my last binary, configure the source there, then import it to my PowerPC, then build it on my G5.  The OS X PowerPC build is lacking sound (did the intel OS X have it?) but it runs!

For anyone that cares, my PowerPC binary is here.

I’ve just updated it to contain all the 32bit binaries…

$ file minivmac

minivmac: Mach-O universal binary with 3 architectures
minivmac (for architecture i386): Mach-O executable i386
minivmac (for architecture ppc7400): Mach-O executable ppc
minivmac (for architecture ppc): Mach-O executable ppc

It turns out this is reliant on Carbon, which doesn’t allow for 64bit binaries…