basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Unable to compile SheepShaver

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

On Wed, Dec 28, 2011 at 9:26 PM, C.W. Betts <com...@ho...> wrote:
> Ever since the recent patches, I have been unable to build SheepShaver for Mac OS X from the command line. It seems to me that it isn't building the custom SDLMain.m file, but using the SDLMain static library from the system.

Should be fixed now. (You'll need to re-run 'make links' from
SheepShaver root dir as well as autogen.)

-Alexei

[B2-devel] Unable to compile SheepShaver

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

Ever since the recent patches, I have been unable to build SheepShaver for Mac OS X from the command line. It seems to me that it isn't building the custom SDLMain.m file, but using the SDLMain static library from the system.

Re: [B2-devel] [sheepshaver] PATCH: add PPC970MP as a recognized CPU type

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

Committed. Thanks!

On Sun, Dec 25, 2011 at 1:34 PM, Douglas Mencken <dou...@gm...> wrote:
> Currently, only PPC970 and PPC970FX CPUs are recognized, but not
> PPC970MP. 970MP users are left without AltiVec by unknown reason :)
>
> But here comes my patch:
>
> cd SheepShaver/src/Unix
>
> # add recognition for 970MP processors
> sed -i 's/{ 0xffff0000, 0x003c0000, "PPC970FX" }/{ 0xffff0000,
> 0x003c0000, "PPC970FX" },\
>                        { 0xffff0000, 0x00440000, "PPC970MP" }/' ./main_unix.cpp
> sed -i 's;.*case 0x003c:.*;        case 0x003c:
>    //  970FX\
>        case 0x0044:                            //  970MP;' ./main_unix.cpp
>
> The diff is attached to this letter.
>
> I took these values from this kernel patch from year 2005:
> http://lists.ozlabs.org/pipermail/linuxppc64-dev/2005-July/004688.html
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

[B2-devel] [sheepshaver] PATCH: add PPC970MP as a recognized CPU type

[Douglas M. <dou...@gm...>]

Currently, only PPC970 and PPC970FX CPUs are recognized, but not
PPC970MP. 970MP users are left without AltiVec by unknown reason :)

But here comes my patch:

cd SheepShaver/src/Unix

# add recognition for 970MP processors
sed -i 's/{ 0xffff0000, 0x003c0000, "PPC970FX" }/{ 0xffff0000,
0x003c0000, "PPC970FX" },\
                        { 0xffff0000, 0x00440000, "PPC970MP" }/' ./main_unix.cpp
sed -i 's;.*case 0x003c:.*;        case 0x003c:
    //  970FX\
        case 0x0044:                            //  970MP;' ./main_unix.cpp

The diff is attached to this letter.

I took these values from this kernel patch from year 2005:
http://lists.ozlabs.org/pipermail/linuxppc64-dev/2005-July/004688.html

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

On Sep 16, 2011, at 3:55 AM, Joshua Juran wrote:

> On Sep 16, 2011, at 12:41 AM, Frank Trampe wrote:
> 
>> On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote:
>> 
>>> On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote:
>>> 
>>>> Also problematic is the premise of storing host OS pointers in the
>>>> guest OS's memory space.  It opens the door for arbitrary native  
>>>> code
>>>> execution on behalf of an emulated program.
>>>> 
>>>> I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac
>>>> emulator, but a library that (at least in theory) could be applied
>>>> toward emulation of any 68K platform.  In v68k, memory is modeled in
>>>> the emulator as base pointer and length.  Emulated memory addresses
>>>> are offsets from the base pointer.
>>>> 
>>>> The important point is that memory errors are
>>>> caught by the translator and don't leak into the native code.
>>> 
>>> 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. In Basilisk  
>>> II the offset is a parameter; in SheepShaver it is pre-calculated  
>>> and compiled into the program.
>>> 
>>> 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.
> 
> v68k is using a hybrid of DIRECT and VIRTUAL.  There's only one bank  
> at the moment, but translation is always bounds-checked and the first  
> 1K is treated specially.
> 
>>> 32-bit SheepShaver on OS X normally runs in REAL mode, for  
>>> performance reasons.  I'm suspecting that 64-bit SheepShaver still  
>>> runs in REAL mode, simply allocating the guest memory down in the  
>>> 32-bit address space.
> 
> Your performance win is my security hole. :-(  Again, not that  
> someone's going to exploit it -- I just don't want the emulator  
> crashing.  On the other hand, SheepShaver doesn't handle hardware  
> exceptions anyway, so it's kind of moot.

I'm not sure there is a security hole.

From what I recall, neither Basilisk II nor SheepShaver allow guest addresses that are out of the range of the guest address space (which in turn is limited by how much RAM you are emulating.)

In some modes emulator code is being used to map addresses and emulate instructions.  In these modes it can simulate seg faults.

But even if it is running in REAL mode, virtualized, the guest OS still knows what the address space is supposed to be and it can through seg faults if you attempt to exceed it.

So what the malware would need to do in that case is patch the ROM code to bypass those checks.


>> At the same time, with processors as fast as they are, the added  
>> over-head of running in direct mode seems a small price to pay for  
>> avoiding all of the pains and woes and sysctl modifications and  
>> extra segmentation faults (beyond those intercepted for various  
>> reasons) that result from running in real mode.
> 
> I concur.  As time passes, portability and robustness become more  
> important and optimization less so.

I would say that the reason SheepShaver doesn't use DIRECT mode is that, inexplicably, it is not as advanced as in Basilisk II.

In B2 DIRECT mode works by allocation of the guest memory block anywhere the host can find space, and then B2 calculates the resulting offset.

In SS the offset is calculated at compile time. But this only works if each user compiles the code!  And, if you apply an upgrade to your machine (thus changing the library address randomization) it invalidates the compiled-in offset. You would need to keep recompiling it. Of course this is completely non-portable.

Also, consider that both B2 and SS support running the guest on the same processor type as the host, e.g. SS can run on a PowerPC host and B2 can run on a 68k host.  When running in this mode, REAL mode allows it to run virtualized instead of emulated.

(Neither program is smart enough to use the host to do the memory address translation in hardware. )

> 
>> It also seems that it might be feasible, if anybody cared enough  
>> and had enough free time, to leverage the virtualization features  
>> in modern processors in order to solve the memory windowing problem  
>> better than the SEGINT handler.
> 
> I assume you mean SIGSEGV.  I maintain that illegal memory accesses  
> should not be caught but prevented in the first place.

And one of SheepShaver's faults is it doesn't emulate the MMC, which does limit what programs it can run. For example that is one of the problems with later versions of QuickTime.


>>> Anyway... my point is that Basilisk II is not restricted to  
>>> running in REAL mode. You just need to compile it with different  
>>> parms.
>> 
>> My experience was on the SheepShaver side of things with the awful  
>> dyngen stuff, so I never noticed this. I might have saved myself a  
>> lot of trouble if I had.
>> 
>> On a related note, does anybody know why there are so many good  
>> M68K emulators (Basilisk II, Mini vMac, and, seemingly, whatever  
>> Joshua is writing) and so few good PowerPC emulators?
> 
> Let's see:
> 
> * m68k has been around about 15 years longer, so there's been more  
> time to write emulators for it
> * m68k has been used for Mac, Atari, Amiga, Sun, Palm, and various  
> other legacy systems, so there's demand for it, whereas PowerPC's  
> only major legacy system is Macs -- and most users had switched to OS  
> X and had little reason to emulate OS 9 and no reason to emulate OS  
> X / PPC.
> * by the time PowerPC shipped, there were fewer Mac-only programs  
> (since Windows was so dominant)
> * PowerPC apps are more likely to have been ported at least to  
> Carbon, and therefore runnable in OS X
> * actual 68K Macs are much slower than PowerPC Macs and therefore  
> more in need of emulators to replace them
> * personally, I find 68K more fun to work with :-

PowerPC emulation died off as soon as OS X started running on Intel. For example, that immediately put a halt to PearPC development.

And as Joshua pointed out, there isn't much else that runs on PowerPC that isn't also available in Intel. For example, while you could compile your favorite Linux distribution for PowerPC, you can also compile for Intel and run natively. 


By the way, I don't think the problem with SheepShaver is the PowerPC emulation part. It is everything else.

A typical PC emulator works by emulating of the complete hardware: CPU, video, network, sound, memory, time controller, interrupts, disk drives, USB, BIOS, etc.  Any OS that can run on a real PC with the same hardware (e.g. the same model of Ethernet card) can run, unmodified, on the emulated machine.

The emulator then typically provides some kind of "Tools" you can install that will modify the running OS to improve performance.

From what I can tell SheepShaver doesn't do that at all.

Instead it is all Tools.  It works by patching the hell out of the Mac OS.  It patches every part of the Mac OS (by hooking the ROM) that deals with hardware, directing it instead to routines in the emulator code.

The downside is that to understand what it is doing you must have an extremely in depth knowledge of how classic Mac OS works. And who knows that anymore?

> 
>> I would have thought (without actually reading much about the  
>> instruction sets) that emulating a RISC machine with a New World  
>> ROM and OpenFirmware ought to be much less difficult than emulating  
>> a CISC machine with all of the crazy ancient Macintosh stuff.
> 
> Well, v68k knows nothing of Mac hardware -- it's just a 68K emulation  
> library.  But you could write a v68k-based Mac emulator -- that's  
> just not one of my priorities at the moment.  My first v68k client  
> provides a native system call bridge, for running Unix programs.   
> Right now, if you built rot13 for MacRelix (and extracted the code  
> resource into its own file), it would also run in v68k-exec:
> 
> 	$ echo Foo bar | v68k-exec rot13.68k
> 	Sbb one
> 
> As for Mac support, I'd be interested in bridging apps directly to  
> the host OS (in the manner of Wine or GrayBox) before I wrote yet  
> another Mac emulator.
> 
> Josh
> 
> 
> 
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] How do I download this ?

[Em A. <ade...@gm...>]

Sorry for the late response, but for 9.2.2, your only bet on modern hardware
is to run Mac on Linux inside OS X 10.3 inside PearPC.  This should let you
run 9.1 through 10.0 (the versions unsupported by SheepShaver and PearPC),
although it's flaky, has no sound, and is slow.

In other news, I've started running BII inside WINEskin on OS X, as I get
the JIT support and am able to bundle up the entire package (no nvram and
prefs files being hard-coded to my home dir).  Until I get around to
recompiling the source myself, it seems to be the only way to do this.

On Fri, Jun 17, 2011 at 1:05 AM, Ronald P. Regensburg <ron...@xs...>wrote:

> Best find a MacOSX alternative for that application. But if there is no
> such alternative, your application may run in MacOS 9.0.4 in SheepShaver for
> MacOSX. Best look for more information on the Emaculation site:
>
> <http://www.emaculation.com/>
>
> Ronald P. Regensburg.
>
>
> Op 16 jun 2011, om 14:52 heeft Jeffrey Zarit het volgende geschreven:
>
> > I use 10.5.8 but have one application that uses OS 9.2.2
> > How do I do this ?
> >
> > Jeffrey S. Zarit
> >
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

On Sep 16, 2011, at 12:41 AM, Frank Trampe wrote:

> On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote:
>
>> On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote:
>>
>>> Also problematic is the premise of storing host OS pointers in the
>>> guest OS's memory space.  It opens the door for arbitrary native  
>>> code
>>> execution on behalf of an emulated program.
>>>
>>> I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac
>>> emulator, but a library that (at least in theory) could be applied
>>> toward emulation of any 68K platform.  In v68k, memory is modeled in
>>> the emulator as base pointer and length.  Emulated memory addresses
>>> are offsets from the base pointer.
>>>
>>> The important point is that memory errors are
>>> caught by the translator and don't leak into the native code.
>>
>> 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. In Basilisk  
>> II the offset is a parameter; in SheepShaver it is pre-calculated  
>> and compiled into the program.
>>
>> 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.

v68k is using a hybrid of DIRECT and VIRTUAL.  There's only one bank  
at the moment, but translation is always bounds-checked and the first  
1K is treated specially.

>> 32-bit SheepShaver on OS X normally runs in REAL mode, for  
>> performance reasons.  I'm suspecting that 64-bit SheepShaver still  
>> runs in REAL mode, simply allocating the guest memory down in the  
>> 32-bit address space.

Your performance win is my security hole. :-(  Again, not that  
someone's going to exploit it -- I just don't want the emulator  
crashing.  On the other hand, SheepShaver doesn't handle hardware  
exceptions anyway, so it's kind of moot.

> At the same time, with processors as fast as they are, the added  
> over-head of running in direct mode seems a small price to pay for  
> avoiding all of the pains and woes and sysctl modifications and  
> extra segmentation faults (beyond those intercepted for various  
> reasons) that result from running in real mode.

I concur.  As time passes, portability and robustness become more  
important and optimization less so.

> It also seems that it might be feasible, if anybody cared enough  
> and had enough free time, to leverage the virtualization features  
> in modern processors in order to solve the memory windowing problem  
> better than the SEGINT handler.

I assume you mean SIGSEGV.  I maintain that illegal memory accesses  
should not be caught but prevented in the first place.

>> Anyway... my point is that Basilisk II is not restricted to  
>> running in REAL mode. You just need to compile it with different  
>> parms.
>
> My experience was on the SheepShaver side of things with the awful  
> dyngen stuff, so I never noticed this. I might have saved myself a  
> lot of trouble if I had.
>
> On a related note, does anybody know why there are so many good  
> M68K emulators (Basilisk II, Mini vMac, and, seemingly, whatever  
> Joshua is writing) and so few good PowerPC emulators?

Let's see:

* m68k has been around about 15 years longer, so there's been more  
time to write emulators for it
* m68k has been used for Mac, Atari, Amiga, Sun, Palm, and various  
other legacy systems, so there's demand for it, whereas PowerPC's  
only major legacy system is Macs -- and most users had switched to OS  
X and had little reason to emulate OS 9 and no reason to emulate OS  
X / PPC.
* by the time PowerPC shipped, there were fewer Mac-only programs  
(since Windows was so dominant)
* PowerPC apps are more likely to have been ported at least to  
Carbon, and therefore runnable in OS X
* actual 68K Macs are much slower than PowerPC Macs and therefore  
more in need of emulators to replace them
* personally, I find 68K more fun to work with :-)

> I would have thought (without actually reading much about the  
> instruction sets) that emulating a RISC machine with a New World  
> ROM and OpenFirmware ought to be much less difficult than emulating  
> a CISC machine with all of the crazy ancient Macintosh stuff.

Well, v68k knows nothing of Mac hardware -- it's just a 68K emulation  
library.  But you could write a v68k-based Mac emulator -- that's  
just not one of my priorities at the moment.  My first v68k client  
provides a native system call bridge, for running Unix programs.   
Right now, if you built rot13 for MacRelix (and extracted the code  
resource into its own file), it would also run in v68k-exec:

	$ echo Foo bar | v68k-exec rot13.68k
	Sbb one

As for Mac support, I'd be interested in bridging apps directly to  
the host OS (in the manner of Wine or GrayBox) before I wrote yet  
another Mac emulator.

Josh

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

On Thu, Sep 15, 2011 at 7:02 PM, Michael Schmitt <msb2ssdev@me> wrote:

> On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote:
>
>
> Also problematic is the premise of storing host OS pointers in the
> guest OS's memory space.  It opens the door for arbitrary native code
> execution on behalf of an emulated program.  Putting aside the idea
> that someone would write a malicious classic Mac OS program to pwn
> your Intel box (which I admit is far-fetched), it's still plausible
> that misbehaving emulated code could crash the emulator itself.
>
> I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac
> emulator, but a library that (at least in theory) could be applied
> toward emulation of any 68K platform.  In v68k, memory is modeled in
> the emulator as base pointer and length.  Emulated memory addresses
> are offsets from the base pointer.  The base pointer is compiled
> however the platform wants; it's never stored in emulated memory and
> no magic is required.
>
> Currently there's only one memory region (although a future version
> will support many), but even so, the translator (through which all
> emulated memory accesses are bottlenecked) has some special logic.
> The system vector table (which includes memory address zero, or NULL)
> can't be read or written in user mode and can't be executed even in
> supervisor mode.  The important point is that memory errors are
> caught by the translator and don't leak into the native code.
>
>
> 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. In Basilisk II the
> offset is a parameter; in SheepShaver it is pre-calculated and compiled into
> the program.
>
> 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.
>
>
> 32-bit SheepShaver on OS X normally runs in REAL mode, for performance
> reasons.  I'm suspecting that 64-bit SheepShaver still runs in REAL mode,
> simply allocating the guest memory down in the 32-bit address space.
>
That would explain why so little code changed. This did not occur to me.

At the same time, with processors as fast as they are, the added over-head
of running in direct mode seems a small price to pay for avoiding all of the
pains and woes and sysctl modifications and extra segmentation faults
(beyond those intercepted for various reasons) that result from running in
real mode. It also seems that it might be feasible, if anybody cared enough
and had enough free time, to leverage the virtualization features in modern
processors in order to solve the memory windowing problem better than the
SEGINT handler.


>
> Since SheepShaver and Basilisk II guests are limited in how much guest
> memory they could possibly use, being limited to the 4 GB address space
> isn't a problem *if* the other memory blocks used by OS X are not in the
> way.  Where does IOKit land in a 64-bit process?
>
>
> Anyway... my point is that Basilisk II is not restricted to running in REAL
> mode. You just need to compile it with different parms.
>
My experience was on the SheepShaver side of things with the awful dyngen
stuff, so I never noticed this. I might have saved myself a lot of trouble
if I had.

On a related note, does anybody know why there are so many good M68K
emulators (Basilisk II, Mini vMac, and, seemingly, whatever Joshua is
writing) and so few good PowerPC emulators? I would have thought (without
actually reading much about the instruction sets) that emulating a RISC
machine with a New World ROM and OpenFirmware ought to be much less
difficult than emulating a CISC machine with all of the crazy ancient
Macintosh stuff.

>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

On Sep 15, 2011, at 3:09 AM, Joshua Juran wrote:
> 
> Also problematic is the premise of storing host OS pointers in the  
> guest OS's memory space.  It opens the door for arbitrary native code  
> execution on behalf of an emulated program.  Putting aside the idea  
> that someone would write a malicious classic Mac OS program to pwn  
> your Intel box (which I admit is far-fetched), it's still plausible  
> that misbehaving emulated code could crash the emulator itself.
> 
> I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac  
> emulator, but a library that (at least in theory) could be applied  
> toward emulation of any 68K platform.  In v68k, memory is modeled in  
> the emulator as base pointer and length.  Emulated memory addresses  
> are offsets from the base pointer.  The base pointer is compiled  
> however the platform wants; it's never stored in emulated memory and  
> no magic is required.
> 
> Currently there's only one memory region (although a future version  
> will support many), but even so, the translator (through which all  
> emulated memory accesses are bottlenecked) has some special logic.   
> The system vector table (which includes memory address zero, or NULL)  
> can't be read or written in user mode and can't be executed even in  
> supervisor mode.  The important point is that memory errors are  
> caught by the translator and don't leak into the native code.

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. In Basilisk II the offset is a parameter; in SheepShaver it is pre-calculated and compiled into the program.

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.


32-bit SheepShaver on OS X normally runs in REAL mode, for performance reasons.  I'm suspecting that 64-bit SheepShaver still runs in REAL mode, simply allocating the guest memory down in the 32-bit address space.

Since SheepShaver and Basilisk II guests are limited in how much guest memory they could possibly use, being limited to the 4 GB address space isn't a problem if the other memory blocks used by OS X are not in the way.  Where does IOKit land in a 64-bit process?


Anyway... my point is that Basilisk II is not restricted to running in REAL mode. You just need to compile it with different parms.

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

On Sep 12, 2011, at 7:40 AM, Frank Trampe wrote:

> There is a rather pervasive problem in the code base of casting  
> pointers to 32-bit integers, which causes a number of problems on  
> 64-bit architectures, like refusal to compile in most cases and  
> total failure at run-time when one gets that far.

Also problematic is the premise of storing host OS pointers in the  
guest OS's memory space.  It opens the door for arbitrary native code  
execution on behalf of an emulated program.  Putting aside the idea  
that someone would write a malicious classic Mac OS program to pwn  
your Intel box (which I admit is far-fetched), it's still plausible  
that misbehaving emulated code could crash the emulator itself.

> There are two possible long-term solutions that seemed plausible a  
> few years ago. One is to preallocate memory for the emulated  
> machine at a full 64-bit address and then to keep 32-bit pointers  
> as internal off-sets in the allocated range. The other is to  
> construct some method for translating between the virtual 32-bit  
> pointers of the guest operating system and the 64-bit pointers of  
> the host, possibly through a look-up table . Both options are  
> extremely costly in terms of time investment. I started working on  
> the first option but became too busy.

I'm writing a new 68K emulator, called v68k.  It's not a full-on Mac  
emulator, but a library that (at least in theory) could be applied  
toward emulation of any 68K platform.  In v68k, memory is modeled in  
the emulator as base pointer and length.  Emulated memory addresses  
are offsets from the base pointer.  The base pointer is compiled  
however the platform wants; it's never stored in emulated memory and  
no magic is required.

Currently there's only one memory region (although a future version  
will support many), but even so, the translator (through which all  
emulated memory accesses are bottlenecked) has some special logic.   
The system vector table (which includes memory address zero, or NULL)  
can't be read or written in user mode and can't be executed even in  
supervisor mode.  The important point is that memory errors are  
caught by the translator and don't leak into the native code.

<http://www.metamage.com/code/v68k/>

Josh

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

Providing specifics about the error might be helpful. Also, for what your
time is worth, you probably come out ahead by purchasing the Windows or DOS
version of the game and running it in wine or dosbox. Which version of
Journeyman Project are you attempting to run?

I would check that the computer is in fact running in 32-bit mode. That is
rather uncommon for computers shipping with Windows 7. Basilisk 2 and
SheepShaver are okay so long as they are running on 32-bit operating systems
since pointers are 32 bits in length .

There is a rather pervasive problem in the code base of casting pointers to
32-bit integers, which causes a number of problems on 64-bit architectures,
like refusal to compile in most cases and total failure at run-time when one
gets that far.

There are two possible long-term solutions that seemed plausible a few years
ago. One is to preallocate memory for the emulated machine at a full 64-bit
address and then to keep 32-bit pointers as internal off-sets in the
allocated range. The other is to construct some method for translating
between the virtual 32-bit pointers of the guest operating system and the
64-bit pointers of the host, possibly through a look-up table . Both options
are extremely costly in terms of time investment. I started working on the
first option but became too busy.

At some point after that, one of the maintainers made some magical
modification that allowed SheepShaver to compile and to run on 64-bit Linux
and Mac OS. I have not had an opportunity to review the code, but I assumed
that it patched the problem for Windows as well.

On Sat, Sep 10, 2011 at 11:30 AM, emddd <em...@ch...> wrote:

> Hi****
>
> ** **
>
>                 I know this is a desperate action, being how old Basilisk 2
> is. I have found one of the greatest games and was shot down instantly for
> one reason. It was a Mac version of the game. The game is Call The
> Journeyman Project, I got it for a steel at a Goodwill store. It’s in
> excellent condition and it is still works. However being that it’s the Mac
> version, I need to find an emulator for it. That’s when I finally found one
> that works, Basilisk 2. However, after I got it running I encountered an in
> game problem. The controls don’t work and my keyboard doesn’t register any
> commands to the game. I have tried to figure out what was wrong with the
> settings but to no luck. I was running it on my mom’s 32-bit windows-7
> computer ?(being that my computer is 64-bit). ****
>
> ** **
>
>                 Am asking if you know of any fixes to Basilisk 2 that will
> solve this problem, and is there a  64-bit compatible version for my
> computer or DILL files that will make it compatible with a 64-bit computer?
> ****
>
> ** **
>
> If you can help me in any way, please send me an email at
> ale...@ch...****
>
> ** **
>
> Sincerely****
>
> ** **
>
> Bastien A. Auxer****
>
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Basilisk 2 and The Journeyman Project

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

There is no regular development of BasiliskII going on. You could try if other BasiliskII users have a solution. See the BasiliskII forum at Emaculation.com:

<http://www.emaculation.com/forum/>

Ronald P. Regenburg.


--------------
Op 10 sep 2011, om 18:30, schreef emddd:

Hi
 
                I know this is a desperate action, being how old Basilisk 2 is. I have found one of the greatest games and was shot down instantly for one reason. It was a Mac version of the game. The game is Call The Journeyman Project, I got it for a steel at a Goodwill store. It’s in excellent condition and it is still works. However being that it’s the Mac version, I need to find an emulator for it. That’s when I finally found one that works, Basilisk 2. However, after I got it running I encountered an in game problem. The controls don’t work and my keyboard doesn’t register any commands to the game. I have tried to figure out what was wrong with the settings but to no luck. I was running it on my mom’s 32-bit windows-7 computer ?(being that my computer is 64-bit).
 
                Am asking if you know of any fixes to Basilisk 2 that will solve this problem, and is there a  64-bit compatible version for my computer or DILL files that will make it compatible with a 64-bit computer?
 
If you can help me in any way, please send me an email at ale...@ch...
 
Sincerely
 
Bastien A. Auxer
------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Basilisk 2 and The Journeyman Project

[emddd <em...@ch...>]

Hi

 

                I know this is a desperate action, being how old Basilisk 2
is. I have found one of the greatest games and was shot down instantly for
one reason. It was a Mac version of the game. The game is Call The
Journeyman Project, I got it for a steel at a Goodwill store. It's in
excellent condition and it is still works. However being that it's the Mac
version, I need to find an emulator for it. That's when I finally found one
that works, Basilisk 2. However, after I got it running I encountered an in
game problem. The controls don't work and my keyboard doesn't register any
commands to the game. I have tried to figure out what was wrong with the
settings but to no luck. I was running it on my mom's 32-bit windows-7
computer ?(being that my computer is 64-bit). 

 

                Am asking if you know of any fixes to Basilisk 2 that will
solve this problem, and is there a  64-bit compatible version for my
computer or DILL files that will make it compatible with a 64-bit computer? 

 

If you can help me in any way, please send me an email at
ale...@ch...

 

Sincerely

 

Bastien A. Auxer

Re: [B2-devel] How do I download this ?

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

Best find a MacOSX alternative for that application. But if there is no such alternative, your application may run in MacOS 9.0.4 in SheepShaver for MacOSX. Best look for more information on the Emaculation site:

<http://www.emaculation.com/>

Ronald P. Regensburg.


Op 16 jun 2011, om 14:52 heeft Jeffrey Zarit het volgende geschreven:

> I use 10.5.8 but have one application that uses OS 9.2.2
> How do I do this ?
> 
> Jeffrey S. Zarit
> 

Re: [B2-devel] How do I download this ?

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

I have had some problems running the release code . I checked the sources
out of the repository , made some modifications , and got those to compile
on Ubuntu and on Snow Leopard . Do you have an Intel system or a PowerPC
system ? If Intel , I can probably just provide the binaries that I compiled
.

I assume that you have already collected the ROM image and the Classic
installation media ?

Also , I hate to be nosy , but there is a good chance that there is an
easier solution to your problem than emulating Classic . What are you trying
to do ?

On Thu, Jun 16, 2011 at 7:52 AM, Jeffrey Zarit <je...@kl...> wrote:

> I use 10.5.8 but have one application that uses OS 9.2.2
> How do I do this ?
>
> Jeffrey S. Zarit
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

[B2-devel] How do I download this ?

[Jeffrey Z. <je...@kl...>]

I use 10.5.8 but have one application that uses OS 9.2.2
How do I do this ?

Jeffrey S. Zarit

Re: [B2-devel] Hello good folks

[howard s. <how...@ho...>]

Most of the older downloads are still available from Gwenole's site:
http://gwenole.beauchesne.free.fr/sheepshaver/files/

Howard

> Date: Mon, 28 Mar 2011 20:18:42 -0400
> From: jos...@gm...
> To: bas...@li...
> Subject: Re: [B2-devel] Hello good folks
> 
> archive.org has preserved some of Gwenolé's downloads.
> 
> I have a very limited copy of one of the pages at
> http://voltaire.nfshost.com/transfer/20080408121223_projects_basilisk2.html
> 
> On Mon, Mar 28, 2011 at 3:37 PM, Em Adespoton <ade...@gm...> wrote:
> > This is a bit delayed, but has anyone attempted to pull the data off of
> > archive.org?
> >
> > On Wed, Jan 5, 2011 at 3:08 AM, Ronald P. Regensburg <ron...@xs...>
> > wrote:
> >>
> >> Gwenole Beauchesne stopped development of BasiliskII and SheepShaver
> >> several years ago and about a year ago he removed his website quite
> >> unexpectedly, without giving the opportunity to keep copies of the
> >> information that could be found on his site.
> >>
> >> Information about the current state of BasiliskII and other Mac emulators
> >> can be found at the Emaculation.com website and the Emaculation.com forums:
> >>
> >> http://www.emaculation.com/
> >>
> >> http://www.emaculation.com/forum/
> >>
> >> Ronald P. Regensburg.
> >>
> >>
> >> Op 5 jan 2011, om 10:21 heeft Morgan Read het volgende geschreven:
> >>
> >> > Hello
> >> >
> >> > I am unable to access Gwenole's Basilisk site at www.gibix.net:
> >> > http://www.gibix.net/projects/basilisk2/
> >> >
> >> > Can anyone offer any help where I can find the info & binaries?
> >> > Strangely I still refer back to my 10 year old system every once in a
> >> > while, it's very important to me...:)
> >> >
> >> > Many thanks,
> >> > Regards,
> >> > Morgan.
> >> > --
> >> > Morgan Read
> >> > NEW ZEALAND
> >> > <mailto:mstuffATreadDOTorgDOTnz>
> >> >
> >> > Confused about DRM?
> >> > Get all the info you need at:
> >> > http://drm.info/
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Learn how Oracle Real Application Clusters (RAC) One Node allows
> >> > customers
> >> > to consolidate database storage, standardize their database environment,
> >> > and,
> >> > should the need arise, upgrade to a full multi-node Oracle RAC database
> >> > without downtime or disruption
> >> > http://p.sf.net/sfu/oracle-sfdevnl
> >> > _______________________________________________
> >> > basilisk-devel mailing list
> >> > bas...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> >> to consolidate database storage, standardize their database environment,
> >> and,
> >> should the need arise, upgrade to a full multi-node Oracle RAC database
> >> without downtime or disruption
> >> http://p.sf.net/sfu/oracle-sfdevnl
> >> _______________________________________________
> >> basilisk-devel mailing list
> >> bas...@li...
> >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> > Use the most popular FREE web apps or write code yourself;
> > WebMatrix provides all the features you need to develop and publish
> > your website. http://p.sf.net/sfu/ms-webmatrix-sf
> >
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
 		 	   		  

Re: [B2-devel] Hello good folks

[Joseph O. <jos...@gm...>]

archive.org has preserved some of Gwenolé's downloads.

I have a very limited copy of one of the pages at
http://voltaire.nfshost.com/transfer/20080408121223_projects_basilisk2.html

On Mon, Mar 28, 2011 at 3:37 PM, Em Adespoton <ade...@gm...> wrote:
> This is a bit delayed, but has anyone attempted to pull the data off of
> archive.org?
>
> On Wed, Jan 5, 2011 at 3:08 AM, Ronald P. Regensburg <ron...@xs...>
> wrote:
>>
>> Gwenole Beauchesne stopped development of BasiliskII and SheepShaver
>> several years ago and about a year ago he removed his website quite
>> unexpectedly, without giving the opportunity to keep copies of the
>> information that could be found on his site.
>>
>> Information about the current state of BasiliskII and other Mac emulators
>> can be found at the Emaculation.com website and the Emaculation.com forums:
>>
>> http://www.emaculation.com/
>>
>> http://www.emaculation.com/forum/
>>
>> Ronald P. Regensburg.
>>
>>
>> Op 5 jan 2011, om 10:21 heeft Morgan Read het volgende geschreven:
>>
>> > Hello
>> >
>> > I am unable to access Gwenole's Basilisk site at www.gibix.net:
>> > http://www.gibix.net/projects/basilisk2/
>> >
>> > Can anyone offer any help where I can find the info & binaries?
>> > Strangely I still refer back to my 10 year old system every once in a
>> > while, it's very important to me...:)
>> >
>> > Many thanks,
>> > Regards,
>> > Morgan.
>> > --
>> > Morgan Read
>> > NEW ZEALAND
>> > <mailto:mstuffATreadDOTorgDOTnz>
>> >
>> > Confused about DRM?
>> > Get all the info you need at:
>> > http://drm.info/
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Learn how Oracle Real Application Clusters (RAC) One Node allows
>> > customers
>> > to consolidate database storage, standardize their database environment,
>> > and,
>> > should the need arise, upgrade to a full multi-node Oracle RAC database
>> > without downtime or disruption
>> > http://p.sf.net/sfu/oracle-sfdevnl
>> > _______________________________________________
>> > basilisk-devel mailing list
>> > bas...@li...
>> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment,
>> and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and publish
> your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Hello good folks

[Em A. <ade...@gm...>]

This is a bit delayed, but has anyone attempted to pull the data off of
archive.org?

On Wed, Jan 5, 2011 at 3:08 AM, Ronald P. Regensburg <ron...@xs...>wrote:

> Gwenole Beauchesne stopped development of BasiliskII and SheepShaver
> several years ago and about a year ago he removed his website quite
> unexpectedly, without giving the opportunity to keep copies of the
> information that could be found on his site.
>
> Information about the current state of BasiliskII and other Mac emulators
> can be found at the Emaculation.com website and the Emaculation.com forums:
>
> http://www.emaculation.com/
>
> http://www.emaculation.com/forum/
>
> Ronald P. Regensburg.
>
>
> Op 5 jan 2011, om 10:21 heeft Morgan Read het volgende geschreven:
>
> > Hello
> >
> > I am unable to access Gwenole's Basilisk site at www.gibix.net:
> > http://www.gibix.net/projects/basilisk2/
> >
> > Can anyone offer any help where I can find the info & binaries?
> > Strangely I still refer back to my 10 year old system every once in a
> > while, it's very important to me...:)
> >
> > Many thanks,
> > Regards,
> > Morgan.
> > --
> > Morgan Read
> > NEW ZEALAND
> > <mailto:mstuffATreadDOTorgDOTnz>
> >
> > Confused about DRM?
> > Get all the info you need at:
> > http://drm.info/
> >
> >
> ------------------------------------------------------------------------------
> > Learn how Oracle Real Application Clusters (RAC) One Node allows
> customers
> > to consolidate database storage, standardize their database environment,
> and,
> > should the need arise, upgrade to a full multi-node Oracle RAC database
> > without downtime or disruption
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Free the Basilisk!

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

FYI: Patches welcome.

-Alexei

On Wed, Nov 24, 2010 at 5:55 AM, Jaime Cagigal <jca...@gm...> wrote:
> Hi
>
> 2010/11/24 Em Adespoton <ade...@gm...>:
>> Yes, catchy subject, but I figured it was about time to move my request over
>> from the emaculation discussion threads to the official mail list.
>>
>> What:
>> Right now, it is not feasible to have several instances of BII with
>> different OSes because they all share the same XPRAM file stored in a fixed
>> location.
>>
>> I'd love to be able to set a  'xpramfile' property in the prefs file or on
>> the command line, similar to the existing 'keycodefile' property that sets
>> the keycode file location.
>>
>> This is the one last bit of code tying BII down.  Questions? Comments?
>>
> Sounds ok, but please use the default xpram file location if the new
> property is not found in the prefs file.
>
> If no property is specified in the prefs file the 2nd, 3rd, 4th
> instance could use a copy in ram of the original xpram file. The
> changes wouldn't be saved to the original xpram file but at least you
> would be able to launch more instances without changing any file.
>
>
> --
> Saludos/Best Regards
> Jaime Cagigal
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Status of Mac OS X port?

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

I've applied your patches from your first mail - though I've done
something slightly different for fixing the fatal() macro.

-Alexei

On Fri, Mar 4, 2011 at 12:50 PM, Joseph Oswald <jos...@gm...> wrote:
> I have become interested in using Basilisk II to emulate a 68k macintosh on
> my Intel MacBookPro, running 10.6.6.
> I have found a few binaries of various ages, from Gwenolé Beauchesne (via
> archive.org) and from emaculation.net. However, I can't seem to replicate
> these from source.
> 1) The src/MacOSX/configure script generated by autoconf is broken (it has
> bad syntax after the egrep test). Applying a fix from the src/Unix fixes
> this. (patch attached) FYI, this also is broken in the MacPorts
> distribution, which I initially tried to use.
>   (minor quibble: my understanding of autoconf is for developers to run
> autoconf, and for source distributions to include the resulting configure
> scripts, which are portable. This avoids recipients from needing up-to-date
> autoconf installations. autoupdate in autoconf 2.88 wanted to tweak a few
> obsolete constructs in the MacOSX/configure.in)
> 2) nowrite.icns is required by PrefsEditor.mm, but is apparently not
> included or generated by CVS head.
> 3) The target "make ide" described by the configure output seems not to
> exist.
> 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible
> with the struct timeval chosen for tm_time_t. I can fix that, by converting
> tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other
> Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be
> altered to pick struct timespec? Should I special case timer_unix.cpp to
> separate Mac OS X from other Mach targets?
> 5) Unix sshpty.c seems to have typos in the definition and use of the
> fatal() macro. (Patch attached)
> 6) After fixing the fatal macro, I seem to need to force #define
> HAVE_OPENPTY 1 to compile. I'm not sure what the correct solution is.
> 7) main_macosx.mm complains that the -psn_XXX command-line flag (with the
> process ID) is not recognized. An attached patch skips this argument (I
> don't know what it would be used for).
> Even after all of this, I get a hang with a black screen at startup. (I
> initially started with a IIfx ROM, but switched to a Performa ROM based on
> it working better with the binaries I downloaded.)
> Any comments? Does anyone maintain or build the Mac OS X port?
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Status of Mac OS X port?

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

Applied the MACH timer patch as well.

-Alexei

On Sat, Mar 5, 2011 at 10:40 AM, Joseph Oswald <jos...@gm...> wrote:
> On Mar 4, 2011, ast 9:07 PM, Charles Srstka wrote:
>> On Mar 4, 2011, at 11:50 AM, Joseph Oswald wrote:
>>
>> > 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible with the struct timeval chosen for tm_time_t. I can fix that, by converting tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be altered to pick struct timespec? Should I special case timer_unix.cpp to separate Mac OS X from other Mach targets?
>>
>> The tm_time_t should be a mach_timespec_t when __MACH__ is true. However, if you can improve the timer, go to town. That precise timer code has never worked as well as hoped, to the point where a lot of people have just been #ifdefing it out.
>>
>
> I don't know enough to tell whether the code works or not, but the
> attached patch to MacOSX/sysdeps.h allows it to use the
> mach_timespec_t
>
>> I don’t believe there are any other Mach targets other than Mac OS X currently in use.
>>
>> Charles
>
>>
>> Message: 7
>> Date: Fri, 4 Mar 2011 12:50:08 -0500
>> From: Joseph Oswald <jos...@gm...>
>> Subject: [B2-devel] Status of Mac OS X port?
>> To: bas...@li...
>> Message-ID:
>>        <AANLkTi=oYJ...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I have become interested in using Basilisk II to emulate a 68k macintosh on
>> my Intel MacBookPro, running 10.6.6.
>>
>> I have found a few binaries of various ages, from Gwenol? Beauchesne (via
>> archive.org) and from emaculation.net. However, I can't seem to replicate
>> these from source.
>>
>> 1) The src/MacOSX/configure script generated by autoconf is broken (it has
>> bad syntax after the egrep test). Applying a fix from the src/Unix fixes
>> this. (patch attached) FYI, this also is broken in the MacPorts
>> distribution, which I initially tried to use.
>>
>>  (minor quibble: my understanding of autoconf is for developers to run
>> autoconf, and for source distributions to include the resulting configure
>> scripts, which are portable. This avoids recipients from needing up-to-date
>> autoconf installations. autoupdate in autoconf 2.88 wanted to tweak a few
>> obsolete constructs in the MacOSX/configure.in)
>>
>> 2) nowrite.icns is required by PrefsEditor.mm, but is apparently not
>> included or generated by CVS head.
>>
>> 3) The target "make ide" described by the configure output seems not to
>> exist.
>>
>> 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible
>> with the struct timeval chosen for tm_time_t. I can fix that, by converting
>> tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other
>> Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be
>> altered to pick struct timespec? Should I special case timer_unix.cpp to
>> separate Mac OS X from other Mach targets?
>>
>> 5) Unix sshpty.c seems to have typos in the definition and use of the
>> fatal() macro. (Patch attached)
>>
>> 6) After fixing the fatal macro, I seem to need to force #define
>> HAVE_OPENPTY 1 to compile. I'm not sure what the correct solution is.
>>
>> 7) main_macosx.mm complains that the -psn_XXX command-line flag (with the
>> process ID) is not recognized. An attached patch skips this argument (I
>> don't know what it would be used for).
>>
>> Even after all of this, I get a hang with a black screen at startup. (I
>> initially started with a IIfx ROM, but switched to a Performa ROM based on
>> it working better with the binaries I downloaded.)
>>
>> Any comments? Does anyone maintain or build the Mac OS X port?
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Status of Mac OS X port?

[Joseph O. <jos...@gm...>]

On Mar 4, 2011, ast 9:07 PM, Charles Srstka wrote:
> On Mar 4, 2011, at 11:50 AM, Joseph Oswald wrote:
>
> > 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible with the struct timeval chosen for tm_time_t. I can fix that, by converting tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be altered to pick struct timespec? Should I special case timer_unix.cpp to separate Mac OS X from other Mach targets?
>
> The tm_time_t should be a mach_timespec_t when __MACH__ is true. However, if you can improve the timer, go to town. That precise timer code has never worked as well as hoped, to the point where a lot of people have just been #ifdefing it out.
>

I don't know enough to tell whether the code works or not, but the
attached patch to MacOSX/sysdeps.h allows it to use the
mach_timespec_t

> I don’t believe there are any other Mach targets other than Mac OS X currently in use.
>
> Charles

>
> Message: 7
> Date: Fri, 4 Mar 2011 12:50:08 -0500
> From: Joseph Oswald <jos...@gm...>
> Subject: [B2-devel] Status of Mac OS X port?
> To: bas...@li...
> Message-ID:
>        <AANLkTi=oYJ...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have become interested in using Basilisk II to emulate a 68k macintosh on
> my Intel MacBookPro, running 10.6.6.
>
> I have found a few binaries of various ages, from Gwenol? Beauchesne (via
> archive.org) and from emaculation.net. However, I can't seem to replicate
> these from source.
>
> 1) The src/MacOSX/configure script generated by autoconf is broken (it has
> bad syntax after the egrep test). Applying a fix from the src/Unix fixes
> this. (patch attached) FYI, this also is broken in the MacPorts
> distribution, which I initially tried to use.
>
>  (minor quibble: my understanding of autoconf is for developers to run
> autoconf, and for source distributions to include the resulting configure
> scripts, which are portable. This avoids recipients from needing up-to-date
> autoconf installations. autoupdate in autoconf 2.88 wanted to tweak a few
> obsolete constructs in the MacOSX/configure.in)
>
> 2) nowrite.icns is required by PrefsEditor.mm, but is apparently not
> included or generated by CVS head.
>
> 3) The target "make ide" described by the configure output seems not to
> exist.
>
> 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible
> with the struct timeval chosen for tm_time_t. I can fix that, by converting
> tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other
> Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be
> altered to pick struct timespec? Should I special case timer_unix.cpp to
> separate Mac OS X from other Mach targets?
>
> 5) Unix sshpty.c seems to have typos in the definition and use of the
> fatal() macro. (Patch attached)
>
> 6) After fixing the fatal macro, I seem to need to force #define
> HAVE_OPENPTY 1 to compile. I'm not sure what the correct solution is.
>
> 7) main_macosx.mm complains that the -psn_XXX command-line flag (with the
> process ID) is not recognized. An attached patch skips this argument (I
> don't know what it would be used for).
>
> Even after all of this, I get a hang with a black screen at startup. (I
> initially started with a IIfx ROM, but switched to a Performa ROM based on
> it working better with the binaries I downloaded.)
>
> Any comments? Does anyone maintain or build the Mac OS X port?

Re: [B2-devel] Status of Mac OS X port?

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

On Mar 4, 2011, at 11:50 AM, Joseph Oswald wrote:

> 4) timer_unix.cpp with __MACH__ true (as it is on Mac OS X) is incompatible with the struct timeval chosen for tm_time_t. I can fix that, by converting tv_usec to tv_nsec, but I'm not sure what other Mach targets want. Do other Mach targets use HAVE_CLOCK_GETTIME? Should Mac OS X configuration be altered to pick struct timespec? Should I special case timer_unix.cpp to separate Mac OS X from other Mach targets?

The tm_time_t should be a mach_timespec_t when __MACH__ is true. However, if you can improve the timer, go to town. That precise timer code has never worked as well as hoped, to the point where a lot of people have just been #ifdefing it out.

I don’t believe there are any other Mach targets other than Mac OS X currently in use.

Charles

Re: [B2-devel] Sheepthreads

[Christian B. <cb...@ce...>]

 Hi!

 On Thu, 13 Jan 2011 22:08:26 -0500, Darren <dm...@gm...> wrote:
> What is the purpose of sheepthreads, and why is it only built on 
> powerpc?

 If I remember correctly (it's been a while...), LinuxThreads didn't 
 work properly with threads which relocated their stack. Also, it used r2 
 as a pointer to a thread-local data structure, whereas for the Mac OS 
 thread this register needs to be free for use as the TOC pointer.

 I wanted to use threading in SheepShaver, so I wrote a replacement 
 threading library that didn't have these limitations.

 Bye,
 Christian

-- 
   / Physics is an algorithm
 \/ www.cebix.net