Yes,

Thanks, hopefully some Intel mac users will have less problems now.

I did manage to build one myself after installing the latest Xcode.
Download the source code of both BasiliskII and SheepShaver in a folder, go to SheepShaver
open a terminal window, go to the SheepShaver folder
execute "make links"
go to SheepShaver/src/Unix
execute "NO_CONFIGURE=1 ACLOCAL_FLAGS="-I m4" ./autogen.sh"
execute "./configure"
execute "make"

The resulting SheepShaver (black terminal icon) will run in X. If you then replace the executable in SheepShaver.app/Contents/MacOS and start it from SheepShaverGUI it will run in X.

Could you please confirm this is what you did? Thanks again for your effort!

Cat_7

It is very near to that you wrote;

i downloaded and installed latest xcode;
then i build sheepshaver following instruction, from Ronald P. Regensburg in this forum (Posted: Fri May 15, 2009 9:48 am)

i have a sheepshaver.app that doesn't directly start

the executable inside starts, first terminal, then X11

the sheepshaver.app can start, but using the sheepshaver GUI app, provided in official release from gwenole beauchesne; it starts in X11

it works, just a strange color behaviour (yellow)

(sorry for my poor english)

Hi,

I have no strange colour behaviour in my build. It also starts directly by double-clicking it. Maybe you can give it a try?

http://www.open.ou.nl/hsp/downloads/SheepShaver.zip

It does, however, not solve the issue we have when using more then 512Mb of memory.

Best,
Cat_7

Thank you, i will try your build later, at work (macpro).
(at home, in my macmini intel leopard, SS always worked with no problems)

I notice your file is a Unix executable, is it?

My build is a .app package; the .app doesn't starts directly, as i said.

The executable inside starts double clicking (first terminal, then X11).

Did you try my build? Do you have the strange colors issue with it?

Hi,

I'm now looking in astonishment at the beautiful colours your build provides.
So, Yes, yellow colour bias.

You can put my build in the sheepshaver.app/Contents/MacOS folder and it will start from the GUI as well.

Best,
Cat_7

Hehe...

after months of anger and cannot map ram,
yellow is the real very most best good beautiful color!

i hope your build will work!

really can't say why my build is yellow! mah!
a SDL problem? a X11 problem?

If you can, just in case your build should present the cannot map ram issue in my mac, could you provide a list of terminal commands to compile myself SS, if different from the one i used from Ronald P. Regensburg?

The description Cat_7 posted above translated into commands only:



The resulting executable will be created in: SheepShaverBuild/SheepShaver/src/Unix

Good News!

The Cat_7 build works, with correct colors!

This build runs as mine:
it opens in X11;

the executable, double clicking (terminal, then x11)

put inside .app package, it starts only using the SS GUI app

...

i am no expert, i only develop in realbasic (!), but i wonder if SDL has a role in this cannot map ram issue, more than xcode (?)
i tried a build with sdl 1.2.13 : cannot map ram
i tried a build with sdl 1.2.10 : ok
i tried a build with sdl 1.2.12 : ok
Does Cat_7 build include sdl? which?
i also wonder why my build has this color behaviour

Cat_7, does your build works in X11 only, too?

Yes,

my build only runs in X11 and includes no SDL. The newer Xcode only helps to be able to build an X executable, not against the 512Mb limit. However, some pages back in this thread an analysis of the problem was given. It comes down to allocating memory twice, and the size in memory of a framework that is not used when you run an X application. So my guess is that some users don't even have enough memory free (at the right place) to start the most elemental SheepShaver (with e.g., 64 Mb ram assigned) while all others run into the 512 Mb limit (which is caused by our SDL implementation)


If you compile with:

"./configure --enable-sdl-static --enable-sdl-audio --enable-sdl-video --disable-vosf"

then you get a build that uses SDL. (you need to have an SDL framework installed somewhere (1.2.10 or 1.2.13)

I wonder what is better, to use or not to use SDL...

what is affected by this choice? speed? graphics?

anyway, i think now all users gone crazy with "cannot map ram" issue,
could finally use SheepShaver (with X11). thanks again.

For building a MacOSX application, SDL 1.2.10 or SDL 1.2.12 is needed to make use of the corrected cursor behavior. Best average cursor performance (especially on slower host machines) will provide building with SDL 1.2.10.

I do not know what other benefits there could be. For my last (March 2009) build I omitted --enable-sdl-audio (disabled by default), because that appeared to result in better sound performance, at least on my Macs.

Cat_7 & RPR, thank you both very much for all your work on this.

I've been fighting with SS +10.5 + Intel for the last 9 months or so, all fruitlessly, despite trying dozens of RAM files, prefs settings, combo updates and app package tricks.

This X11-based solution has finally allowed me to leave the various dreaded "Cannot Map RAM" errors behind!

Cheers!

Why don't you change the values of "RAM_BASE" in src/Unix/main_unix.cpp and "ROM_BASE" in src/include/cpu_emulation.h?

In my case, SS on standalone intel iMacs and net-booted macs with Leopard 10.5.7 did not work due to Error "Cannot map RAM: File exists", although it works well on my standalone MacBook Pros. X11 solutions suggested by Cat_7 certainly solved this problem on my standalone iMac, but did not solved on net-boot clients (I got the same error; Cannot map RAM).

Error "Cannot map RAM" is certainly invoked by the fail of static vm_allocate() in src/Unix/vm_alloc.cpp when SS tries to allocate OS9's RAM (or ROM) on the OSX's virtual memory. In my case vm_mac_acquire(RAM_BASE, RAMSize) in src/Unix/main_unix.cpp that calls vm_allocate() returned error "KERN_NO_SPACE", which means that the specified RAM_BASE address has already been occupied by somebody (perhaps SDL or net-boot related programs, in my case).

So I changed the "RAM_BASE" from 0x20000000 (original) to 0x50000000 (because in my case, 0x20000000-0x40000000 were used by somebody). Since "ROM_BASE" must be larger than "RAM_BASE", I also changed "ROM_BASE" from 0x40800000 (original) to 0x70800000. Then it worked perfectly on my standalone intel iMac and net-boot clients with SDL 1.2.13.

Note that, with the BASE addresses above, the maximum memory size for OS9 is limited to 128MB (enough for me), so if you wanna try this, do not forget to reduce the RAM size to 128MB in the SS prefs editor. Further hacking may solve this limitation, I believe.

Cheers, Tenya

See extensive discussion of cause and solutions, as well as builds that solve the problem without the RAM size limitation, in this thread:
http://www.emaculation.com/forum/viewtopic.php?t=5722