Announcing Cockatrice III

Well I was shuffling files back and forth into Shoebill, and with the advent of Ethernet support, I decided I wanted to build an AppleTalk network.  This endeavor seems to have taken a life of it’s own.

So, the first thing I did was tear into minivmac, as I figured it would be the easiest to modify, as ‘mini’ is in it’s name.  But it’s more geared to LocalTalk.  From it’s readme:

It does this by converting the LocalTalk packets between SDLC frames in the virtual machine to LocalTalk Over Ethernet (LTOE) packets.  These LTOE packets will be sent out the host machines Ethernet interface and will reach any other machine on the LAN.  LTOE packets are not routable and not recognized by EtherTalk devices.

Which is pretty creative, but I want to talk to A/UX, Windows NT and Cisco routers.  So this isn’t going to work out for me.

The next other ‘big’ names in Macintosh emulation are Basilisk II and SheepShaver.  Both of which are from Christian Bauer which is a sizable download (or so I thought) and has a very confusing release versions for Windows. So I went ahead and tried BasiliskII, which only does some native networking via a TUN/TAP & bridge solution (which is really popular solution for plenty of UNIX based stuff), which personally I don’t really care for.  The Windows version does support SLiRP, but for some strange and annoying reason it always crashes when I try to download anything big.  As a matter of fact, the Windows version crashes, a lot!

While digging around for various builds of Basilisk II, I found the defunct sourceforge page, which is thankfully still up.  And there I found the 0.8 and 0.9 release source code, which weighs in at a tiny 350kb in size.  This is something I could probably dive into.  So I went ahead and tried to build it on a Debian 7 x86 VM.  And much to my surprise, after altering configure to accept GCC 4.7, and forcing it to turn X11 on (I don’t know why it kept failing to detect it), I was able to build a binary in no time.  Even better, it worked!

So the first few goals were simple, I wanted to take 0.8 and remove it’s dependency on X11,and make it use SDL 1.2.  Why not SDL 2.0?  Well 2.0 is more about 3d space, and even to render a flat framebuffer it uses streaming textures.  Which is too heavy for me, so I’m sticking with 1.2.  I took a bunch of code from SDLQuake, and after a while of bashing it around, I was able to open a window, and capture some ouput from the framebuffer.  With even more bashing around I got it to work correctly.  I did make some small tweaks though, it only supports 8bit depth.  But I’m interested in networking, so 256 colours is fine by me.  Now that i could see what I was doing, I was able to then re-compile on OS X, and I was greeted with the Mac Boot screen.  The harder part was Windows, as the system code written by Lauri Pesonen who did an excellent job of porting BasiliskII to Windows, but to say their code took 100% advantage of the Win32 API would be an understatement.. And I wanted something more pure to being SDL so I really couldn’t use much of that code.  And what code I could find it was for far later versions.  However with enough pushing I did finally get BasiliskII to boot up on Windows.  I was once more again bitten by the fact that open on Windows defaults to being in ASCII mode.

The next thing to add was SDL input for the keyboard and mouse.  And at this point googling around for an example of an input loop for SDL that is appropriate for an emulator I stumbled uppon the fact that there already was a SDL support built into the more current version of Basilisk II.  But for some strange reason I kept going ahead, and incorporated some of the code into my 0.8 branch.  And then I could finally send some keystrokes, move the mouse, and click on things!  Things were looking up!

While looking at the SDL code, I did see they also have audio support, so I went ahead and borrowed the skeleton framework from there, although the initialization didn’t work at all as BasiliskII had drifted in how it hooked into the native sound support.  So I once more again turned to SDLQuake, and I was able to initialize sound, and Even get QuickTime to play the old Quadra quicktime video, which was the first QuickTime thing I’d ever seen, back when they were still making Quadras.

So now with video and sound in place, it was finally time to tackle the networking.  At first this seemed quite easy to do, and using SIMH for inspiration I was able to quickly replace the tun/tap code with some pcap code to open the interface, send packets, and receive packets.  One more again I started on Linux, made it build on OS X, although my MacBook air doesn’t have anything I can really inject packets into so I don’t know if it actually works.  The bigger test for me was on Windows with a GNS3 network, and with a few more minor changes I was happily sending AppleTalk to both Shoebill and Windows NT.

The next thing I wanted to tackle was SLiRP support.  Ironically to bring SLiRP to Shoebill I used the SLiRP from the github of Basilisk II.  At this point I figured this would be very simple, and I could wrap up later that day.  It ended up taking me three days.  Once more again my build would crash all the time, just like the later Basilisk II builds.  Using Internet Explorer 4.0.1 would seemingly crash the whole system within seconds with faults in SLiRP’s slirp_select_fill, and slirp_select_poll functions.  Now if you don’t call these functions SLiRP doesn’t process it’s TCP state and you end up with barely functioning UDP to only SLiRP which isn’t great beyond DHCP and DNS.  First I tried semaphores which only made things worse as the nature of Basilisk II’s threaded nature just made the requests stack up deadlocking within seconds.  I tried a mutex, timed mutexes and various other locking methods insdide of SLiRP and Basilisk II to no end.  Netscape would kind of work, but IE would crash the whole thing out after a few pages. Then a better solution hit me as I was playing with the system clock on the Windows build.  There is a 60Hz timer that calls a 1Hz timer once every 60 ticks.  What if I had the clock drive SLiRP?  And to my amazement not only did that work, but it worked great until I hit another problem that I had with Shoebill (that needs to be fixed now that I found away around it here).  There is a static buffer that passes data between SLiRP’s callback when it is going to send a packet to BasiliskII and when Basilisk II then feeds the packet to MacOS.  With enough traffic it will overwrite part of itself as they are on two different threads.  Once more again I tried semaphores, which of course is the wrong tool here as if something is stacking waiting for it to unstack is just crazy, and more mutexes.  The mutexes kind of worked but performance was horrible, as in 1992 dialup speed horrible.  And I didn’t want to simulate a 1992 internet experience 100%

So the obvious solution as a queue.  I took a simple queue implementation, added the ability to peek, changed it to accept a packet structure and I was set.  Now I only needed a mutex when I queued items, and dequeued them.  But I could hold 100 packets easily.

So with all that in place I can finally download files greater than 10MB, and even with Internet Explorer!

Download

124MB in 8 minutes!

So the next was to make Pcap dynamically loaded, which for C++ is a bit of fun with __cdecl, GetProcAddress and all that fun.  But I had it working after a bit so now if the user doesn’t have WinPcap installed they don’t get an error message, and I don’t have to maintain two builds.  Nobody likes doing that kind of stuff.  Ever.

Multitasking.. Kind of.

Multitasking.. Kind of.

There is still plenty of things broken afterall I’m using an ancient version of Basilisk to base this off of. I’ve also removed a bunch of features as I wanted to make this more of a ‘core’ product with again a focus on networking.

Will this interest the majority of people? Probably not.  But for anyone who wants to actually download a file this may be somewhat useful.

Where to go from here?

Well there is still a lot of OS specific stuff in the code that I want to convert to SDL.  I’d like to build from a 100% more generic code tree rather than having private files here and there.  The CPU optimization programs that re-read GCC’s assembly output don’t do anything.  I want to try it through an older version of GCC and see if there is any difference in speed.  I also recently received the source code to vc5opti.cpp and I’d like to try that to see if it speeds up the Windows Visual C++ based build.  Long term I’d love to patch in the UAE CPU code from the newer versions that have a far more solid 68030/68881 and 68040 emulation.  The price of standing on so many tall shoulders is that when I fall off I don’t know if the CPU exceptions I see are faults in the CPU emulation, Basilisk II or just plain crashes in MacOS which was certainly not the most stablest thing once you mixed in multimedia and networking.  It was par with Windows 3.1, which honestly both of them were ‘saved’ with help from the older generation, ala BSD Unix for MacOS, and the VMS team for Windows.

So after all this I’m ready to release some binaries, and code.  Although the last thing I wanted to do is add more confusion by calling this Basillisk II v0.8.SOMETHING … A quick google search on Basilisk gave me this:

As for some reason I actually never did look up what a Basilisk was.  So seeing that this project is basically the same thing I chose Cockatrice.

The Cockatrice III source forge page is here, Windows binaries, Mac OS X binaries, and source code here.

There are plenty of bugs, and plenty of things not working, but it works well enough to do things, and that is a credit to everyone who worked on Basilisk II before me.

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.  Or a copy on archive.org.

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

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 Las 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?  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.

It’s 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…

SoftPC 3.1 for MacOS

SoftPC 3.1 for MacOS

SoftPC 3.1 for MacOS

I had purchased this a while back on ebay for $15, and used it occasionally but ever anything that involved. Mostly because it’s dreadfully slow on an 030, and ever since the intel cpu has won out, it’s not all that needed in this day in age. But at the same time, its interesting to check out various emulators through the ages.

Installing it was way easier under Basillisk II, then running it is more smooth under mini vmac. Mostly because of it’s 68881 emulation, and also it just seems faster.

An 80286 in every box!

Running MSD shows that it does in fact emulate a 80286 processor!

So doing the only natural thing, I installed Microsoft C 5.1 but configured it only for OS/2 development, then used a old 286 dos extender I found, and blamo, it works!

Hello from protected mode!

The sad thing, is that it seems the 80386 & 80486 stuff was RISC (MIPS/Alpha/PowerPC) or 80486 based only. I’m pretty sure the version of SoftPC for NeXTSTEP did a 80386… I’d love a real copy of that, but I know there was a demo out there somewhere.

Anyways for it’s age, SoftPC seems to be about as annoying as any 286 computer was at the time. And as a bonus running emulators under emulators makes it about as slow as a 286..…

Duke Nukem 3D for the Macintosh (68020)

mini vmac II duke nukem

mini vmac II duke nukem

I had no idea this even existed… I guess it’s to be expected, all the popular games of the time (doom) were ported to pretty much everything and anything.

So after stubmling across this site, Emacualtion, I had to fire this thing up!

The first thing I needed to do was get the latest source to Mini vMac. What is different about this is that you get the source from within the emulator. Basically you pass a program what config you want and it’ll spit out source code. So for me to build on windows, a mac II with 256 colors, I gave it..

-t wx86 -m II -depth 3

Easy right?

There is some help on the mini vmac site, but it’s kind of in places.

With the emulator built, the next fun filled thing was to dump the ROM from my SE/30, which was.. an exciting adventure in floppy disks, but with it in hand I was ready!

The next part of the puzzle was System 7.5.3, which apple still thankfully provides, along with HFVExplorer, and Stuffit, and I was all set to go!

I created a target diskette of 100MB, then used hfvexplorer to copy 7.5.3 and it’s 19 segments into the disk. Then I booted the emulator with a minimal System 7 floppy. I then installed 7.5.3 into the 100mb disk, then shut down the emulator. Then using hfv explorer, copy over Duke and stuffit.

Boot back into MacOS, install stuffit, and expand Duke and away we GO!

Naturally with the speed limits dropped it’s quite FAST! vMac doesn’t have sound yet, so it’s a silent experience but it works quite well.

mini vmac II duke

mini vmac II duke

The sad thing is that Doom requires 32bit mode, which it seems that Mini vMac can’t do just yet.

Sheepshaver

SheepShaver on Windows

SheepShaver on Windows

I was hoping for this to be a full featured review but alas there are a few major issues to prevent wide spread use of this emulator…

First you really need access to a Power Macintosh of some kind to use this. You’ll need a ROM and a version of the OS that isn’t for free on Apple’s site. Right now I’m using my 7.6.1 CD to run stuff, and it works great. Honestly its way better than the real deal.. Unless you are running something CPU intensive… Like SIMH on MiNT (all 68000 code) on Sheepshaver (PowerPC emulator)… it can be quirky at times.

However let me say if you do have MacOS 7.6 – 9 you’ll love Sheepshaver. If you feel left out from the PowerPC to Intel transition and feel you need this old clunker around to run some 68000 apps or even PowerPC system 7-9 applications that are not carbon compatible, sheepshaver is freaking AWESOME.

I’m still running Vista x86_64 on my laptop where I do most of my work, so for me I needed to download Sheepshaver. Now it does mention it can run MacOS 7.5.2 however the copy on apple’s site is a massive disk image… So you’ll need a Mac to extract it… Yeah I know.  I did make an ISO image to help those who need/want it.

I haven’t tried it, however I do know that 7.5.2 did *NOT* work on my 5400. The good news is that the disk images work between MiniVmac & Sheepshaver. This has saved my sanity (perhaps yours as well!) This does mean that you can also use HFVExplorer to move files in/out of Sheepshaver. A word of caution, the SLiRP networking causes my setup to crash… I really don’t know if it’s Vista 64, and I’m not in the mood to test within Virtual PC… emulating within an emulator is a recipe for disaster.

Another thing you’ll need is the GTK+ runtime for the gui configuration… I found mine by googling the term “gtk-2.12.9-win32-2.exe” … For some reason sourceforge seems to have issues at the moment with its projects unless you know exactly what you are looking for.

That being said I love sheepshaver. I run it full screen at my laptops native resolution (1280×800) and with the sound on, and it FEELS like a Macintosh Laptop. Even my 1.8Ghz laptop feels snappier than the 120Mhz PowerPC.. But from the Sheepshaver site, they do say to expect to run at 1/8th the speed.. So my laptop “feels” like it’s 225Mhz. A SCREAMER! Of course this would be horrible for people expecting to run photoshop & friends.

There is no doubt about it, Sheepshaver is great for running old games and applications.

A few tips though. Turn off Virtual memory in Sheepshaver. There is no need for it, as it’s far better to allow Sheepshaver to just have more memory.. In this day & age odds are you can easily allow it to have 64 – 256 megabytes. While you are unable to turn off the disk cache, you should tune it down to 64kb. Although the CPU isn’t much faster than many of the Power Mac’s, the disk IO of a modern computer far exceeds it. Most computers are actually IO bound, so running older systems with faster IO gives the appearance of them running substantially faster. It’s only nested emulation that brings it out how slow it is.

I’ve also found that older version of the OS support more software, and run better.  That is 7.5.3, 7.6, 8.0 and 8.1.  8.5, 8.6 and 9.0 have more PowerPC hooks in them, and SheepShaver hooks the 68000 code to do it’s paravirtualization (it doesn’t emulate any hardware), and the more older tied to the 68000 code tend to be more stable.

That being said, running Mathematica, SoftPC, and Photoshop would not be a “good idea” if you are expecting faster performance. But at the same time, it’s great being able to run old software that you’ve purchased throughout the years.

Some 5400/12 – Performa 200 restoration notes

(Image from Wikipedia) I never took a picture of mine.

(Image from Wikipedia) I never took a picture of mine.

I’ll throw out a little tidbit about the Power Macintosh 5400/120, otherwise known as the Performa 200. If you do not have any Mac OS CD’s this will be *VERY* hard to get going with nothing. The good news is that there are boot floppies available out there.

The bad news is that they are encoded in a method in which you’ll have to get access to a working Mac. If there was somewhere I could post these files forever I would.

Anyways the boot disk is this one:

5400-6400_Disk_Tools.img.bin

Which I currently see online here:

http://www2.cddc.vt.edu/apple/Apple_Software_Updates/English-North_American/Macintosh/System/CPU_Specific_Updates/6360-64xx-54xx/5400-6400_Disk_Tools.img.bin

Now it’s a diskcopy 6.4 image. Which you’ll need a Mac. I was able to finagle one from a Mac, however I’m wondering now if it’s possible to do this via emulation. During this whole resurrect my $12 Mac I’ve come across vMac, Basilisk II & SheepShaver.

I plan on doing some serious review, however it is worth noting that while both do run fine, they are actually buggy on weird stuff vs the real iron.

From what I gather with the boot disk, you can boot your Mac up, partition & format it, and install this super small bootable System 7.6 onto the hard disk. It will complain about you doing it this way, but it will work, allowing you to get the box up & running somewhat, to let you try some methods of getting the install disk for 7.6 onto your Mac.

It is worth noting that the 7.5.3 on Apple’s download site that is provided for FREE does *NOT* work on the 5400! I did at one point try it, and I got some wonderful message :

The System Software 7.5.3 Installer script does not recognize this Macintosh. Please use the original disks that came with your computer.

Sadly all information I see is that this thing shipped with 7.5.3 Oh well. I eventually found a boot floppy!

The site I gleaned this boot disk from was this:

http://home.earthlink.net/~gamba2/bootdisks.html

If anyone does anything MacOS for a living or is going to play with a Mac you ought to save the whole thing! It’s VERY useful, more so than Apple’s documentation.

Anyways I’ve tweaked up a copy of the SIMH PDP-11 to compile and do a small test under MiNT/MacOS. Tomorrow we shall see if it’s usable.