Random links

No I’m not dead, just been busy.

But here is some interesting things I’ve seen the last while:

Infer: static code analysis from facebook of all people.  Supports C, Objective-C and Java.

Dr Jack Whitham’s blog, with some interesting stuff related to compiler optimizations and how they alter floating point results, along with ‘bug 323‘, and some DOOM fun!  Plus he has his updated source repositories online here.

And finally, Building A 10BASE5 “Thick ethernet” network.  A fun look at the first gen ethernet cabling on ‘slightly’ newer machines.

Porting Quake II to MS-DOS pt2

Continuing in this series on porting Quake II to MS-DOS, we get to touch some of the fun stuff.  The first big ‘fun’ thing is networking.

Now in my prior work with the MS-DOS version of Quake, I had used the WATTCP library to bring networking to the otherwise Windows/UNIX specific fun of network deathmatch back to MS-DOS.  Quake by default had support for the Beame & Whiteside’s TCP/IP stack which for all intents and purposes has vanished from the face of the Earth (does anyone have a copy?!).  So, at the time, I thought it’d be cool to try to interface WATTCP with Quake, and it worked on the first attempt as WATTCP is a very competent TCP/IP stack.

So I took the Linux networking file net_udp, and compiled it, and I got an executable!

When it comes to testing WATTCP though, I prefer to use Qemu instead of DOSBox as it can not only emulate various network cards to which I can find packet drivers (yes even the evil PCI NE2000!) but it has a built in SLiRP network stack that let’s me NAT on my desktop without any crazy network configs.

And for the sake of testing, I setup a ‘null’ text mode server, figured out some flags, and I was able to connect!

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

Very exciting stuff indeed!

Now for some interesting stuff.  First, I noticed that MS-DOS 5.00 with himem.sys is almost unplayable because it is so slow.  MS-DOS 4.01 without himem.sys is actually faster.  No, I’m not kidding.

Next is that some levels LOVE to gobble up RAM.  Maps like city1 will need at least 192MB of ram.  I haven’t even tried playing with the virtual memory of DJGPP, and I really don’t want to.  And let’s face it, if you even try to load Quake II on a MS-DOS machine, it better be a ‘big’ one.  This means you should be using the ‘dos’ from Windows 98, or perhaps FreeDOS, although I haven’t tested that at all.

So far from our limited testing the networking seems to be pretty good.   And at least that is one function we didn’t have to really pour a lot of effort into.  Although the payoff of being able to connect to servers on the LAN and even the internet is a good thing.

Continued in pt3, pt4, and part 5.

Previous 0.52 (trunk 391) + slirp

I got this request to add in some SLiRP to Previous, the NeXT computer emulator.  Sadly work got in the way, and I trashed my windows dev machine.  To make it worse I also trashed my MacBook Air, but with a bit of screwing around I got X-code removed, and re-installed.

So here is my wonderful work, some 50 lines of code + the SLiRP from Cockatrice all hacked up.

ICMP to 10.0.2.2 seems to work fine, UDP seems to not work, so no DNS.  I don’t know why either.  I can telnet to my BBS just fine, which is about all the testing I’ve done.

Previous to the BBS

Previous to the BBS

Inbound TCP seems to be broken too, but I could be initializing slirp_redirect incorrectly too.

In case you want to follow up on this the NeXT computer forums is the place to be.  Networking with NeXTSTEP is involved.

And for anyone who want’s my files, the source is here, and an OS X 10.10.3 binary is here.  Be sure to install the SDL2 framework ahead of time!

Getting Qemu’s NetWare 3.12 onto the LAN with Tun/Tap

I could also call this ‘going with the flow’… So instead of fighting the system, like I usually do today we are going to do things the way everyone else enjoys doing things, and that is building stuff with tun/tap and bridges.

YUCK.

Ok, so I’m using Windows, and that is what I’m assuming you are as well for this ‘guide’.

The first thing you’ll need is the tun/tap driver for Windows, and the easiest way to get that is via OpenVPN.  The next thing you’ll need is Qemu, again I’m just using the pre-compiled stuff right here.

Go ahead, and install them both.  With OpenVPN installed, when you open your control panel, and check out your network interfaces you’ll see something like this:

One NIC, One Tap

One NIC, One Tap

Good.

Now for my example, I’m going to add another TAP interface.  TAP’s are only good for a 1:1 relationship with the VMs.  Yes, that is why I prefer something else, but again we are going to do things today the way everyone else does them.

Now for me, I run the ‘addtap’ batch file located in the C:\Program Files\TAP-Windows\bin folder as Administrator, and this now gives me two TAP adapters.  I highly recommend disabling TCP/IP v4 and v6 on the TAP adapters, along with the MS client/server stuff.  We are only using these for bridging the VMs so we dont’ need the host computer to participate in this network.

Now for the fun part.  I’m assuming you have your NetWare server and client images all ready to go (I guess I can go over installation again some other day), and now we get to bind each one to a SINGLE TAP instance.  Also don’t forget that each machine needs a UNIQUE MAC address.  One of them can use the default settings, but the other one cannot.

I’m going to start my server like this:

\Progra~1\qemu\qemu-system-i386.exe -m 16 -hda netware312.disk -device ne2k_isa,netdev=usernet,mac=52:43:aa:00:00:11,irq=10,iobase=0x300 -netdev “tap,ifname=Local Area Connection 2,id=usernet”

As you can see, this gives me a NE2000 on port 0x300, IRQ 10 and sets the MAC address to 52:43:aa:00:00:11 .  And this sets it on the first TAP adapter, lovingly called “Local Area Connection 2″ because the primary adapter is called “Local Area Connection“.  Also take note of the quotes in this command line, as it’ll encapsulate the full default name of the TAP adapter.  The other alternative is to just rename the adapters, but where is the fun in that?

Now for my client:

\Program Files\qemu\qemu-system-i386.exe” -m 16 -hda client.disk -soundhw sb16,adlib,pcspk -device ne2k_isa,irq=10,iobase=0x300,netdev=usernet -netdev “tap,ifname=Local Area Connection 3,id=usernet”

As you can see the primary difference here is that it’s connected to “Local Area Connection 3” which is my second TAP interface.

Now with both virtual machines running the interfaces will turn on!

But as you’ll quickly discover, neither machine can talk to each-other, as they are islands so to speak.

Two virtual machines on islands.

Two virtual machines on islands.

Now for the fun part, we highlight the two TAP interfaces, right click, and turn on the built in bridge function of Windows!

highlight and select

highlight and select

And once that is done, a new Network Bridge interface will show up, transfer what layer 3 settings there are, and then setup the layer 2 bridge between the TAP interfaces.

Bridge activating...

Bridge activating…

And once the bridge interface has gone live, give spanning tree 15 seconds to do it’s thing, and YES you can now login to the NetWare server!

Logging in from the MS-DOS VM to the NetWare 3.12 VM

Logging in from the MS-DOS VM to the NetWare 3.12 VM

And there you go!  This is the ‘approved’ way to do virtual networking with Qemu.

Now I know what you are thinking, this is great for VM’s and all that jazz, but what if I say have an office FULL of old PC’s and I want them onto my new fangled ancient server?

No problem, right click on the bridge, and select delete.  This will put everything back the way it was, sending the VMs back to their own TAP interfaces.  Now select all the interfaces, and then setup a bridge (I suppose you could edit the existing one to include the physical interface…) and now once the bridge has been setup, it’ll now be talking out the local Ethernet interface.

One quick note, bridging and WiFi tend to not go hand in hand.  Some interfaces will work, but the rule seems to be the vast majority of setups will not.  So don’t complain if yours didn’t work, you are just part of the 99.99999%.  And if you did get yours to work, well good for you.

Novell Netware 3.12 once more runs on Qemu!

This version of Qemu seems to be one of the better ones in a LONG LONG time.

Netware 3.12

Netware 3.12

Much to my amazement, as I fully expected this to crash much like all the other versions, it actually runs.

qemu-system-i386.exe -m 16 -hda netware312.disk -device ne2k_isa,irq=10,iobase=0x300 -soundhw pcspk -serial none -parallel none -k en-us

I’m just more amazed it works.  Now I did try it on my old setup of a NE2000 on 0x300 Interrup 2/9 but I was getting some IRQ issues.  So I went ahead and reconfigured Netware for IRQ ‘A’, and set the CLI for 10. Of course I haven’t actually tested networking, this is really a ‘wow it did something’ statement.  No doubt I’ll have to build a new GNS3 test bed with this Qemu, and see how Netware performs.

shellinabox

So while browsing reddit, I came across this neat package, shellinabox.  Simply put, it runs as a process on your ‘box’ and fronts it with a javascript terminal interface.  So as long as you have a halfway modern machine with javascript support you too can just connect to a machine and run CLI based stuff.

BBS via telnet

BBS via telnet

So as a test I setup a game of tetris, and a telnet session to my BBS.

There isn’t much to ‘setup’ in the way of shellinabox, because it’s all command line driven.

/shellinabox-2.14/shellinaboxd -t -s /:LOGIN -s “/bbs:nobody:nogroup:/:/usr/bin/telnet localhost” -s /tetris:nobody:nogroup:/:/usr/games/tetris-bsd –css /shellinabox-2.14/shellinabox/white-on-black.css -b

So this will create a new web server that by default listens on TCP port 4200 which in turn uses the virtual directories / for a login, /bbs which launches telent, and /tetris which starts the BSD tetris for terminals game.  Now as many of you are aware, not all people with internet connections have the luxury of having all outbound TCP/IP ports. Even the most excellent flashterm still establishes a TCP session.  That is what makes this different is that all the traffic is done via HTTP, which means it can be proxied.  Now the real trick is having a web server do the proxing for you, so that all the user has to do is hit a special URL, and the server will proxy the request to shellinabox’s web server.

Enter Apache2’s reverse proxy!

So on my BBS’es apache config, I add in the following lines:

ProxyPass /tetris http://localhost:4200/tetris
ProxyPassReverse /tetris http://localhost:4200/tetris
ProxyPass /bbs http://localhost:4200/bbs
ProxyPassReverse /bbs http://localhost:4200/bbs

I’m not sure exactly of the specific modules to enable, but hammering away this got it to work:

a2enmod proxy
a2enmod mod_proxy
a2enmod rewrite
a2enmod mod_proxy
a2enmod proxy_http
a2enmod proxy_module
a2enmod headers
a2enmod deflate

Under my virtual server’s ‘root’ directory.  So now when you access https://virtuallyfun.com/tetris/ Apache will proxy your request into the shellinabox http server, and you’ll get…

Tetris

Tetris

So now only using HTTP you can play tetris!

So where to go from here?  I was thinking some kind of SIMH CP/M on demand thing.  There is a command line Wyse 60 emulator, so maybe that’d be fun.  I may even bring back something I had ages ago, access into a bunch of legacy systems.  This is a great ‘solution’ to enable multiplexing without having to use another software MUX.

 

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.

Time for another Cockatrice release

I’ve been busy at work, but I did get some stuff done on this over the weekend, and just wanted to push this version out while there is some momentum.

The big fixes are in SCSI to support the dynamic scatter gather buffers so you can format big (lol) disks.  Then again I only tested a 2GB disk but it’s working fine as far as I can tell.

I also hard coded SCSI id #6 as a CD-ROM.  It only reads HFS partitioned images, and only can boot from a handful of those.  From some SCSI CD emulation packages with passthru it performs just as poorly, so it’s not just me.  I tested with the ‘blessed’ Win32 build 142, with ForceASPI in a Windows XP VM with emulated SCSI CD.  There is a lot more ‘magic’ going on with the cdenable.sys driver on the Windows side, which mounts ISO’s without any hesitation.

This also includes my latest networking fixes as I moved more of the networking code to use queues, forced the 60Hz timer to hit the network card so it won’t stall anymore, and added in that timer patch, that more than doubled my LAN download speeds.

I’ve also added a simple PCAP filter as I noticed that my LAN was quite chatty, and I figured all this traffic wouldn’t be good as an emulator really shouldn’t be processing stuff it doesn’t need to.  Something like this:

(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:16:48)))

09:00:07:ff:ff:ff is the AppleTalk broadcast address, ff:ff:ff:ff:ff:ff is the typical all hosts broadcast, and I’m still generating a MAC based on PID which is good enough for me.

Speed!

Feel the need for speed!

So while before downloading 124MB on my LAN took 8 minutes, now it’s about a minute.

I’ve updated the sourceforge page with source, Win32, Linux i386 and OS X (10.8) builds. I’ll add a 10.6 x86/PowerPC build later.  On the sourceforge page I also added a utilities section with a simple ISO image with various utilities to get you started, including the A/UX partitioning tool to partition & format a virtual disk, a tool to try to mount ISO’s (remember HFS has the only hope right now), QuickTime, Flash, Internet Explorer and some other stuff.

Also, thanks to Peter, it’s also available on github, so my horrific edits are open for the world to see…

I have no idea why the networking in Basilisk II keeps stalling

And it is quite frustrating.  The most I can do is about 100MB worth of AppleTalk traffic, or 1.5GB of TCP/IP then the receive function EtherReadPacket just stop being called, and then the whole thing stalls out.

I don’t really ‘like’ my solution, but it does work.  I went ahead and chained the EtherInterrupt function to the 60Hz timer to ensure it’ll fire, and it seems to be working. The good thing is now I’m getting ~200K/sec using pcap or SLiRP.  So things are faster!

Then after scanning the changelog, I found this interrupt patch, and it doubled my throughput on the network to over 400K/sec!

427K/sec via SLiRP

427K/sec via SLiRP

So now I can copy about 350MB worth of data in about 5-7 minutes, and it doesn’t stall out.

357MB worth of AppleTalk

357MB worth of AppleTalk

I can now copy hundreds of MB worth of stuff from one AT server to another.

What is also surprising is that by using Internet Explorer 4.0.1 for MacOS, I get speeds of around 1.0Mb/sec(with as high as 1.6!)

Internet Explorer 4.0.1 screaming along

Internet Explorer 4.0.1 screaming along

I know IE has always had a bum rap, but it really is a better legacy browser on MacOS.

I also merged the scsi driver’s buffer with BasiliskII’s buffer so the scatter/gather can now handle the absurd requests of 4MB++ worth of reads in one swoop.

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.