basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] [Patch] Use default ROM when ROM path preference is blank

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

They have more recent builds than that if you dig deeper - such as from this
summer. You can also try betas of the new launcher I made, which uses
.sheepvm bundles (see
http://www.emaculation.com/forum/viewtopic.php?t=5754&start=25 ).
Either way, I suggest making a post on those forums asking them to put a
sticky up with newer builds.

Or you can build it yourself from source.

Making builds is not as simple as it sounds. First, people want UB builds,
which is a little painful to make since you have to compile twice and then
merge them. Then, you gotta make sure they're compatible with Tiger, so you
need a Tiger system. Then, you have to decide what the various options that
people want in it are - there's too many for SS and I don't know what other
people use. Additionally, a Windows build to correspond to the Mac one for
the same date should be provided. And don't get me started on Linux and
BeOS.

Then, there's the issue with "official" builds and version numbers. Do I
have the right to bump the version number to 2.4 just because I have CVS
access? I don't know. Also, the only site that's official is Gwenole's,
which I can't edit. Oh and when there's new versions, someone needs to go
and upload them to sites like MacUpdate and VersionTracker and friends.

So all in all, its a complicated story. Perhaps some part of it can be
solved technically (like making scripts to build a Tiger-compatible UB of SS
on a Leopard or Snow Leopard Intel system).

-Alexei

On Sun, Oct 4, 2009 at 2:13 PM, Kevin Jaques <kev...@hi...>wrote:

> If only! The last official build was 2006. Even the last unofficial build
> for Mac OS X was July 2008. See
> http://emaculation.com/doku.php/sheepshaver#sheepshaver_for_mac_os_x.
> I know you have no duty to help us, and even just posting your knowledge on
> this forum is a kindness, but it seems like such a small additional step, if
> you guys are compiling from the latest patch, to simply upload the result.
>
> On Oct. 4, 2009, at 11:40 , Alexei Svitkine wrote:
>
> Updated builds of SS are usually available on the SheepShaver forums at
> emaculation.com.
> -Alexei
>
> On Sun, Oct 4, 2009 at 1:27 PM, Lew Irwin/Studio Briefing <st...@us...>wrote:
>
>> I do not have the technical expertise to understand the patches discussed
>> in your recent message (and how they may affect the performance of
>> SheepShaver). Is there another upgrade or complete build of SS that I can
>> (should?) install?
>>
>>
>> On Tue, Aug 25, 2009 at 5:12 PM, Alexei Svitkine <
>> ale...@gm...> wrote:
>>
>>> Committed with modifications. I changed the strlen(rom_path) to
>>> *rom_path to make it O(1). Thanks.
>>>
>>> -Alexei
>>>
>>> On Mon, Aug 24, 2009 at 8:39 PM, Michael Schmitt<msb2ssdev@me> wrote:
>>> > Attached is a patch to SheepShaver, to fix a problem where the ROM file
>>> can
>>> > only be found on the first boot.
>>> >
>>> > When a user creates a new SheepShaver machine, there is no preference
>>> file,
>>> > so there is not ROM path preference. SheepShaver has logic so that in
>>> this
>>> > case, it will look for a ROM file named "ROM" or "Mac OS ROM" in the
>>> current
>>> > directory.
>>> >
>>> > The user starts SheepShaver in order to get to the built-in Preferences
>>> > Editor, and changes various settings (such as creation of a hard disk).
>>> Then
>>> > the user reboots.
>>> >
>>> > If the user forgot to set the ROM path at this time, then SheepShaver
>>> can no
>>> > longer boot. The only recourse is for the user to find and delete the
>>> > preferences file, or use an external preferences editor to set the ROM
>>> path.
>>> >
>>> > The fix is to change SheepShaver to use the default ROM names when
>>> either
>>> > the rom path is null (no preference) OR an empty string (preference
>>> exists
>>> > with no rom path).
>>> >
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> > trial. Simplify your report design, integration and deployment - and
>>> focus
>>> > on
>>> > what you do best, core application coding. Discover what's new with
>>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> > _______________________________________________
>>> > basilisk-devel mailing list
>>> > bas...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>> >
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>
>>>
>>
>>
>> --
>> Lew Irwin
>> STUDIO BRIEFING
>> st...@us...
>> (818) 865-0044
>> Fax: (815) 333-2765
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
> --
>
> Sincerely, Kevin Jaques (at home)
>
>
> Use ja...@hi... for work related messages
>
>
> "Send lawyers, guns and money! Dad get me out of this!" - Warren Zevon
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [Patch] Use default ROM when ROM path preference is blank

[Kevin J. <kev...@hi...>]

If only! The last official build was 2006. Even the last unofficial  
build for Mac OS X was July 2008. See http://emaculation.com/doku.php/sheepshaver#sheepshaver_for_mac_os_x 
.

I know you have no duty to help us, and even just posting your  
knowledge on this forum is a kindness, but it seems like such a small  
additional step, if you guys are compiling from the latest patch, to  
simply upload the result.

On Oct. 4, 2009, at 11:40 , Alexei Svitkine wrote:

> Updated builds of SS are usually available on the SheepShaver forums  
> at emaculation.com.
>
> -Alexei
>
> On Sun, Oct 4, 2009 at 1:27 PM, Lew Irwin/Studio Briefing <st...@us... 
> > wrote:
> I do not have the technical expertise to understand the patches  
> discussed in your recent message (and how they may affect the  
> performance of SheepShaver). Is there another upgrade or complete  
> build of SS that I can (should?) install?
>
>
>
> On Tue, Aug 25, 2009 at 5:12 PM, Alexei Svitkine <ale...@gm... 
> > wrote:
> Committed with modifications. I changed the strlen(rom_path) to
> *rom_path to make it O(1). Thanks.
>
> -Alexei
>
> On Mon, Aug 24, 2009 at 8:39 PM, Michael Schmitt<msb2ssdev@me> wrote:
> > Attached is a patch to SheepShaver, to fix a problem where the ROM  
> file can
> > only be found on the first boot.
> >
> > When a user creates a new SheepShaver machine, there is no  
> preference file,
> > so there is not ROM path preference. SheepShaver has logic so that  
> in this
> > case, it will look for a ROM file named "ROM" or "Mac OS ROM" in  
> the current
> > directory.
> >
> > The user starts SheepShaver in order to get to the built-in  
> Preferences
> > Editor, and changes various settings (such as creation of a hard  
> disk). Then
> > the user reboots.
> >
> > If the user forgot to set the ROM path at this time, then  
> SheepShaver can no
> > longer boot. The only recourse is for the user to find and delete  
> the
> > preferences file, or use an external preferences editor to set the  
> ROM path.
> >
> > The fix is to change SheepShaver to use the default ROM names when  
> either
> > the rom path is null (no preference) OR an empty string  
> (preference exists
> > with no rom path).
> >
> >
> >
> >
> >  
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports  
> 2008 30-Day
> > trial. Simplify your report design, integration and deployment -  
> and focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
>
>
> -- 
> Lew Irwin
> STUDIO BRIEFING
> st...@us...
> (818) 865-0044
> Fax: (815) 333-2765
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

--
Sincerely, Kevin Jaques (at home)

Use ja...@hi... for work related messages

"Send lawyers, guns and money! Dad get me out of this!" - Warren Zevon

Re: [B2-devel] [Patch] Use default ROM when ROM path preference is blank

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

Updated builds of SS are usually available on the SheepShaver forums at
emaculation.com.
-Alexei

On Sun, Oct 4, 2009 at 1:27 PM, Lew Irwin/Studio Briefing <st...@us...>wrote:

> I do not have the technical expertise to understand the patches discussed
> in your recent message (and how they may affect the performance of
> SheepShaver). Is there another upgrade or complete build of SS that I can
> (should?) install?
>
>
> On Tue, Aug 25, 2009 at 5:12 PM, Alexei Svitkine <
> ale...@gm...> wrote:
>
>> Committed with modifications. I changed the strlen(rom_path) to
>> *rom_path to make it O(1). Thanks.
>>
>> -Alexei
>>
>> On Mon, Aug 24, 2009 at 8:39 PM, Michael Schmitt<msb2ssdev@me> wrote:
>> > Attached is a patch to SheepShaver, to fix a problem where the ROM file
>> can
>> > only be found on the first boot.
>> >
>> > When a user creates a new SheepShaver machine, there is no preference
>> file,
>> > so there is not ROM path preference. SheepShaver has logic so that in
>> this
>> > case, it will look for a ROM file named "ROM" or "Mac OS ROM" in the
>> current
>> > directory.
>> >
>> > The user starts SheepShaver in order to get to the built-in Preferences
>> > Editor, and changes various settings (such as creation of a hard disk).
>> Then
>> > the user reboots.
>> >
>> > If the user forgot to set the ROM path at this time, then SheepShaver
>> can no
>> > longer boot. The only recourse is for the user to find and delete the
>> > preferences file, or use an external preferences editor to set the ROM
>> path.
>> >
>> > The fix is to change SheepShaver to use the default ROM names when
>> either
>> > the rom path is null (no preference) OR an empty string (preference
>> exists
>> > with no rom path).
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> > trial. Simplify your report design, integration and deployment - and
>> focus
>> > on
>> > what you do best, core application coding. Discover what's new with
>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > basilisk-devel mailing list
>> > bas...@li...
>> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>>
>
>
> --
> Lew Irwin
> STUDIO BRIEFING
> st...@us...
> (818) 865-0044
> Fax: (815) 333-2765
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [Patch] Use default ROM when ROM path preference is blank

[Lew Irwin/S. B. <st...@us...>]

I do not have the technical expertise to understand the patches discussed in
your recent message (and how they may affect the performance of
SheepShaver). Is there another upgrade or complete build of SS that I can
(should?) install?


On Tue, Aug 25, 2009 at 5:12 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Committed with modifications. I changed the strlen(rom_path) to
> *rom_path to make it O(1). Thanks.
>
> -Alexei
>
> On Mon, Aug 24, 2009 at 8:39 PM, Michael Schmitt<msb2ssdev@me> wrote:
> > Attached is a patch to SheepShaver, to fix a problem where the ROM file
> can
> > only be found on the first boot.
> >
> > When a user creates a new SheepShaver machine, there is no preference
> file,
> > so there is not ROM path preference. SheepShaver has logic so that in
> this
> > case, it will look for a ROM file named "ROM" or "Mac OS ROM" in the
> current
> > directory.
> >
> > The user starts SheepShaver in order to get to the built-in Preferences
> > Editor, and changes various settings (such as creation of a hard disk).
> Then
> > the user reboots.
> >
> > If the user forgot to set the ROM path at this time, then SheepShaver can
> no
> > longer boot. The only recourse is for the user to find and delete the
> > preferences file, or use an external preferences editor to set the ROM
> path.
> >
> > The fix is to change SheepShaver to use the default ROM names when either
> > the rom path is null (no preference) OR an empty string (preference
> exists
> > with no rom path).
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>


-- 
Lew Irwin
STUDIO BRIEFING
st...@us...
(818) 865-0044
Fax: (815) 333-2765

Re: [B2-devel] [Patch] Use default ROM when ROM path preference is blank

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

Committed with modifications. I changed the strlen(rom_path) to
*rom_path to make it O(1). Thanks.

-Alexei

On Mon, Aug 24, 2009 at 8:39 PM, Michael Schmitt<msb2ssdev@me> wrote:
> Attached is a patch to SheepShaver, to fix a problem where the ROM file can
> only be found on the first boot.
>
> When a user creates a new SheepShaver machine, there is no preference file,
> so there is not ROM path preference. SheepShaver has logic so that in this
> case, it will look for a ROM file named "ROM" or "Mac OS ROM" in the current
> directory.
>
> The user starts SheepShaver in order to get to the built-in Preferences
> Editor, and changes various settings (such as creation of a hard disk). Then
> the user reboots.
>
> If the user forgot to set the ROM path at this time, then SheepShaver can no
> longer boot. The only recourse is for the user to find and delete the
> preferences file, or use an external preferences editor to set the ROM path.
>
> The fix is to change SheepShaver to use the default ROM names when either
> the rom path is null (no preference) OR an empty string (preference exists
> with no rom path).
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [Patch] Init NVRAM to enable PPC memory manager

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

Committed. Thanks.

-Alexei

On Mon, Aug 24, 2009 at 8:29 PM, Michael Schmitt<msb2ssdev@me> wrote:
> Attached is a patch to SheepShaver, to fix a SIGSEGV crash that occurs when
> booting a new machine with OS 7.5.
>
> One of the bytes in the xPRAM portion of the NVRAM controls which version of
> the system memory manager is used by OS 7.5: the legacy 680x0 memory manager
> or the PPC memory manager (aka the "Modern Memory Manager"). OS 7.5 is
> supposed to be able to use either one, but for some reason SheepShaver
> crashes on boot if the 680x0 version is used.
>
> Later Mac OS versions don't have this problem. They don't support the 680x0
> version, so they force the PPC version to be used.
>
> The fix is to have SheepShaver initialize the NVRAM to use the PPC memory
> manager. Note: This is supposed to be the default in OS 7.5.
>
> This affects when a new NVRAM file is used, or when it is initialized after
> doing zapping the PRAM.
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] [Patch] Use default ROM when ROM path preference is blank

[Michael S. <msb...@me...>]

Attached is a patch to SheepShaver, to fix a problem where the ROM  
file can only be found on the first boot.

When a user creates a new SheepShaver machine, there is no preference  
file, so there is not ROM path preference. SheepShaver has logic so  
that in this case, it will look for a ROM file named "ROM" or "Mac OS  
ROM" in the current directory.

The user starts SheepShaver in order to get to the built-in  
Preferences Editor, and changes various settings (such as creation of  
a hard disk). Then the user reboots.

If the user forgot to set the ROM path at this time, then SheepShaver  
can no longer boot. The only recourse is for the user to find and  
delete the preferences file, or use an external preferences editor to  
set the ROM path.

The fix is to change SheepShaver to use the default ROM names when  
either the rom path is null (no preference) OR an empty string  
(preference exists with no rom path).

[B2-devel] [Patch] Init NVRAM to enable PPC memory manager

[Michael S. <msb...@me...>]

Attached is a patch to SheepShaver, to fix a SIGSEGV crash that occurs  
when booting a new machine with OS 7.5.

One of the bytes in the xPRAM portion of the NVRAM controls which  
version of the system memory manager is used by OS 7.5: the legacy  
680x0 memory manager or the PPC memory manager (aka the "Modern Memory  
Manager"). OS 7.5 is supposed to be able to use either one, but for  
some reason SheepShaver crashes on boot if the 680x0 version is used.

Later Mac OS versions don't have this problem. They don't support the  
680x0 version, so they force the PPC version to be used.

The fix is to have SheepShaver initialize the NVRAM to use the PPC  
memory manager. Note: This is supposed to be the default in OS 7.5.

This affects when a new NVRAM file is used, or when it is initialized  
after doing zapping the PRAM.

Re: [B2-devel] [patch] Port SheepShaver's precise timer to OS X

[Michael S. <msb...@me...>]

Yes, it works. Thanks.

On Aug 21, 2009, at 12:40 PM, Alexei Svitkine wrote:

> I've changed the include to what you suggested. Does it build fine  
> on Tiger now?
>
> -Alexei
>
> On Wed, Aug 19, 2009 at 1:03 AM, Michael Schmitt<msb2ssdev@me> wrote:
>> I think I see the problem:
>>
>> timer_unix.cpp is including <mach/mach_host.h>, but it should be  
>> <mach/
>> mach.h>.
>>
>> mach_current_time() is actually defined in mach_init.h.
>>
>> On Leopard mach_host.h includes mach_init.h. On Tiger it does not.

Re: [B2-devel] [patch] Port SheepShaver's precise timer to OS X

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

I've changed the include to what you suggested. Does it build fine on Tiger now?

-Alexei

On Wed, Aug 19, 2009 at 1:03 AM, Michael Schmitt<msb2ssdev@me> wrote:
> I think I see the problem:
>
> timer_unix.cpp is including <mach/mach_host.h>, but it should be <mach/
> mach.h>.
>
> mach_current_time() is actually defined in mach_init.h.
>
> On Leopard mach_host.h includes mach_init.h. On Tiger it does not.
>
>
> On Aug 18, 2009, at 9:53 PM, Michael Schmitt wrote:
>
>> We've got a build problem:
>>
>> Using current CVS, including your timer changes, I can build on OS X
>> 10.5 successfully.
>>
>> But if I build with OS X 10.4 as the deployment target (e.g. using
>> the 10.4 SDK) then it fails:
>>
>> timer_unix.cpp: In function ‘void mach_current_time(tm_time_t&)’:
>> timer_unix.cpp:44: error: ‘mach_host_self’ was not declared in this
>> scope
>>
>>
>>
>> On Aug 17, 2009, at 2:29 PM, Charles Srstka wrote:
>>
>>> Attached is a set of patches to port the precise timer that is
>>> currently used in the Linux and BeOS builds of SheepShaver to Mac
>>> OS X (and any other Mach-based operating systems).
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] [patch] Port SheepShaver's precise timer to OS X

[Michael S. <msb...@me...>]

I think I see the problem:

timer_unix.cpp is including <mach/mach_host.h>, but it should be <mach/ 
mach.h>.

mach_current_time() is actually defined in mach_init.h.

On Leopard mach_host.h includes mach_init.h. On Tiger it does not.


On Aug 18, 2009, at 9:53 PM, Michael Schmitt wrote:

> We've got a build problem:
>
> Using current CVS, including your timer changes, I can build on OS X  
> 10.5 successfully.
>
> But if I build with OS X 10.4 as the deployment target (e.g. using  
> the 10.4 SDK) then it fails:
>
> timer_unix.cpp: In function ‘void mach_current_time(tm_time_t&)’:
> timer_unix.cpp:44: error: ‘mach_host_self’ was not declared in this  
> scope
>
>
>
> On Aug 17, 2009, at 2:29 PM, Charles Srstka wrote:
>
>> Attached is a set of patches to port the precise timer that is  
>> currently used in the Linux and BeOS builds of SheepShaver to Mac  
>> OS X (and any other Mach-based operating systems).
>

Re: [B2-devel] [patch] Port SheepShaver's precise timer to OS X

[Michael S. <msb...@me...>]

We've got a build problem:

Using current CVS, including your timer changes, I can build on OS X  
10.5 successfully.

But if I build with OS X 10.4 as the deployment target (e.g. using the  
10.4 SDK) then it fails:

timer_unix.cpp: In function ‘void mach_current_time(tm_time_t&)’:
timer_unix.cpp:44: error: ‘mach_host_self’ was not declared in this  
scope



On Aug 17, 2009, at 2:29 PM, Charles Srstka wrote:

> Attached is a set of patches to port the precise timer that is  
> currently used in the Linux and BeOS builds of SheepShaver to Mac OS  
> X (and any other Mach-based operating systems).

Re: [B2-devel] [Patch] Fix for memory allocation errors on Leopard

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

Committed. Thanks.

-Alexei

On Sun, Aug 16, 2009 at 7:21 PM, Michael Schmitt<msb2ssdev@me> wrote:
> Attached is a patch to SheepShaver to fix memory allocation problems when OS
> X 10.5 is the host. It also relaxes the 512 MB RAM limit on OS X hosts.
>
>
>
>
>
> Problem
> -------
> Some users have been unable to run SheepShaver on OS X 10.5 (Leopard) hosts.
> The symptom is error "ERROR: Cannot map RAM: File already exists".
>
> SheepShaver allocates RAM at fixed addresses. If it is running in "Real"
> addressing mode, and can't allocate at address 0, then it was hard-coded to
> allocate the RAM area at 0x20000000. The ROM area as allocated at
> 0x40800000.
>
> The normal configuration is for SheepShaver to run under SDL, which is a
> Cocoa wrapper. By the time SheepShaver does its memory allocations, the
> Cocoa application has already started. The result is the SheepShaver memory
> address space already contains libraries, fonts, Input Managers, and IOKit
> areas.
>
> On Leopard hosts these areas can land on the same addresses SheepShaver
> needs, so SheepShaver's memory allocation fails.
>
>
> Solution
> --------
> The approach is to change SheepShaver (on Unix & OS X hosts) to allocate the
> RAM area anywhere it can find the space, rather than at a fixed address.
>
> This could result in the RAM allocated higher than the ROM area, which
> causes a crash. To prevent this from occurring, the RAM and ROM areas are
> allocated contiguously.
>
> Previously the ROM starting address was a constant ROM_BASE, which was used
> throughout the source files. The ROM start address is now a variable
> ROMBase. ROMBase is allocated and set by main_*.cpp just like RAMBase.
>
> A side-effect of this change is that it lifts the 512 MB RAM limit for OS X
> hosts. The limit was because the fixed RAM and ROM addresses were such that
> the RAM could only be 512 MB before it overlapped the ROM area.
>
>
> Impact
> ------
> The change to make ROMBase a variable is throughout all hosts & addressing
> modes.
>
> The RAM and ROM areas will only shift when run on Unix & OS X hosts,
> otherwise the same fixed allocation address is used as before.
>
> This change is limited to "Real" addressing mode. Unlike Basilisk II,
> SheepShaver *pre-calculates* the offset for "Direct" addressing mode; the
> offset is compiled into the program. If the RAM address were allowed to
> shift, it could result in the RAM area wrapping around address 0.
>
>
> Changes to main_unix.cpp
> ------------------------
> 1. Real addressing mode no longer defines a RAM_BASE constant.
>
> 2. The base address of the Mac ROM (ROMBase) is defined and exported by this
> program.
>
> 3. Memory management helper vm_mac_acquire is renamed to
> vm_mac_acquire_fixed. Added a new memory management helper vm_mac_acquire,
> which allocates memory at any address.
>
> 4. Changed and rearranged the allocation of RAM and ROM areas.
>
> Before it worked like this:
>
>   - Allocate ROM area
>   - If can, attempt to allocate RAM at address zero
>   - If RAM not allocated at 0, allocate at fixed address
>
> We still want to try allocating the RAM at zero, and if using DIRECT
> addressing we're still going to use the fixed addresses. So we don't know
> where the ROM should be until after we do the RAM. The new logic is:
>
>   - If can, attempt to allocate RAM at address zero
>   - If RAM not allocated at 0
>       if REAL addressing
>          allocate RAM and ROM together. The ROM address is aligned to a 1 MB
> boundary
>       else (direct addressing)
>          allocate RAM at fixed address
>   - If ROM hasn't been allocated yet, allocate at fixed address
>
> 5. Calculate ROMBase and ROMBaseHost based on where the ROM was loaded.
>
> 6. There is a crash if the RAM is allocated too high. To try and catch this,
> check if it was allocated higher than the kernel data address.
>
> 7. Change subsequent code from using constant ROM_BASE to variable ROMBase.
>
>
> Changes to Other Programs
> -------------------------
> emul_op.cpp, main.cpp, name_registery.cpp, rom_patches.cpp,
> rsrc_patches.cpp, emul_ppc.cpp, sheepshaver_glue.cpp, ppc-translate-cpp:
> Change from constant ROM_BASE to variable ROMBase.
>
> ppc_asm.S: It was setting register to a hard-coded literal address:
> 0x40b0d000. Changed to set it to ROMBase + 0x30d000.
>
> ppc_asm.tmpl: It defined a macro ASM_LO16 but it assumed that the macro
> would always be used with operands that included a register specification.
> This is not true. Moved the register specification from the macro to the
> macro invocations.
>
> main_beos.cpp, main_windows.cpp: Since the subprograms are all expecting a
> variable ROMBase, all the main_*.cpp pgrams have to define and export it.
> The ROM_BASE constant is moved here for consistency. The mains for beos and
> windows just allocate the ROM at the same fixed address as before, set
> ROMBaseHost and ROMBase to that address, and then use ROMBase for the
> subsequent code.
>
> cpu_emulation.h: removed ROM_BASE constant. This value is moved to the
> main_*.cpp modules, to be consistent with RAM_BASE.
>
> user_strings_unix.cpp, user_strings_unix.h: Added new error messages related
> to errors that occur when the RAM and ROM are allocated anywhere.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [Patch] Fix for memory allocation errors on Leopard

[Joshua J. <jj...@gm...>]

On Aug 16, 2009, at 4:21 PM, Michael Schmitt wrote:

> SheepShaver allocates RAM at fixed addresses. If it is running in  
> "Real" addressing mode, and can't allocate at address 0, then it  
> was hard-coded to allocate the RAM area at 0x20000000. The ROM area  
> as allocated at 0x40800000.

Perhaps you mean "area WAS allocated"?

Josh

Re: [B2-devel] [patch] Port SheepShaver's precise timer to OS X

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

Committed. Thanks.

-Alexei

On Mon, Aug 17, 2009 at 3:29 PM, Charles
Srstka<bas...@ch...> wrote:
> Attached is a set of patches to port the precise timer that is currently
> used in the Linux and BeOS builds of SheepShaver to Mac OS X (and any other
> Mach-based operating systems).
>
> Currently, the Linux build uses the clock_gettime() function to get
> nanosecond-precision time, and falls back on gettimeofday() if it is not
> present. Unfortunately, Mac OS X does not currently support clock_gettime(),
> and gettimeofday() has only microsecond granularity. The Mach kernel,
> however, has a clock_get_time() function that does very nearly the same
> thing as clock_gettime(). The patches to BasiliskII cause the timing
> functions such as timer_current_time() to use clock_get_time() instead of
> gettimeofday() on Mach-based systems that do not support clock_gettime().
>
> The changes to SheepShaver involve the precise timer. The existing code for
> Linux uses pthreads and real-time signals to handle the timing. Mac OS X
> unfortunately does not seem to support real-time signals, so Mach calls are
> again used to suspend and resume the timer thread in order to attempt to
> duplicate the Linux and BeOS versions of the timer. The code is somewhat
> ugly right now, as I decided to leave alone the pre-existing style of the
> source file, which unfortunately involves #ifdefs scattered throughout the
> file and some duplication of code. A future patch may want to clean this up
> to separate out the OS-specific code and put it all together at the top of
> the file. However, for the time being, this seems to work.
>
> This has not been extensively tested, because I have not been able to get my
> hands on a good test-case app for the classic Mac OS that would run inside
> the emulator and try out the timer. However, performance does seem to be
> better than with the pre-existing code, and nothing seems to have blown up
> as far as I can tell. I did find a game via a Google search -  Cap'n Magneto
> - that is known to have problems with Basilisk/SheepShaver's legacy 60 Hz
> timer, and the opening fade-to-color for this game appears to run much more
> smoothly with the precise timer code in place.
>
> I hope that you find these patches satisfactory.
>
>
>
>
> Charles
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] [patch] Port SheepShaver's precise timer to OS X

[Charles S. <bas...@ch...>]

Attached is a set of patches to port the precise timer that is  
currently used in the Linux and BeOS builds of SheepShaver to Mac OS X  
(and any other Mach-based operating systems).

Currently, the Linux build uses the clock_gettime() function to get  
nanosecond-precision time, and falls back on gettimeofday() if it is  
not present. Unfortunately, Mac OS X does not currently support  
clock_gettime(), and gettimeofday() has only microsecond granularity.  
The Mach kernel, however, has a clock_get_time() function that does  
very nearly the same thing as clock_gettime(). The patches to  
BasiliskII cause the timing functions such as timer_current_time() to  
use clock_get_time() instead of gettimeofday() on Mach-based systems  
that do not support clock_gettime().

The changes to SheepShaver involve the precise timer. The existing  
code for Linux uses pthreads and real-time signals to handle the  
timing. Mac OS X unfortunately does not seem to support real-time  
signals, so Mach calls are again used to suspend and resume the timer  
thread in order to attempt to duplicate the Linux and BeOS versions of  
the timer. The code is somewhat ugly right now, as I decided to leave  
alone the pre-existing style of the source file, which unfortunately  
involves #ifdefs scattered throughout the file and some duplication of  
code. A future patch may want to clean this up to separate out the OS- 
specific code and put it all together at the top of the file. However,  
for the time being, this seems to work.

This has not been extensively tested, because I have not been able to  
get my hands on a good test-case app for the classic Mac OS that would  
run inside the emulator and try out the timer. However, performance  
does seem to be better than with the pre-existing code, and nothing  
seems to have blown up as far as I can tell. I did find a game via a  
Google search -  Cap'n Magneto - that is known to have problems with  
Basilisk/SheepShaver's legacy 60 Hz timer, and the opening fade-to- 
color for this game appears to run much more smoothly with the precise  
timer code in place.

I hope that you find these patches satisfactory.

[B2-devel] [Patch] Fix for memory allocation errors on Leopard

[Michael S. <msb...@me...>]

Attached is a patch to SheepShaver to fix memory allocation problems  
when OS X 10.5 is the host. It also relaxes the 512 MB RAM limit on OS  
X hosts.

Re: [B2-devel] [patch] Fix to misleading memory allocation error messages in SheepShaver

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

Thanks. Committed.

-Alexei

On Sun, Aug 9, 2009 at 7:45 PM, Michael Schmitt<msb2ssdev@me> wrote:
> Attached is a patch to Basilisk II, to fix a problem seen in SheepShaver.
>
> SheepShaver includes the C errno string in many error messages. One case is
> when it calls the memory allocation routines in the Basilisk II vm_alloc.cpp
> program.
>
> This works when the memory allocation routine uses functions that set errno
> (such as mmap or malloc). For example, running SheepShaver on a Linux hosts
> produces meaningful error messages.
>
> The problem is that when run on an OS X host, the memory allocation uses
> Mach routines such as vm_allocate, which do not set errno.
>
> So when SheepShaver reported the error, it used a stale value of errno,
> which happened to be 17. The result was an extremely misleading error
> message: "Cannot map RAM: File already exists".
>
> The fix is to change vm_alloc so that it translates Mac return codes into
> POSIX errno values.
>
> It also initializes errno to 0 at the start of the memory allocation
> routine, so that no matter what path it takes, it won't return a stale
> value.
>
> There are no changes to the calling programs.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Build and run failures from current CVS

[Joshua J. <jj...@gm...>]

On May 29, 2009, at 8:25 AM, Joshua Juran wrote:

> On May 28, 2009, at 3:45 PM, Joshua Juran wrote:
>
>> Hello,
>>
>> I've updated my Basilisk II and SheepShaver CVS checkouts.   
>> Basilisk II builds and works as expected on 10.4 "Tiger", but the  
>> build fails on 10.5 "Leopard".  SheepShaver builds on either but  
>> dies on launch.
>>
>> Basilisk II build errors on Leopard:
>>
>>> gcc  -arch i386 -I../include -I. -I../uae_cpu -I../slirp - 
>>> Igen.i386 -DHAVE_CONFIG_H  -DOS_darwin -DBSD_COMP - 
>>> DDIRECT_ADDRESSING -D_REENTRANT -DAQUA -DFPU_IEEE - 
>>> DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" - 
>>> DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -g -O2 - 
>>> fomit-frame-pointer -mdynamic-no-pic -g -c sshpty.c -o obj.i386/ 
>>> sshpty.o
>>> sshpty.c: In function ‘pty_allocate’:
>>> sshpty.c:148: error: ‘mysig_t’ undeclared (first use in this  
>>> function)
>>> sshpty.c:148: error: (Each undeclared identifier is reported only  
>>> once
>>> sshpty.c:148: error: for each function it appears in.)
>>> sshpty.c:148: error: syntax error before ‘old_signal’
>>> sshpty.c:155: error: ‘old_signal’ undeclared (first use in this  
>>> function)
>>> sshpty.c:183: error: ‘I_PUSH’ undeclared (first use in this  
>>> function)
>>> make[1]: *** [obj.i386/sshpty.o] Error 1
>>> make: *** [BasiliskII.i386] Error 2
>
> I got past this by passing no_dev_ptmx=1 to configure.  Basilisk II  
> builds and runs, but Macsbug no longer works.  I get an  
> "unimplemented trap" system error right after "Welcome to Mac OS"  
> unless I disable Macsbug.  This works fine in my build from August  
> 7, 2008.

The problem occurs when building on Leopard only.  A Tiger-built  
binary runs on Leopard.

>> SheepShaver console output:
>>
>>> Unrecognized option '-psn_0_616824833'
>>> Usage: /Users/jjuran/src/cebix/SheepShaver/src/Unix/ 
>>> SheepShaver.app/Contents/MacOS/SheepShaver [OPTION...]
>>>
>>> Unix options:
>>>   --display STRING
>>>     X display to use
>
> Basilisk II checks for this in its OS X main().  SheepShaver  
> doesn't have an OS X main(), just a Unix main(), and a brief look  
> through CVS suggests it never checked for the psn option.  Where's  
> the native OS X shell for SheepShaver?

Ah, right,  SDL.

I have SheepShaver running now, and I'm investigating a new crash in  
one of my apps.

Josh

Re: [B2-devel] Build and run failures from current CVS

[Joshua J. <jj...@gm...>]

On May 28, 2009, at 3:45 PM, Joshua Juran wrote:

> Hello,
>
> I've updated my Basilisk II and SheepShaver CVS checkouts.   
> Basilisk II builds and works as expected on 10.4 "Tiger", but the  
> build fails on 10.5 "Leopard".  SheepShaver builds on either but  
> dies on launch.
>
> Basilisk II build errors on Leopard:
>
>> gcc  -arch i386 -I../include -I. -I../uae_cpu -I../slirp - 
>> Igen.i386 -DHAVE_CONFIG_H  -DOS_darwin -DBSD_COMP - 
>> DDIRECT_ADDRESSING -D_REENTRANT -DAQUA -DFPU_IEEE - 
>> DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" - 
>> DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -g -O2 - 
>> fomit-frame-pointer -mdynamic-no-pic -g -c sshpty.c -o obj.i386/ 
>> sshpty.o
>> sshpty.c: In function ‘pty_allocate’:
>> sshpty.c:148: error: ‘mysig_t’ undeclared (first use in this  
>> function)
>> sshpty.c:148: error: (Each undeclared identifier is reported only  
>> once
>> sshpty.c:148: error: for each function it appears in.)
>> sshpty.c:148: error: syntax error before ‘old_signal’
>> sshpty.c:155: error: ‘old_signal’ undeclared (first use in this  
>> function)
>> sshpty.c:183: error: ‘I_PUSH’ undeclared (first use in this function)
>> make[1]: *** [obj.i386/sshpty.o] Error 1
>> make: *** [BasiliskII.i386] Error 2

I got past this by passing no_dev_ptmx=1 to configure.  Basilisk II  
builds and runs, but Macsbug no longer works.  I get an  
"unimplemented trap" system error right after "Welcome to Mac OS"  
unless I disable Macsbug.  This works fine in my build from August 7,  
2008.

> SheepShaver console output:
>
>> Unrecognized option '-psn_0_616824833'
>> Usage: /Users/jjuran/src/cebix/SheepShaver/src/Unix/ 
>> SheepShaver.app/Contents/MacOS/SheepShaver [OPTION...]
>>
>> Unix options:
>>   --display STRING
>>     X display to use

Basilisk II checks for this in its OS X main().  SheepShaver doesn't  
have an OS X main(), just a Unix main(), and a brief look through CVS  
suggests it never checked for the psn option.  Where's the native OS  
X shell for SheepShaver?

Josh

[B2-devel] [PATCH] Don't suppress dotfiles (other than . and ..) in extfs

[Joshua J. <jj...@gm...>]

Suppressing all dotfiles is overkill.  It's perfectly valid for a  
user to create or rename a file so it begins with a dot, and various  
programs use dotfiles for their own purposes.

Also, the means to write Mac apps that don't inadvertently open  
drivers (FSpOpenDF()) has been available for two decades.


Index: extfs.cpp
===================================================================
RCS file: /home/cvs/cebix/BasiliskII/src/extfs.cpp,v
retrieving revision 1.36
diff -u -r1.36 extfs.cpp
--- extfs.cpp	20 Jun 2008 00:39:47 -0000	1.36
+++ extfs.cpp	28 May 2009 23:18:54 -0000
@@ -1245,6 +1245,18 @@
  	return (int16)r.d[0];
  }

+static bool is_dot_or_dotdot( const char* name )
+{
+	if ( name[0] == '.' )
+	{
+		const bool dotdot = name[1] == '.';
+		
+		return name[ 1 + dotdot ] == '\0';
+	}
+	
+	return false;
+}
+
  // Query file attributes (HFileParam)
  static int16 fs_get_file_info(uint32 pb, bool hfs, uint32 dirID)
  {
@@ -1283,7 +1295,7 @@
  				closedir(d);
  				return fnfErr;
  			}
-			if (de->d_name[0] == '.')
+			if (is_dot_or_dotdot(de->d_name))
  				goto read_next_de;	// Suppress names beginning with '.' (MacOS  
could interpret these as driver names)
  			//!! suppress directories
  		}
@@ -1406,7 +1418,7 @@
  				closedir(d);
  				return fnfErr;
  			}
-			if (de->d_name[0] == '.')
+			if (is_dot_or_dotdot(de->d_name))
  				goto read_next_de;	// Suppress names beginning with '.' (MacOS  
could interpret these as driver names)
  		}
  		add_path_comp(de->d_name);
@@ -1465,7 +1477,7 @@
  					de = readdir(d);
  					if (de == NULL)
  						break;
-					if (de->d_name[0] == '.')
+					if (is_dot_or_dotdot(de->d_name))
  						continue;	// Suppress names beginning with '.'
  					count++;
  				}

[B2-devel] Build and run failures from current CVS

[Joshua J. <jj...@gm...>]

Hello,

I've updated my Basilisk II and SheepShaver CVS checkouts.  Basilisk  
II builds and works as expected on 10.4 "Tiger", but the build fails  
on 10.5 "Leopard".  SheepShaver builds on either but dies on launch.

Basilisk II build errors on Leopard:

> gcc  -arch i386 -I../include -I. -I../uae_cpu -I../slirp -Igen.i386  
> -DHAVE_CONFIG_H  -DOS_darwin -DBSD_COMP -DDIRECT_ADDRESSING - 
> D_REENTRANT -DAQUA -DFPU_IEEE -DUNALIGNED_PROFITABLE - 
> DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY - 
> DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -g -O2 -fomit-frame-pointer  
> -mdynamic-no-pic -g -c sshpty.c -o obj.i386/sshpty.o
> sshpty.c: In function ‘pty_allocate’:
> sshpty.c:148: error: ‘mysig_t’ undeclared (first use in this function)
> sshpty.c:148: error: (Each undeclared identifier is reported only once
> sshpty.c:148: error: for each function it appears in.)
> sshpty.c:148: error: syntax error before ‘old_signal’
> sshpty.c:155: error: ‘old_signal’ undeclared (first use in this  
> function)
> sshpty.c:183: error: ‘I_PUSH’ undeclared (first use in this function)
> make[1]: *** [obj.i386/sshpty.o] Error 1
> make: *** [BasiliskII.i386] Error 2


SheepShaver console output:

> SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
> 2009-05-28 15:34:42.732 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x414d10 of class NSPathStore2 autoreleased with no pool  
> in place - just leaking
> 2009-05-28 15:34:42.732 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x414160 of class NSCFString autoreleased with no pool  
> in place - just leaking
> 2009-05-28 15:34:42.733 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x416770 of class NSPathStore2 autoreleased with no pool  
> in place - just leaking
> 2009-05-28 15:34:42.733 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x417340 of class NSCFString autoreleased with no pool  
> in place - just leaking
> 2009-05-28 15:34:42.733 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x416a10 of class NSMenuItem autoreleased with no pool  
> in place - just leaking
> 2009-05-28 15:34:42.733 SheepShaver[29754] *** _NSAutoreleaseNoPool 
> (): Object 0x7816fe2c of class NSCFString autoreleased with no pool  
> in place - just leaking
> Unrecognized option '-psn_0_616824833'
> Usage: /Users/jjuran/src/cebix/SheepShaver/src/Unix/SheepShaver.app/ 
> Contents/MacOS/SheepShaver [OPTION...]
>
> Unix options:
>   --display STRING
>     X display to use
>
> General options:
>   --disk STRING
>     device/file name of Mac volume [default=/Users/jjuran/Data/ 
> macos9.0.4.vol]
>   --floppy STRING
>     device/file name of Mac floppy drive [default=none]
>   --cdrom STRING
>     device/file names of Mac CD-ROM drive [default=none]
>   --extfs STRING
>     root path of ExtFS [default=/Users/jjuran/Data/Shared/]
>   --scsi0 STRING
>     SCSI target for Mac SCSI ID 0 [default=none]
>   --scsi1 STRING
>     SCSI target for Mac SCSI ID 1 [default=none]
>   --scsi2 STRING
>     SCSI target for Mac SCSI ID 2 [default=none]
>   --scsi3 STRING
>     SCSI target for Mac SCSI ID 3 [default=none]
>   --scsi4 STRING
>     SCSI target for Mac SCSI ID 4 [default=none]
>   --scsi5 STRING
>     SCSI target for Mac SCSI ID 5 [default=none]
>   --scsi6 STRING
>     SCSI target for Mac SCSI ID 6 [default=none]
>   --screen STRING
>     video mode [default=win/800/600]
>   --windowmodes NUMBER
>     bitmap of allowed window video modes [default=0]
>   --screenmodes NUMBER
>     bitmap of allowed fullscreen video modes [default=0]
>   --seriala STRING
>     device name of Mac serial port A [default=/dev/cu.usbmodem]
>   --serialb STRING
>     device name of Mac serial port B [default=/dev/null]
>   --rom STRING
>     path of ROM file [default=/Users/jjuran/Library/ROM Images/ROM  
> Update 1.0]
>   --bootdrive NUMBER
>     boot drive number [default=0]
>   --bootdriver NUMBER
>     boot driver number [default=0]
>   --ramsize NUMBER
>     size of Mac RAM in bytes [default=536870912]
>   --frameskip NUMBER
>     number of frames to skip in refreshed video modes [default=8]
>   --gfxaccel BOOL
>     turn on QuickDraw acceleration [default=true]
>   --nocdrom BOOL
>     don't install CD-ROM driver [default=false]
>   --nonet BOOL
>     don't use Ethernet [default=false]
>   --nosound BOOL
>     don't enable sound output [default=false]
>   --nogui BOOL
>     disable GUI [default=true]
>   --noclipconversion BOOL
>     don't convert clipboard contents [default=false]
>   --ignoresegv BOOL
>     ignore illegal memory accesses [default=true]
>   --jit BOOL
>     enable JIT compiler [default=true]
>   --jit68k BOOL
>     enable 68k DR emulator [default=false]
>   --keyboardtype NUMBER
>     hardware keyboard type [default=5]
>
> Platform-specific options:
>   --ether STRING
>     device name of Mac ethernet adapter [default=slirp]
>   --etherconfig STRING
>     path of network config script [default=none]
>   --keycodes BOOL
>     use keycodes rather than keysyms to decode keyboard [default=true]
>   --keycodefile STRING
>     path of keycode translation file [default=/Users/jjuran/ 
> Applications/SheepShaver-2.3/keycodes.sdl]
>   --mousewheelmode NUMBER
>     mouse wheel support mode (0=page up/down, 1=cursor up/down)  
> [default=0]
>   --mousewheellines NUMBER
>     number of lines to scroll in mouse wheel mode 1 [default=3]
>   --dsp STRING
>     audio output (dsp) device name [default=/dev/dsp]
>   --mixer STRING
>     audio mixer device name [default=/dev/mixer]
>   --ignoresegv BOOL
>     ignore illegal memory accesses [default=true]
>   --idlewait BOOL
>     sleep when idle [default=true]
>
> Boolean options are specified as '--OPTION true|on|yes' or
> '--OPTION false|off|no'.


The key is "Unrecognized option '-psn_0_616824833'" -- it's not  
expecting to be invoked as a Mac application.

I used these commands to build, in src/Unix:

NO_CONFIGURE=1 ACLOCAL_FLAGS="-I m4" ./autogen.sh
./configure --enable-sdl-static --enable-sdl-video --enable-sdl-audio  
--enable-vosf=no
make
make SheepShaver_app

Josh

Re: [B2-devel] Two dreams of mine

[Eagle <ea...@li...>]

CW--

You bring up an excellent point: my goal is not necessarily to emulate  
the NeXT hardware.  Put simply my real goal is to be able to run some  
m68k-only NeXT applications, and since we already have x86 versions of  
NeXTSTEP/OPENSTEP, it may be better to emulate just the CPU in  
NeXTSTEP/OPENSTEP-x86 itself, rather than trying to emulate the entire  
platform.  This would be similar to what Apple did for the m68k-to-PPC  
conversion, which allowed the direct execution of m68k Mac OS apps on  
the PPC platform.

I'll check on QEMU - thanks.

On May 18, 2009, at 19:34, C.W. Betts wrote:

> The PowerPC Mac Emulator might be possible.  The main thing missing  
> is the Memory Management Unit in SheepShaver.  You could try using  
> PearPC to get it working, but there is no guarantee that it would  
> work with that old of Mac OS X.
>
> As for getting a NeXT emulator, that would require some more work.   
> The chips are completely different and thus would require a lot of  
> re-write.  My advice is ask the Qemu mailing list about this.  While  
> their m68k emulator is different than Basilisk II's, Qemu is capable  
> of implementing different computer architectures on the same  
> processor base.
> On May 15, 2009, at 8:14 PM, Eagle wrote:
>
>> Greetings, all.
>>
>> I love SheepShaver and Basilisk, but I have two dreams related to  
>> them:
>> 1- a NeXT hardware emulator (m68k)
>> 2- a PPC Mac emulator capable of running OS X Server v1.2.
>>
>> The reason I want the first one is to be able to run Improv, which
>> unfortunately was never released as a fat binary - it is m68k only. :
>> (  So, even though I'm running OPENSTEP in VMware, I still can't run
>> Improv.
>>
>> The reason I want the second one is because I no longer have a PPC  
>> Mac
>> capable of running OS X Server.  SheepShaver is a great emulator, but
>> there is no support for running OS X Server v 1.x on it.  Sure I  
>> could
>> run Rhapsody DR2 in VMware, but I want to be able to run Blue Box and
>> play with all the other stuff that came in OS X Server.
>>
>> Is there any hope for these two things?  I have no idea what it would
>> take to do something like this...
>>
>> Apologies to those of you who are on the nextcomputers.org website  
>> and
>> have seen this there.
>>
>> Thanks!
>>
>> Eagle
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables
>> unlimited royalty-free distribution of the report engine
>> for externally facing server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Two dreams of mine

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

The PowerPC Mac Emulator might be possible.  The main thing missing is  
the Memory Management Unit in SheepShaver.  You could try using PearPC  
to get it working, but there is no guarantee that it would work with  
that old of Mac OS X.

As for getting a NeXT emulator, that would require some more work.   
The chips are completely different and thus would require a lot of re- 
write.  My advice is ask the Qemu mailing list about this.  While  
their m68k emulator is different than Basilisk II's, Qemu is capable  
of implementing different computer architectures on the same processor  
base.
On May 15, 2009, at 8:14 PM, Eagle wrote:

> Greetings, all.
>
> I love SheepShaver and Basilisk, but I have two dreams related to  
> them:
> 1- a NeXT hardware emulator (m68k)
> 2- a PPC Mac emulator capable of running OS X Server v1.2.
>
> The reason I want the first one is to be able to run Improv, which
> unfortunately was never released as a fat binary - it is m68k only. :
> (  So, even though I'm running OPENSTEP in VMware, I still can't run
> Improv.
>
> The reason I want the second one is because I no longer have a PPC Mac
> capable of running OS X Server.  SheepShaver is a great emulator, but
> there is no support for running OS X Server v 1.x on it.  Sure I could
> run Rhapsody DR2 in VMware, but I want to be able to run Blue Box and
> play with all the other stuff that came in OS X Server.
>
> Is there any hope for these two things?  I have no idea what it would
> take to do something like this...
>
> Apologies to those of you who are on the nextcomputers.org website and
> have seen this there.
>
> Thanks!
>
> Eagle
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Two dreams of mine

[Eagle <ea...@li...>]

Greetings, all.

I love SheepShaver and Basilisk, but I have two dreams related to them:
1- a NeXT hardware emulator (m68k)
2- a PPC Mac emulator capable of running OS X Server v1.2.

The reason I want the first one is to be able to run Improv, which  
unfortunately was never released as a fat binary - it is m68k only. : 
(  So, even though I'm running OPENSTEP in VMware, I still can't run  
Improv.

The reason I want the second one is because I no longer have a PPC Mac  
capable of running OS X Server.  SheepShaver is a great emulator, but  
there is no support for running OS X Server v 1.x on it.  Sure I could  
run Rhapsody DR2 in VMware, but I want to be able to run Blue Box and  
play with all the other stuff that came in OS X Server.

Is there any hope for these two things?  I have no idea what it would  
take to do something like this...

Apologies to those of you who are on the nextcomputers.org website and  
have seen this there.

Thanks!

Eagle