Problem building SheepShaver on OSX 10.6.4
Moderators: Cat_7, Ronald P. Regensburg, ClockWise
Problem building SheepShaver on OSX 10.6.4
Hi,
I started a new topic on this issue to regain some attention to the problem.
When building SheepShaver with or without SDL(1.2.14) support on OS X 10.6.4, building succeeds, but when I run the build, I get:
Using SDL/coreaudio audio output
### No appropriate blitter found
R/G/B mask values : 0x00ff00, 0xff0000, 0xff000000 (depth = 32)
R/G/B shift values : 8/16/24
Abort trap
The crash report is below.
Might it have something to do with the video support as reported here:
http://www.emaculation.com/forum/viewto ... 1804#31804
/*
To make SheepShaver work with this version of SDL, I added one more Screen_blit_func_info to the Screen_blitters table in video_blit.cpp to deal with the new BGRA pixel format used:
Code:
{ 32, 0xff00, 0xff0000, 0xff000000, Blit_Copy_Raw , Blit_Copy_Raw } // OK
*/
Even when adding that code line to video_blit.cpp, it doesn't work.
Does anyone care to take this up?
Cat_7
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff826a43d6 __kill + 10
1 libSystem.B.dylib 0x00007fff82744972 abort + 83
2 SheepShaver 0x000000007806d71d Screen_blitter_init(VisualFormat const&, bool, int) + 397 (video_blit.cpp:575)
3 SheepShaver 0x000000007807b758 driver_window::driver_window(SDL_monitor_desc&) + 328 (video_sdl.cpp:821)
4 SheepShaver 0x000000007807b8e7 SDL_monitor_desc::video_open() + 247 (video_sdl.cpp:1074)
5 SheepShaver 0x000000007807c107 VideoInit() + 1031 (video_sdl.cpp:1303)
6 SheepShaver 0x0000000078055e4c InitAll(char const*) + 492 (main.cpp:157)
7 SheepShaver 0x0000000078057651 SDL_main + 2369 (main_unix.cpp:957)
8 SheepShaver 0x00000000780bf2c0 -[SDLMain applicationDidFinishLaunching:] + 48
9 com.apple.Foundation 0x00007fff805e084e _nsnote_callback + 167
10 com.apple.CoreFoundation 0x00007fff88e42a90 __CFXNotificationPost + 1008
11 com.apple.CoreFoundation 0x00007fff88e2f008 _CFXNotificationPostNotification + 200
12 com.apple.Foundation 0x00007fff805d77b8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 101
13 com.apple.AppKit 0x00007fff87a19832 -[NSApplication _postDidFinishNotification] + 100
14 com.apple.AppKit 0x00007fff87a19767 -[NSApplication _sendFinishLaunchingNotification] + 66
15 com.apple.AppKit 0x00007fff87ae4719 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 219
16 com.apple.AppKit 0x00007fff87ae4395 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 77
17 com.apple.Foundation 0x00007fff8060f14a -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 360
18 com.apple.Foundation 0x00007fff8060ef7a _NSAppleEventManagerGenericHandler + 114
19 com.apple.AE 0x00007fff868d1323 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 162
20 com.apple.AE 0x00007fff868d121c dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 32
21 com.apple.AE 0x00007fff868d1123 aeProcessAppleEvent + 210
22 com.apple.HIToolbox 0x00007fff83351741 AEProcessAppleEvent + 48
23 com.apple.AppKit 0x00007fff879e9481 _DPSNextEvent + 1191
24 com.apple.AppKit 0x00007fff879e8bed -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
25 com.apple.AppKit 0x00007fff879ae8d3 -[NSApplication run] + 395
26 SheepShaver 0x00000000780bf913 main + 1299
27 SheepShaver 0x0000000078055be8 start + 52
I started a new topic on this issue to regain some attention to the problem.
When building SheepShaver with or without SDL(1.2.14) support on OS X 10.6.4, building succeeds, but when I run the build, I get:
Using SDL/coreaudio audio output
### No appropriate blitter found
R/G/B mask values : 0x00ff00, 0xff0000, 0xff000000 (depth = 32)
R/G/B shift values : 8/16/24
Abort trap
The crash report is below.
Might it have something to do with the video support as reported here:
http://www.emaculation.com/forum/viewto ... 1804#31804
/*
To make SheepShaver work with this version of SDL, I added one more Screen_blit_func_info to the Screen_blitters table in video_blit.cpp to deal with the new BGRA pixel format used:
Code:
{ 32, 0xff00, 0xff0000, 0xff000000, Blit_Copy_Raw , Blit_Copy_Raw } // OK
*/
Even when adding that code line to video_blit.cpp, it doesn't work.
Does anyone care to take this up?
Cat_7
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff826a43d6 __kill + 10
1 libSystem.B.dylib 0x00007fff82744972 abort + 83
2 SheepShaver 0x000000007806d71d Screen_blitter_init(VisualFormat const&, bool, int) + 397 (video_blit.cpp:575)
3 SheepShaver 0x000000007807b758 driver_window::driver_window(SDL_monitor_desc&) + 328 (video_sdl.cpp:821)
4 SheepShaver 0x000000007807b8e7 SDL_monitor_desc::video_open() + 247 (video_sdl.cpp:1074)
5 SheepShaver 0x000000007807c107 VideoInit() + 1031 (video_sdl.cpp:1303)
6 SheepShaver 0x0000000078055e4c InitAll(char const*) + 492 (main.cpp:157)
7 SheepShaver 0x0000000078057651 SDL_main + 2369 (main_unix.cpp:957)
8 SheepShaver 0x00000000780bf2c0 -[SDLMain applicationDidFinishLaunching:] + 48
9 com.apple.Foundation 0x00007fff805e084e _nsnote_callback + 167
10 com.apple.CoreFoundation 0x00007fff88e42a90 __CFXNotificationPost + 1008
11 com.apple.CoreFoundation 0x00007fff88e2f008 _CFXNotificationPostNotification + 200
12 com.apple.Foundation 0x00007fff805d77b8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 101
13 com.apple.AppKit 0x00007fff87a19832 -[NSApplication _postDidFinishNotification] + 100
14 com.apple.AppKit 0x00007fff87a19767 -[NSApplication _sendFinishLaunchingNotification] + 66
15 com.apple.AppKit 0x00007fff87ae4719 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 219
16 com.apple.AppKit 0x00007fff87ae4395 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 77
17 com.apple.Foundation 0x00007fff8060f14a -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 360
18 com.apple.Foundation 0x00007fff8060ef7a _NSAppleEventManagerGenericHandler + 114
19 com.apple.AE 0x00007fff868d1323 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 162
20 com.apple.AE 0x00007fff868d121c dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 32
21 com.apple.AE 0x00007fff868d1123 aeProcessAppleEvent + 210
22 com.apple.HIToolbox 0x00007fff83351741 AEProcessAppleEvent + 48
23 com.apple.AppKit 0x00007fff879e9481 _DPSNextEvent + 1191
24 com.apple.AppKit 0x00007fff879e8bed -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
25 com.apple.AppKit 0x00007fff879ae8d3 -[NSApplication run] + 395
26 SheepShaver 0x00000000780bf913 main + 1299
27 SheepShaver 0x0000000078055be8 start + 52
Hi
There seem to be several things wrong when compiling on 10.6.4
Yes, you will need to add that line to video_blit.cpp (plus a comma on the preceding line) to fix the "No appropriate blitter found" error.
When you start SheepShaver Launcher, disable the JIT compiler. The JIT compiler is broken when building on 10.6.4. You should now be able to run SheepShaver and boot up MacOS8 or 9.
For fun, you can add an old working SheepShaver executable into the new SheepShaver Launcher app (it is stored in the Contents/MACOS folder along with the SheepShaverLauncher executable) to get a hybrid that gives you the new multiple VM chooser.
When building on 10.6.4 you are building SheepShaver as a 64-bit app. The JIT compiler uses MACH exceptions to catch bad memory accesses, but the exception handler in sigsegv.cpp is written for the way exceptions happen in 32-bit. I looked at "libsigsegv-2.8" project and think I understand and have new code that should work for 64-bit exceptions. So I've tried that, but that still doesn't get it running. Next, the ix86_skip_instruction routine is being asked to skip some Intel MMX instructions that it isn't prepared for. Not sure that's a real problem or just a symptom of another fault. I have also built as 32-bit and get the same result. So I am still hunting...
Dave
There seem to be several things wrong when compiling on 10.6.4
Yes, you will need to add that line to video_blit.cpp (plus a comma on the preceding line) to fix the "No appropriate blitter found" error.
When you start SheepShaver Launcher, disable the JIT compiler. The JIT compiler is broken when building on 10.6.4. You should now be able to run SheepShaver and boot up MacOS8 or 9.
For fun, you can add an old working SheepShaver executable into the new SheepShaver Launcher app (it is stored in the Contents/MACOS folder along with the SheepShaverLauncher executable) to get a hybrid that gives you the new multiple VM chooser.
When building on 10.6.4 you are building SheepShaver as a 64-bit app. The JIT compiler uses MACH exceptions to catch bad memory accesses, but the exception handler in sigsegv.cpp is written for the way exceptions happen in 32-bit. I looked at "libsigsegv-2.8" project and think I understand and have new code that should work for 64-bit exceptions. So I've tried that, but that still doesn't get it running. Next, the ix86_skip_instruction routine is being asked to skip some Intel MMX instructions that it isn't prepared for. Not sure that's a real problem or just a symptom of another fault. I have also built as 32-bit and get the same result. So I am still hunting...
Dave
Hi,
Thanks for looking into this!
Yes, indeed, the application runs when the jit compiler is deactivated in the GUI.
It does, however not compile when the --enable-jit=no is used during the configuration step.
Also, when running with SDL 1.2.14 (latest) and without jit, these warnings come by when anything on the screen is updated:
2010-09-23 10:43:26.568 SheepShaver[5179:b803] *** __NSAutoreleaseNoPool(): Object 0x42c270 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking.
etc, etc....
Best,
Cat_7
Thanks for looking into this!
Yes, indeed, the application runs when the jit compiler is deactivated in the GUI.
It does, however not compile when the --enable-jit=no is used during the configuration step.
Also, when running with SDL 1.2.14 (latest) and without jit, these warnings come by when anything on the screen is updated:
2010-09-23 10:43:26.568 SheepShaver[5179:b803] *** __NSAutoreleaseNoPool(): Object 0x42c270 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking.
etc, etc....
Best,
Cat_7
Last edited by Cat_7 on Fri Sep 24, 2010 7:58 am, edited 1 time in total.
To fix building with jit disabled edit SheepShaver/src/kpx_cpu/src/cpu/ppc/ppc-cpu.hpp
add lines with +
It worked on linux, I hope it works on OS X.
add lines with +
Code: Select all
#include "cpu/ppc/ppc-bitfields.hpp"
#include "cpu/ppc/ppc-blockinfo.hpp"
#include "cpu/ppc/ppc-registers.hpp"
+#if PPC_ENABLE_JIT
#include "cpu/ppc/ppc-jit.hpp"
+#endif
#include "cpu/ppc/ppc-instructions.hpp"
#include <vector>
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I see two tables, do I add the line to both?mac1984 wrote:Yes, you will need to add that line to video_blit.cpp (plus a comma on the preceding line) to fix the "No appropriate blitter found" error.
Code: Select all
#ifdef WORDS_BIGENDIAN
table
#else
table
#endif
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Yes, it works. I used SDL 1.2.14 and configured with:
--enable-sdl-framework --enable-sdl-audio --enable-sdl-video --disable-vosf --disable-jit
Good thing is that, with SDL 1.2.14, SheepShaver now uses Quartz and not QuickDraw anymore.
But still some problems to solve:
1. JIT-compiler
Without the JIT compiler SheepShaver feels sluggish. This is especially disturbing with the, now only available, software cursor.
2. Hardware cursor
The hardware cursor should be enabled for SDL 1.2.14. Now we have only the software cursor. The hardware cursor could be used with SDL 1.2.10, not with SDL 1.2.12, but apparently again with SDL 1.2.14. Chombier created a SheepShaver build with SDL 1.2.14 and the hardware cursor enabled. I do not know where in the source code this is determined.
3. Memory leak
In Console this is produced endlessly:
This is the memory leak that was reported by Jean-Pierre Chombier and for which he made a patch for SDL 1.2.14:
http://bugzilla.libsdl.org/show_bug.cgi?id=870
--enable-sdl-framework --enable-sdl-audio --enable-sdl-video --disable-vosf --disable-jit
Good thing is that, with SDL 1.2.14, SheepShaver now uses Quartz and not QuickDraw anymore.
But still some problems to solve:
1. JIT-compiler
Without the JIT compiler SheepShaver feels sluggish. This is especially disturbing with the, now only available, software cursor.
2. Hardware cursor
The hardware cursor should be enabled for SDL 1.2.14. Now we have only the software cursor. The hardware cursor could be used with SDL 1.2.10, not with SDL 1.2.12, but apparently again with SDL 1.2.14. Chombier created a SheepShaver build with SDL 1.2.14 and the hardware cursor enabled. I do not know where in the source code this is determined.
3. Memory leak
In Console this is produced endlessly:
Code: Select all
24-09-10 12:11:35 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x25ae70 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x267550 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x1b4400 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x267580 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x184a00 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x172c70 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x2675b0 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
24-09-10 12:11:36 SheepShaver[6709] *** __NSAutoreleaseNoPool(): Object 0x1b4530 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
http://bugzilla.libsdl.org/show_bug.cgi?id=870
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I found this in video_sdl.cpp. Could this be related? Maybe the mentioned "Quartz driver bug" is solved in SDL 1.2.14?Ronald P. Regensburg wrote:2. Hardware cursor
The hardware cursor should be enabled for SDL 1.2.14. Now we have only the software cursor. The hardware cursor could be used with SDL 1.2.10, not with SDL 1.2.12, but apparently again with SDL 1.2.14. Chombier created a SheepShaver build with SDL 1.2.14 and the hardware cursor enabled. I do not know where in the source code this is determined.
Code: Select all
/*
* Can we set the MacOS cursor image into the window?
*/
#ifdef SHEEPSHAVER
bool video_can_change_cursor(void)
{
static char driver[] = "Quartz?";
static int quartzok = -1;
if (display_type != DISPLAY_WINDOW)
return false;
if (quartzok < 0) {
if (SDL_VideoDriverName(driver, sizeof driver) == NULL || strncmp(driver, "Quartz", sizeof driver))
quartzok = true;
else {
// Quartz driver bug prevents cursor changing in SDL 1.2.11 and later
const SDL_version *vp = SDL_Linked_Version();
quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) <= SDL_VERSIONNUM(1, 2, 10);
}
}
return quartzok;
}
#endif
/*
* Set cursor image for window
*/
#ifdef SHEEPSHAVER
void video_set_cursor(void)
{
cursor_changed = true;
}
#endif
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
In the above posted code, I changed SDL_VERSIONNUM(1, 2, 10) into SDL_VERSIONNUM(1, 2, 14)
And indeed, the result is now again a SheepShaver that switches between hardware cursor and software cursor as needed.
This enhances the user experience considerably.
Of course, the source should not be changed in this way. I suppose it should be done in such a way that it will be still possible to also build with SDL 1.2.10 and the hardware cursor.
And indeed, the result is now again a SheepShaver that switches between hardware cursor and software cursor as needed.
This enhances the user experience considerably.
Of course, the source should not be changed in this way. I suppose it should be done in such a way that it will be still possible to also build with SDL 1.2.10 and the hardware cursor.
-
- Forum All-Star
- Posts: 1726
- Joined: Tue Oct 14, 2008 12:12 am
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
With jit disabled, I can now also build SheepShaver with sdl static again (makes a smaller application).
Summarizing: We need a couple of problems solved:
1. Make JIT-compiler work when building in Snow Leopard (x86_64 architecture)
This may be complex. I understand that mac1984 is looking into this.
The other two problems should be easily solvable by anyone with programmer skills.
2. Make cursor changing (between hardware en software cursor) available with SDL 1.2.14
It was possible with SDL 1.2.10. Because of a bug it was not possible with later versions, but it is again possible with SDL 1.2.14.
In the file BasiliskII/src/SDL/video_sdl.cpp this piece of code should be edited to add cursor changing with SDL 1.2.14:
3. Solve the memory leak with SDL 1.2.14 and SheepShaver
Jean-Pierre Chombier describes a patch for SDL 1.2.14 that solves this problem: http://bugzilla.libsdl.org/show_bug.cgi?id=870
I can add the three lines in the indicated place in the file release-1.2.14/source/video/quartz/SDL_QuartzVideo.m but apparently more needs to be changed. My knowledge is not sufficient to understand his very concise description of the patch:
Summarizing: We need a couple of problems solved:
1. Make JIT-compiler work when building in Snow Leopard (x86_64 architecture)
This may be complex. I understand that mac1984 is looking into this.
The other two problems should be easily solvable by anyone with programmer skills.
2. Make cursor changing (between hardware en software cursor) available with SDL 1.2.14
It was possible with SDL 1.2.10. Because of a bug it was not possible with later versions, but it is again possible with SDL 1.2.14.
In the file BasiliskII/src/SDL/video_sdl.cpp this piece of code should be edited to add cursor changing with SDL 1.2.14:
Code: Select all
else {
// Quartz driver bug prevents cursor changing in SDL 1.2.11 and later
const SDL_version *vp = SDL_Linked_Version();
quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) <= SDL_VERSIONNUM(1, 2, 10);
}
Jean-Pierre Chombier describes a patch for SDL 1.2.14 that solves this problem: http://bugzilla.libsdl.org/show_bug.cgi?id=870
I can add the three lines in the indicated place in the file release-1.2.14/source/video/quartz/SDL_QuartzVideo.m but apparently more needs to be changed. My knowledge is not sufficient to understand his very concise description of the patch:
To fix this, I added a 'CGContextRef wcg_context' field to the SDL_PrivateVideoData structure, Initialized it at the end of QZ_SetVideoWindowed():And used this wcg_context field in the UpdateRects() function instead of [NSGraphicsContext graphicsContextWithWindow].Code: Select all
this->UpdateRects = QZ_UpdateRects; this->LockHWSurface = QZ_LockHWSurface; this->UnlockHWSurface = QZ_UnlockHWSurface; + wcg_context = (CGContextRef) + [[NSGraphicsContext graphicsContextWithWindow: qz_window] + graphicsPort];
No more leak.
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Not sure if this is the proper way of doing this, but this is what I did (added one line, marked with +, and edited comment) and it appears to work with SDL 1.2.14:Ronald P. Regensburg wrote:2. Make cursor changing (between hardware en software cursor) available with SDL 1.2.14
Code: Select all
/*
* Can we set the MacOS cursor image into the window?
*/
#ifdef SHEEPSHAVER
bool video_can_change_cursor(void)
{
static char driver[] = "Quartz?";
static int quartzok = -1;
if (display_type != DISPLAY_WINDOW)
return false;
if (quartzok < 0) {
if (SDL_VideoDriverName(driver, sizeof driver) == NULL || strncmp(driver, "Quartz", sizeof driver))
quartzok = true;
else {
// Quartz driver bug prevents cursor changing in SDL 1.2.11, 1.2.12, and 1.2.13
const SDL_version *vp = SDL_Linked_Version();
quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) <= SDL_VERSIONNUM(1, 2, 10);
+ quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) >= SDL_VERSIONNUM(1, 2, 14);
}
}
return quartzok;
}
#endif
Success!
Here are the build instructions for a Mac OS X 10.6.4 32-bit i386 version. I will look at getting a 64-bit version running, but the way it generates code it won't really use any more registers. I figured that a 386 version would be easier to get running as there didn't need to be any changes to the code. I'll make another post later on what is going wrong using gcc 4.2
Dave
#You need an installation of SDL:
#Enter some folder where you want the source to reside.
mkdir SDL
cd SDL
svn checkout http://svn.libsdl.org/tags/SDL/release-1.2.14
cd ..
cvs -d :pserver:anoncvs@cvs.cebix.net:/home/cvs/cebix login
#(password is "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
cd release-1.2.14
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
./autogen.sh
./configure --disable-shared --prefix=`pwd`
make
make install
PATH=`pwd`/bin:$PATH
export PATH
cd ..
cd ..
cd SheepShaver
make links
cd src/Unix
# Need to build /src/Unix/Darwin/lowmem as 64-bit code
export CPPFLAGS=""
export LDFLAGS=""
./autogen.sh --disable-vosf --enable-sdl-audio --enable-sdl-video
# Switch to gcc4.0 and 32-bit code generation (rerun autogen - lowmen executable will not not overwritten)
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
export CC=gcc-4.0
export CXX=g++-4.0
./autogen.sh --disable-vosf --enable-sdl-audio --enable-sdl-video
make
#open SheepShaver/src/MacOSX/Launcher/SheepShaverLauncher.xcodeproj in XCode and build
Here are the build instructions for a Mac OS X 10.6.4 32-bit i386 version. I will look at getting a 64-bit version running, but the way it generates code it won't really use any more registers. I figured that a 386 version would be easier to get running as there didn't need to be any changes to the code. I'll make another post later on what is going wrong using gcc 4.2
Dave
#You need an installation of SDL:
#Enter some folder where you want the source to reside.
mkdir SDL
cd SDL
svn checkout http://svn.libsdl.org/tags/SDL/release-1.2.14
cd ..
cvs -d :pserver:anoncvs@cvs.cebix.net:/home/cvs/cebix login
#(password is "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
cd release-1.2.14
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
./autogen.sh
./configure --disable-shared --prefix=`pwd`
make
make install
PATH=`pwd`/bin:$PATH
export PATH
cd ..
cd ..
cd SheepShaver
make links
cd src/Unix
# Need to build /src/Unix/Darwin/lowmem as 64-bit code
export CPPFLAGS=""
export LDFLAGS=""
./autogen.sh --disable-vosf --enable-sdl-audio --enable-sdl-video
# Switch to gcc4.0 and 32-bit code generation (rerun autogen - lowmen executable will not not overwritten)
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
export CC=gcc-4.0
export CXX=g++-4.0
./autogen.sh --disable-vosf --enable-sdl-audio --enable-sdl-video
make
#open SheepShaver/src/MacOSX/Launcher/SheepShaverLauncher.xcodeproj in XCode and build
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Nice!
I do not really understand why it works, but it works. Also works when modified for the way I always build SheepShaver, with simply "make SheepShaver_app" for the final step:
I do not really understand why it works, but it works. Also works when modified for the way I always build SheepShaver, with simply "make SheepShaver_app" for the final step:
Code: Select all
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.14
cd release-1.2.14
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
./autogen.sh
./configure --disable-shared --prefix=`pwd`
make
make install
PATH=`pwd`/bin:$PATH
export PATH
cd ../../SheepShaver
make links
cd src/Unix
export CPPFLAGS=""
export LDFLAGS=""
./autogen.sh --enable-sdl-static --enable-sdl-audio --enable-sdl-video --disable-vosf
export CPPFLAGS="-arch i386"
export LDFLAGS="-arch i386"
export CC=gcc-4.0
export CXX=g++-4.0
./autogen.sh --enable-sdl-static --enable-sdl-audio --enable-sdl-video --disable-vosf
make
make SheepShaver_app
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
That procedure re-enabled jit-compiler. Thanks mac1984!
Now, with my patch in BasiliskII/src/SDL/video_sdl.cpp changing is restored with sdl 1.2.14 (can someone please check above if that is done correctly).
That leaves the patch for sdl 1.2.14 to stop the memory leak.
Where Jean-Pierre Chombier writes: "I added a 'CGContextRef wcg_context' field to the SDL_PrivateVideoData structure", that probably needs to be done in the file SDL_QuartzVideo.h
Where he writes: "Initialized it at the end of QZ_SetVideoWindowed()", that is probably adding the three lines in the file SDL_QuartzVideo.m:
Where he writes "And used this wcg_context field in the UpdateRects() function instead of [NSGraphicsContext graphicsContextWithWindow]" that refers probably to that function close to the end of the file SDL_QuartzVideo.m
Can someone please try to figure out exactly how this patch is to be added. I tried to ask Chombier himself, but he never answered my messages.
Now, with my patch in BasiliskII/src/SDL/video_sdl.cpp changing is restored with sdl 1.2.14 (can someone please check above if that is done correctly).
That leaves the patch for sdl 1.2.14 to stop the memory leak.
Where Jean-Pierre Chombier writes: "I added a 'CGContextRef wcg_context' field to the SDL_PrivateVideoData structure", that probably needs to be done in the file SDL_QuartzVideo.h
Where he writes: "Initialized it at the end of QZ_SetVideoWindowed()", that is probably adding the three lines in the file SDL_QuartzVideo.m:
Code: Select all
this->UpdateRects = QZ_UpdateRects;
this->LockHWSurface = QZ_LockHWSurface;
this->UnlockHWSurface = QZ_UnlockHWSurface;
+ wcg_context = (CGContextRef)
+ [[NSGraphicsContext graphicsContextWithWindow: qz_window]
+ graphicsPort];
Can someone please try to figure out exactly how this patch is to be added. I tried to ask Chombier himself, but he never answered my messages.
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
I have some thoughts on this.Ronald P. Regensburg wrote:Not sure if this is the proper way of doing this, but this is what I did (added one line, marked with +, and edited comment) and it appears to work with SDL 1.2.14:Ronald P. Regensburg wrote:2. Make cursor changing (between hardware en software cursor) available with SDL 1.2.14
First, this change is not doing exactly what you want. It will enable the hardware cursor for SDL 1.2.14 and later, but disable it for all earlier versions. If you change the assignment operator from "=" to "|=" in your added line, it will compute the right result. (I wouldn't check it in that way because it could be cleaner, but functionally it doesn't matter.)
Second, consider whether you want to presume that the hardware cursor will work in later versions, particularly SDL 1.3. It might be wise to use the software cursor for any SDL version not specifically tested and known to work. Changing the comparison from ">=" to "==" will achieve that. I don't have strong feelings about it one way or the other.
Third, it sure would be nice if we had a version of SDL that worked properly with both hardware and software cursor. (My tests showed that 1.2.10 and earlier worked properly with hardware cursor, but not with software cursor, and versions later than 1.2.10 were the other way around. At the time, I thought that 1.2.13 was the last release in the SDL 1.2.X line.) If 1.2.14 works properly with both, then the choice can finally be made a runtime option.
By the way, in my test results, "does not work properly with hardware cursor" meant "the cursor remains an arrow and cannot be changed". The notion of "does not work properly with software cursor" was more subtle: the symptom was that the cursor did not always transition properly across the SheepShaver window boundary; if I recall correctly, this occurred around the bottom edge of the window. This might not reveal itself to casual testing.
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Thanks Kelvin,
I never noticed any specific problems with cursor changing when 10.1.10 was used and now again with 1.2.14. As far as I can see the cursors work identically with both.
Since you introduced the hardware cursor and cursor changing, I always built SheepShaver with sdl 1.2.10, because I felt that the combination of the two cursors, with the software cursor only when needed, provided the best user experience. I myself use an application that occasionally needs the software cursor to display animated color cursors. As soon as those cursors are not used anymore, the cursor changes back to the hardware cursor.
The one problem that one can notice (with both 1.2.10 and 1.2.14) is that when the software cursor is active, that cursor will stay at the border of the SheepShaver window and the OSX cursor will take over outside the window. However, in normal use, most of the time the hardware cursor is functional.
(This problem with the software cursor makes that I can see in one glance if a SheepShaver build was build with the hardware cursor and cursor changing or with just the software cursor. When built with only the software cursor, like with 1.2.12 and until I made the change also with 1.2.14, the cursor will always stay at the border of the window.)
I already considered that SDL 1.3 will be very different from SDL 1.2, so better to not include that yet. Also I do not see a reason for building SheepShaver with SDL earlier than 1.2.10. So, maybe this would be the best solution for now:
Is this correct code? (It works with 1.2.14)
I never noticed any specific problems with cursor changing when 10.1.10 was used and now again with 1.2.14. As far as I can see the cursors work identically with both.
Since you introduced the hardware cursor and cursor changing, I always built SheepShaver with sdl 1.2.10, because I felt that the combination of the two cursors, with the software cursor only when needed, provided the best user experience. I myself use an application that occasionally needs the software cursor to display animated color cursors. As soon as those cursors are not used anymore, the cursor changes back to the hardware cursor.
The one problem that one can notice (with both 1.2.10 and 1.2.14) is that when the software cursor is active, that cursor will stay at the border of the SheepShaver window and the OSX cursor will take over outside the window. However, in normal use, most of the time the hardware cursor is functional.
(This problem with the software cursor makes that I can see in one glance if a SheepShaver build was build with the hardware cursor and cursor changing or with just the software cursor. When built with only the software cursor, like with 1.2.12 and until I made the change also with 1.2.14, the cursor will always stay at the border of the window.)
I already considered that SDL 1.3 will be very different from SDL 1.2, so better to not include that yet. Also I do not see a reason for building SheepShaver with SDL earlier than 1.2.10. So, maybe this would be the best solution for now:
Code: Select all
else {
// Quartz driver bug prevents cursor changing in SDL 1.2.11, 1.2.12, and 1.2.13
// Cursor changing works in SDL 1.2.10 and 1.2.14
const SDL_version *vp = SDL_Linked_Version();
quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) == SDL_VERSIONNUM(1, 2, 10) || SDL_VERSIONNUM(1, 2, 14);
}
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I never build SheepShaver with the Launcher.mac1984 wrote:#open SheepShaver/src/MacOSX/Launcher/SheepShaverLauncher.xcodeproj in XCode and build
I think that discussing the Launcher is worth a separate topic: http://www.emaculation.com/forum/viewtopic.php?p=35735
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
That would always set quartzok to true. Here is my suggestion:Ronald P. Regensburg wrote:Is this correct code? (It works with 1.2.14)Code: Select all
quartzok = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch) == SDL_VERSIONNUM(1, 2, 10) || SDL_VERSIONNUM(1, 2, 14);
Code: Select all
// Quartz driver bug prevents cursor changing in SDL 1.2.11, 1.2.12, and 1.2.13.
// Version 1.2.14 is the latest that has been tested.
const SDL_version *vp = SDL_Linked_Version();
int vers = SDL_VERSIONNUM(vp->major, vp->minor, vp->patch);
quartzok = (vers <= SDL_VERSIONNUM(1, 2, 10)) || (vers == SDL_VERSIONNUM(1, 2, 14));
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Thanks. As I understand it, that will set quartzok to true with 1.2.10 and earlier and with 1.2.14
It is clear that I am no programmer.
Do you or do I send this to basilisk-devel list for committing to cvs?
Edit 24.10.2010: Further testing revealed that with SDL 1.2.14 the hardware cursor does NOT change correctly, so the suggested changes should not be made.
See also: http://www.emaculation.com/forum/viewto ... 6155#36155
It is clear that I am no programmer.
Do you or do I send this to basilisk-devel list for committing to cvs?
Edit 24.10.2010: Further testing revealed that with SDL 1.2.14 the hardware cursor does NOT change correctly, so the suggested changes should not be made.
See also: http://www.emaculation.com/forum/viewto ... 6155#36155
Last edited by Ronald P. Regensburg on Sat Oct 23, 2010 11:17 pm, edited 1 time in total.
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
That's correct about quartzok.Ronald P. Regensburg wrote:Thanks. As I understand it, that will set quartzok to true with 1.2.10 and earlier and with 1.2.14 [... ] Do you or do I send this to basilisk-devel list for committing to cvs?
As for the code, I haven't built or tested it (am away from my home machine). Somebody who has done so should be the one to submit it. I don't doubt that it's correct, but I make it a rule never to submit code without having personally built and tested it.
To fix NSAutoreleaseNoPool errors: (From Jean-Pierre post on bugzilla)
In folder src/video/quartz/
In file SDL_QuartzVideo.h
after this lineadd line
after this line
add line
In file SDL_QuartzVideo.m
after these lines in procedure QZ_SetVideoWindowed
add
update procedure QZ_UpdateRects to:
In folder src/video/quartz/
In file SDL_QuartzVideo.h
after this line
Code: Select all
SInt32 system_version; /* used to dis-/enable workarounds depending on the system version */
Code: Select all
CGContextRef wcg_context; /* Current Window drawing CG context */
Code: Select all
#define system_version (this->hidden->system_version)
Code: Select all
#define wcg_context (this->hidden->wcg_context)
after these lines in procedure QZ_SetVideoWindowed
Code: Select all
current->flags |= SDL_SWSURFACE;
current->flags |= SDL_ASYNCBLIT;
current->hwdata = (void *) cg_context;
this->UpdateRects = QZ_UpdateRects;
this->LockHWSurface = QZ_LockHWSurface;
this->UnlockHWSurface = QZ_UnlockHWSurface;
Code: Select all
wcg_context = (CGContextRef)[[NSGraphicsContext graphicsContextWithWindow: qz_window] graphicsPort];
Code: Select all
static void QZ_UpdateRects (_THIS, int numRects, SDL_Rect *rects)
{
if (SDL_VideoSurface->flags & SDL_OPENGLBLIT) {
QZ_GL_SwapBuffers (this);
}
else if ( [ qz_window isMiniaturized ] ) {
/* Do nothing if miniaturized */
}
else {
QZ_DrawResizeIcon (this);
CGContextFlush (cg_context);
CGImageRef image = CGBitmapContextCreateImage (cg_context);
CGRect rectangle = CGRectMake (0,0,[window_view frame].size.width,[window_view frame].size.height);
CGContextDrawImage (wcg_context, rectangle, image);
CGImageRelease(image);
CGContextFlush (wcg_context);
}
}
- Ronald P. Regensburg
- Expert User
- Posts: 7835
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Thanks. This does indeed fix those errors.mac1984 wrote:To fix NSAutoreleaseNoPool errors: (From Jean-Pierre post on bugzilla)
In the meantime, I am busy testing the change in BasiliskII/src/SDL/video_sdl.cpp as suggested by kelvin31415, building with different sdl versions. With 1.2.14 it works as expected. Will now try 1.2.10 and 1.2.12. Needed to set up my PowerBook G4 again to do that.