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