Edit July 10, 2009 by Ronald P. Regensburg:

Experimental builds (Intel only!) of SheepShaver are available that will probably run fine on your system if you encounter this issue trying to use one of the other SheepShaver builds.

Extensive discussion of the problem and solutions, as well as the new builds can be found in this thread:
http://www.emaculation.com/forum/viewtopic.php?t=5722



Orinal post starts here:

In this post, I describe how to fix the error, "Cannot map RAM: File already exists." Some people encountered this error running SheepShaver on Leopard.

It is caused when you migrate from Tiger to Leopard and the User Account has the group "Unknown." This is a known bug (Apple's fault) in OS X 10.5.

To fix this problem (it will make SheepShaver run perfectly) do the following steps as described in this Apple tech support document:
http://support.apple.com/kb/TA25100?viewlocale=en_US

Solution

1. Log in as an administrator.
2. Open Terminal (in /Applications/Utilities).
3. Type the following commands, each on a single line and followed by Return (enter an admin password when prompted):


sudo dscl . create /Groups/username GroupMembership username

sudo dscl . change /Groups/username RecordName username _username


Replace the italicized "username" with your account username (which is also the name of the user's Home folder, in the Users folder). Remember to include the underscore "_" before your user name in the second command.

If you have more than one account on the computer affected by this issue, you should run these two commands again for each account, substituting with the appropriate user name each time.


Pwnage.

-=DG=-

Thank you for pointing to the Leopard "Unknown" group issue as the cause for this "Cannot map RAM: File already exists" error. This is important information.

Interesting that Apple's advice in fact recreates the Tiger group permissions with a group "username" for each user. Tiger was in that respect an exception and Leopard returns to users being in group "staff".

(Edit: The MacOSX versions that used the single user groups were Panther and Tiger. Before that users were in group staff and in Leopard again users are in group staff.)

Being aware of this permissions issue with migration from Tiger to Leopard, the first thing I did after migrating from Tiger was to make sure I (the user) was in group staff and my Home folder and its contents belonged to group "staff". (See commands below.)

Probably because I did this, I never had the "Cannot map RAM" error on my iMac.

Several forum members reported solution of this error problem after applying a 10.5.x Combo update. Could such a Combo update also correct this permissions issue?


What I did after migrating from Tiger to Leopard:


showed I was not in group staff.


added me to group staff.


changed group ownership on all files in home to staff.


repaired disk permissions.

Finally I rebooted.

Source was this hint and discussion on MacOSXhints:
http://www.macosxhints.com/article.php? ... 1291134001

THNKS DG! - that fixed my problem where installing the combo update did not!


SWEET - I've got my OS 9 on my new MBP.....

THANKS again for taking the time to post.

These (and simple variants) still don't work for me, but yes, it's odd as I have a PB 17" G4 1.67 that was going to be my bang-on-this-and-figure-it out, and it worked first time. On the other hand, the G5 has never worked (both in Leopard). Anyway, There was was a mention of the latest CVS snapshot; where is that? I went the one on cebix, and it didn't show anything newer than a few years ago that I could see, so I was wondering there the source came from for the 7/2008 update? Thanks.-kby

Hi,

The source still comes from that very site, but the developer doesn't add to it anymore. Some others have contributed code that solved some problems. You can only benefit from it if you build the application from source yourself, or use use the builds we provide on this forum.

To look at the source and the dates the files we altered, just point at:
http://www.cebix.net/viewcvs/cebix/SheepShaver/

Cat_7

Thanks; I did download the source. However, the closest instructions on the site build a nice Un*x binary that runs under X11.

The good news is that for me doesn't have the "Cannot map RAM: File exists"
error, and, in fact, runs fine under X11.

However, I can't seem t o find any instructions on getting the more self-contained OS X SheepShaver.app that is stand-alone. I tried just replacing the binary within the package (SheepShaver.app/Contents/MacOS/SheepShaver), but that doesn't run either. Incidentally, with the "new" packages (7/2008 build), I don't even see the "Cannot map RAM" error; assuming the program doesn't get an illegal reference, it just quits. I can only see the "Cannot map RAM" by executing the binary within the package from a Terminal or xterm window.

Also, under the "default" config settings from autoconf (using the Un*x recommended instructions) what kind of cursor is built? ./configure --help
doesn't list a configuration option for software/hardware cursor.

Incidentally, running under X11 is a lot better than "Cannot map RAM" but has some issues. Minor: it only seems to work with explicit video sizes. Less minor: command maps to meta in X11 or is trapped by X11 itself. Tried to use Roland's keycodes file, but it complains about no MacX vector...may try to hack around this.

Thanks in advance...-kby

Hi, have you seen this?
http://gwenole.beauchesne.info/en/proje ... /compiling

First go to the SheepShaver folder and issue
"make links"

The current SheepShaver source for OSX builds from the Unix folder with:

NO_CONFIGURE=1 ./autogen.sh
./configure --disable-standalone-gui --enable-vosf --enable-sdl-video
--disable-sdl-audio --enable-addressing=real --without-esd --without-gtk
--without-mon --without-x --enable-jit
make
make SheepShaver_app

I don't know which option builds the hw or sw cursor version.

Best,
Cat_7

The hardware and software cursor versions are build with different SDL versions.

The hardware cursor version:



For the software cursor version use SDL release-1.2.13 instead of release-1.2.10.

Thanks for the help; I had not managed to find the instructions.

The bad news is it appears that using SDL is related to the various "cannot map RAM" errors. I'll have to look further to figure out what is really happening.

Incidentally, Fink currently installs SDL version 1.2.12, as opposed t o the 1.2.10 you mentioned. The current latest stable is 1.2.13 (.12 or .13 don't seem to make a difference for the problems).

There seems to be call to basilik's vm_acquire_fixed routine that are called with the the ramsize argument (there are a number of smaller calls earlier). The second one fails.

Unforuntately the X version not using SDL doesn't run with gdb so I can't compare yet.-kby

I think the subcode ("file exists", "operation timed out", etc.) is bogus. The primary message ("cannot map ram") is correct, although I don't know why. It appears that vm_allocate is called first to allocate a block at "0" of size ramsize; then a second time to allocate a block at ramsize for another ramsize chunk. I don't know why it's asking for the second, but that one is failing. There are only a couple of bad returns from vm_allocate, KERN_NO_SPACE and KERN_ADDRESS_INUSE (or something like that). I think the code it's really getting is KERN_NO_SPACE. Inspecting the registers on return from vm_allocate shows r0=-1 and r3=3; it looks from the disassembly of the code that the return code should really be in r0, but I might be remembering the conventions wrong, and 3 is KERN_NO_SPACE. But I don't know why it should get that.

As far as the unknown group and such, there are some shared memory segments that have ownership also along uid/gid lines, so that may have been in play for those people that fixing the unknown gid seemed to help; just a guess.-kby

Hi,

When I investigated the issue I came up with SDL no being able to map ram twice to the same space. That looks about right from what limited understanding I have of what you wrote. Somewhere there is call to allocated memory twice, thus leading to that error... But not for everyone.

Best wishes, and most of all: success with solving this!

Cat_7

That's what makes this problem so strange. Judging by the posts in these forums, the problem hits only a minority of Leopard on Intel users. Some could solve the problem by (re)installing the latest 10.5.x combo-updater.

It's not only on intel; I'm on ppc (G5).

The vm_allocate call is actually not for exactly the same place. In my case, with ramsize=512MB it allocates 512MB at 0 and then tries to allocate another 512MB at 512MB (and no, making the numbers smaller doesn't help).-kby

I have a pretty good idea of why it's failing, but I have no idea how to fix it at this point (don't know enough internals about a lot of things).

I am not sure why the first call to vm_allocate for RAMsize succeeds (although maybe it doesn't but no one cares), as the region from 0-512MB is already
in use by the time that call is made; but it is in very many pieces. It could also be a thread ownership or something like that, but I'm just grabbing at straws.

However, the second call for RAMsize at 512MB (RAMsize is 512MB) seems to fail because of a large IOKit memory region that overlaps it. The size of this region appears to be variable. On the machine I have where SheepShaver works (a PB 17" HiRes), IOKit is 128MB and given its location doesn't overlap 512MB. On my G5, the IOKit region is 512MB. For the SheepShaver that runs under X11, IOKit is 20k!

I found this post about IOKit memory:


(The original post is here: http://lists.apple.com/archives/darwin-dev/2009/Jan/msg00138.html

(Note that it has nothing to do with SheepShaver directly).

So, this might be dependent on video card, screen size, and other rather difficult to control things.

Seems like the "Correct" thing would be to get SheepShaver to not request memory at a specific address. Not sure if this would work, though, without a lot of work (getting it to not request it is probably easy; making sure it works probably less easy if one doesn't know the code fairly intimately).-kby

I did verify that changing the RAM_base address AND in my case the ram size can get things to work better. But I also found out it's even more complicated than I'd hoped in that on the machine the works not only is IOKit in particular smaller, it's much higher in memory, far higher than 512MB ram extends. But there are other things in between, and this is also probably the reason 1024MB (or actually it caps things internally at 1023MB for other reasons) never works; there's just too much stuff scattered around.

There also seems to be a dependency that ROM is at a higher address than RAM and this is probably dependent on the particular ROM file in use. I normally use a 9500 clone ROM and have never gotten the New World rom rom ROM Update 1 to work, probably because of this difference and address layout differences.-kby

Funny thing is this error was only relatively recently introduced. The original build from the developers website doesn't exhibit this behaviour. And some of the build we cooked up are also unaffected.
And for some users on windows they have to set memory higher than 512, while on OSX users can't set memory above 512.

Best,
Cat_7

By the code, you should be able to get 1023MB real RAM. But, as this is an address layout-sensitive issue, it will be very hard to predict when it will or won't hit you. Hardware (including platform) will affect it *a lot*. The big user of IOKit being 512MB, and the ROM having to be located at a specific area tend to make this really problematic. It's not an issue with IOKit per se, just that it's a *really big* player when it's that large. Remember when I mentioned that IOKit is a lot smaller running under X because a lot of the video stuff is handled by the X server. So, although it can still be a problem depending on where it's located, you're a lot less likely to trip over it when it's 20k rather than 512MB. This particular block is OSX specific so would not be present in Wintel or Linux (which presumably would run under X).

Running under X wouldn't be so bad if I could get the keycode map to work, otherwise there is no command key.-kby

Hello everyone -

I'm trying to get Sheepshaver to work on my PPC G5 on Mac OS X 10.5.6, and try as I might, I can't seem to get it started...

If I double-click on the app, it bounces once i the dock, and disappears without any warning, or error message.

If I launch via the sheepshaver GUI, I get the infamous 'cannot Map RAM File Exists' error.

Any help would be appreciated.

If you search these forums, you will find several threads about this problem. The cause is still not understood and so far it has been reported only on a minority of Leopard machines. Some solved the problem by (re-)installing the latest 10.5.x Combo-update.

Thank you for your reply!

I neglected to mention that I applied the fix mentioned at the beginning of this thread, and although it fixed some other permission problems I was having, it didn't fix my SheepShaver problem

I do have the latest SDL installed (I run SDLMAME), and I am currently downloading the 10.5.6 combo updater.

I'll let you know the result as soon as I finish running the updater, and I look forward to adding SheepShaver to my emulator collection!

Success!

For whatever reason, reinstalling the 10.5.6 Combo updater did the trick!

I can now at least get to the "?"

On to locating one of my 9.0.x CDs...

Thanks again!

I'm one of the unfortuntates who has always had this problem on my MacPro, which came with Leopard pre-installed. (No upgrade from Tiger, although i did use the migration tool to migrate my settings from the old computer that was running Tiger.)

I tried all the suggestions on this thread, but it still fails with the same error. I mention this only to let everyone know the fix above is not 100% definitive.

I'm also having this problem. I'm on a 2009 iMac. I tried the solution in the first post to no avail. I'm now onto updating from the combo installer and will let you know <G>.

Hi I have just done the code for my IMAC 10.5.6

in my terminal

and it says the following

Last login: Thu Apr 23 03:47:51 on ttys000
jason-greys-imac:~ jasongrey$ sudo dscl. create/Groups/jasongrey/
sudo: dscl.: command not found
jason-greys-imac:~ jasongrey$ sudo dscl.create/Groups/jasongrey/GroupMembership/jasongrey"_"sudo dscl.change/Groups/jasongrey RecordName jasongrey_jasongrey
sudo: dscl.create/Groups/jasongrey/GroupMembership/jasongrey_sudo: command not found
jason-greys-imac:~ jasongrey$




I am wondering if any one can Re Create it for me using my name in the replace of it and i am the main administrator logged into my IMAC,

This didn't Migrate from Tiger it was Leoapard when I bought it new a year ago, SO i am wondering if anyone can help me.

Thnxs

Jason Grey

First of all: When you did not migrate from an earlier version of MacOSX you do not need and should not use this correction of a permissions issue with 10.5.x that exists only after migrating from Tiger or Panther!!!

Secondly: You did not correctly type the command (omitted spaces), but you should be glad you did that, so you did not spoil permissions on your system.

If you have the "Cannot map RAM: File already exists" problem on a system that was Leopard from the start, you should try the other possible solutions:

1. Download and (re-)install the latest 10.5.x Combo updater. The 10.5.7 update is expected to be released soon. You can then use the full combo-updater instead of the update through Software Update.

2. Recently, someone reported in another thread that the problem also occurs with he RAM memory for SheepShaver set higher than 512MB. Make sure it is set at 512MB or less.