Fix for "Cannot map RAM" on Leopard

About SheepShaver, a PPC Mac emulator for Windows, MacOS X, and Linux that can run System 7.5.3 to MacOS 9.0.4.

Moderators: Cat_7, Ronald P. Regensburg, ClockWise

mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Fix for "Cannot map RAM" on Leopard

Post by mschmitt »

I have a fix for the "Cannot map RAM" bug that some machines (including mine) get running SheepShaver on Leopard.

This build also lifts the restriction on RAM size, so now OS X hosts can set the SheepShaver machine to have up to 1 GB of RAM.

I'll post the gory details in second posting.

Question:

What is the official procedure for building a multi-OS version, Universal Binary for release? I can't find it in any official documentation. I looked through the forums and see contradictory instructions. There doesn't seem to even any agreement on the configure settings.


Update 7/26:

Here is a link to SheepShaver with my fix, including all other fixes committed to CVS. It is a Universal Binary. I'd be interested to know if this works for any other users, especially those who are currently getting this error:

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

Edit From 2010: Go for the most modern version of SheepShaver to fix this problem: http://emaculation.com/forum/viewtopic.php?t=5722
Last edited by mschmitt on Wed Jul 29, 2009 1:46 am, edited 8 times in total.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Post by Cat_7 »

Hi,
I would suggest sticking with the proven method like below. (for OSX)
On two machines, one PowerPC, one Intel, build the program and use the "lipo" command to join them into a Universal Binary.

In the SheepShaver folder execute:
make links

In the SheepShaver source folder, execute:
NO_CONFIGURE=1 ACLOCAL_FLAGS="-I m4" ./autogen.sh
./configure --enable-sdl-static --enable-sdl-video --enable-sdl-audio --disable-vosf
make
make SheepShaver_app

Very interested to see your cannot map ram solution! If you have source code changes and want us to create a Universal binary, please let us know.

Best,
Cat_7
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: Fix for "Cannot map RAM" on Leopard

Post by Ronald P. Regensburg »

mschmitt wrote:What is the official procedure for building a multi-OS version, Universal Binary for release?
I don't know about an "official" procedure. This is how I built my latest UB build for Tiger and Leopard:

Two identical procedures, both in Tiger with XCode 2.5, one on a PPC machine and one on an Intel machine:

Code: Select all

mkdir SheepShaverBuild
cd SheepShaverBuild

cvs -d :pserver:anoncvs@cvs.cebix.net:/home/cvs/cebix login

(password: "anoncvs")

cvs -d :pserver:anoncvs@cvs.cebix.net:/home/cvs/cebix checkout BasiliskII
cvs -d :pserver:anoncvs@cvs.cebix.net:/home/cvs/cebix checkout SheepShaver


mkdir SDL
cd SDL
svn checkout http://svn.libsdl.org/tags/SDL/release-1.2.10
cd release-1.2.10
./autogen.sh
./configure --disable-shared --prefix=`pwd`
make
make install

PATH=`pwd`/bin:$PATH
export PATH
cd ../..

cd SheepShaver
make links

cd src/Unix
./autogen.sh --disable-vosf --enable-sdl-static --enable-sdl-video

make
make SheepShaver_app
Next took the executables from the packages, renamed them SheepShaver-intel and SheepShaver-ppc. Made from those two files one UB executable using lipo command:

Code: Select all

lipo -create SheepShaver-intel SheepShaver-ppc -output SheepShaver
Checked the resulting file with:

Code: Select all

file SheepShaver
Finally put the UB executable back in place in one of the two packages and manually edited the Info.plist file, adding the date to the version number to discern the build from all other "2.3" versions.

Edit: Not doing "--enable-sdl-audio" seemed to slightly improve sound performance on slower machines.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

"Cannot map RAM" error details

Post by mschmitt »

For those that are interested, here are the details behind this error.

First, I acknowledge the excellent work of kby, who I think is the first person to figure out what is going on.

Second, please note that Mac (and C) programming is not my normal area of expertise, so I Could Be Wrong.

In the ever popular Q&A format:


Q. What does SheepShaver mean by "ERROR: Cannot map RAM"?

A. SheepShaver is attempting to allocate a block of virtual memory, for the size specified in the preferences. This allocation attempt is failing.


Q. Why does the error say "File already exists"?

A. This is a bug in the code. It is displaying the value of the C error variable "errno". The problem is, errno isn't set by the calls it is making. Errno has a value (17) left over from before it tries to allocate the memory. 17 is the value for "File already exists".

I changed it so that it uses an error code of ENOMEM, which changes the message to "ERROR: Cannot map RAM: Cannot allocate memory", which is closer to what is going on.


Q. Why can't it allocate the memory it wants?

A. The address block it wants is already in use.

SheepShaver is coded to allocate its memory blocks at fixed addresses. This seems strange, but it sort of makes sense.

SheepShaver can be compiled to run in two different memory access modes: DIRECT and REAL. REAL means that the virtual memory addresses as allocated in the host machine are the same as the virtual address seen inside the emulated machine. For example, if the ROM is loaded into the host space at 0x40000000, then the emulated Mac sees the ROM at the same address.

This improves performance (especially when run natively on PowerPC hosts), since it doesn't have to do address translation (aside from byte swapping).

SheepShaver wants to allocate the following blocks on Mac OS or Unix/Linux hosts running in REAL mode:

Code: Select all

RAM area       ???M   0x20000000 to ? 
ROM area:        5M   0x40800000 to 0x40D00000 
Kernel Data 2:   8K   0x5fffe000 to 0x60000000 
SS Globals:    512K   0x60000000 to 0x60080000 
Sig stack:      64K   0x60080000 to 0x60090000 
DR Emulator:    64K   0x68070000 to 0x68080000 
Kernal Data 1:   8K   0x68ffe000 to 0x69000000 
DR Cache:      512K   0x69000000 to 0x69080000 
Load mod:             0x78048000 
The first thing we notice is that if the RAM starts at 0x20000000 and the ROM starts at 0x40800000, then there is no way to have a RAM area greater than 512 MB. (Larger RAM areas work on Windows because on Windows SheepShaver allocates the RAM starting at 0x0.)

On certain Leopard machines, it can't get the RAM area because there already is something allocated at 0x20000000.


Q. What is already allocated at 0x20000000?

A. I have an Intel iMac with 512 MB of graphics memory. On my machine, there is a 512MB memory allocation by IOKit, running from 0x01f4d000 to 0x21f4d000.

There are some other blocks allocated past that point. To succeed in allocating the RAM, the RAM area has to start at x25811000.


Q. Why does the problem only occur on some machines?

A. I think kby had the answer: it is the IOKit allocation. I wouldn't be surprised if most of the people that get the error have 512 MB of graphics memory in their machines.

It also depends on some other factors:
  • Do you have any Input Managers (Saft, 1Password, PithHelmet, etc.)? Input managers inject code into every process, including SheepShaver. This will slightly shift the memory allocations.
  • Did the Mac load IOKit in low memory or high memory? On my Intel Mac running Leopard, it loaded it low. On my PowerPC Mac running Tiger, it loads it high, which is out of the way of SheepShaver
Q. Even so, why does it vary by machine? And why would running a OS update combo updater fix it? And what does this have to do with Leopard?

A. My theory is: Leopard introduced "Library Randomization".

Library Randomization means that the OS doesn't always load the system libraries at the same point. This is to make it more difficult to hack the machine.

I suspect that on Tiger the IOKit always loads high, and on Leopard it doesn't. (This is a wild guess.)

The key is that Library Randomization is not per launch or per boot. It is per machine. And when do the library load points get randomized? It is when pre-binding occurs.

Guess what happens when you install an OS update? The last thing it does is update the pre-binding!

So my theory is that some machines redoing the pre-binding shifted the library load points just enough so that the block at 0x20000000 was left free, so SheepShaver could load.

(We could test this theory by using a utility to just update the pre-binding. But don't try this on a working machine; it could shift it so SheepShaver no longer runs!)


Q. Why does it work when SheepShaver is compiled for running under X, rather than SDL?

A. The problem is that SDL is a Cocoa program. The way it works is there is an SDL starter program that performs all the Cocoa initialization and setup, then it turns control over to the main SheepShaver program.

At the very start, there is nothing much loaded in memory at all. As soon as it does the Cocoa init, that's when all the libraries, fonts, and the IOKit areas get allocated. By the time the SheepShaver code tries to allocate, it is too late.

When you run under X, there is no SDL cocoa wrapper before the SheepShaver main program.


Q. Is there a simple fix?

A. We could simply change the RAM load point, such as to 0x30000000. But that would decrease the maximum RAM size for the emulated machine. At 0x30000000, it can only be 256 MB.


Q. How did you fix it?

A. I changed it so that the RAM block is no longer acquired at a fixed address; it will be allocated at any address that has enough contiguous free memory.

This works because even though on a real classic Mac the RAM starts at zero, it can actually start at other addresses. The Mac defines the bottom of memory as "starting where the RAM is".


Q. But the SheepShaver code will error if the RAM is higher than the ROM. Why does it do that?

A. Apparently on a real classic Mac, the start of the ROM has to be at a higher address than the start of the RAM. Otherwise it crashes.

Also, the ROM address has to be aligned to a 1 MB boundary; it can't just be any address.


Q. So how did you get the ROM address to be higher than the RAM?

A. I changed it to allocate a contiguous block: RAM size + ROM size + 1 MB. I set the RAM to start at the beginning of this block, at the ROM starts after the RAM. The ROM is aligned to a 1 MB boundary.

Note: It only does this code when running in REAL mode. This code won't work in DIRECT mode, due to the way SheepShaver's configuration files are set up.


Q. So how much memory can we give the emulated machine now? More than 512 MB? 1 GB? 1.5 GB (the maximum memory of a PowerMac 9600)?

A. Yes, the 512 MB limit is lifted, but not necessarily all the way to 1 GB.

If your machine didn't have the "Cannot map RAM" problem before, then you should be able to go to 1024 MB. Otherwise you probably can't go all the way. On my machine I can give it 929 MB, but anything higher crashes.

The problem is that with a larger allocation, it can't find it down in the 0x20000000 range, so it allocates it high (above 0xa0000000). This causes a crash; probably because the RAM/ROM is higher than one of the other allocations (globals, sig stack, kernel, etc.). Or maybe it is just that the classic Mac OS code doesn't expect it to be that high. Or maybe there is a bug in SheepShaver.

Update: It will now write an error if the RAM/ROM area loads too high to be usable, and suggest lowering the requested RAM amount.


Q. Is your solution the "right" solution? Or is there some other way we could fix it? How can we get 1 GB of memory on the emulated machine, running on an OS X host?

A. I don't know. See the disclaimer above; this is not my normal type of programming.

The way I see it, the alternatives are:
  1. Do the simple fix where we just change the RAM block to start at a higher address.

    The disadvantage is that it reduces the memory limit, and will probably fail in the future.
  2. Do the SheepShaver memory allocations before the SDL Cocoa initialization.

    The problem here is that the SDL code comes from the Basilisk II source, not SheepShaver. And Basilisk II is not modifying the SDL main program at all; it is identical to what you download from SDL.
  3. Run in DIRECT mode rather than REAL mode, and change the program so it can have different memory offsets for RAM and ROM.

    This is non-trivial, and may not even work. SheepShaver may be depending on the fact that the distance between memory addresses in the host is always the same as the distance between the emulated machine addresses.
  4. Include the other data areas in the same contiguous block, so they are allocated higher than the ROM.

    Don't know if this would work.
  5. Change to run in 64-bit mode.

    I suspect this is very non-trivial, especially since the emulated machine still has to see addresses in the 32-bit address space.
Q. Are there any known drawbacks to your fix?

A. One is that now it is trying to allocate one larger block (which apparently has to come from below 0x60000000), rather than two smaller blocks (in fixed positions).

It is conceivable that there is some scenario where it worked before and fails now, but that would involve a very strange memory map.


Q. What types of hosts are affected by your change? How many programs did you change?

A. SheepShaver's code had the ROM area at a hard-coded address across many programs. This had to change, so the code changes are in the base SheepShaver code, which affects everything.

In theory the only real impact should be to Unix and Mac OS platforms. In other platforms (such as Windows), it should be doing exactly what it was doing before.

I changed 14 programs.
Last edited by mschmitt on Tue Jul 07, 2009 9:22 pm, edited 2 times in total.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

Thank you for your thorough exploration of this problem !

However, your build does not run on my Intel iMac. It crashes as soon as it is launched. I replaced the working application with your build in the same location and did not make any changes to the settings.

In Console:

06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Referenced from: /Users/ronald/Applications/SheepShaver/Mac OS 9.0.4/SheepShaver.app/Contents/MacOS/SheepShaver
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Reason: image not found
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Reason: image not found
06-07-09 12:11:53 com.apple.launchd[75] ([0x0-0x3d03d].SheepShaver[519]) Exited abnormally: Trace/BPT trap


2.4 GHz Intel Core 2 Duo
4 GB 667 MHz DDR2 SDRAM
ATI Radeon HD 2600 Pro, 256 MB VRAM
MacOSX 10.5.7

In SheepShaver settings RAM set to 512MB (536870912)


(Another problem that affects all Intel-only versions of both BasiliskII and SheepShaver is that I need to disable Intego VirusBarrier X5 to be able to use it, because VirusBarrier insists that the application is (infected with) the "OSX/MachArena.B" virus.)
PeterHolbrook
Apple Corer
Posts: 273
Joined: Fri Oct 26, 2007 7:56 am

Post by PeterHolbrook »

I want to express my gratitude to kby and mschmitt for their impressive research. However, I have a question for them and/or for the administrators of this forum.
1. Does the mschmitt build of SheepShaver include all previous code improvements found in the latest "semi-official" builds of this forum?
2. Will the "semi official" build of this forum incorporate mschmitt's changes? If so, when? If not, why not?
3. Are there any drawbacks in this procedure? For instance, I'm one of those lucky people who have never seen the pesky error. Will SheepShaver performance on my machine deteriorate if I use mschmitt's build or a future build adopting his solution?
4. Will SheepShave or OS 9 applications behave better, faster or more robustly by allocating more RAM in mschmitt's build or a future build adopting his solution?
5. Has anyone done any research as to the odd behaviour of QuickTime in SheepShaver might be related to this memory problem? Does anyone see a realistic prospect of upgrading to QuickTime 6?

Thanks for your work, guys.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Ronald P. Regensburg wrote:Thank you for your thorough exploration of this problem !

However, your build does not run on my Intel iMac. It crashes as soon as it is launched. I replaced the working application with your build in the same location and did not make any changes to the settings.

In Console:

06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Referenced from: /Users/ronald/Applications/SheepShaver/Mac OS 9.0.4/SheepShaver.app/Contents/MacOS/SheepShaver
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Reason: image not found
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Reason: image not found
06-07-09 12:11:53 com.apple.launchd[75] ([0x0-0x3d03d].SheepShaver[519]) Exited abnormally: Trace/BPT trap
I suspect that this means the way it built, it requires a library that it can't find. There was no message preceding the "Referenced from" line, in the system log?

I'm going to send the source to Cat_7 and see if he can build a more compatible version.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

mschmitt wrote:There was no message preceding the "Referenced from" line, in the system log?
Nothing related to launching SheepShaver.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

PeterHolbrook wrote:I want to express my gratitude to kby and mschmitt for their impressive research. However, I have a question for them and/or for the administrators of this forum.
1. Does the mschmitt build of SheepShaver include all previous code improvements found in the latest "semi-official" builds of this forum?
2. Will the "semi official" build of this forum incorporate mschmitt's changes? If so, when? If not, why not?
3. Are there any drawbacks in this procedure? For instance, I'm one of those lucky people who have never seen the pesky error. Will SheepShaver performance on my machine deteriorate if I use mschmitt's build or a future build adopting his solution?
4. Will SheepShave or OS 9 applications behave better, faster or more robustly by allocating more RAM in mschmitt's build or a future build adopting his solution?
5. Has anyone done any research as to the odd behaviour of QuickTime in SheepShaver might be related to this memory problem? Does anyone see a realistic prospect of upgrading to QuickTime 6?

Thanks for your work, guys.
  1. I pulled the CVS source a couple of weeks ago, so it should include the semi-official changes.
  2. Once we make sure it works, we'll submit the code for uploading to CVS, so it will go into the semi-official builds.
  3. The code changes I made should have no performance impact.
  4. The OS 9 Mac running within SheepShaver doesn't have virtual memory turned on; it thinks that all the memory you give it is "real" (even though it is actually virtual memory in the host.) So it won't help performance that much to give it more memory that it actually needs. Personally I think that 512 MB is plenty. I ran my OS 9 Mac for 12 years with 160 MB of memory real memory, using the default of 320 MB of virtual.
  5. Quicktime locks up for me.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

Ronald P. Regensburg wrote:
mschmitt wrote:There was no message preceding the "Referenced from" line, in the system log?
Nothing related to launching SheepShaver.
Sorry, yes, there was more. Apparently something went wrong with copying and pasting.

Console:

06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] dyld: Library not loaded: /Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libgtk-quartz-2.0.0.1500.0.dylib
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Referenced from: /Users/ronald/Applications/SheepShaver/Mac OS 9.0.4/SheepShaver.app/Contents/MacOS/SheepShaver
06-07-09 12:11:53 [0x0-0x3d03d].SheepShaver[519] Reason: image not found
06-07-09 12:11:53 com.apple.launchd[75] ([0x0-0x3d03d].SheepShaver[519]) Exited abnormally: Trace/BPT trap


There is indeed no /Library/Frameworks/Mono.framework/
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

I recompiled with:

Code: Select all

./configure --enable-sdl-static --enable-sdl-video --without-gtk --disable-vosf
and re-uploaded. The file name and link is the same as before. Please try again.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Post by Cat_7 »

Hi,

Your current build runs fine on my Intel machine with 2Gb of Memory. It even allows setting memory to 1024 Mb without a problem. I have a 512Mb NVidia graphics card (8800GT) but never experienced the cannot map ram error.

Great!

Cat_7
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Cat_7 wrote:... It even allows setting memory to 1024 Mb without a problem. ...
The Basilisk II code has an edit that prevents attempts to set more than 1024 MB of memory.

I can't find any such edit in SheepShaver.

I wonder what the maximum memory really is. What happens if you go over 1024 MB?

The Apple documents say that the maximum usable memory on classic Macs is 1.5 GB. On some machines you can install up to 2 GB, but it will only use 1.5 GB.

Of course, this may be ROM dependent.

Should SheepShaver edit the requested RAM and limit it? To what value?
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Cat_7 wrote:... I have a 512Mb NVidia graphics card (8800GT) but never experienced the cannot map ram error....
To see where things are loading:
  1. Start SheepShaver.
  2. Open a Terminal window.
  3. Enter: vmmap -interleaved -wide SheepShaver

    (-wide is optional)
I bet your IOKit areas are loading higher than SheepShaver.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

Runs OK here, even with RAM set to 1024MB.

This build uses the software cursor only, which makes cursor movements less smooth and which slows down the emulator slightly. The, so far, best compromise, with hardware cursor when possible and software cursor only when needed, can only be built with SDL version 1.2.10.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Post by Cat_7 »

With 256 Mb this is the output for vmmap

IOKit 02355000-119c5000 [246.4M] rw-/rw- SM=NUL
VM_ALLOCATE ? 1540d000-25500000 [256.9M] rw-/rwx SM=ZER


With 512 Mb:
IOKit 02355000-119c5000 [246.4M] rw-/rw- SM=NUL
VM_ALLOCATE ? 1540d000-35500000 [512.9M] rw-/rwx SM=ZER

with 1024 Mb:
IOKit 02355000-119c5000 [246.4M] rw-/rw- SM=NUL
M_ALLOCATE ? 1540d000-55500000 [ 1.0G] rw-/rwx SM=ZER

So, at my machine these are loaded at the same address every time, and IOKit loaded lower then SheepShaver.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

You said you had a 512 MB graphics card. But the IOKit allocation is only 246.4M.

On my machine vmmap shows three allocations for IOKit: one large one and two smaller ones. The allocations are contiguous and add up to exactly 512 MB.

Do you have any other IOKit allocations in the vmmap?

We don't really know what is going on with IOKit. For all we know, the allocation depends on other factors, such as display resolution.

Or maybe the exact graphics adapter makes a difference. Mine is the build-to-order "NVIDIA GeForce 8800 GS w/ 512MB GDDR3 Memory". (It isn't really an 8800 GS, that is just what Apple called it.)
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Ronald P. Regensburg wrote:This build uses the software cursor only, which makes cursor movements less smooth and which slows down the emulator slightly. The, so far, best compromise, with hardware cursor when possible and software cursor only when needed, can only be built with SDL version 1.2.10.
I (just now) tried SDL 1.2.10, but I get errors building SDL. It is some kind of issue with the Core Audio headers; apparently it doesn't like building under Leopard.

...

Meanwhile, I changed the code so it now checks if it loads the RAM/ROM area too high, rather than just crash. I decided to compare the RAM load address to the kernel data address. If the RAM is too high, the console message is "ERROR: Cannot map usable RAM area. Try to decrease the Mac OS RAM size.".

I uploaded the new version; same file name, same link.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

mschmitt wrote:I (just now) tried SDL 1.2.10, but I get errors building SDL. It is some kind of issue with the Core Audio headers; apparently it doesn't like building under Leopard.
Any reason why your code could not be build or used in Tiger? If you give me access to the source, I can try to build a Tiger/Leopard compatible UB version like I did before. I have identical Tiger installations for both PPC and Intel, both with XCode 2.5 (which provides Tiger/Leopard compatibility) on which I have build with SDL 1.2.10 before.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

After copying the changed files to SheepShaver source, I tried to build SheepShaver on both PPC and Intel in order to make a UB version. I built with SDL 1.2.10 in Tiger (to get the H-S compromise cursor) with XCode 2.5 installed.

Building on both PPC and Intel proceeded as expected, no errors or any other remarkable events.

The PPC version, however, does not run. It crashes as soon as it is launched. In Console:

Code: Select all

SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
Paranoia checks...
[tick_thread] waiting for emul thread to initialize
[emul_thread] waiting for tick thread to initialize
[emul_thread] filling in registers and waiting for interrupt
[tick_thread] trigger interrupt
SIGUSR2 caught
...passed
Reading ROM file...
SIGSEGV
   pc 25c162d8     lr 25c10214    ctr 25c10000    msr 0000d930
  xer 00000004     cr 82004424  
   r0 00000000     r1 68ffe000     r2 54485244     r3 40b0d000
   r4 68fff000     r5 00000001     r6 00000000     r7 25c162b8
   r8 00000000     r9 00000000    r10 78100000    r11 a00065d0
  r12 25c10214    r13 dead0000    r14 00100000    r15 00100000
  r16 78100000    r17 780fad48    r18 78100000    r19 78100000
  r20 78100000    r21 78100000    r22 78100000    r23 78100000
  r24 78100000    r25 78100000    r26 78100000    r27 78100000
  r28 001db092    r29 780fe754    r30 00000008    r31 00000000
Jul  7 18:05:04 MacKanjer3 crashdump[27025]: SheepShaver crashed
Jul  7 18:05:08 MacKanjer3 crashdump[27025]: crash report written to: /Users/ronald/Library/Logs/CrashReporter/SheepShaver.crash.log

The Intel version seems to run fine in both Tiger and Leopard, in both using the intended H-S compromise cursor.

Console in Tiger:

Code: Select all

SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
Console in Leopard:

Code: Select all

07-07-09 21:18:03 SheepShaver[296] Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz. 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] Reading ROM file... 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] Detected CPU features: MMX SSE SSE2 SSE3 SSSE3 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] PowerPC CPU emulator by Gwenole Beauchesne 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] WARNING: Unknown DiskStatus(6) 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] WARNING: Unknown DiskStatus(6) 
07-07-09 21:18:59 [0x0-0x2e02e].SheepShaver[296] WARNING: Unknown DiskStatus(6) 
If anyone wants to try this build, it is here: http://www.xs4all.nl/~ronaldpr/sheepsha ... 090707.zip
I edited the version number to be "2.3 (090707)" to discern it from all the other 2.3 version builds.

Edit: The above link did not like brackets in the file name. I corrected that.
Last edited by Ronald P. Regensburg on Tue Jul 07, 2009 9:30 pm, edited 5 times in total.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Ronald P. Regensburg wrote: The PPC version, however, does not run. It crashes as soon as it is launched.
...
OK, I need to do some testing on PPC.

I ran into similar symptoms when I first tried it with Intel. First problem was that the ROM has to be higher than the RAM or it gets a SIGSEGV or other crash. But after that fix, it still crashed. That's when I figured out that it wants the ROM to be aligned on a 1 MB boundary.

The test will be first to get it to use the code it has now, but coerce it to load at exactly the same address as before. If that works, it means the changes work, but it is picky about the load addresses.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

Does anyone know what the trick is to active the d(bug) lines in the code?


Or how to debug it with the Xcode GUI debugger? I couldn't get that to work; no matter what I tried, it would never stop in in the code.

I've been debugging using command line gdb, which is not very user friendly.
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

mschmitt wrote:Does anyone know what the trick is to active the d(bug) lines in the code?
Change "#define DEBUG 0" to "#define DEBUG 1" in the source file of interest.
mschmitt
Tinkerer
Posts: 80
Joined: Sun Jul 05, 2009 10:33 pm

Post by mschmitt »

When I run the version I built (built on Intel Leopard, SDL 1.2.13), running on OS X 10.5.7 Intel, on a machine with 3.06 GHz Core 2 Duo & 4 GB RAM,

SheepShaver uses about 12.3% of one CPU at idle. If I swirl the cursor around it goes up another 2% or so.

(I assume we know it is the software cursor because it gets "pinned" against the side of the window when the mouse is moved away.)


When I run the version Ronald built from my code, on the same machine, it draws 43% of one cpu at idle. (Rapidly moving the cursor has no effect.)

Is this normal?
Last edited by mschmitt on Wed Jul 08, 2009 12:18 pm, edited 1 time in total.
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

The biggest factor affecting SheepShaver CPU usage is the choice of video refresh strategy; for example, vosf vs. non-vosf.
Post Reply