Subject: Basilisk II and native 68k emulation!
To: None <port-mac68k@netbsd.org>
From: Nathan Raymond <nate@portents.com>
List: port-mac68k
Date: 08/19/1999 03:50:37
I was just taking a look at Basilisk II -

http://www.uni-mainz.de/~bauec002/B2Main.html

This emulator can actually run software on a native 68k processor on 
systems that have one - this means it may be possible to run the 
MacOS inside NetBSD in X Windows at near full speed!  All we need is 
pthreads, it looks like:

   Unix (tested under Linux, Solaris 2.5, FreeBSD 3.x and IRIX 6.5):
   You need X11R4, pthreads support and GNU make. To use the GUI preferences
   editor, you also need GTK+ version 1.2 or better. On Linux, you need
   glibc 2.0 or better.

Does anyone have any ideas when pthreads 68k will be available?

Info on the native 68k mode for those interested:

3. Native CPU (EMULATED_68K = 0, this also requires REAL_ADDRESSING = 1)
    This mode is designed for systems that use a 68k (68020 or better) processor
    as host CPU and is the technically most difficult mode to handle. The Mac
    CPU is no longer emulated (the UAE CPU emulation is not needed) but MacOS
    and Mac applications run natively on the existing 68k CPU. This means that
    the emulator has its maximum possible speed (very close to that of a real
    Mac with the same CPU). As there is no control over the memory accesses of
    the CPU, real addressing mode is implied, and so the Low Memory area must
    be accessible (an MMU might be used to set up different address spaces for
    the Mac and the host, but this is not implemented in Basilisk II). The
    native CPU mode has some possible pitfalls that might make its
    implementation difficult on some systems:
      a) Implied real addressing (this also means that Mac programs that go out
         of control can crash the emulator or the whole system)
      b) MacOS and Mac applications assume that they always run in supervisor
         mode (more precisely, they assume that they can safely use certain
         priviledged instructions, mostly for interrupt control). So either
         the whole emulator has to be run in supervisor mode (which usually is
         not possible on multitasking systems) or priviledged instructions have
         to be trapped and emulated. The Amiga version of Basilisk II uses the
         latter approach (it is possible to run supervisor mode tasks under
         the AmigaOS multitasking kernel (ShapeShifter does this) but it
         requires modifying the task switcher and makes the emulator more
         unstable).
      c) On multitasking systems, interrupts can usually not be handled as on
         a real Mac (or with the UAE CPU). The interrupt levels of the host
         will not be the same as on a Mac, and the operating systems might not
         allow installing hardware interrupt handlers or the interrupt handlers
         might have different stack frames and run-time environments than 68k
         hardware interrupts. The usual solution is to use some sort of software
         interrupts or signals to interrupt the main emulation process and to
         manually call the Mac 68k interrupt handler with a faked stack frame.
      d) 68060 systems are a small problem because there is no Mac that ever
         used the 68060 and MacOS doesn't know about this processor. Basilisk II
         reports the 68060 as being a 68040 to the MacOS and patches some places
         where MacOS makes use of certain 68040-specific features such as the
         FPU state frame layout or the PTEST instruction. Also, Basilisk II
         requires that all of the Motorola support software for the 68060 to
         emulate missing FPU and integer instructions and addressing modes is
         provided by the host operating system (this also applies to the 68040).
      e) The "EMUL_OP" mechanism described below requires the interception and
         handling of certain emulator-defined instructions.
--
nathan raymond
webmaster <a href="http://www.everythingmac.com">everythingmac.com</a>