Login  •  Register


The time is now: Thu Apr 24, 2014 11:20 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 4 [ 99 posts ]    Go to page 1, 2, 3, 4  Next
Print view Previous topic  |  Next topic
Author Message
PostPosted: Sun Jul 05, 2009 10:40 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Sun Jul 05, 2009 10:51 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3322
Location: Sittard, The Netherlands
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


Top
 Profile  
Post a reply  
PostPosted: Sun Jul 05, 2009 11:07 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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:
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:
lipo -create SheepShaver-intel SheepShaver-ppc -output SheepShaver


Checked the resulting file with:
Code:
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.


Top
 Profile  
Post a reply  
PostPosted: Sun Jul 05, 2009 11:59 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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:
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 10:35 am 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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.)


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 10:38 am 
Offline
Mac Mechanic

Joined: Fri Oct 26, 2007 7:56 am
Posts: 167
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 12:32 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 12:35 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
mschmitt wrote:
There was no message preceding the "Referenced from" line, in the system log?

Nothing related to launching SheepShaver.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 12:44 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 1:27 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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/


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 2:03 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
I recompiled with:
Code:
./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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 4:56 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3322
Location: Sittard, The Netherlands
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


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 5:15 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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?


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 5:21 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 5:47 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 6:19 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 3322
Location: Sittard, The Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Mon Jul 06, 2009 7:01 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.)


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 2:03 am 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 11:55 am 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 8:17 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 3931
Location: Amsterdam, Netherlands
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:
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:
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:
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 8:34 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 8:39 pm 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Tue Jul 07, 2009 8:43 pm 
Offline
Tinkerer

Joined: Sat Apr 12, 2008 8:22 pm
Posts: 77
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Wed Jul 08, 2009 1:08 am 
Offline
Tinkerer

Joined: Sun Jul 05, 2009 10:33 pm
Posts: 72
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.


Top
 Profile  
Post a reply  
 Post subject:
PostPosted: Wed Jul 08, 2009 1:35 am 
Offline
Tinkerer

Joined: Sat Apr 12, 2008 8:22 pm
Posts: 77
The biggest factor affecting SheepShaver CPU usage is the choice of video refresh strategy; for example, vosf vs. non-vosf.


Top
 Profile  
Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 4 [ 99 posts ]    Go to page 1, 2, 3, 4  Next


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group