basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] 64bit network driver

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

I was under the impression that the recent Git master has source code for the 64-bit and 32-bit Windows drivers. You will have to compile them; I think they're written using Visual Studio, and Visual Studio Express might not be enough.
> From: jj...@gm...
> Date: Thu, 30 Aug 2012 02:52:55 -0700
> To: bas...@li...
> Subject: Re: [B2-devel] 64bit network driver
> 
> On Aug 29, 2012, at 7:48 AM, Olivier Renaud wrote:
> 
> > I need this driver asap, and would pay for it, anyone interested in  
> > developing it?
> >
> 
> Is this for Basilisk II or SheepShaver, and on what host platform?
> 
> Josh
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
 		 	   		  

Re: [B2-devel] 64bit network driver

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

On Aug 29, 2012, at 7:48 AM, Olivier Renaud wrote:

> I need this driver asap, and would pay for it, anyone interested in  
> developing it?
>

Is this for Basilisk II or SheepShaver, and on what host platform?

Josh

Re: [B2-devel] How do I play games in SheepShaver?

[Frank T. <fra...@gm...>]

As Ronald mentions, this list is not really for general support. From an
implementation perspective, though, I do have a few suggestions.

If you are trying to run software that was also available for Windows, I
would advise that you instead try running the Windows versions of Baldur's
gate in Wine or in a Wintel emulator. SheepShaver and other Macintosh
emulators are still a bit rough and do not have full hardware graphics
acceleration.

If you do need a working copy of SheepShaver for 10.6 or later, try
installing this (
http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html )
in /Applications. You will need to supply your own boot volume image at
/Applications/SheepShaver-2.3/Support/Classic_Drive_1.img. The SheepShaver
Assistant generates a profile for you.

I have a few notes below as well. In order to keep the list uncluttered, it
might be best if you posted any additional responses just to me instead of
to the list.

On Tue, Aug 14, 2012 at 8:32 PM, Pål Hart <mon...@ya...> wrote:

> Sorry to bother you, but this email is listed under support on the
> SheepShaver official website. Emaculation forum is also listed but its
> complete garbage; It says my email is already used so I can't register but
> it has no way to recover my username/password and it has no support and I'm
> not willing to make anymore effort than that to use their website.
>
> So, I did a search the other day for an OS 9 emulator, specifically for
> the purpose of playing Baldur's Gate, Baldur's Gate 2, and a couple other
> OS 9 games I miss playing. I found this video (
> http://www.youtube.com/watch?v=WrrT9_4Jdbs) which contains a link to a
> RapidShare dl of SheepShaver. I've heard of SheepShaver before, but the
> Download link on the official website doesn't have a link to download the
> app in this way, and its not worth additional effort so I never got the
> program.
>
> The problem is there's only half a gig on the disc image that the program
> boots from.


You can rectify this by generating a new system boot volume or by adding an
additional volume. Use dd if=/dev/zero (with other options such as count
and bs as necessary) in order to make an empty disk image of the size
desired. Add that image as a disk line to ~/.sheepshaver_prefs (preferably
after the original drive). Launch SheepShaver. Tell it to initialize the
new volume. You can then copy stuff to it, including the System folder. If
you make the new disk bootable, you can remove the old one from
~/.sheepshaver_prefs.

Alternatively, you can install stuff into UNIX directories. (This works
better on Mac O.S. than on Linux for reasons that I have not had the
opportunity to explore.)

Now, I can add 1 game to it (Baldur's Gate Tales of The Sword Coast in this
> case) however it requires a disc to play, and the disc mounts on my OSX
> desktop which isn't acknowledged in the OS9 environment.


As Ronald mentions, Lion seems to have some problems with this.


> I tried making a disc image, but it can't be put onto it because of space
> limitation. Navigating to it through "Unix" I couldn't run the dmg anyway.
> So I downloaded a little program called Disk Copy 6.4 that claimed to allow
> OS9 to run .dmg, however when I try I get an error -50.
>
> Dump the disk into a flat image file via dd. (You can determine the device
name of the disk in Disk Utility; it is probably /dev/disk1.) Copy that
file (so that the original never gets modified), and mount it in
SheepShaver. SheepShaver ought to allow you to drag-and-drop disk images
for mounting. If that does not work for you, you can add the disk to your
configuration file at ~/.sheepshaver_prefs as mentioned previously.


> I'm running Lion in a late '09 MBP (I also have an '07 24" iMac AL) but
> I'm upgrading to Mountain Lion tomorrow. I use my iMac as my
> desktop/storage comp so I have a 2.5TB drive on it so I'm going to make a
> partition and install SL on it, so I can run PPC games and apps using
> Rosetta. Will SheepShaver run better on SL?


Aside from the CD-ROM issue, I have not seen a difference in stability or
performance.


> Both my comps are intel otherwise I'd install Tiger on a partition too.
> Thank you for taking the time to read and reply to this message.
>
>                         Sincerely,
>                                 -Pål Hart
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] BasiliskII compilation issues

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

On Sat, Aug 18, 2012 at 7:28 PM, Giulio Paci <giu...@gm...> wrote:
> Hi Alexei,
>         looking at the sigsegv.cpp sources, I noticed an "#epif". Is it a typo?

Oops, yes that's a typo. Fixed now. Thanks!

>
> Bests,
>         Giulio.
>
> Il 18/08/2012 16:29, Giulio Paci ha scritto:
>> Il 12/08/2012 19:17, Alexei Svitkine ha scritto:
>>> This should now be fixed in TOT in the git repo. You'll need to re-run
>>> autogen.sh.
>>
>> I confirm that the fix is working properly: both compilation and
>> execution work.
>>
>> Thank you very much.
>>
>>> On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote:
>>>> On 09/08/2012 06:27, Alexei Svitkine wrote:
>>>>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
>>>>>> Hi to all,
>>>>>>
>>>>>> On 09/06/2012 20:44, Giulio Paci wrote:
>>>>>>> Basilisk II has been accepted into Debian unstable.
>>>>>>> Unfortunately the first upload is not compiling properly in most of the
>>>>>>> supported architectures, as it is described by this compilation report:
>>>>>>> https://buildd.debian.org/status/package.php?p=basilisk2
>>>>>>
>>>>>> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
>>>>>> For kfreebsd Alexei Svitkine committed a fix, that is working.
>>>>>>
>>>>>> For armel the building procedure reports:
>>>>>>
>>>>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
>>>>>> declared in this scope
>>>>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
>>>>>> gmake: *** [obj/sigsegv.o] Error 1
>>>>>> gmake: *** Waiting for unfinished jobs....
>>>>>> *** Error code 2
>>>>>
>>>>> Those line numbers don't look right to me. Do you have local edits to the file?
>>>>
>>>> No I have not, however this report is not about the latest version in
>>>> git (that is still failing with the same error message, about 800 lines
>>>> below): it is about the codebase I used to build the Debian package
>>>> (i.e., a CVS snapshot at the end of march).
>>>>
>>>>>> I had a quick look to this issue, but, once again, the fix is beyond my
>>>>>> knowledge and I found no useful information about it on the web (only
>>>>>> people experimenting this issue, but no solution). Unfortunately I also
>>>>>> had very few time last month, so I was not able to do anything useful
>>>>>> about this issue.
>>>>>> I have installed a Debian armel using qemu, so I have access to an armel
>>>>>> system now. If anyone wants to propose a solution for this issue I will
>>>>>> be able to try it. If anyone is interested I can also share the VM image.
>>>>
>>>>> Please share the VM image
>>>>
>>>> boot.sh: a script that can be used to start the VM (using qemu)
>>>> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU
>>>>
>>>> boot.tar.bz2: the /boot directory containing the kernel to start the VM
>>>> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8
>>>>
>>>> debian-testing-armel.qcow.bz2: the image of a current Debian testing
>>>> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8
>>>>
>>>> To run the VM, install qemu with arm support, untar the boot.tar.bz2,
>>>> expand debian-testing-armel.qcow.bz2 and run the script.
>>>>
>>>> There is a "root" user and a "debian" user.
>>>> The password for both is "debian".
>>>> The "debian" user already has macemu git repository in its home
>>>> (~/Source/macemu), and BasiliskII has already been configured. Running
>>>> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error.
>>>>
>>>> In ~/Source/debian-packages/basilisk2 there are the sources of the
>>>> Debian package. To compile it you can run "git-buildpackage
>>>> --git-ignore-new", and compilation should fail with the error above.
>>>>
>>>>> and I'll try to take a look at it as time permits. Thanks.
>>>>
>>>> Thank you very much for your help.
>>>>
>>>> Bests,
>>>>         Giulio.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> basilisk-devel mailing list
>>>> bas...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Hi Alexei,
	looking at the sigsegv.cpp sources, I noticed an "#epif". Is it a typo?

Bests,
	Giulio.

Il 18/08/2012 16:29, Giulio Paci ha scritto:
> Il 12/08/2012 19:17, Alexei Svitkine ha scritto:
>> This should now be fixed in TOT in the git repo. You'll need to re-run
>> autogen.sh.
> 
> I confirm that the fix is working properly: both compilation and
> execution work.
> 
> Thank you very much.
> 
>> On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote:
>>> On 09/08/2012 06:27, Alexei Svitkine wrote:
>>>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
>>>>> Hi to all,
>>>>>
>>>>> On 09/06/2012 20:44, Giulio Paci wrote:
>>>>>> Basilisk II has been accepted into Debian unstable.
>>>>>> Unfortunately the first upload is not compiling properly in most of the
>>>>>> supported architectures, as it is described by this compilation report:
>>>>>> https://buildd.debian.org/status/package.php?p=basilisk2
>>>>>
>>>>> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
>>>>> For kfreebsd Alexei Svitkine committed a fix, that is working.
>>>>>
>>>>> For armel the building procedure reports:
>>>>>
>>>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
>>>>> declared in this scope
>>>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
>>>>> gmake: *** [obj/sigsegv.o] Error 1
>>>>> gmake: *** Waiting for unfinished jobs....
>>>>> *** Error code 2
>>>>
>>>> Those line numbers don't look right to me. Do you have local edits to the file?
>>>
>>> No I have not, however this report is not about the latest version in
>>> git (that is still failing with the same error message, about 800 lines
>>> below): it is about the codebase I used to build the Debian package
>>> (i.e., a CVS snapshot at the end of march).
>>>
>>>>> I had a quick look to this issue, but, once again, the fix is beyond my
>>>>> knowledge and I found no useful information about it on the web (only
>>>>> people experimenting this issue, but no solution). Unfortunately I also
>>>>> had very few time last month, so I was not able to do anything useful
>>>>> about this issue.
>>>>> I have installed a Debian armel using qemu, so I have access to an armel
>>>>> system now. If anyone wants to propose a solution for this issue I will
>>>>> be able to try it. If anyone is interested I can also share the VM image.
>>>
>>>> Please share the VM image
>>>
>>> boot.sh: a script that can be used to start the VM (using qemu)
>>> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU
>>>
>>> boot.tar.bz2: the /boot directory containing the kernel to start the VM
>>> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8
>>>
>>> debian-testing-armel.qcow.bz2: the image of a current Debian testing
>>> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8
>>>
>>> To run the VM, install qemu with arm support, untar the boot.tar.bz2,
>>> expand debian-testing-armel.qcow.bz2 and run the script.
>>>
>>> There is a "root" user and a "debian" user.
>>> The password for both is "debian".
>>> The "debian" user already has macemu git repository in its home
>>> (~/Source/macemu), and BasiliskII has already been configured. Running
>>> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error.
>>>
>>> In ~/Source/debian-packages/basilisk2 there are the sources of the
>>> Debian package. To compile it you can run "git-buildpackage
>>> --git-ignore-new", and compilation should fail with the error above.
>>>
>>>> and I'll try to take a look at it as time permits. Thanks.
>>>
>>> Thank you very much for your help.
>>>
>>> Bests,
>>>         Giulio.
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Il 12/08/2012 19:17, Alexei Svitkine ha scritto:
> This should now be fixed in TOT in the git repo. You'll need to re-run
> autogen.sh.

I confirm that the fix is working properly: both compilation and
execution work.

Thank you very much.

> On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote:
>> On 09/08/2012 06:27, Alexei Svitkine wrote:
>>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
>>>> Hi to all,
>>>>
>>>> On 09/06/2012 20:44, Giulio Paci wrote:
>>>>> Basilisk II has been accepted into Debian unstable.
>>>>> Unfortunately the first upload is not compiling properly in most of the
>>>>> supported architectures, as it is described by this compilation report:
>>>>> https://buildd.debian.org/status/package.php?p=basilisk2
>>>>
>>>> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
>>>> For kfreebsd Alexei Svitkine committed a fix, that is working.
>>>>
>>>> For armel the building procedure reports:
>>>>
>>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
>>>> declared in this scope
>>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
>>>> gmake: *** [obj/sigsegv.o] Error 1
>>>> gmake: *** Waiting for unfinished jobs....
>>>> *** Error code 2
>>>
>>> Those line numbers don't look right to me. Do you have local edits to the file?
>>
>> No I have not, however this report is not about the latest version in
>> git (that is still failing with the same error message, about 800 lines
>> below): it is about the codebase I used to build the Debian package
>> (i.e., a CVS snapshot at the end of march).
>>
>>>> I had a quick look to this issue, but, once again, the fix is beyond my
>>>> knowledge and I found no useful information about it on the web (only
>>>> people experimenting this issue, but no solution). Unfortunately I also
>>>> had very few time last month, so I was not able to do anything useful
>>>> about this issue.
>>>> I have installed a Debian armel using qemu, so I have access to an armel
>>>> system now. If anyone wants to propose a solution for this issue I will
>>>> be able to try it. If anyone is interested I can also share the VM image.
>>
>>> Please share the VM image
>>
>> boot.sh: a script that can be used to start the VM (using qemu)
>> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU
>>
>> boot.tar.bz2: the /boot directory containing the kernel to start the VM
>> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8
>>
>> debian-testing-armel.qcow.bz2: the image of a current Debian testing
>> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8
>>
>> To run the VM, install qemu with arm support, untar the boot.tar.bz2,
>> expand debian-testing-armel.qcow.bz2 and run the script.
>>
>> There is a "root" user and a "debian" user.
>> The password for both is "debian".
>> The "debian" user already has macemu git repository in its home
>> (~/Source/macemu), and BasiliskII has already been configured. Running
>> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error.
>>
>> In ~/Source/debian-packages/basilisk2 there are the sources of the
>> Debian package. To compile it you can run "git-buildpackage
>> --git-ignore-new", and compilation should fail with the error above.
>>
>>> and I'll try to take a look at it as time permits. Thanks.
>>
>> Thank you very much for your help.
>>
>> Bests,
>>         Giulio.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] How do I play games in SheepShaver?

[Ronald P. R. <ron...@xs...>]

Hi Pål,

The basilisk-devel mailing list is not intended for support questions. Emaculation is by far the best place for support, with also downloads links for recent application builds and several elaborate user guides. Apparently you did register for Emaculation forum before but forgot the user name you used. I will send your Emaculation account info to your email address directly.

Note that Mountain Lion prevents SheepShaver to mount CD-ROMS. Disk images made of CDs work fine.

Ronald.

----------------------------------------
Op 15 augustus 2012, om 03:32, schreef Pål Hart <mon...@ya...>:

Sorry to bother you, but this email is listed under support on the SheepShaver official website. Emaculation forum is also listed but its complete garbage; It says my email is already used so I can't register but it has no way to recover my username/password and it has no support and I'm not willing to make anymore effort than that to use their website. 

So, I did a search the other day for an OS 9 emulator, specifically for the purpose of playing Baldur's Gate, Baldur's Gate 2, and a couple other OS 9 games I miss playing. I found this video (http://www.youtube.com/watch?v=WrrT9_4Jdbs) which contains a link to a RapidShare dl of SheepShaver. I've heard of SheepShaver before, but the Download link on the official website doesn't have a link to download the app in this way, and its not worth additional effort so I never got the program. 

The problem is there's only half a gig on the disc image that the program boots from. Now, I can add 1 game to it (Baldur's Gate Tales of The Sword Coast in this case) however it requires a disc to play, and the disc mounts on my OSX desktop which isn't acknowledged in the OS9 environment. I tried making a disc image, but it can't be put onto it because of space limitation. Navigating to it through "Unix" I couldn't run the dmg anyway. So I downloaded a little program called Disk Copy 6.4 that claimed to allow OS9 to run .dmg, however when I try I get an error -50. 

I'm running Lion in a late '09 MBP (I also have an '07 24" iMac AL) but I'm upgrading to Mountain Lion tomorrow. I use my iMac as my desktop/storage comp so I have a 2.5TB drive on it so I'm going to make a partition and install SL on it, so I can run PPC games and apps using Rosetta. Will SheepShaver run better on SL? Both my comps are intel otherwise I'd install Tiger on a partition too. Thank you for taking the time to read and reply to this message. 

			Sincerely,
				-Pål Hart


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] In OSX 10.8 Mountain Lion, both SS and BII cannot mount CD-ROMs

[Ronald P. R. <ron...@xs...>]

It appears that in OSX 10.8 (Mountain Lion) both SheepShaver and BasiliskII can no longer mount CD-ROMs. The issue is identical in both emulators:

When the CD is mounted in OSX and the emulator is started, the emulator finds the disk but cannot read it and offers to initialize or eject it.

When the emulator is running and the CD is inserted, the disk is mounted in OSX but nothing happens in the emulator.

When a bootable (Mac OS system install) CD is mounted in OSX and the emulator is started with no other bootable volumes available, the emulator pauses with a light grey screen, apparently finds and inspects the CD, then the CD is ejected, and the emulator proceeds to the known screen with floppy image and blinking question mark.

Ronald.

(Sorry, first sent this from my gmail address by mistake.)

[B2-devel] How do I play games in SheepShaver?

[Pål H. <mon...@ya...>]

Sorry to bother you, but this email is listed under support on the SheepShaver official website. Emaculation forum is also listed but its complete garbage; It says my email is already used so I can't register but it has no way to recover my username/password and it has no support and I'm not willing to make anymore effort than that to use their website. 

So, I did a search the other day for an OS 9 emulator, specifically for the purpose of playing Baldur's Gate, Baldur's Gate 2, and a couple other OS 9 games I miss playing. I found this video (http://www.youtube.com/watch?v=WrrT9_4Jdbs) which contains a link to a RapidShare dl of SheepShaver. I've heard of SheepShaver before, but the Download link on the official website doesn't have a link to download the app in this way, and its not worth additional effort so I never got the program. 

The problem is there's only half a gig on the disc image that the program boots from. Now, I can add 1 game to it (Baldur's Gate Tales of The Sword Coast in this case) however it requires a disc to play, and the disc mounts on my OSX desktop which isn't acknowledged in the OS9 environment. I tried making a disc image, but it can't be put onto it because of space limitation. Navigating to it through "Unix" I couldn't run the dmg anyway. So I downloaded a little program called Disk Copy 6.4 that claimed to allow OS9 to run .dmg, however when I try I get an error -50. 

I'm running Lion in a late '09 MBP (I also have an '07 24" iMac AL) but I'm upgrading to Mountain Lion tomorrow. I use my iMac as my desktop/storage comp so I have a 2.5TB drive on it so I'm going to make a partition and install SL on it, so I can run PPC games and apps using Rosetta. Will SheepShaver run better on SL? Both my comps are intel otherwise I'd install Tiger on a partition too. Thank you for taking the time to read and reply to this message. 

			Sincerely,
				-Pål Hart

Re: [B2-devel] BasiliskII compilation issues

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

This should now be fixed in TOT in the git repo. You'll need to re-run
autogen.sh.

-Alexei

On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote:
> On 09/08/2012 06:27, Alexei Svitkine wrote:
>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
>>> Hi to all,
>>>
>>> On 09/06/2012 20:44, Giulio Paci wrote:
>>>> Basilisk II has been accepted into Debian unstable.
>>>> Unfortunately the first upload is not compiling properly in most of the
>>>> supported architectures, as it is described by this compilation report:
>>>> https://buildd.debian.org/status/package.php?p=basilisk2
>>>
>>> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
>>> For kfreebsd Alexei Svitkine committed a fix, that is working.
>>>
>>> For armel the building procedure reports:
>>>
>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
>>> declared in this scope
>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
>>> gmake: *** [obj/sigsegv.o] Error 1
>>> gmake: *** Waiting for unfinished jobs....
>>> *** Error code 2
>>
>> Those line numbers don't look right to me. Do you have local edits to the file?
>
> No I have not, however this report is not about the latest version in
> git (that is still failing with the same error message, about 800 lines
> below): it is about the codebase I used to build the Debian package
> (i.e., a CVS snapshot at the end of march).
>
>>> I had a quick look to this issue, but, once again, the fix is beyond my
>>> knowledge and I found no useful information about it on the web (only
>>> people experimenting this issue, but no solution). Unfortunately I also
>>> had very few time last month, so I was not able to do anything useful
>>> about this issue.
>>> I have installed a Debian armel using qemu, so I have access to an armel
>>> system now. If anyone wants to propose a solution for this issue I will
>>> be able to try it. If anyone is interested I can also share the VM image.
>
>> Please share the VM image
>
> boot.sh: a script that can be used to start the VM (using qemu)
> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU
>
> boot.tar.bz2: the /boot directory containing the kernel to start the VM
> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8
>
> debian-testing-armel.qcow.bz2: the image of a current Debian testing
> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8
>
> To run the VM, install qemu with arm support, untar the boot.tar.bz2,
> expand debian-testing-armel.qcow.bz2 and run the script.
>
> There is a "root" user and a "debian" user.
> The password for both is "debian".
> The "debian" user already has macemu git repository in its home
> (~/Source/macemu), and BasiliskII has already been configured. Running
> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error.
>
> In ~/Source/debian-packages/basilisk2 there are the sources of the
> Debian package. To compile it you can run "git-buildpackage
> --git-ignore-new", and compilation should fail with the error above.
>
>> and I'll try to take a look at it as time permits. Thanks.
>
> Thank you very much for your help.
>
> Bests,
>         Giulio.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] SheepShaver commit efa32be9e "Optimize invalidate_cache_range()..." linked to obscure crash

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

On Aug 8, 2012, at 9:15 PM, Alexei Svitkine wrote:

> I am not convinced that the revision in question is the cause of the
> issue you're seeing.
>
> I've read over that change and it seems correct to me. Perhaps
> something else is going wrong that is corrupting the internal state of
> those linked lists and that change merely exposes the issue?

You may be right.  While reverting the patch avoids the garbled error  
I was seeing, I still get occasional SheepShaver crashes.  I haven't  
reviewed all the changes between Git 1.7.5.4 and 1.7.6, but one file,  
sha1-array.c, was added, and a broken SHA1 hash is consistent with  
the error I was getting from Git.

> Could you actually debug this and verify that the two paths in that
> function end up invalidating different nodes?

I don't have time for this right now, but I intend to pursue it later.

Josh

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

On 09/08/2012 06:27, Alexei Svitkine wrote:
> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
>> Hi to all,
>>
>> On 09/06/2012 20:44, Giulio Paci wrote:
>>> Basilisk II has been accepted into Debian unstable.
>>> Unfortunately the first upload is not compiling properly in most of the
>>> supported architectures, as it is described by this compilation report:
>>> https://buildd.debian.org/status/package.php?p=basilisk2
>>
>> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
>> For kfreebsd Alexei Svitkine committed a fix, that is working.
>>
>> For armel the building procedure reports:
>>
>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
>> declared in this scope
>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
>> gmake: *** [obj/sigsegv.o] Error 1
>> gmake: *** Waiting for unfinished jobs....
>> *** Error code 2
> 
> Those line numbers don't look right to me. Do you have local edits to the file?

No I have not, however this report is not about the latest version in
git (that is still failing with the same error message, about 800 lines
below): it is about the codebase I used to build the Debian package
(i.e., a CVS snapshot at the end of march).

>> I had a quick look to this issue, but, once again, the fix is beyond my
>> knowledge and I found no useful information about it on the web (only
>> people experimenting this issue, but no solution). Unfortunately I also
>> had very few time last month, so I was not able to do anything useful
>> about this issue.
>> I have installed a Debian armel using qemu, so I have access to an armel
>> system now. If anyone wants to propose a solution for this issue I will
>> be able to try it. If anyone is interested I can also share the VM image.

> Please share the VM image

boot.sh: a script that can be used to start the VM (using qemu)
https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU

boot.tar.bz2: the /boot directory containing the kernel to start the VM
https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8

debian-testing-armel.qcow.bz2: the image of a current Debian testing
https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8

To run the VM, install qemu with arm support, untar the boot.tar.bz2,
expand debian-testing-armel.qcow.bz2 and run the script.

There is a "root" user and a "debian" user.
The password for both is "debian".
The "debian" user already has macemu git repository in its home
(~/Source/macemu), and BasiliskII has already been configured. Running
make in ~/Source/macemu/BasiliskII/src/Unix should give you the error.

In ~/Source/debian-packages/basilisk2 there are the sources of the
Debian package. To compile it you can run "git-buildpackage
--git-ignore-new", and compilation should fail with the error above.

> and I'll try to take a look at it as time permits. Thanks.

Thank you very much for your help.

Bests,
	Giulio.

Re: [B2-devel] BasiliskII compilation issues

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

On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote:
> Hi to all,
>
> On 09/06/2012 20:44, Giulio Paci wrote:
>> Basilisk II has been accepted into Debian unstable.
>> Unfortunately the first upload is not compiling properly in most of the
>> supported architectures, as it is described by this compilation report:
>> https://buildd.debian.org/status/package.php?p=basilisk2
>
> For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
> For kfreebsd Alexei Svitkine committed a fix, that is working.
>
> For armel the building procedure reports:
>
> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
> declared in this scope
> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
> gmake: *** [obj/sigsegv.o] Error 1
> gmake: *** Waiting for unfinished jobs....
> *** Error code 2

Those line numbers don't look right to me. Do you have local edits to the file?

>
> I had a quick look to this issue, but, once again, the fix is beyond my
> knowledge and I found no useful information about it on the web (only
> people experimenting this issue, but no solution). Unfortunately I also
> had very few time last month, so I was not able to do anything useful
> about this issue.
> I have installed a Debian armel using qemu, so I have access to an armel
> system now. If anyone wants to propose a solution for this issue I will
> be able to try it. If anyone is interested I can also share the VM image.
>

Please share the VM image and I'll try to take a look at it as time
permits. Thanks.


> On Debian system libsigsegv is available as a system library. Is it
> possible to use it instead of the included sigsegv.cpp?
>
> Bests,
>         Giulio.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] SheepShaver commit efa32be9e "Optimize invalidate_cache_range()..." linked to obscure crash

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

On Thu, Aug 9, 2012 at 12:15 AM, Alexei Svitkine
<ale...@gm...> wrote:
> I am not convinced that the revision in question is the cause of the
> issue you're seeing.
>
> I've read over that change and it seems correct to me. Perhaps
> something else is going wrong that is corrupting the internal state of
> those linked lists and that change merely exposes the issue?
>
> Could you actually debug this and verify that the two paths in that
> function end up invalidating different nodes?
>
> One way to do it would be with something like (mailer-code - may need tweaking):
>
>         std::vector<entry*> entries;
>         entry *p, *q;
>         if (cacheline(start) < cacheline(end - 1)) {
>                 // Optimize for short ranges flush
>                 const int end_cl = cacheline(end - 1);
>                 for (int cl = cacheline(start); cl <= end_cl; cl++) {
>                         p = cache_tags[cl];
>                         while (p) {
>                                 q = p;
>                                 p = p->next_same_cl;
>                                 if (q->intersect(start, end)) {
>                                         entries.push_back(q);
>                                 }
>                         }
>                 }
>         }
>
>         int index = 0;
>         p = active;
>         while (p) {
>                 q = p;
>                 p = p->next;
>                 if (q->intersect(start, end)) {
>                         if (entries[index++] != q)
>                                 abort();
>                         q->invalidate();
>                         remove_from_cl_list(q);
>                         remove_from_list(q);
>                         delete_blockinfo(q);
>                 }
>         }

Sorry, I think the code I suggested may not be quite right to check this as it
assumes the order of the nodes found is the same between the two
paths. It probably isn't - so you may need to save the results of the
two paths into separate vectors and sort them before comparing. But
you get the idea. (I hope...)

-Alexei
>
> If it does indeed hit the abort() code, maybe you can dump the state
> of the linked lists and narrow down where the state gets corrupted?
>
> -Alexei
>
>
> On Wed, Aug 8, 2012 at 9:50 PM, Josh Juran <jj...@gm...> wrote:
>>
>> Hi,
>>
>> I've bisected a crash in one of my programs running in SheepShaver to
>> this commit:
>>
>>         commit efa32be9ec44956c77e5001e31bebce151cb2ad6
>>         Author: gbeauche <>
>>         Date:   Sat Jul 21 10:25:51 2007 +0000
>>
>>                 Optimize invalidate_cache_range() for short ranges.
>>
>> I applied 7bb230ab "apparently this makes newest SDL happy" to each
>> checkout I tested to get SheepShaver to run at all.  This is in Mac
>> OS X 10.4 "Tiger" for Intel.
>>
>> The issue occurs only rarely, with regard to what triggers it, but
>> it's 100% reproducible.  To reproduce:
>>
>> * Launch MacRelix
>> * Run `git --version`
>> * cd into a Git repo (I only tried my metamage repo)
>> * Run `time git status` with git v1.7.6
>>
>> One of three failure modes occurs:
>>
>> * SheepShaver exits immediately
>> * The guest OS hangs and SheepShaver consumes maximum CPU
>> * The command completes with garbled output, having failed to
>> recognize its input
>>
>>         $ time /git status
>>         10-102.964309e-3152200othing added.
>>         0x1.0002400000000p-1023ybe you wanted to say 'git add .'?
>>
>>         real 0.07
>>         user 0.00
>>         sys  0.07
>>
>> No failure occurs with any of the following:
>>
>> * Don't run `git --version` first
>> * Run `git status` without `time`
>> * Use git v1.7.5 instead of v1.7.6
>> * Use a git binary built with symbolics (i.e. enabled to run in the
>> Metrowerks debugger)
>> * Run in Classic instead of SheepShaver
>> * Use a SheepShaver built with the optimization reverted
>>
>> If I cd before running `git --version`, the error message is
>> displayed ungarbled (which is still wrong, since the repo isn't empty).
>>
>> If I use an optimized build instead, I get a different error:
>>
>>         fatal: bad config value for 'core.repositoryformatversion' in .git/
>> config
>>
>> Since efa32be9e is at best an optimization and demonstrably causes
>> problems, I suggest it be reverted immediately.
>>
>> Josh
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] SheepShaver commit efa32be9e "Optimize invalidate_cache_range()..." linked to obscure crash

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

I am not convinced that the revision in question is the cause of the
issue you're seeing.

I've read over that change and it seems correct to me. Perhaps
something else is going wrong that is corrupting the internal state of
those linked lists and that change merely exposes the issue?

Could you actually debug this and verify that the two paths in that
function end up invalidating different nodes?

One way to do it would be with something like (mailer-code - may need tweaking):

        std::vector<entry*> entries;
	entry *p, *q;
	if (cacheline(start) < cacheline(end - 1)) {
		// Optimize for short ranges flush
		const int end_cl = cacheline(end - 1);
		for (int cl = cacheline(start); cl <= end_cl; cl++) {
			p = cache_tags[cl];
			while (p) {
				q = p;
				p = p->next_same_cl;
				if (q->intersect(start, end)) {
					entries.push_back(q);
				}
			}
		}
	}

  	int index = 0;
	p = active;
	while (p) {
		q = p;
		p = p->next;
		if (q->intersect(start, end)) {
			if (entries[index++] != q)
				abort();
			q->invalidate();
			remove_from_cl_list(q);
			remove_from_list(q);
			delete_blockinfo(q);
		}
	}

If it does indeed hit the abort() code, maybe you can dump the state
of the linked lists and narrow down where the state gets corrupted?

-Alexei


On Wed, Aug 8, 2012 at 9:50 PM, Josh Juran <jj...@gm...> wrote:
>
> Hi,
>
> I've bisected a crash in one of my programs running in SheepShaver to
> this commit:
>
>         commit efa32be9ec44956c77e5001e31bebce151cb2ad6
>         Author: gbeauche <>
>         Date:   Sat Jul 21 10:25:51 2007 +0000
>
>                 Optimize invalidate_cache_range() for short ranges.
>
> I applied 7bb230ab "apparently this makes newest SDL happy" to each
> checkout I tested to get SheepShaver to run at all.  This is in Mac
> OS X 10.4 "Tiger" for Intel.
>
> The issue occurs only rarely, with regard to what triggers it, but
> it's 100% reproducible.  To reproduce:
>
> * Launch MacRelix
> * Run `git --version`
> * cd into a Git repo (I only tried my metamage repo)
> * Run `time git status` with git v1.7.6
>
> One of three failure modes occurs:
>
> * SheepShaver exits immediately
> * The guest OS hangs and SheepShaver consumes maximum CPU
> * The command completes with garbled output, having failed to
> recognize its input
>
>         $ time /git status
>         10-102.964309e-3152200othing added.
>         0x1.0002400000000p-1023ybe you wanted to say 'git add .'?
>
>         real 0.07
>         user 0.00
>         sys  0.07
>
> No failure occurs with any of the following:
>
> * Don't run `git --version` first
> * Run `git status` without `time`
> * Use git v1.7.5 instead of v1.7.6
> * Use a git binary built with symbolics (i.e. enabled to run in the
> Metrowerks debugger)
> * Run in Classic instead of SheepShaver
> * Use a SheepShaver built with the optimization reverted
>
> If I cd before running `git --version`, the error message is
> displayed ungarbled (which is still wrong, since the repo isn't empty).
>
> If I use an optimized build instead, I get a different error:
>
>         fatal: bad config value for 'core.repositoryformatversion' in .git/
> config
>
> Since efa32be9e is at best an optimization and demonstrably causes
> problems, I suggest it be reverted immediately.
>
> Josh
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] SheepShaver commit efa32be9e "Optimize invalidate_cache_range()..." linked to obscure crash

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

Hi,

I've bisected a crash in one of my programs running in SheepShaver to  
this commit:

	commit efa32be9ec44956c77e5001e31bebce151cb2ad6
	Author: gbeauche <>
	Date:   Sat Jul 21 10:25:51 2007 +0000
	
		Optimize invalidate_cache_range() for short ranges.

I applied 7bb230ab "apparently this makes newest SDL happy" to each  
checkout I tested to get SheepShaver to run at all.  This is in Mac  
OS X 10.4 "Tiger" for Intel.

The issue occurs only rarely, with regard to what triggers it, but  
it's 100% reproducible.  To reproduce:

* Launch MacRelix
* Run `git --version`
* cd into a Git repo (I only tried my metamage repo)
* Run `time git status` with git v1.7.6

One of three failure modes occurs:

* SheepShaver exits immediately
* The guest OS hangs and SheepShaver consumes maximum CPU
* The command completes with garbled output, having failed to  
recognize its input

	$ time /git status
	10-102.964309e-3152200othing added.
	0x1.0002400000000p-1023ybe you wanted to say 'git add .'?
	
	real 0.07
	user 0.00
	sys  0.07

No failure occurs with any of the following:

* Don't run `git --version` first
* Run `git status` without `time`
* Use git v1.7.5 instead of v1.7.6
* Use a git binary built with symbolics (i.e. enabled to run in the  
Metrowerks debugger)
* Run in Classic instead of SheepShaver
* Use a SheepShaver built with the optimization reverted

If I cd before running `git --version`, the error message is  
displayed ungarbled (which is still wrong, since the repo isn't empty).

If I use an optimized build instead, I get a different error:

	fatal: bad config value for 'core.repositoryformatversion' in .git/ 
config

Since efa32be9e is at best an optimization and demonstrably causes  
problems, I suggest it be reverted immediately.

Josh

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Hi to all,

On 09/06/2012 20:44, Giulio Paci wrote:
> Basilisk II has been accepted into Debian unstable.
> Unfortunately the first upload is not compiling properly in most of the
> supported architectures, as it is described by this compilation report:
> https://buildd.debian.org/status/package.php?p=basilisk2

For ia64, mips, mipsel, sparc and powerpc it was my fault and I fixed that.
For kfreebsd Alexei Svitkine committed a fix, that is working.

For armel the building procedure reports:

sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not
declared in this scope
sigsegv.cpp:1624: error: expected ',' or ';' before '{' token
gmake: *** [obj/sigsegv.o] Error 1
gmake: *** Waiting for unfinished jobs....
*** Error code 2

I had a quick look to this issue, but, once again, the fix is beyond my
knowledge and I found no useful information about it on the web (only
people experimenting this issue, but no solution). Unfortunately I also
had very few time last month, so I was not able to do anything useful
about this issue.
I have installed a Debian armel using qemu, so I have access to an armel
system now. If anyone wants to propose a solution for this issue I will
be able to try it. If anyone is interested I can also share the VM image.

On Debian system libsigsegv is available as a system library. Is it
possible to use it instead of the included sigsegv.cpp?

Bests,
	Giulio.

Re: [B2-devel] Macintosh memory information?

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

On Jul 19, 2012, at 7:23 AM, Alexander von Gluck wrote:

> On 18.07.2012 23:01, Michael Schmitt wrote:
>> Inside Macintosh: Memory is available at
>> 
>> <http://developer.apple.com/legacy/mac/library/#documentation/mac/Memory/Memory-2.html>
>> 
>> As far as I can tell (and I could be wrong)...
>> 
>> Basilisk II supports three types of memory access modes. Which one to use 
>> is selected at compile time:
>> 
>> REAL: The addresses seen inside the emulated machine are exactly the same 
>> as the host memory address.
>> 
>> DIRECT: The addresses are shifted by a fixed offset. It calculates it at 
>> runtime, by allocating the guest memory
>> block anywhere the host can find space, and then calculating the offset 
>> between the guest and host addresses.
>> 
>> VIRTUAL:  The guest address space is broken down into banks, e.g. the RAM, 
>> ROM and frame buffer are handled
>> separately. It uses some kind of address translation logic.
> 
> These definitions seem to be swapped (as far as I can tell)
> https://github.com/kallisti5/sheepshear/blob/master/src/platform/Unix/main_unix.cpp#L944
> 
> The UNIX code above seems to allocate the memory anywhere available with 
> REAL addressing, and at a fixed location
> with DIRECT addressing.
> 
> I haven't seen and references to VIRTUAL memory access mode though.

That's because first I was describing how the Basilisk II code works, from which SheepShaver is derived.

BII has VIRTUAL, SS doesn't.

In REAL mode SS allocates the HOST block where ever it can. But once it is allocated, the address the guest sees is exactly the host address where the block was allocated.

In DIRECT mode the memory is allocated at a fixed address (that in SS is determined at compile time), and then the addresses are translated so the guest sees RAM starting at zero.


>> SheepShaver (at least the 32-bit version, I don't know about 64-bit) 
>> supports REAL and DIRECT addressing modes, but
>> not VIRTUAL.
>> 
>> I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal 
>> flaw.  Unlike Basilisk II, the offset is
>> calculated at *compile* time.  But this only works if each user compiles 
>> the code!  And if something changes the
>> library address randomization (such as applying an upgrade) it invalidates 
>> the compiled-in offset. You would need to
>> keep recompiling it. Of course this is completely non-portable.
> 
> This may explain some of the large emulation problems seen on newer gcc + 
> x86_64

Does it use DIRECT mode?

I've only used SheepShaver in REAL mode.

>> That leaves REAL mode.
>> 
>> When running on PPC, REAL mode allows it to run virtualized instead of 
>> emulated, where it can just let the native
>> processor loose on the code.  Running on Intel there shouldn't be a 
>> penalty for doing an address shift, since it has
>> to emulate the CPU and anyway. But it doesn't shift it, due to the way 
>> DIRECT is implemented as described above.
> 
> 
> Given these limitations, can we put a wrapper around memory calls and adjust 
> the memory offsets at run time? (enabling
> us to cherrypick whichever host memory we want to? (but we should make sure 
> it is aligned to 1MB))

Remember it is the guest ROM rom address that needs to be aligned. It doesn't matter if the host address is aligned.

> Example:
> Mac2HostAddr, Host2MacAddr can do address translation, so why not do the 
> following:
> 
> 1) Take a hunk of memory, allocate it large enough for RAM and ROM 
> (aligned) for easy debugging
> 2) Set the RAMBaseHost to the start of the chunk of memory
> 3) Set the ROMBaseHost to the start of the chunk of memory + RAM size 
> (which should be at least 1MB intervals)
> 
> *) Mac2HostAddr - If we catch a RAM address (0 - 1GB) with Mac2HostAddr, 
> point it to RAMBaseHost + mac offset
> *) Mac2HostAddr - If we catch a ROM address (0x40800000 - 0x40D00000), 
> point it to the ROMBaseHost + mac offset
> *) Host2MacAddr - If we catch RAMBaseHost - RAM Size, subtract RAMBaseHost
> *) Host2MacAddr - If we catch ROMBaseHost - 5MB, subtract ROMBaseHost
> 
> I don't understand the JIT stuff enough yet though to see if this would work 
> with it.
> 
> Thoughts?

Essentially that would be changing SheepShaver to use the same DIRECT mode as Basilisk II (if all addresses are shifted by the same offset), or Basilisk II's VIRTUAL mode, which currently is not in SheepShaver.

But since the Mac OS doesn't need to have the RAM and ROM at any particular address, simply shifting the host-to-guest RAM/ROM addresses doesn't buy us much.

What we would want is to translate all of the addresses: the low system globals at 0x0, the special data areas, etc.

When I looked at the DIRECT code I wasn't sure if it could handle 32-bit wrap-around access properly. Consider that if guest 0x0 is actually in the middle of the host space, then some of the high guest space is actually less than it.  What happens when a guest memory operation needs to wrap from high host to low host?

And there could be cases where SheepShaver is making an assumption that the distance between two guest addresses is the same as the distance between the two corresponding host addresses, and vice versa.


In 64-bit mode we should have huge amounts of host address space.  Can we map the entire guest address space, all 4 GB of it or whatever the classic Mac OS had, high up in 64-bit land and then shift everything -- including the 0x0 globals? Or do we still have the problem of Cocoa allocating stuff in our address space at initialization?


> -- Alex
> 
>> 
>> On Jul 18, 2012, at 7:20 AM, Alexander von Gluck wrote:
>> 
>>> Does anyone have any documentation on the memory layout of the old world
>>> Macintosh? (Performa 6400 era)
>>> 
>>> I've been looking to rework how SheepShear manages memory and it's not
>>> completely clear to me how it does
>>> it's memory translation.  Most of the bugs I've seen on x86_64 are due to
>>> the exact memory mapping on emulated
>>> powerpc systems (eg, hard coded memory addresses we *have* to map for 
>>> things
>>> to function) and something getting mangled
>>> on x86_64.
>>> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
>>> 
>>> I see memory maps for the really early Mac's, but am failing to find
>>> anything for the later old world machines
>>> online or in the old Macintosh service manuals.
>>> 
>>> Here is what I know for a fact looking at the code:
>>> 
>>> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
>>> RAM,               0x0        - (memory size selected less then 1GB)
>>> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1
>>> host:guest location)
>>> 
>>> Real addressing == "normal" allocation where memory locations are 
>>> dynamic,
>>> and we translate addresses to match
>>> Direct addressing == memory is directly addressed, mostly used on native
>>> PowerPC?
>>> Nat_mem offset == ???, guessing it's for native PowerPC
>>> 
>>> It looks given the code below that the Macintosh has to be patched to use
>>> the host memory
>>> addresses vs the emulator doing the memory translation (SheepShear acting 
>>> as
>>> a mmu to the guest)
>>> 
>>> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
>>> 
>>> The reason I ask here is because these changes could be pulled upstream 
>>> to
>>> SheepShaver.
>>> 
>>> -- Thanks!
>>> Alex
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Macintosh memory information?

[Alexander v. G. <kal...@un...>]

On 18.07.2012 23:01, Michael Schmitt wrote:
> Inside Macintosh: Memory is available at
> 
> <http://developer.apple.com/legacy/mac/library/#documentation/mac/Memory/Memory-2.html>
>
> As far as I can tell (and I could be wrong)...
>
> Basilisk II supports three types of memory access modes. Which one to use 
> is selected at compile time:
>
> REAL: The addresses seen inside the emulated machine are exactly the same 
> as the host memory address.
>
> DIRECT: The addresses are shifted by a fixed offset. It calculates it at 
> runtime, by allocating the guest memory
> block anywhere the host can find space, and then calculating the offset 
> between the guest and host addresses.
>
> VIRTUAL:  The guest address space is broken down into banks, e.g. the RAM, 
> ROM and frame buffer are handled
> separately. It uses some kind of address translation logic.

These definitions seem to be swapped (as far as I can tell)
https://github.com/kallisti5/sheepshear/blob/master/src/platform/Unix/main_unix.cpp#L944

The UNIX code above seems to allocate the memory anywhere available with 
REAL addressing, and at a fixed location
with DIRECT addressing.

I haven't seen and references to VIRTUAL memory access mode though.

> SheepShaver (at least the 32-bit version, I don't know about 64-bit) 
> supports REAL and DIRECT addressing modes, but
> not VIRTUAL.
>
> I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal 
> flaw.  Unlike Basilisk II, the offset is
> calculated at *compile* time.  But this only works if each user compiles 
> the code!  And if something changes the
> library address randomization (such as applying an upgrade) it invalidates 
> the compiled-in offset. You would need to
> keep recompiling it. Of course this is completely non-portable.

This may explain some of the large emulation problems seen on newer gcc + 
x86_64

> That leaves REAL mode.
>
> When running on PPC, REAL mode allows it to run virtualized instead of 
> emulated, where it can just let the native
> processor loose on the code.  Running on Intel there shouldn't be a 
> penalty for doing an address shift, since it has
> to emulate the CPU and anyway. But it doesn't shift it, due to the way 
> DIRECT is implemented as described above.


Given these limitations, can we put a wrapper around memory calls and adjust 
the memory offsets at run time? (enabling
us to cherrypick whichever host memory we want to? (but we should make sure 
it is aligned to 1MB))

Example:
   Mac2HostAddr, Host2MacAddr can do address translation, so why not do the 
following:

   1) Take a hunk of memory, allocate it large enough for RAM and ROM 
(aligned) for easy debugging
   2) Set the RAMBaseHost to the start of the chunk of memory
   3) Set the ROMBaseHost to the start of the chunk of memory + RAM size 
(which should be at least 1MB intervals)

   *) Mac2HostAddr - If we catch a RAM address (0 - 1GB) with Mac2HostAddr, 
point it to RAMBaseHost + mac offset
   *) Mac2HostAddr - If we catch a ROM address (0x40800000 - 0x40D00000), 
point it to the ROMBaseHost + mac offset
   *) Host2MacAddr - If we catch RAMBaseHost - RAM Size, subtract RAMBaseHost
   *) Host2MacAddr - If we catch ROMBaseHost - 5MB, subtract ROMBaseHost

I don't understand the JIT stuff enough yet though to see if this would work 
with it.

Thoughts?

-- Alex

>
> On Jul 18, 2012, at 7:20 AM, Alexander von Gluck wrote:
>
>> Does anyone have any documentation on the memory layout of the old world
>> Macintosh? (Performa 6400 era)
>>
>> I've been looking to rework how SheepShear manages memory and it's not
>> completely clear to me how it does
>> it's memory translation.  Most of the bugs I've seen on x86_64 are due to
>> the exact memory mapping on emulated
>> powerpc systems (eg, hard coded memory addresses we *have* to map for 
>> things
>> to function) and something getting mangled
>> on x86_64.
>> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
>>
>> I see memory maps for the really early Mac's, but am failing to find
>> anything for the later old world machines
>> online or in the old Macintosh service manuals.
>>
>> Here is what I know for a fact looking at the code:
>>
>> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
>> RAM,               0x0        - (memory size selected less then 1GB)
>> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1
>> host:guest location)
>>
>> Real addressing == "normal" allocation where memory locations are 
>> dynamic,
>> and we translate addresses to match
>> Direct addressing == memory is directly addressed, mostly used on native
>> PowerPC?
>> Nat_mem offset == ???, guessing it's for native PowerPC
>>
>> It looks given the code below that the Macintosh has to be patched to use
>> the host memory
>> addresses vs the emulator doing the memory translation (SheepShear acting 
>> as
>> a mmu to the guest)
>> 
>> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
>>
>> The reason I ask here is because these changes could be pulled upstream 
>> to
>> SheepShaver.
>>
>> -- Thanks!
>>  Alex
>>
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Macintosh memory information?

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

Inside Macintosh: Memory is available at <http://developer.apple.com/legacy/mac/library/#documentation/mac/Memory/Memory-2.html>


As far as I can tell (and I could be wrong)...

Basilisk II supports three types of memory access modes. Which one to use is selected at compile time:

REAL: The addresses seen inside the emulated machine are exactly the same as the host memory address.

DIRECT: The addresses are shifted by a fixed offset. It calculates it at runtime, by allocating the guest memory block anywhere the host can find space, and then calculating the offset between the guest and host addresses.

VIRTUAL:  The guest address space is broken down into banks, e.g. the RAM, ROM and frame buffer are handled separately. It uses some kind of address translation logic.


SheepShaver (at least the 32-bit version, I don't know about 64-bit) supports REAL and DIRECT addressing modes, but not VIRTUAL.

I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal flaw.  Unlike Basilisk II, the offset is calculated at *compile* time.  But this only works if each user compiles the code!  And if something changes the library address randomization (such as applying an upgrade) it invalidates the compiled-in offset. You would need to keep recompiling it. Of course this is completely non-portable.

That leaves REAL mode.

When running on PPC, REAL mode allows it to run virtualized instead of emulated, where it can just let the native processor loose on the code.  Running on Intel there shouldn't be a penalty for doing an address shift, since it has to emulate the CPU and anyway. But it doesn't shift it, due to the way DIRECT is implemented as described above.


OK, given that, what about restrictions?

Before I messed with the memory allocation, SheepShaver's host memory map was:


  RAM area       ???M   0x20000000 to ? 
  ROM area:        5M   0x40800000 to 0x40D00000 
  Kernel Data 2:   8K   0x5fffe000 to 0x60000000 
  SS Globals:    512K   0x60000000 to 0x60080000 
  Sig stack:      64K   0x60080000 to 0x60090000 
  DR Emulator:    64K   0x68070000 to 0x68080000 
  Kernal Data 1:   8K   0x68ffe000 to 0x69000000 
  DR Cache:      512K   0x69000000 to 0x69080000 
  Load mod:             0x78048000 


The system globals have to be at guest address 0.  SheepShaver uses several techniques to achieve this, including attempting to allocate the RAM block at 0, using linking magic to get a program segment to load at 0, or direct allocation of a small amount of storage at 0. (Note that allocating at zero is problematic in Linux, because the default setting in some Linux versions is to not allow it.)

Mac OS doesn't care where the RAM or ROM blocks start. The starting addresses are just plugged into a global.

However, I did observe that:

1. It crashes if the guest ROM address isn't on a 1 MB boundary. 

I'm not sure if that is a Mac OS restriction or something in SheepShaver.  I suspect this code in rsrc_patches.cpp has something to do with it:

	// Patch native GetResource()
	uint32 upp = ReadMacInt32(0x1480);
	if ((upp & 0xffc00000) == ROMBase)
		return;

2. It crashes if the guest ROM address is not higher than the RAM address.

I worked around this by allocating the RAM and ROM together as one block, with enough extra space to permit the ROM to be aligned.

This ensures that the ROM is higher than RAM, but at a disadvantage: it increases the size of the memory block, which makes it more likely that a) it might not get it, or b) it may get it but run into another problem...


3. It crashes if the RAM is allocated too high.

Higher than what? It must be one of the "other areas" (Kernel Data, Sig stack, etc.), but which one?  Is it a Mac OS restriction or something in SheepShaver?

I worked around it by checking if it did load higher than the kernel data address, and if so it just gives up. This obviously is not an ideal situation.


So, per your question, SheepShaver on Mac and Unix no longer load the ROM to be at 0x40800000, and it only "tries" to load RAM at 0x0.  It is more likely that it loads it higher.


Windows is differnet. Since it didn't have the problem finding memory (since its address space wasn't polluted by Cocoa), there was no reason to change SheepShaver to shift memory.



On Jul 18, 2012, at 7:20 AM, Alexander von Gluck wrote:

> Does anyone have any documentation on the memory layout of the old world 
> Macintosh? (Performa 6400 era)
> 
> I've been looking to rework how SheepShear manages memory and it's not 
> completely clear to me how it does
> it's memory translation.  Most of the bugs I've seen on x86_64 are due to 
> the exact memory mapping on emulated
> powerpc systems (eg, hard coded memory addresses we *have* to map for things 
> to function) and something getting mangled
> on x86_64.
> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
> 
> I see memory maps for the really early Mac's, but am failing to find 
> anything for the later old world machines
> online or in the old Macintosh service manuals.
> 
> Here is what I know for a fact looking at the code:
> 
> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
> RAM,               0x0        - (memory size selected less then 1GB)
> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1 
> host:guest location)
> 
> Real addressing == "normal" allocation where memory locations are dynamic, 
> and we translate addresses to match
> Direct addressing == memory is directly addressed, mostly used on native 
> PowerPC?
> Nat_mem offset == ???, guessing it's for native PowerPC
> 
> It looks given the code below that the Macintosh has to be patched to use 
> the host memory
> addresses vs the emulator doing the memory translation (SheepShear acting as 
> a mmu to the guest)
> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
> 
> The reason I ask here is because these changes could be pulled upstream to 
> SheepShaver.
> 
> -- Thanks!
>  Alex
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Macintosh memory information?

[Alexander v. G. <kal...@un...>]

All great stuff, definitely helps! :)

Thanks!
  -- Alex

On 18.07.2012 09:29, Frank Trampe wrote:
> There is stuff of interest in Inside Macintosh: PowerPC System Software 
> and Inside Macintosh: Memory. The former is
> available on-line but not the latter. This ( 
> http://www.mindfiresolutions.com/mindfire/Mac_Memory_Manager.pdf [7] )
> may have some of what you need.
>
> On Wed, Jul 18, 2012 at 8:49 AM, Frank Trampe <fra...@gm... [8]> 
> wrote:
>
>> I think that you need the PowerPC edition/addition of Inside Macintosh. I 
>> will try to check on this in a few hours.
>> I believe that there is a copy available on-line somewhere, but I can 
>> scan the pages that you need if not.
>>
>> On Wed, Jul 18, 2012 at 7:21 AM, Alexander von Gluck 
>> <kal...@un... [6]> wrote:
>>
>>> Does anyone have any documentation on the memory layout of the old world
>>> Macintosh? (Performa 6400 era)
>>>
>>> I've been looking to rework how SheepShear manages memory and it's not
>>> completely clear to me how it does
>>> it's memory translation.  Most of the bugs I've seen on x86_64 are due 
>>> to
>>> the exact memory mapping on emulated
>>> powerpc systems (eg, hard coded memory addresses we *have* to map for 
>>> things
>>> to function) and something getting mangled
>>> on x86_64.
>>> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089 
>>> [1]
>>>
>>> I see memory maps for the really early Mac's, but am failing to find
>>> anything for the later old world machines
>>> online or in the old Macintosh service manuals.
>>>
>>> Here is what I know for a fact looking at the code:
>>>
>>> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
>>> RAM,               0x0        - (memory size selected less then 1GB)
>>> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1
>>> host:guest location)
>>>
>>> Real addressing == "normal" allocation where memory locations are 
>>> dynamic,
>>> and we translate addresses to match
>>> Direct addressing == memory is directly addressed, mostly used on native
>>> PowerPC?
>>> Nat_mem offset == ???, guessing it's for native PowerPC
>>>
>>> It looks given the code below that the Macintosh has to be patched to 
>>> use
>>> the host memory
>>> addresses vs the emulator doing the memory translation (SheepShear 
>>> acting as
>>> a mmu to the guest)
>>> 
>>> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185 
>>> [2]
>>>
>>> The reason I ask here is because these changes could be pulled upstream 
>>> to
>>> SheepShaver.
>>>
>>>   -- Thanks!
>>>     Alex
>>>
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. 
>>> Discussions
>>> will include endpoint security, mobile security and the latest in 
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ [3]
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li... [4]
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel [5]
>
>
>
> Links:
> ------
> [1] https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
> [2] 
> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
> [3] http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> [4] mailto:bas...@li...
> [5] https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> [6] mailto:kal...@un...
> [7] http://www.mindfiresolutions.com/mindfire/Mac_Memory_Manager.pdf
> [8] mailto:fra...@gm...

Re: [B2-devel] Macintosh memory information?

[Frank T. <fra...@gm...>]

There is stuff of interest in Inside Macintosh: PowerPC System Software and
Inside Macintosh: Memory. The former is available on-line but not the
latter. This (
http://www.mindfiresolutions.com/mindfire/Mac_Memory_Manager.pdf ) may have
some of what you need.

On Wed, Jul 18, 2012 at 8:49 AM, Frank Trampe <fra...@gm...>wrote:

> I think that you need the PowerPC edition/addition of Inside Macintosh. I
> will try to check on this in a few hours. I believe that there is a copy
> available on-line somewhere, but I can scan the pages that you need if not.
>
>
> On Wed, Jul 18, 2012 at 7:21 AM, Alexander von Gluck <
> kal...@un...> wrote:
>
>> Does anyone have any documentation on the memory layout of the old world
>> Macintosh? (Performa 6400 era)
>>
>> I've been looking to rework how SheepShear manages memory and it's not
>> completely clear to me how it does
>> it's memory translation.  Most of the bugs I've seen on x86_64 are due to
>> the exact memory mapping on emulated
>> powerpc systems (eg, hard coded memory addresses we *have* to map for
>> things
>> to function) and something getting mangled
>> on x86_64.
>> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
>>
>> I see memory maps for the really early Mac's, but am failing to find
>> anything for the later old world machines
>> online or in the old Macintosh service manuals.
>>
>> Here is what I know for a fact looking at the code:
>>
>> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
>> RAM,               0x0        - (memory size selected less then 1GB)
>> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1
>> host:guest location)
>>
>> Real addressing == "normal" allocation where memory locations are dynamic,
>> and we translate addresses to match
>> Direct addressing == memory is directly addressed, mostly used on native
>> PowerPC?
>> Nat_mem offset == ???, guessing it's for native PowerPC
>>
>> It looks given the code below that the Macintosh has to be patched to use
>> the host memory
>> addresses vs the emulator doing the memory translation (SheepShear acting
>> as
>> a mmu to the guest)
>>
>> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
>>
>> The reason I ask here is because these changes could be pulled upstream to
>> SheepShaver.
>>
>>   -- Thanks!
>>     Alex
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>

Re: [B2-devel] Macintosh memory information?

[Frank T. <fra...@gm...>]

I think that you need the PowerPC edition/addition of Inside Macintosh. I
will try to check on this in a few hours. I believe that there is a copy
available on-line somewhere, but I can scan the pages that you need if not.

On Wed, Jul 18, 2012 at 7:21 AM, Alexander von Gluck
<kal...@un...>wrote:

> Does anyone have any documentation on the memory layout of the old world
> Macintosh? (Performa 6400 era)
>
> I've been looking to rework how SheepShear manages memory and it's not
> completely clear to me how it does
> it's memory translation.  Most of the bugs I've seen on x86_64 are due to
> the exact memory mapping on emulated
> powerpc systems (eg, hard coded memory addresses we *have* to map for
> things
> to function) and something getting mangled
> on x86_64.
> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089
>
> I see memory maps for the really early Mac's, but am failing to find
> anything for the later old world machines
> online or in the old Macintosh service manuals.
>
> Here is what I know for a fact looking at the code:
>
> Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
> RAM,               0x0        - (memory size selected less then 1GB)
> ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1
> host:guest location)
>
> Real addressing == "normal" allocation where memory locations are dynamic,
> and we translate addresses to match
> Direct addressing == memory is directly addressed, mostly used on native
> PowerPC?
> Nat_mem offset == ???, guessing it's for native PowerPC
>
> It looks given the code below that the Macintosh has to be patched to use
> the host memory
> addresses vs the emulator doing the memory translation (SheepShear acting
> as
> a mmu to the guest)
>
> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185
>
> The reason I ask here is because these changes could be pulled upstream to
> SheepShaver.
>
>   -- Thanks!
>     Alex
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

[B2-devel] Macintosh memory information?

[Alexander v. G. <kal...@un...>]

Does anyone have any documentation on the memory layout of the old world 
Macintosh? (Performa 6400 era)

I've been looking to rework how SheepShear manages memory and it's not 
completely clear to me how it does
it's memory translation.  Most of the bugs I've seen on x86_64 are due to 
the exact memory mapping on emulated
powerpc systems (eg, hard coded memory addresses we *have* to map for things 
to function) and something getting mangled
on x86_64.
https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089

I see memory maps for the really early Mac's, but am failing to find 
anything for the later old world machines
online or in the old Macintosh service manuals.

Here is what I know for a fact looking at the code:

Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
RAM,               0x0        - (memory size selected less then 1GB)
ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1 
host:guest location)

Real addressing == "normal" allocation where memory locations are dynamic, 
and we translate addresses to match
Direct addressing == memory is directly addressed, mostly used on native 
PowerPC?
Nat_mem offset == ???, guessing it's for native PowerPC

It looks given the code below that the Macintosh has to be patched to use 
the host memory
addresses vs the emulator doing the memory translation (SheepShear acting as 
a mmu to the guest)
https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185

The reason I ask here is because these changes could be pulled upstream to 
SheepShaver.

  -- Thanks!
    Alex

[B2-devel] Macintosh memory information?

[Alexander v. G. <kal...@un...>]

Does anyone have any documentation on the memory layout of the old world 
Macintosh? (Performa 6400 era)

I've been looking to rework how SheepShear manages memory and it's not 
completely clear to me how it does
it's memory translation.  Most of the bugs I've seen on x86_64 are due to 
the exact memory mapping on emulated
powerpc systems (eg, hard coded memory addresses we *have* to map for things 
to function) and something getting mangled
on x86_64.
https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089

I see memory maps for the really early Mac's, but am failing to find 
anything for the later old world machines
online or in the old Macintosh service manuals.

Here is what I know for a fact looking at the code:

Low memory area, - 0x0        - 0x3000  (static 1:1 host:guest location)
RAM,               0x0        - (memory size selected less then 1GB)
ROM,               0x40800000 - 0x40C00000 (4MB mac rom)  (static 1:1 
host:guest location)

Real addressing == "normal" allocation where memory locations are dynamic, 
and we translate addresses to match
Direct addressing == memory is directly addressed, mostly used on native 
PowerPC?
Nat_mem offset == ???, guessing it's for native PowerPC

It looks given the code below that the Macintosh has to be patched to use 
the host memory
addresses vs the emulator doing the memory translation (SheepShear acting as 
a mmu to the guest)
https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185

The reason I ask here is because these changes could be pulled upstream to 
SheepShaver.

  -- Thanks!
    Alex