I got the latest changes from mschmitt and I built a new UB from it:
http://www.xs4all.nl/~ronaldpr/sheepsha ... 090714.zip

I built both Intel and PPC versions in Leopard 10.5.7, XCode 3.1.3, against MacOSX 10.4 SDK, with SDL 1.2.10, and both with:



I tested this version on both Intel and PPC in Leopard. I did not test in Tiger.

On Intel it worked as expected, just like the previous recent builds, and with CPU usage well below 20%.

On PPC, overall performance was, as with previous builds, OK but not more than that. It used all available CPU, sometimes up to 95%. Sound was better than with the builds that were built without --enable-sdl-audio (--disable-sdl-audio is the default).

I tried my own experiment, building from unaltered CVS source code, with sdl 1.2.10 and configuration --enable-sdl-static --enable-sdl-video --enable-sdl-audio --disable-vosf.

Two Intel-only builds were performed, one on Tiger and one on Leopard, both on the same Intel MacBook Pro. Each build used an identical, pristine copy of the full source tree, to exclude any possibility of leftover build products hanging around from an earlier build. The exact same build steps were performed in each case, apart from the magic incantation on Leopard to build against the 10.4 SDK.

Each of the two builds was run on Tiger and then on Leopard, on the same machine, using an identical copy of my Mac OS 8.6 disk image, with identical .sheepshaver_nvram and .sheepshaver_prefs files.

Subjective performance was about the same regardless of which build and which OS it was running on. Perhaps the Tiger build was more prone to video "tearing" than the Leopard build, regardless of where running; but the difference was not dramatic and could even be my imagination.

When idle, the Tiger build was consuming 50-60% of a CPU whether running on Tiger or on Leopard.

When idle, the Leopard build was consuming about 16% of a CPU whether running on Tiger or on Leopard.

I profiled each build running on each system, and there was a dramatic difference between the Tiger and Leopard builds, in a certain area that appears related to SDL video. This requires further examination, because artifacts of the profiling technique could be misleading.

If time permits, I'll be looking for differences in compiler optimization of some critical code path, probably video related. No doubt the Leopard compiler is doing a better job, and it may have a different set of optimization defaults as well.

You could try to isolate it to the SDL programs vs. SheepShaver, by building SS Leopard from SDL Tiger, or vice versa.

I'm leaning against optimizations performed by the compiler itself, as we've discovered that Xcode 2.x and 3.x is installing the same GCC toolchain (GCC version 4.0.1)

I'm wondering if SDL's build process is doing something different, either in the config or in compiler directives in the SDL code.

One thing to check is to compare the Tiger and Leopard SDL_config.h files.

By the way, while hunting around in the SDL config files, I discovered it has specific support for building cross-architecture (and building Universal Binary).

The PPC versions of SheepShaver consume even more CPU time (up to 95% on my PowerBook G4). This is also true for my latest build which was build in Leopard. Can there be any relation between this extremely high CPU usage and the high CPU usage by the Intel Tiger builds?

I had been planning to try swapping a particular .o that caught my attention in the profiling output. Finding time to play with this stuff is going to be the hard part.

I did notice that I had 4.0.1 on both systems, but they are different builds (5370 on Tiger and 5484 on Leopard). Might not be significant. However, I seem to vaguely recall reading somewhere that some optimizer bug(s) had been fixed, allowing different default optimizations to be enabled. Possibly that's just an old or spurious memory.

I fixed the PPC code so the RAM/ROM shifting works, which means that PPC now supports 1 GB of RAM. And it should fix the "Cannot map RAM: File already exists" error on PPC Leopard.

I uploaded a new Universal Binary version, dated 2009-07-19. (The date is in ISO format to avoid confusion.)

http://files.getdropbox.com/u/879516/Sh ... -07-19.zip

This version is compiled with sdl-audio.

I updated the link in this thread's top post.


PowerPC assembly language is sure a lot different than z/OS, that's all I can say. :-)

Does this build have the full screen fixes from the other stickied build?

Apparently yes!

Cat_7

All previous fixes since 2006 are in this build and in CVS. These latest "Cannot map RAM" fixes are not (yet) in CVS. I wonder if and how they would affect compiling for Windows and Linux.

On PPC this build still has the the enormous CPU consumption. Any thoughts on that? The CPU consumption on PPC is related to the Refresh Rate settings. Maybe PPC users should be advised to set Refresh Rate to 15. With a refresh rate of 15 (frameskip 4) CPU consumption is considerably less and it is still workable for most applications, also because the hardware cursor is not affected by the low refresh rate.

I already reported on building for Windows: that still works.

I'll also install some linux distro to check.

Cat_7

I tried it in Ubuntu Linux (Intel) last night. I think it worked, but it did reveal that I need to change how I fixed the error messages. Fix forthcoming.

One thing to test is Linux on PPC -- especially because Apple uses a custom assembler, which uses different syntax than the GNU Assembler. That affects the assembly code I changed.

The changes are still made only to the SheepShaver source? So we do not need to worry about effects for BasiliskII?

Is this page on Gwenole's site known?
http://gwenole.beauchesne.info/en/proje ... /compiling
(For MacOSX, the essential difference with these older instructions is that now we do not install Fink and do not use Fink to install SDL.)

I have ubuntu 9.04 on my netbook. Maybe I can try and see what happens if I compile SheepShaver there when I get the latest changes.

As of today, all my changes are within SheepShaver source.

But, I think I'm going to need to change the VM allocation routine in the Basilisk II source.

Remember the "File already exists" bogus message? That was because the Mach memory allocation function used by Basilisk II on OS X doesn't set the C errno variable, which the program was using to get the error code.

I fixed it by changing the higher level code to ignore the errno value, and instead use a constant that indicates it couldn't allocate memory.

However, the memory allocation function it uses on Linux does set errno, which means that my code is losing valuable information, expecially when it can't set the low memory area due to permissions issues.

I'm thinking that a better fix would be to change the Basilisk II code so that when it gets a bad result from the Mach memory allocation, it sets errno. Then the higher level code can go back to the way it was before, and it will work for both OS X and Linux.

I wonder...
There is a sourceforge basilisk-devel mailing list. Shouldn't this discussion (also) take place there?

I think that's an acceptable solution. When you have a patch ready, please send it to the basilisk dev list, and I can commit it to CVS. Thanks.

I fixed the problem with the error logic and rebuilt. This version incorporates the latest changes committed by Myrd to CVS.

http://files.getdropbox.com/u/879516/Sh ... -07-26.zip

I tried profiling with Shark. It says that the cpu time on PowerPC is spent in the BasiliskII program video_sdl.cpp, function update_display_static_bbox, in a call to memcmp.

One possibility is that the memcmp function is much less efficient when compiled for PPC. I'm wondering if glibc has an optimized memcmp for PowerPC with Altivec, and if we are using the right compile parameters to enable it.

Another is that the code path for Intel is taking a different route through this program. I looked into that but got lost.

I,

I get an "not enough memory is available when using sound manager error" when using this build on Intel mac, with memory set to 512 Mb.

And after updating a disk to 9.04, it wouldn't start anymore with your current build. Only if I set memory to 256Mb or lower, it will start. This is on a 1Gb memory machine.

Best,
Cat_7

Runs fine both 9.0.4 (with newworld rom) and 7.5.5 (with oldworld rom) on my Intel Core 2 Duo iMac (4GB) with RAM set to 512. Have not tried on PPC yet.

I would like to try the new "self-contained .sheepvm bundle", but how do I turn a xxxx.sheepvm folder into a bundle?

That is weird. The only changes are:

1. Fix to the memory error code
2. Built with SDL Audio on
3. Incorporates Myrd's code.

I can try backing out Myrd's changes and see if it makes any difference.

The "not enough memory is available when using sound manager error" is within the guest Mac OS?

When you say a 9.0.4 disk won't start, does it throw an error?

I assume you're testing the pre-built version, not building from source.

Runs fine on my (4GB) machine with both RAM set to 512 and RAM set to 1024.

Another change I picked up from CVS appears to be for handling illegal memory access in the PowerPC emulator.

Your 2009-07-26 build runs OK on my PowerBook G4 Leopard, still with the huge CPU consumption.

I haven't tried this yet, but I'm guessing it works like this:

1. You need OS X to recognize the new Info.plist.
   
   OS X Launch Services automatically registers applications in the Applications folder, any subfolder of Applications, or when the Finder becomes aware of the application (such as when you open the folder containing the application).
   
   Sometimes you have to force it to refresh and pick up new information for an .app. I use the Nudge contextual menu for this purpose, it is easier than logging out and back in.
   
2. Once Launch Services has recognized the new Info.plist, xxx.sheepvm folders should automatically turn into packages. However, sometimes the Finder needs to be kicked into refreshing; again, I give the folder a Nudge when this happens.

I see a problem in the future: us testers may have multiple copies of SheepShaver on our hard drives. Once we get two versions that both have Myrd's code change, how will Launch Services decide which one to launch (when you double-click a .sheepvm bundle)?

The rule is that in the case of a tie, the app with the highest version number wins. Does this include the date we are appending to the version string? If so, then we'll have to standardize on ISO dates; otherwise we're going to get very strange results.

Well, I have a folder "sheepshaver.sheepvm" but whatever I do, it remains an ordinary folder.

Also, the Info.plist file does not look any different from the one in previous builds.