basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] [PATCH] SheepShaver fullscreen on OS X

[Alexei S. <ale...@gm...>]

Thanks. Patch applied.

As for your questions, I have no idea. Perhaps whoever implemented it
originally may have an answer, but good luck finding them active on
this list these days.

-Alexei

On Tue, Mar 3, 2009 at 2:25 AM, Dave Vasilevsky
<va...@us...> wrote:
> Hi folks,
>
> Thanks for all your work on Basilisk II and SheepShaver, they're truly
> amazing programs! However, there's a little bug: Current SheepShaver
> SVN compiled with VOSF off will not display fullscreen on OS X. The VM
> boots, but the display is entirely black. This is expected, I suppose,
> since video_refresh_dga() doesn't actually attempt to draw anything!
>
> The patch at http://vasi.dyndns.org:3128/files/patch/sheepshaver-fullscreen-3.patch
> fixes this. Notes:
> * video_refresh_window() now takes an argument of type driver_base,
> since nothing specific to driver_window was used
> * video_refresh_dga() can now call video_refresh_window_static()
> * update_display_static_bbox() now respects the destination having a
> different bytes-per-row from the source
> * fullscreen modes are now created for all depths
>
> I have two relevant questions:
> * Why was non-VOSF SheepShaver previously restricted to just one depth
> when using fullscreen? Seems to work fine with all depths.
> * Why is update_display_static() used only for depths < 8 bits?
>
> Comments welcome.
> Dave Vasilevsky
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] SDL Framework patch

[Alexei S. <ale...@gm...>]

Committed. Thanks.

I made some modifications to the configure conditions to AND them
rather than making nested ifs, in some cases. I also decided to leave
the _app builds as-is, so the person doing the build can copy it over
or not if he wishes.

-Alexei

On Mon, Feb 23, 2009 at 6:06 PM, Mike Sliczniak
<bas...@sp...> wrote:
> Hi,
>
> Here is a patch to allow compiling of SS and B2 with an SDL Framework. You
> can get this by downloading from:
>
> http://www.libsdl.org/release/SDL-1.2.13.dmg
>
> SDLMain.[mh] should be placed in BasiliskII/src/SDL, they are from the above
> disk image.
>
> Here is how I tested on an intel 32-bit mac with Mac OS X 10.5.6:
>
> SS ./autogen.sh --disable-standalone-gui --enable-vosf
> --enable-sdl-framework
> --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks
> --enable-sdl-video --disable-sdl-audio --enable-addressing=real
> --without-esd --without-gtk --without-mon --without-x
>
> SS /autogen.sh --disable-standalone-gui --enable-vosf
> --disable-sdl-framework --disable-sdl-video --disable-sdl-audio
> --enable-addressing=real --without-esd --without-gtk --without-mon --with-x
>
> B2 ./autogen.sh --disable-standalone-gui --enable-vosf
> --enable-sdl-framework
> --enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks
> --enable-sdl-video --enable-sdl-audio --enable-addressing=real --without-esd
> --without-gtk --without-mon --without-x --enable-jit-compiler
>
> B2 ./autogen.sh --disable-standalone-gui --enable-vosf
> --disable-sdl-framework --disable-sdl-video --disable-sdl-audio
> --enable-addressing=real --with-esd --without-gtk --without-mon --with-x
> --enable-jit-compiler
>
> (esound does not really work on mac, esound needs some better coreaudio
> patches.)
>
> Alexei did not like my first patch where I renamed
> MacOSX/PrefsEditor/main.m, so I put in a rule for SDLMain.o in the
> Makefile.in files, but something like this in Makefile.in also works (though
> maybe it would make more sense then to put the SDLMain.[mh] files in MacOSX
> or Darwin so in the future .m files would be built as well as long as they
> were in that dir):
>
> # do not want to generate main.o from ../MacOSX/PrefsEditor/main.m
> $(OBJ_DIR)/%.o : ../SDL/%.m
>        $(CC) $(CPPFLAGS) $(DEFS) $(CFLAGS) -c $< -o $@
>
> I deliberately did not reindent the changes I made to the configure.ac files
> so that it would be easier to to see how I changed things, whatever gets
> accepted, should be reindented.
>
> configure.ac for SS has two little additional fixes so that the Cocoa
> preferences gui does not get built if you are building for X11 and so that
> you can use esd, sdl, or coreaudio for sound.
>
> One question I have is should the *_app targets copy the SDL framework into
> the app bundle? I think not, so someone doing a build can do that only if
> they wish (suppose they intend to install the SDL framework under
> /Library/Frameworks instead). Or maybe it should and then someone that does
> not want it can simply delete it from the .app bundle afterwards. Both
> options are easy.
>
> mzs
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] [PATCH] SheepShaver fullscreen on OS X

[Dave V. <va...@us...>]

Hi folks,

Thanks for all your work on Basilisk II and SheepShaver, they're truly
amazing programs! However, there's a little bug: Current SheepShaver
SVN compiled with VOSF off will not display fullscreen on OS X. The VM
boots, but the display is entirely black. This is expected, I suppose,
since video_refresh_dga() doesn't actually attempt to draw anything!

The patch at http://vasi.dyndns.org:3128/files/patch/sheepshaver-fullscreen-3.patch
fixes this. Notes:
* video_refresh_window() now takes an argument of type driver_base,
since nothing specific to driver_window was used
* video_refresh_dga() can now call video_refresh_window_static()
* update_display_static_bbox() now respects the destination having a
different bytes-per-row from the source
* fullscreen modes are now created for all depths

I have two relevant questions:
* Why was non-VOSF SheepShaver previously restricted to just one depth
when using fullscreen? Seems to work fine with all depths.
* Why is update_display_static() used only for depths < 8 bits?

Comments welcome.
Dave Vasilevsky

[B2-devel] SDL Framework patch

[Mike S. <bas...@sp...>]

Hi,

Here is a patch to allow compiling of SS and B2 with an SDL Framework. 
You can get this by downloading from:

http://www.libsdl.org/release/SDL-1.2.13.dmg

SDLMain.[mh] should be placed in BasiliskII/src/SDL, they are from the 
above disk image.

Here is how I tested on an intel 32-bit mac with Mac OS X 10.5.6:

SS ./autogen.sh --disable-standalone-gui --enable-vosf 
--enable-sdl-framework 
--enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks 
--enable-sdl-video --disable-sdl-audio --enable-addressing=real
--without-esd --without-gtk --without-mon --without-x

SS /autogen.sh --disable-standalone-gui --enable-vosf 
--disable-sdl-framework --disable-sdl-video --disable-sdl-audio 
--enable-addressing=real --without-esd --without-gtk --without-mon 
--with-x

B2 ./autogen.sh --disable-standalone-gui --enable-vosf 
--enable-sdl-framework 
--enable-sdl-framework-prefix=/Users/mzs/Library/Frameworks 
--enable-sdl-video --enable-sdl-audio --enable-addressing=real 
--without-esd --without-gtk --without-mon --without-x 
--enable-jit-compiler

B2 ./autogen.sh --disable-standalone-gui --enable-vosf 
--disable-sdl-framework --disable-sdl-video --disable-sdl-audio 
--enable-addressing=real --with-esd --without-gtk --without-mon --with-x 
--enable-jit-compiler

(esound does not really work on mac, esound needs some better coreaudio 
patches.)

Alexei did not like my first patch where I renamed 
MacOSX/PrefsEditor/main.m, so I put in a rule for SDLMain.o in the 
Makefile.in files, but something like this in Makefile.in also works 
(though maybe it would make more sense then to put the SDLMain.[mh] files 
in MacOSX or Darwin so in the future .m files would be built as well as 
long as they were in that dir):

# do not want to generate main.o from ../MacOSX/PrefsEditor/main.m
$(OBJ_DIR)/%.o : ../SDL/%.m
         $(CC) $(CPPFLAGS) $(DEFS) $(CFLAGS) -c $< -o $@

I deliberately did not reindent the changes I made to the configure.ac 
files so that it would be easier to to see how I changed things, whatever 
gets accepted, should be reindented.

configure.ac for SS has two little additional fixes so that the Cocoa 
preferences gui does not get built if you are building for X11 and so that 
you can use esd, sdl, or coreaudio for sound.

One question I have is should the *_app targets copy the SDL framework 
into the app bundle? I think not, so someone doing a build can do that 
only if they wish (suppose they intend to install the SDL framework under 
/Library/Frameworks instead). Or maybe it should and then someone that 
does not want it can simply delete it from the .app bundle afterwards. 
Both options are easy.

mzs

Re: [B2-devel] Leopard X11 DISPLAY variable patch

[Alexei S. <ale...@gm...>]

Applied to both SS and BasiliskII. Thanks.

On Tue, Feb 17, 2009 at 9:34 AM, Mike Sliczniak
<bas...@sp...> wrote:
> Hi,
>
> I was testing some other SS patches and I noticed that when I ran an X11
> build of SS there were not all the video modes I expected in the the
> control strip. Mac OS X 10.5 changed the form of the DISPLAY environment
> variable. I pasted (sorry) the patch for SheepShaver/src/Unix below. A
> similar change most likely needs to be made to
> BasiliskII/src/Unix/video_x.cpp as well. The reason for this is that the
> DISPLAY variable looks like this in Leopard:
>
> /tmp/launch-XXXXXX/:0
>
> The Xs are like in mktemp.
>
> Also I have some more patches I would like to submit but I am waiting to
> see if the others I submitted will be accepted. The cpr.sh one touches the
> autoconf stuff that other patches also touch.
>
> mzs
>
> Index: video_x.cpp
> ===================================================================
> RCS file: /home/cvs/cebix/SheepShaver/src/Unix/video_x.cpp,v
> retrieving revision 1.50
> diff -u -8 -r1.50 video_x.cpp
> --- video_x.cpp 1 Jan 2008 09:47:39 -0000       1.50
> +++ video_x.cpp 17 Feb 2009 14:23:46 -0000
>  #ifdef ENABLE_VOSF
>        // Zero the mainBuffer structure
>        mainBuffer.dirtyPages = NULL;
>        mainBuffer.pageInfo = NULL;
>  #endif
>
>        // Check if X server runs on local machine
>        local_X11 = (strncmp(XDisplayName(x_display_name), ":", 1) == 0)
> +                || (strncmp(XDisplayName(x_display_name), "/", 1) == 0)
>                 || (strncmp(XDisplayName(x_display_name), "unix:", 5) == 0);
>
>        // Init keycode translation
>        keycode_init();
>
>        // Read frame skip prefs
>        frame_skip = PrefsFindInt32("frameskip");
>        if (frame_skip == 0)
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] B2 and SS build working .app bundle patch

[Alexei S. <ale...@gm...>]

Applied. :)

2009/2/6 Mike Sliczniak <bas...@sp...>:
> Hi,
>
> Here is a patch that has a shell script cpr.sh to recursively copy
> directories but discarding things that cause problems at least on 10.4 when
> making the .app bundles. I have tested the script on 10.4 and 10.5 and I
> have built and tested on 32-bit intel 10.5.6 like so:
>
> B2 --disable-standalone-gui --enable-vosf --enable-sdl-video
> --enable-sdl-audio --enable-addressing=real --without-esd --without-gtk
> --without-mon --without-x
>
> SS --disable-standalone-gui --enable-vosf -enable-sdl-video
> --disable-sdl-audio --enable-addressing=real --without-esd --without-gtk
> --without-mon --without-x --enable-jit
>
> Put cpr.sh into BasiliskII/src/Unix and make it executable. Also you need to
> run patch -p0 on BasiliskII-cpr.patch from that dir as well. I noticed that
> in that mega patch earlier I forgot to patch Makefile.in to use cpr.sh for
> BasiliskII. It did not have the problems that SheepShaver did with CVS dirs
> and .SD_Store files on 10.4, but I patched it anyway in case someone makes a
> prefs menu item that uses a .nib file akin to SheepShaver in the future.
>
> Also I removed extfs_macosx.h from the 'make links' target as this file is
> gone now and it used to create a broken symlink.
>
> Be careful with make links. If you have already run it in the SheepShaver
> dir and run it again, you will get a mess of symlinks. What I did to test is
> started from a fresh SheepShaver dir from cvs and then added all the little
> patches I have made. Maybe someone should fix make links so that sort of
> stuff does not happen and possibly so it makes relative links not absolute
> ones.
>
> Finally, at this point I cannot provide any more broken down smaller patches
> for the rest. It is too intertwined with these patches I have submitted. I
> need to know what gets accepted and wait until I can do a cvs update to send
> more.
>
> mzs
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] B2 and SS sdl audio patch for slow machines

[Alexei S. <ale...@gm...>]

Applied. Thanks.

2009/2/6 Mike Sliczniak <bas...@sp...>:
> Hi,
>
> This patch helps to keep the audio from breaking-up on slow machines when
> using SDL audio. On those slow machines you do still get the break-up every
> so often but the sound tends not to break-up nearly as often. It is much
> better on the ears. Notably often the system beeps do not have a pause in
> them. Slow machine is <= 1 GHz G4.
>
> Also did you get my broken-up patch for the compiling under Leopard and
> Tiger? Do you have any questions?
>
> mzs
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] Leopard X11 DISPLAY variable patch

[Mike S. <bas...@sp...>]

Hi,

I was testing some other SS patches and I noticed that when I ran an X11 
build of SS there were not all the video modes I expected in the the 
control strip. Mac OS X 10.5 changed the form of the DISPLAY environment 
variable. I pasted (sorry) the patch for SheepShaver/src/Unix below. A 
similar change most likely needs to be made to 
BasiliskII/src/Unix/video_x.cpp as well. The reason for this is that the 
DISPLAY variable looks like this in Leopard:

/tmp/launch-XXXXXX/:0

The Xs are like in mktemp.

Also I have some more patches I would like to submit but I am waiting to 
see if the others I submitted will be accepted. The cpr.sh one touches the 
autoconf stuff that other patches also touch.

mzs

Index: video_x.cpp
===================================================================
RCS file: /home/cvs/cebix/SheepShaver/src/Unix/video_x.cpp,v
retrieving revision 1.50
diff -u -8 -r1.50 video_x.cpp
--- video_x.cpp	1 Jan 2008 09:47:39 -0000	1.50
+++ video_x.cpp	17 Feb 2009 14:23:46 -0000
  #ifdef ENABLE_VOSF
  	// Zero the mainBuffer structure
  	mainBuffer.dirtyPages = NULL;
  	mainBuffer.pageInfo = NULL;
  #endif

  	// Check if X server runs on local machine
  	local_X11 = (strncmp(XDisplayName(x_display_name), ":", 1) == 0)
+	         || (strncmp(XDisplayName(x_display_name), "/", 1) == 0)
  	         || (strncmp(XDisplayName(x_display_name), "unix:", 5) == 0);

  	// Init keycode translation
  	keycode_init();

  	// Read frame skip prefs
  	frame_skip = PrefsFindInt32("frameskip");
  	if (frame_skip == 0)

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Mike S. <bas...@sp...>]

Hi Alexei,

Don't worry about being busy. Thanks for accepting the patch.

I have checked-out of cvs and built and run like so with no problems:

ppc32 10.5.6:

B2 --disable-standalone-gui --enable-vosf --enable-sdl-video 
--enable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x

SS --disable-standalone-gui --enable-vosf -enable-sdl-video 
--disable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x

ia32 10.5.6:

B2 ./configure --disable-standalone-gui --enable-vosf --enable-sdl-video 
--enable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x --enable-jit-compiler

SS --disable-standalone-gui --enable-vosf -enable-sdl-video 
--disable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x --enable-jit

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

I've just fixed the issue I described by moving sigsegv_info_t struct
declaration to the sigserv.h

I'd appreciate if someone could verify that this doesn't break the
build for their favorite platforms.

-Alexei

On Wed, Feb 11, 2009 at 2:27 PM, Alexei Svitkine
<ale...@gm...> wrote:
> Hi Mike,
>
> I've committed the first two patches you sent. Sorry it took so long,
> but I've been really busy lately.
>
> I know it's not related to your code, but looking at the code brought
> up some serious concerns.
>
> Particularly struct sigsegv_info_t that's re-declared would be
> incomplete if HAVE_MACH_EXCEPTIONS is on.
>
> I've added a big FIXME there, and haven't had the time to investigate
> further - but if Screen_fault_handler ends up accessing the extra
> fields in that struct - it will be a serious bug (accessing memory
> past the end of that structure). This really needs to be fixed (again
> it's not your changes, but still..)
>
> -Alexei
>
> On Mon, Feb 9, 2009 at 5:11 PM, Nigel Pearson <ni...@in...> wrote:
>> On Mon, 9 Feb, Mike Sliczniak wrote:
>>
>>> for B2 when building from Unix there is no way to use
>>> core audio currently.
>>>
>>> Did I break it? I don't know. The build from MacOSX uses many of
>>> the files
>>> from ../Unix. Maybe Nigel can say something about it.
>>
>> Haven't had time/motivation to build B2 in months.
>>
>>
>>> I don't know if he uses the project files or the autotools files.
>>
>> Last few times, I used autoconf/make. There were source code changes
>> that required -D changes in the project files, and I got tired of
>> chasing them up.
>>
>> ...
>>> B2 might be immune to much of this since it avoids the signal handler
>>> stuff in all cases on MacOSX I believe.
>>
>> The versions I built/run/shipped had no signal handler,
>> or always set it to be disabled. Slightly speeding up
>> the screen refresh wasn't an issue when most (game) users
>> complained that BasiliskII was too fast :-)
>>
>> --
>> Nigel Pearson, ni...@in...|"Things  you  own  |
>> Telstra Net. Eng., Sydney, Australia | end up owning you"|
>> Office: 9202 3900    Fax:  9212 6348 |      Tyler,       |
>> Mobile: 0408 664435  Home: 9792 6998 |    Fight Club     |
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

Hi Mike,

I've committed the first two patches you sent. Sorry it took so long,
but I've been really busy lately.

I know it's not related to your code, but looking at the code brought
up some serious concerns.

Particularly struct sigsegv_info_t that's re-declared would be
incomplete if HAVE_MACH_EXCEPTIONS is on.

I've added a big FIXME there, and haven't had the time to investigate
further - but if Screen_fault_handler ends up accessing the extra
fields in that struct - it will be a serious bug (accessing memory
past the end of that structure). This really needs to be fixed (again
it's not your changes, but still..)

-Alexei

On Mon, Feb 9, 2009 at 5:11 PM, Nigel Pearson <ni...@in...> wrote:
> On Mon, 9 Feb, Mike Sliczniak wrote:
>
>> for B2 when building from Unix there is no way to use
>> core audio currently.
>>
>> Did I break it? I don't know. The build from MacOSX uses many of
>> the files
>> from ../Unix. Maybe Nigel can say something about it.
>
> Haven't had time/motivation to build B2 in months.
>
>
>> I don't know if he uses the project files or the autotools files.
>
> Last few times, I used autoconf/make. There were source code changes
> that required -D changes in the project files, and I got tired of
> chasing them up.
>
> ...
>> B2 might be immune to much of this since it avoids the signal handler
>> stuff in all cases on MacOSX I believe.
>
> The versions I built/run/shipped had no signal handler,
> or always set it to be disabled. Slightly speeding up
> the screen refresh wasn't an issue when most (game) users
> complained that BasiliskII was too fast :-)
>
> --
> Nigel Pearson, ni...@in...|"Things  you  own  |
> Telstra Net. Eng., Sydney, Australia | end up owning you"|
> Office: 9202 3900    Fax:  9212 6348 |      Tyler,       |
> Mobile: 0408 664435  Home: 9792 6998 |    Fight Club     |
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Nigel P. <ni...@in...>]

On Mon, 9 Feb, Mike Sliczniak wrote:

> for B2 when building from Unix there is no way to use
> core audio currently.
>
> Did I break it? I don't know. The build from MacOSX uses many of  
> the files
> from ../Unix. Maybe Nigel can say something about it.

Haven't had time/motivation to build B2 in months.


> I don't know if he uses the project files or the autotools files.

Last few times, I used autoconf/make. There were source code changes
that required -D changes in the project files, and I got tired of
chasing them up.

...
> B2 might be immune to much of this since it avoids the signal handler
> stuff in all cases on MacOSX I believe.

The versions I built/run/shipped had no signal handler,
or always set it to be disabled. Slightly speeding up
the screen refresh wasn't an issue when most (game) users
complained that BasiliskII was too fast :-)

--
Nigel Pearson, ni...@in...|"Things  you  own  |
Telstra Net. Eng., Sydney, Australia | end up owning you"|
Office: 9202 3900    Fax:  9212 6348 |      Tyler,       |
Mobile: 0408 664435  Home: 9792 6998 |    Fight Club     |

Re: [B2-devel] PPC JIT

[Jaime C. <jca...@gm...>]

Hi Mike

2009/2/9 Mike Sliczniak <bas...@sp...>:
> Hi,
>
> Beginning in November of 2007 there were a handful of emails about a PPC
> JIT by Bernd Meyer:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=44565d590711261425t241a6e46x7dcaa30c36a4e153%40mail.gmail.com
>
> I think that email maybe referring to this post by umisef:
>
> http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=24264&forum=8&start=20&viewmode=flat&order=0
>
> Did anything come of this? Did Gwenole get a hold of the code?
>
AFAIK nobody has shown any interest on this.

This is sad as Bernd Meyer's backup CDs some day will corrupt the
precious sources :-(

Doesn't anyone understand how a JIT works?


-- 
Saludos/Best Regards
Jaime Cagigal

[B2-devel] PPC JIT

[Mike S. <bas...@sp...>]

Hi,

Beginning in November of 2007 there were a handful of emails about a PPC 
JIT by Bernd Meyer:

http://sourceforge.net/mailarchive/message.php?msg_name=44565d590711261425t241a6e46x7dcaa30c36a4e153%40mail.gmail.com

I think that email maybe referring to this post by umisef:

http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=24264&forum=8&start=20&viewmode=flat&order=0

Did anything come of this? Did Gwenole get a hold of the code?

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Mike S. <bas...@sp...>]

Hi,

On Sun, 8 Feb 2009, C.W. Betts - com...@ho... wrote:

> You are aware that there is a Macintosh GUI for Basilisk II, right?
> Also, I believe there is an audio back-end that uses CoreAudio.

Yes to both, but for B2 when building from Unix there is no way to use 
core audio currently.

Did I break it? I don't know. The build from MacOSX uses many of the files 
from ../Unix. Maybe Nigel can say something about it. I don't know if he 
uses the project files or the autotools files. In any case I don't have 
the 10.2 or 10.3 SDks installed on any mac, and even sometimes I do not 
have the 10.4 SDK installed.

B2 might be immune to much of this since it avoids the signal handler 
stuff in all cases on MacOSX I believe.

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[C.W. B. <com...@ho...>]

On Feb 4, 2009, at 4:15 PM, Mike Sliczniak wrote:

>
> B2
> ./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl- 
> video --enable-sdl-audio --enable-addressing=real --without-esd -- 
> without-gtk --without-mon --without-x
You are aware that there is a Macintosh GUI for Basilisk II, right?   
Also, I believe there is an audio back-end that uses CoreAudio.

[B2-devel] B2 and SS build working .app bundle patch

[Mike S. <bas...@sp...>]

Hi,

Here is a patch that has a shell script cpr.sh to recursively copy 
directories but discarding things that cause problems at least on 10.4 
when making the .app bundles. I have tested the script on 10.4 and 10.5 
and I have built and tested on 32-bit intel 10.5.6 like so:

B2 --disable-standalone-gui --enable-vosf --enable-sdl-video 
--enable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x

SS --disable-standalone-gui --enable-vosf -enable-sdl-video 
--disable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x --enable-jit

Put cpr.sh into BasiliskII/src/Unix and make it executable. Also you need 
to run patch -p0 on BasiliskII-cpr.patch from that dir as well. I noticed 
that in that mega patch earlier I forgot to patch Makefile.in to use 
cpr.sh for BasiliskII. It did not have the problems that SheepShaver did 
with CVS dirs and .SD_Store files on 10.4, but I patched it anyway in case 
someone makes a prefs menu item that uses a .nib file akin to SheepShaver 
in the future.

Also I removed extfs_macosx.h from the 'make links' target as this file is 
gone now and it used to create a broken symlink.

Be careful with make links. If you have already run it in the SheepShaver 
dir and run it again, you will get a mess of symlinks. What I did to test 
is started from a fresh SheepShaver dir from cvs and then added all the 
little patches I have made. Maybe someone should fix make links so that 
sort of stuff does not happen and possibly so it makes relative links not 
absolute ones.

Finally, at this point I cannot provide any more broken down smaller 
patches for the rest. It is too intertwined with these patches I have 
submitted. I need to know what gets accepted and wait until I can do a 
cvs update to send more.

mzs

[B2-devel] B2 and SS sdl audio patch for slow machines

[Mike S. <bas...@sp...>]

Hi,

This patch helps to keep the audio from breaking-up on slow machines when 
using SDL audio. On those slow machines you do still get the break-up 
every so often but the sound tends not to break-up nearly as often. It is 
much better on the ears. Notably often the system beeps do not have a 
pause in them. Slow machine is <= 1 GHz G4.

Also did you get my broken-up patch for the compiling under Leopard and 
Tiger? Do you have any questions?

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Mike S. <bas...@sp...>]

Hi,

I understand your frustration, I'll break-up the patches. Do you want to 
do that patch for the audio or not?

On Wed, 4 Feb 2009, Alexei Svitkine - ale...@gm... wrote:

> For one, I don't like the renaming of main.m in PrefsEditor. It seems

This problem is already there but I'll try something else.

>> -              MacOSX/macos_util_macosx.h MacOSX/extfs_macosx.h \
>> +              MacOSX/macos_util_macosx.h Unix/cpr.sh \

That is because MacOSX/extfs_macosx.h is gone and make links creates a bad 
symlink.

This first patch gets B2 and SS to build under Leopard and Tiger.

I tested this on a 32-bit intel 10.5.6 mac like so:

B2
./autogen.sh --disable-standalone-gui --enable-vosf --enable-sdl-video 
--enable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x

SS
./autogen.sh --disable-standalone-gui --enable-vosf -enable-sdl-video 
--disable-sdl-audio --enable-addressing=real --without-esd --without-gtk 
--without-mon --without-x --enable-jit

There is also a little tweak so that you can use sdl audio in SheepShaver 
when building for Mac OS X.

Tweak this how ever you wish and then I will do a check-out if you decide 
to commit it and make a patch for more of the changes I made.

In this patch I would pay attention of stack_t and maybe you have a better 
way to get around the problems where __darwin_ and __ prefixes were added 
to a number of structures in various releases of Mac OS X so that SS and 
B2 can build under various versions of OS X.

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

If you _really_ want to keep it as one patch, then I'm gonna have to
spend more time reviewing your the full set of changes and asking more
questions.

For one, I don't like the renaming of main.m in PrefsEditor. It seems
it poses a restriction on how things are named which can cause subtle
problems.

Perhaps it would be better have a convention of xyz.ext.o - for
example xyz.cpp.o or xyz.m.o. I've seen this convention used before in
other projects. This way there's no confusion as to what object file
should come from where.

-Alexei

On Wed, Feb 4, 2009 at 4:43 PM, Alexei Svitkine
<ale...@gm...> wrote:
> Smaller patches are easier to review because I can look at the code
> and at the description of what the patch does and see if it
> corresponds. A giant patch of "make things work" is hard to review for
> mistakes.
>
> For example:
>
> -              MacOSX/macos_util_macosx.h MacOSX/extfs_macosx.h \
> +              MacOSX/macos_util_macosx.h Unix/cpr.sh \
>
>
> Why is extfs_macosx.h removed? Is this intentional or a mistake?
>
> if this was part of a smaller patch that described exactly what's
> being added (ex: added cpr.sh to replace cp command), then I would
> know for sure its a mistake. But here I don't know - perhaps its
> related to your other change.
>
> I also don't buy your argument of not being able to test it on the
> other machine. By that logic no other change to the code should be
> made after I add your patch because it's impossible to test on all the
> machines!
>
> I think that its possible to split the patch into incremental changes
> while keeping the end result the same (and thus equivalent to the code
> you tested that worked).
>
> Also if one of the changes causes an issue, its easier to roll back
> just that change instead of the huge patch...
>
> -Alexei
>
> On Wed, Feb 4, 2009 at 2:21 PM, Mike Sliczniak
> <bas...@sp...> wrote:
>> Hi,
>>
>> Good catches.
>>
>> On Tue, 3 Feb 2009, Alexei Svitkine - ale...@gm... wrote:
>>
>>> Also I don't see the why you're replace cp -f with cpr.sh. It should
>>> only replace cp -R.
>>
>> Resource forks and extended attrs don't need to be conserved.
>>
>>> Also you have an "i" for some reason after an #undef:
>>>
>>> +#undef       MACH_EXCEPTION_CODES                                    i
>>
>> I use vim, that was a stray insert when I was already in insert. Get rid
>> of that i. Luckily cpp does not care about that, but I got lucky.
>>
>>> > Also from a quick glance, this makes no sense:
>>> >
>>> >  sigsegv_address_t sigsegv_get_fault_instruction_address(sigsegv_info_t *SIP)
>>> >  {
>>> >  #ifdef HAVE_MACH_EXCEPTIONS
>>> > +#ifdef HAVE_MACH_EXCEPTIONS
>>> >        if (!SIP->has_thr_state) {
>>> >                mach_get_thread_state(SIP);
>>> >
>>> >                SIP->pc = (sigsegv_address_t)SIGSEGV_FAULT_INSTRUCTION;
>>> >        }
>>> >  #endif
>>> > +#endif
>>> >        return SIP->pc;
>>> >  }
>>
>> That should be #ifdef EMULATED_PPC instead of #ifdef HAVE_MACH_EXCEPTIONS.
>> I never tested the sigsegv instruction skipper so that is why I did not
>> notice this one. When you are building for a PPC, SIGUSR2 is used for the
>> interrrupt trigger and signal handlers instead of the mach exception
>> handling. If you do thread_get_state here you get a crash since you are
>> getting the state of your own running thread which is not suspended. I
>> believe that Gwenole tried to get the signal handlers working together
>> with mach exceptions sometime back after I added the mach exception stuff
>> to BasiliskII but was not successful and so that is why it is the way it
>> is. Also back then I did not understand how SheepShaver (since I never
>> needed it) worked so I was no help. One of the things I want to
>> investigate is if thread_suspend and mach exception handlers instead of
>> signal handlers would be an improvement.
>>
>> About breaking-up the patches. I would rather not. Also some are in the
>> same files, would you like patches that do not patch cleanly or would you
>> like me to submit a patch and wait then prepare another? I'm not too
>> comfortable with that because like I wrote before, the PPC 10.4 machine I
>> had to test and build on has died. I am afraid to perturb too much and
>> make a set of patches that do not build or run on 10.4. What I did to
>> create this is I made some patches to the code until I got it to compile
>> and run on one combination of os and cpu and then I tried it on another. I
>> tweaked until it worked on the new one and then I learned that those no
>> longer worked on the previous. I had to do that for a few combinations of
>> different options for SheepShaver and BasiliskII on three machines. It
>> took a lot of trial and error (and time) to get a nice set of patches that
>> worked on every combination I had access to.
>>
>> But here is a description if that helps:
>>
>> The sdl audio change is easy to see. If you do not want that one, that is
>> fine, it only makes things more tolerable on slower machines. (Meaning the
>> system beep tends not to break-up.) It is only a change to a single
>> file.
>>
>> The other source code changes are all about getting it to compile under
>> Tiger and Leopard.
>>
>> The cpr.sh was to get .app bundles that worked right on Tiger because if
>> they had extra detritus they would not work right. Leopard was much more
>> forgiving.
>>
>> The changes to the autoconf stuff, most of it was to support building with
>> a prebuilt SDL framework, it is pretty easy to see what belongs with that.
>> Then there is a smidge so that you can have SDL audio if you wish even
>> with OS X. The rest are little tweaks to get it to build and link a
>> working binary for Tiger and Leopard.
>>
>> The two new files and the changes to the GUI prefseditor files were for
>> the build to continue to work correctly after adding the option of the SDL
>> Framework build.
>>
>> Let me know if you have other concerns especially about the patches to the
>> code or want me to do something in a different way like you only want me
>> to patch a subset and forget about the rest.
>>
>> mzs
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

Smaller patches are easier to review because I can look at the code
and at the description of what the patch does and see if it
corresponds. A giant patch of "make things work" is hard to review for
mistakes.

For example:

-	       MacOSX/macos_util_macosx.h MacOSX/extfs_macosx.h \
+	       MacOSX/macos_util_macosx.h Unix/cpr.sh \


Why is extfs_macosx.h removed? Is this intentional or a mistake?

if this was part of a smaller patch that described exactly what's
being added (ex: added cpr.sh to replace cp command), then I would
know for sure its a mistake. But here I don't know - perhaps its
related to your other change.

I also don't buy your argument of not being able to test it on the
other machine. By that logic no other change to the code should be
made after I add your patch because it's impossible to test on all the
machines!

I think that its possible to split the patch into incremental changes
while keeping the end result the same (and thus equivalent to the code
you tested that worked).

Also if one of the changes causes an issue, its easier to roll back
just that change instead of the huge patch...

-Alexei

On Wed, Feb 4, 2009 at 2:21 PM, Mike Sliczniak
<bas...@sp...> wrote:
> Hi,
>
> Good catches.
>
> On Tue, 3 Feb 2009, Alexei Svitkine - ale...@gm... wrote:
>
>> Also I don't see the why you're replace cp -f with cpr.sh. It should
>> only replace cp -R.
>
> Resource forks and extended attrs don't need to be conserved.
>
>> Also you have an "i" for some reason after an #undef:
>>
>> +#undef       MACH_EXCEPTION_CODES                                    i
>
> I use vim, that was a stray insert when I was already in insert. Get rid
> of that i. Luckily cpp does not care about that, but I got lucky.
>
>> > Also from a quick glance, this makes no sense:
>> >
>> >  sigsegv_address_t sigsegv_get_fault_instruction_address(sigsegv_info_t *SIP)
>> >  {
>> >  #ifdef HAVE_MACH_EXCEPTIONS
>> > +#ifdef HAVE_MACH_EXCEPTIONS
>> >        if (!SIP->has_thr_state) {
>> >                mach_get_thread_state(SIP);
>> >
>> >                SIP->pc = (sigsegv_address_t)SIGSEGV_FAULT_INSTRUCTION;
>> >        }
>> >  #endif
>> > +#endif
>> >        return SIP->pc;
>> >  }
>
> That should be #ifdef EMULATED_PPC instead of #ifdef HAVE_MACH_EXCEPTIONS.
> I never tested the sigsegv instruction skipper so that is why I did not
> notice this one. When you are building for a PPC, SIGUSR2 is used for the
> interrrupt trigger and signal handlers instead of the mach exception
> handling. If you do thread_get_state here you get a crash since you are
> getting the state of your own running thread which is not suspended. I
> believe that Gwenole tried to get the signal handlers working together
> with mach exceptions sometime back after I added the mach exception stuff
> to BasiliskII but was not successful and so that is why it is the way it
> is. Also back then I did not understand how SheepShaver (since I never
> needed it) worked so I was no help. One of the things I want to
> investigate is if thread_suspend and mach exception handlers instead of
> signal handlers would be an improvement.
>
> About breaking-up the patches. I would rather not. Also some are in the
> same files, would you like patches that do not patch cleanly or would you
> like me to submit a patch and wait then prepare another? I'm not too
> comfortable with that because like I wrote before, the PPC 10.4 machine I
> had to test and build on has died. I am afraid to perturb too much and
> make a set of patches that do not build or run on 10.4. What I did to
> create this is I made some patches to the code until I got it to compile
> and run on one combination of os and cpu and then I tried it on another. I
> tweaked until it worked on the new one and then I learned that those no
> longer worked on the previous. I had to do that for a few combinations of
> different options for SheepShaver and BasiliskII on three machines. It
> took a lot of trial and error (and time) to get a nice set of patches that
> worked on every combination I had access to.
>
> But here is a description if that helps:
>
> The sdl audio change is easy to see. If you do not want that one, that is
> fine, it only makes things more tolerable on slower machines. (Meaning the
> system beep tends not to break-up.) It is only a change to a single
> file.
>
> The other source code changes are all about getting it to compile under
> Tiger and Leopard.
>
> The cpr.sh was to get .app bundles that worked right on Tiger because if
> they had extra detritus they would not work right. Leopard was much more
> forgiving.
>
> The changes to the autoconf stuff, most of it was to support building with
> a prebuilt SDL framework, it is pretty easy to see what belongs with that.
> Then there is a smidge so that you can have SDL audio if you wish even
> with OS X. The rest are little tweaks to get it to build and link a
> working binary for Tiger and Leopard.
>
> The two new files and the changes to the GUI prefseditor files were for
> the build to continue to work correctly after adding the option of the SDL
> Framework build.
>
> Let me know if you have other concerns especially about the patches to the
> code or want me to do something in a different way like you only want me
> to patch a subset and forget about the rest.
>
> mzs
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Mike S. <bas...@sp...>]

Hi,

Good catches.

On Tue, 3 Feb 2009, Alexei Svitkine - ale...@gm... wrote:

> Also I don't see the why you're replace cp -f with cpr.sh. It should
> only replace cp -R.

Resource forks and extended attrs don't need to be conserved.

> Also you have an "i" for some reason after an #undef:
>
> +#undef       MACH_EXCEPTION_CODES                                    i

I use vim, that was a stray insert when I was already in insert. Get rid 
of that i. Luckily cpp does not care about that, but I got lucky.

> > Also from a quick glance, this makes no sense:
> >
> >  sigsegv_address_t sigsegv_get_fault_instruction_address(sigsegv_info_t *SIP)
> >  {
> >  #ifdef HAVE_MACH_EXCEPTIONS
> > +#ifdef HAVE_MACH_EXCEPTIONS
> >        if (!SIP->has_thr_state) {
> >                mach_get_thread_state(SIP);
> >
> >                SIP->pc = (sigsegv_address_t)SIGSEGV_FAULT_INSTRUCTION;
> >        }
> >  #endif
> > +#endif
> >        return SIP->pc;
> >  }

That should be #ifdef EMULATED_PPC instead of #ifdef HAVE_MACH_EXCEPTIONS. 
I never tested the sigsegv instruction skipper so that is why I did not 
notice this one. When you are building for a PPC, SIGUSR2 is used for the 
interrrupt trigger and signal handlers instead of the mach exception 
handling. If you do thread_get_state here you get a crash since you are 
getting the state of your own running thread which is not suspended. I 
believe that Gwenole tried to get the signal handlers working together 
with mach exceptions sometime back after I added the mach exception stuff 
to BasiliskII but was not successful and so that is why it is the way it 
is. Also back then I did not understand how SheepShaver (since I never 
needed it) worked so I was no help. One of the things I want to 
investigate is if thread_suspend and mach exception handlers instead of 
signal handlers would be an improvement.

About breaking-up the patches. I would rather not. Also some are in the 
same files, would you like patches that do not patch cleanly or would you 
like me to submit a patch and wait then prepare another? I'm not too 
comfortable with that because like I wrote before, the PPC 10.4 machine I 
had to test and build on has died. I am afraid to perturb too much and 
make a set of patches that do not build or run on 10.4. What I did to 
create this is I made some patches to the code until I got it to compile 
and run on one combination of os and cpu and then I tried it on another. I 
tweaked until it worked on the new one and then I learned that those no 
longer worked on the previous. I had to do that for a few combinations of 
different options for SheepShaver and BasiliskII on three machines. It 
took a lot of trial and error (and time) to get a nice set of patches that 
worked on every combination I had access to.

But here is a description if that helps:

The sdl audio change is easy to see. If you do not want that one, that is 
fine, it only makes things more tolerable on slower machines. (Meaning the 
system beep tends not to break-up.) It is only a change to a single 
file.

The other source code changes are all about getting it to compile under 
Tiger and Leopard.

The cpr.sh was to get .app bundles that worked right on Tiger because if 
they had extra detritus they would not work right. Leopard was much more 
forgiving.

The changes to the autoconf stuff, most of it was to support building with 
a prebuilt SDL framework, it is pretty easy to see what belongs with that. 
Then there is a smidge so that you can have SDL audio if you wish even 
with OS X. The rest are little tweaks to get it to build and link a 
working binary for Tiger and Leopard.

The two new files and the changes to the GUI prefseditor files were for 
the build to continue to work correctly after adding the option of the SDL 
Framework build.

Let me know if you have other concerns especially about the patches to the 
code or want me to do something in a different way like you only want me 
to patch a subset and forget about the rest.

mzs

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

Also I don't see the why you're replace cp -f with cpr.sh. It should
only replace cp -R.

Also you have an "i" for some reason after an #undef:

+#undef	MACH_EXCEPTION_CODES					i

-Alexei

On Tue, Feb 3, 2009 at 2:05 PM, Alexei Svitkine
<ale...@gm...> wrote:
> Can you provide separate patches for each of the issues you're addressing?
>
> Also from a quick glance, this makes no sense:
>
>  sigsegv_address_t sigsegv_get_fault_instruction_address(sigsegv_info_t *SIP)
>  {
>  #ifdef HAVE_MACH_EXCEPTIONS
> +#ifdef HAVE_MACH_EXCEPTIONS
>        if (!SIP->has_thr_state) {
>                mach_get_thread_state(SIP);
>
>                SIP->pc = (sigsegv_address_t)SIGSEGV_FAULT_INSTRUCTION;
>        }
>  #endif
> +#endif
>        return SIP->pc;
>  }
>
> -Alexei
>
> On Mon, Feb 2, 2009 at 7:32 PM, Mike Sliczniak
> <bas...@sp...> wrote:
>> Hi,
>>
>> I had some trouble building BasiliskII and SheepShaver on a handful of
>> Macs. Here are some patches:
>>
>>   http://home.fnal.gov/~mzs/b2.tar.bz2
>>
>> There a NOTES.txt file in there that describes everything.
>>
>> During the course ot this one of the macs got sick, but I am pretty
>> confident that this patch would still work for 32-bit PPC on Tiger.
>>
>> mzs
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>

Re: [B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Alexei S. <ale...@gm...>]

Can you provide separate patches for each of the issues you're addressing?

Also from a quick glance, this makes no sense:

 sigsegv_address_t sigsegv_get_fault_instruction_address(sigsegv_info_t *SIP)
 {
 #ifdef HAVE_MACH_EXCEPTIONS
+#ifdef HAVE_MACH_EXCEPTIONS
 	if (!SIP->has_thr_state) {
 		mach_get_thread_state(SIP);

 		SIP->pc = (sigsegv_address_t)SIGSEGV_FAULT_INSTRUCTION;
 	}
 #endif
+#endif
 	return SIP->pc;
 }

-Alexei

On Mon, Feb 2, 2009 at 7:32 PM, Mike Sliczniak
<bas...@sp...> wrote:
> Hi,
>
> I had some trouble building BasiliskII and SheepShaver on a handful of
> Macs. Here are some patches:
>
>   http://home.fnal.gov/~mzs/b2.tar.bz2
>
> There a NOTES.txt file in there that describes everything.
>
> During the course ot this one of the macs got sick, but I am pretty
> confident that this patch would still work for 32-bit PPC on Tiger.
>
> mzs
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

[B2-devel] Fixes for BasiliskII and SheepShaver for Mac OS X 10.4 and 10.5 ppc and intel

[Mike S. <bas...@sp...>]

Hi,

I had some trouble building BasiliskII and SheepShaver on a handful of 
Macs. Here are some patches:

   http://home.fnal.gov/~mzs/b2.tar.bz2

There a NOTES.txt file in there that describes everything.

During the course ot this one of the macs got sick, but I am pretty 
confident that this patch would still work for 32-bit PPC on Tiger.

mzs