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

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

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

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.

Hi,

I saw your suggestion has been incorporated into the CVS. Building on OSX with the --enable-jit=no now parameter works.

Best,
Cat_7

I see two tables, do I add the line to both?

Hi,

That addition has also been incorporated into CVS. It is now in both the big and little endian entries. So you don't need to do anything except refresh your local cvs copies of Basilisk/SheepShaver.

Best,
cat_7

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

I found this in video_sdl.cpp. Could this be related? Maybe the mentioned "Quartz driver bug" is solved in SDL 1.2.14?

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.

Ronald,

Does this mean that we have a new version that could be used by the rest of us??

No, not yet and may be not for some time. There are several problems still and there is no advantage over the existing latest build (25-10-2009), that will run fine on Tiger, Leopard and Snow Leopard. I will continue using the 25-10-2009 build myself for the time being.

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:

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:

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

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:

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.

I have some thoughts on this.

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.

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 build SheepShaver with the Launcher.

I think that discussing the Launcher is worth a separate topic: http://www.emaculation.com/forum/viewtopic.php?p=35735

That would always set quartzok to true. Here is my suggestion:

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

That's correct about quartzok.

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 line
add line


after this line
add line


In file SDL_QuartzVideo.m

after these lines in procedure QZ_SetVideoWindowed


add



update procedure QZ_UpdateRects to:

Thanks. This does indeed fix those errors.

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.