I haven't used SheepShaverGUI for a very long time and I have not started SheepShaver from the GUI in years. I edit the prefs file directly in a text editor or use the built in preferences in the latest SheepShaver builds or the stand alone SheepShaverPrefs preferences editor.
When I try SheepShaverGUI, it gives a similar output in Console on my Mac. And I cannot start SheepShaver from the GUI ("Cannot open ROM file"), probably because the GUI wants full paths. But the problem we discuss here is related to SheepShaver, not to the GUI.
Or could it be? Did you set up SheepShaver with the GUI application? And which SheepShaver build do you use? If the version number is just 2.3, please tell the build date and/or from where you downloaded it. (All builds since May 2006 are version 2.3.)
19/05/09 09:47:51 /SheepShaver/SheepShaver.app/Contents/MacOS/SheepShaver[2703] CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
19/05/09 09:47:51 /SheepShaver/SheepShaver.app/Contents/MacOS/SheepShaver[2703] CPSSetForegroundOperationState(): This call is deprecated and should not be called anymore.
19/05/09 09:47:51 [0x0-0x1d41d4].SheepShaver[2703] SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
19/05/09 09:47:51 [0x0-0x1d41d4].SheepShaver[2703] ERROR: Cannot map RAM: File exists.
19/05/09 09:48:13 /SheepShaver/SheepShaver.app/Contents/MacOS/SheepShaver[2704] CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
this is when i launch the executable out from the app package:
19/05/09 09:48:13 [0x0-0x1d51d5].SheepShaver[2704] ERROR: Cannot map RAM: File exists.
19/05/09 09:48:59 login[2709] USER_PROCESS: 2709 ttys000
19/05/09 09:49:00 /SheepShaver/SheepShaver[2721] CPSGetCurrentProcess(): This call is deprecated and should not be called anymore.
19/05/09 09:49:00 /SheepShaver/SheepShaver[2721] CPSSetForegroundOperationState(): This call is deprecated and should not be called anymore.
19/05/09 09:49:00 login[2709] DEAD_PROCESS: 2709 ttys000
The May 2006 version has many problems (even issues that can cause files to disappear). Gwenole Beauchesne has since suspended development of SheepShaver and BasiliskII. In the past three years, improvements have been added to cvs by different developers and most serious issues have been solved. There are no new "official" releases, but one can build from cvs to include the added improvements.
I am afraid that we will not find a solution until someone discovers the cause of the problem. The problem apparently only affects some Intel machines with Leopard. If the problem would be more widespread, there would not be only a few reports of this problem and so many threads about other issues with SheepShaver. Why (re-)installing the latest 10.5.x combo updater solves the problem in many cases is just as much a mystery as the problem itself.
I wished that someone with a more intimate knowledge and understanding of the source code would try and find when the error "Cannot map RAM: File exist" occurs. That could possibly help.
BTW: The messages about depreciated calls are not a problem for running the application. It is simply is a warning to the developer that Apple could (and probably will) remove them in a future version of OSX.
In the standard download and installation, i opened the package of the SheepShaver.app and replaced the old executable (into Contents => MacOS) with my compiled new one.
Then i can use GUI for setting and launching SheepShaver (launching the app directly doesn't work).
It opens in X11
If you can, suggest a place where to post the ready-to-use SheepShaver.app compiled by me, hopefully solving once and for all the cannot map ram problem for all who can't in any other way.
Just being a bare Unix executable and not a OSX application package, it will run in X11.
i set 512mb memory, emulating a powerpc 9600, monitor at 1024x768 60hz windowed.
1024mb ram doesn't work (who cares? ehe)
Oops!
SheepShaver will not run with RAM set to more than 512MB. If I set it to 1024MB, I will get the "Cannot map RAM: File exists" error in Console. Did you have RAM set at 1024MB? Does the latest SheepShaver build posted in this forum run on your machine with RAM set to 512MB?
i made the build using your instructions given before.
as you stated, the app crashed on launch. but...
i put the executable into the old (official) app, replacing the old one, and that is, working using the old official GUI.
ERROR: Cannot map RAM: Unknown error: 0.
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 105 (X_ChangePointerControl)
Value in failed request: 0x0
Serial number of failed request: 9
Current serial number in output stream: 10
logout
with 512mb, no problem
No other builds, using any kind of suggestions (updates, combos, ram, users, ACLs, and many more) from this or other forums, solved the deadly cannot map ram error.
I think only local build with latest dev tools can make ss working on these intel-leopard machines
Last edited by vincifr on Wed May 20, 2009 10:13 am, edited 1 time in total.
What I asked: Did you try the existing bulds with RAM set to a higher value than 512MB? That would be enough to explain the "Cannot map RAM: File exists" error. If you did that, I wonder if the existing latest builds will work on your machine with RAM set to 512MB.
No other builds, using any kind of suggestions (updates, combos, ram, users, ACLs, and many more) from this or other forums, solved the deadly cannot map ram error.
i made all kind of tries, ram to 1, 2 , 8 , 16, etc, tried a wide lot of ROMs, i assure i read this and other forums many times and tried all suggestions.
I think only local build with latest dev tools can make ss working on these intel-leopard machines
(i think this build from me should work for others with intel-leopard too)
Did you try to use the existing builds with a setting for RAM more than 512MB? If so, that is probably the explanation for the "Cannot map RAM: File exists" error in your case and setting the RAM to 512MB would have been the simple solution with no need to build yourself.
Edit: O, I see now, you did try different settings for RAM. Well...
Last edited by Ronald P. Regensburg on Wed May 20, 2009 10:29 am, edited 1 time in total.
BTW: I myself run SheepShaver fine on Intel and Leopard and so do most other users running SheepShaver on Intel and Leopard. There must be something special with the machines that have a persisting "Cannot map RAM" problem.
the last three months i tested all builds found of sheepshaver (from older to newer, yours)
i tested thees builds with a lot of combination of: ROMs, RAM (from 1 to 1024), Ethernet on or off, sound on or off, Java on or off.
i tested sheepshaver in home directory, in other directories, in external drives.
i applied all the updates of macos, i applied the combo, i tried to downgrade to older 10.5, i tried to reformat and reinstall macos
i tried to temper with permission, opened everything to everyone
i think i tested all that could be tested
the aswer was always: cannot map ram
thanks to your instrucions, i was finally able to make a build myself. on intel, leopard 10.5.7
i needed xcode tools (latest) or that was not possible (the command cvs not present)
this build did not started (crash on launch, as you stated).
but i remembered that old ss app did not started too this way.
i should use the GUI.
so i replacede the new build executable into old package.
vincifr wrote:this build did not started (crash on launch, as you stated).
but i remembered that old ss app did not started too this way.
i should use the GUI.
What do you mean with "GUI". You mean the SheepShaverGUI application? Why is that?
so i replacede the new build executable into old package.
that works
Which package did you use? The content of the packages differs between different builds.
i made a build following your instructions using SDL 1.2.13,
the cannot map ram: file exists (or the variant "no such file or directory") is
BACK AGAIN
then i made the build (argh!) once again using SDL 1.2.10,
and SS works (as i said before, using the SS GUI app, runs in X11)
i think we discovered that the bug is in SDL, no?
i could test 1.2.11 , 12 .... mah!
Last edited by vincifr on Wed May 20, 2009 4:58 pm, edited 1 time in total.
Could very well be. A problem is that there is not yet a runtime option available in the source to choose and build either a Software cursor version or a Hardware cursor version. They are linked to specific SDL versions. With SDL 1.2.10 the hardware cursor version is build, a hardware cursor version that will temporarily switch to software cursor mode if the asked for cursor cannot be provided by the hardware cursor.
It is a solution for cursor problems in earlier versions, where in SheepShaver the cursor would be displayed a few pixels displaced and in some cases would not be displayed properly at all. With, if I remember correctly, SDL 1.2.12 a full software cursor version would be build, also solving the cursor problems but with the cursor moving jerkily on slower machines.
Reading back what you did, I am not sure I understand correctly when you talk about "package" and "executable". The package is the SheepShaver.app application that is shown in the Finder with a SheepShaver icon. The "executable" is the file inside the SheepShaver application: SheepShaver.app/Contents/MacOS/SheepShaver that is shown with a black rectangular icon.
That is what you are talking about? And the application does not launch but the executable taken from the application does? And do I understand correctly that it runs in X11? If you launch the executable directly, I would expect a Terminal window to open.
Ronald P. Regensburg wrote:Reading back what you did, I am not sure I understand correctly when you talk about "package" and "executable". The package is the SheepShaver.app application that is shown in the Finder with a SheepShaver icon. The "executable" is the file inside the SheepShaver application: SheepShaver.app/Contents/MacOS/SheepShaver that is shown with a black rectangular icon.
That is what you are talking about? And the application does not launch but the executable taken from the application does? And do I understand correctly that it runs in X11? If you launch the executable directly, I would expect a Terminal window to open.
Yes, it is what you wrote.
the executable drawn outside the .app package starts opening X11:
first the terminal, then X11 automatically.
the package (.app) doesn't start directly. strange
if i use the old SS GUI app, that is able to let the SS.app package (build as you said) to work, using the "start" button in the SS GUI window.
