Switch to full style
About SheepShaver, a PPC Mac emulator for Windows, MacOSX, and Linux that can run System 7.5.3 through MacOS 9.0.4.
Post a reply

Let's document Sheepshaver's code

Mon Oct 24, 2016 9:52 pm

Before I begin, Sheepshaver's code is here. Sheepshaver hasn't seen much development since Gwenole left. The most significant patch in memory is a patch that allows some Ambrosia games like Escape Velocity: Nova and Ferazel's Wand to run under Sheepshaver. There's also a monitor/disassembler named cxmon, which was recently put into the macemu tree.

Here are some notable places under macemu/SheepShaver/src/ :

/dummy - Empty files used for whenever a component is not available.

/emul_ppc - The original Sheepshaver core. No longer used and is effectively dummied out by sheepshaver_glue.cpp in the below folder.

/kpx_cpu - The current Sheepshaver core.

emul_op.cpp - Emulating various operations that were 68k code in the original ROM.

gfxaccel.cpp - Quickdraw (2D) acceleration, but it only handles some basic functions.

main.cpp - This is where Sheepshaver initializes everything, poking the XPRAM to values expected by Mac OS.

name_registry.cpp - Set up the names for the devices, such as the processors and the ethernet devices.

prefs_items.cpp - Items referenced by the preferences files.

video.cpp - Video emulation.

rom_patches.cpp - Patches for the ROM. There are patches used for New World ROMs compiled in 1998 and 1999, but mainly focuses the Old World ROMs.

rsrc_patches.cpp - Patches based on the OS's resource forks.

timer.cpp - Time Manager emulation. This is an emulation of the Time Manager, but using the Unix functions.

Of course, several files are shortcuts to files in Basilisk II, reusing the audio, CD, and disk functionality from that.

There are also .i files, which are really binaries. To see these in a hex editor and disassemble them easier...
1)Open the .i file up any word processor
2)Replace 0x and , with blanks.
3)Copy and paste into the editor.

The original code for these driver stubs hasn't been found yet and I don't think it was included.

Patterns I've noticed in the code so far:

D(bug("String\n")); <- Used whenever the debug mode is enabled, noting which function was enabled

ReadMacInt32(), ReadMacInt16() <- Trying to read from the emulated Mac's memory.

FindLibSymbol() <- Not common, but it's supposed to be used any time Sheepshaver is trying to find a library within the Mac OS itself.

As for the video driver stub, there are exactly two functions: TheDriverDescription, and DoDriverIO. It's very primitive, being under 512 bytes. I'll check out the other stubs included.

Inside kpx_cpu, you have four folders:

cpu - The main code for the CPU
mathlib - Used for the floating point operations
test - PowerPC regression testing, but it's largely floating point and integer operations... and some AltiVec/VMX ones.
utils - Processor check, but this is largely for the x86 processors

There's also ppc-dis.c, which is a file straight from GNU, and is now being used as the disassembler.

You can also work with a monitor (using the command mon), but you have to manually enable this command in the code.

I plan on adding/commenting on the code more, so stay tuned on this topic.

Also, some new resources:
Mac Process Manager Document

Re: Let's document Sheepshaver's code

Wed Nov 02, 2016 3:45 pm

Hello, allow me to add a shy contribution.
I like the way Basilisk II was documented. The document can be found here:

Since SheepShaver and Basilisk II share some components, I'd suggest we shamelessly copy the structure of it and adapt it to fit SheepShaver's description. I don't think that "the documentation" is limited to this and this should be the whole thing, but the document would be a nice-to-have manual nevertheless.

And here I have compiled some of SheepShaver's configuration properties:


You will notice there's nothing about Windows properties and there can be some Linux configuration items missing or too many.

I got many of these properties from the 'prefs_items.cpp' file. Description and usage I took from examples, from Basilisk II and trial and error.


Also, there is a discussion in this forum somewhere about the model SheepShaver reports to the system. It seems it was developed based on the Power Macintosh 9500, which is the model reported. The processor, though, is not the original PowerPC 604, but a PowerPC G4 (it contains some AltiVec instructions).

Re: Let's document Sheepshaver's code

Sat Nov 24, 2018 5:05 pm

Massive bump, but it's still pretty important. So, Sheepshaver determines how the emulator functions by a string in the ROM, which is always located at hex address 0x30D064. However, older ROMs have that string at hex address 0x30C064 instead. Only the ROMs that Bauer and Beauchesne had access to are supported. Even stranger is how it seems to rely on a New World ROM located within the OS's hard disk rather than a proper New World ROM.

It also seems that, when first loading in a ROM, rather than loading the whole ROM, it instead only copies the first three MB, which are largely 68k code. The last megabyte is PowerPC code, along with a jump table at the very bottom. So, Sheepshaver has its own routines it can use. This means that there's flexibility as to whether or not to load portions from the ROM, or inject new PPC code for new functionality like the 68k UAE core.

Re: Let's document Sheepshaver's code

Sun Nov 25, 2018 12:59 am

So which ROMs in https://docs.google.com/spreadsheets/d/ ... =840977089 does that mean SheepShaver works with? And I wonder... should we update the load code to check for the proper values and check the alternate address if things don't line up?

Re: Let's document Sheepshaver's code

Sun Nov 25, 2018 5:29 am

Here's the thing - Sheepshaver does not check for checksums, just strings. So it doesn't matter how much you change the ROM, so long as the strings is found in its proper place. That said, I don't think there are any hacks of the Apple Mac ROMs.

Anyhow, here are the ROMs that Sheepshaver can work with, among what I have in my collection:

6F5724C0 - Performa 6400 (Alchemy)
6E92FE08 - Power Mac 6500 (Gazelle)
78F57389 - Power Mac G3 (v3) (Gossamer)
79D68D63 - Power Mac G3 desktop (Gossamer)
960E4BE9 - Power Mac 7300 & 7600 & 8600 & 9600 (v1) (TNT)
960FC647 - Power Mac 8600 & 9600 (v2) (TNT)
9630C68B - Power Mac 7200&7500&8500&9500 v2 (TNT)
96CD923D - Power Mac 7200&7500&8500&9500 v1 (TNT)

There's also no ROM listed there with the code name of "Zanzibar".

Here's the others that don't work with Sheepshaver, with the boot string address and codename noted in the ROM.

Boot String at 0x30D064...

2BEF21B7 - Bandai Pippin (Kinka 1.0) (Pip)
2BF65931 - Bandai Pippin (Kinka Dev) (Pip)
63ABFD3F - Power Mac & Performa 5200,5300,6200,6300 (Cordyceps)
B46FFB63 - PowerBook G3 Wallstreet PDQ (GRX)
CBB01212 - PowerBook G3 Wallstreet (GRX)

Boot Strings at 0x30A064, 0x30B064, 0x30C064 0x30D064...

83A21950 - PowerBook 1400cs (PBX 603)
83C54F75 - Powerbook 2300 & PB5x0 PPC Upgrade (PBX 603)

Boot String at 0x30C064...

9FEB69B3 - Power Mac 6100 & 7100 & 8100 (Boot PDM 601)

There's more Macs here that are missing, like the Twentieth Anniversary Mac (Spartacus).

Re: Let's document Sheepshaver's code

Sun Jan 06, 2019 11:40 pm

Thanks so much for posting this. I've been meaning to delve into the SS source files. So far I've been putting it on the backburner because I couldn't find much documentation.

I know QEMU is supposedly better, but I have not been able to get it to run fast and don't see much of a need for it other than to run 9.2.2. For the wrapper project I've been working on, boot time is extremely critical and SS wins (at least for my usage).

Re: Let's document Sheepshaver's code

Mon Jan 07, 2019 4:34 am

That said, I don't think there are any hacks of the Apple Mac ROMs.

I'm not sure about hacks per se, but there is a reverse engineered new world rom. You might have already heard of it:

It produces a byte-perfect copy of the rom, so in theory it should make hacking the rom quite a bit easier. The devs are also active. I was thinking of compiling a version that displays all black pixels on the happy mac icon.

I know you were making the point that SS doesn't need to handle ROM hacks, but talking about it reminded me of this so I thought I'd post lol.

Re: Let's document Sheepshaver's code

Sun Mar 24, 2019 4:37 am

classicmacreborn wrote:The devs are also active.


Mac OS ROM 1.6 and later are unsupported because they have the super-cool multitasking v2 NanoKernel baked into the ROM image (same place as the old one, offset 0x310000). This kernel absolutely requires a working MMU -- SS’s sleazy hacks are not enough to get it working. I bet there is plenty of fun to be had here, though. With the help of the partly reverse engineered v2 kernel sources in my repo (I have done a better job on v1 elsewhere, and hope to redo v2 at some stage), it might be possible to hack the kernel so the preemptive multitasking actually *works*.

I do have a very brief wish list for SS (not that I can even compile it successfully): load the Mac OS ROM file from the boot image at runtime, and provide a way to use Basilisk’s 68k emulator for MixedMode switches in place of Apple’s ROM-based PPC-assembly one.

Re: Let's document Sheepshaver's code

Sun Mar 24, 2019 8:55 pm

It should be possible to add code into SS that gets it to look in the disk image for the ROM listed in the prefs file, then System Folder:Mac OS ROM, then the root folder; I haven't taken the time to make it work, but all the logic for image traversal and ROM loading is already in place.

For MixedMode switches, my wish list item was to replace with the new UAE code (and also port that into BII, so I guess it's the same item, just with an extra step added).
Post a reply