SheepShaver with pcap support

Posted on by
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.

4 thoughts on “SheepShaver with pcap support”

  1. Hi,

    Thanks for your effort!
    It seems the appletalk stuff suffers from the same issue as the current windows build: just after start you have to disconnect/reconnect the fysical network before you can get Appletalk running through the Basilisk ethernet driver 😉
    Do the builds in the source tree include the 30-packet filter you mention? Is it only effective when ether pcap is set? Is there some instruction to get scsi to work or is it the same as with Basilisk? How to run ether pcap? I ran as root, but still get ethernet.c: pcap_open_live error on pcap! (On Yosemite).

    Best wishes,
    Howard

    • The source has the 30 packet count thing in there, it doesn’t wait 30 seconds, although it probably should.. Its the same code that I used in Basilisk II, and there you don’t have to wait, the network can start right away.

      You do have to run as root (su) for pcap to work, as this program not only ‘listens’ on the ethernet adapter, but also injects packets.

      SCSI is kind of a dream on Sheep, as only one ROM will boot from a ‘scsi disk’ and once you boot, the OS doesn’t recognize the adapter so nothing else will mount. Even disk tools and the profiler won’t see the SCSI stuff. The best I can figure (I’m the wrong person to ask about this kind of stuff) is that SheepShaver patches the 68000 part of things and the PowerPC side doesn’t care about old outdated drivers.

      • I haven’t tried it out yet, but a real 9500 supports System 7.5.5 onwards. It’s my understanding that most of those early system versions were still running under the 68K emulator in ROM. I have no idea however if the drivers in ROM would be 68K code or PPC. From a SCSI perspective, perhaps using an earlier System version might allow the bus to work.

        However from a virtual Mac Client perspective, there wouldn’t be much point in bothering – Basilisk II can run System 7.5 just fine – and few programs from that era required a PPC.

        • I guess that’ll explain why 7.5.3 doesn’t work.

          I haven’t torn fully into the thing, but as far as I’ve seen sheep still hooks the 68k code… I know the old world 7/8/9 was anything but pure, It was only the new world + OS X that was 100% PowerPC.

          Something about the MMU prevents 9 from booting from booting on Qemu/Pear but I never looked that far into it, and I really don’t know enough one way or the other on this kind of thing.

Leave a Reply