| 38 |
|
|
| 39 |
|
Basilisk II is designed to run on many different hardware platforms and on |
| 40 |
|
many different operating systems. To provide optimal performance under all |
| 41 |
< |
environments, it can run in three different modes, depending on the features |
| 42 |
< |
of the underlying environment (the modes are selected with the REAL_ADDRESSING |
| 43 |
< |
and EMULATED_68K defines in "sysdeps.h"): |
| 41 |
> |
environments, it can run in four different modes, depending on the features |
| 42 |
> |
of the underlying environment (the modes are selected with the REAL_ADDRESSING, |
| 43 |
> |
DIRECT_ADDRESSING and EMULATED_68K defines in "sysdeps.h"): |
| 44 |
|
|
| 45 |
|
1. Emulated CPU, "virtual" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 0): |
| 46 |
|
This mode is designed for non-68k or little-endian systems or systems that |
| 47 |
< |
don't allow accessing RAM at 0x0000..0x1fff. This is also the only mode that |
| 48 |
< |
allows 24-bit addressing, and thus the only mode that allows Mac Classic |
| 49 |
< |
emulation. The 68k processor is emulated with the UAE CPU engine and two |
| 50 |
< |
memory areas are allocated for Mac RAM and ROM. The memory map seen by the |
| 51 |
< |
emulated CPU and the host CPU are different. Mac RAM starts at address 0 |
| 52 |
< |
for the emulated 68k, but it may start at a different address for the host |
| 53 |
< |
CPU. All memory accesses of the CPU emulation go through memory access |
| 54 |
< |
functions (do_get_mem_long() etc.) that translate addresses. This slows |
| 55 |
< |
down the emulator, of course. |
| 56 |
< |
|
| 57 |
< |
2. Emulated CPU, "real" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 0): |
| 58 |
< |
This mode is intended for big-endian non-68k systems that do allow access to |
| 59 |
< |
RAM at 0x0000..0x1fff. As in the virtual addressing mode, the 68k processor |
| 60 |
< |
is emulated with the UAE CPU engine and two areas are set up for RAM and ROM |
| 61 |
< |
but the emulated CPU lives in the same address space as the host CPU. |
| 62 |
< |
This means that if something is located at a certain address for the 68k, |
| 63 |
< |
it is located at the exact same address for the host CPU. Mac addresses |
| 64 |
< |
and host addresses are the same. The memory accesses of the CPU emulation |
| 65 |
< |
still go through access functions but the address translation is no longer |
| 66 |
< |
needed, and if the host CPU uses big-endian data layout and can handle |
| 67 |
< |
unaligned accesses like the 68k, the memory access functions are replaced |
| 68 |
< |
by direct, inlined memory accesses, making for the fastest possible speed |
| 69 |
< |
of the emulator. |
| 47 |
> |
don't allow accessing RAM at 0x0000..0x1fff. This is also the only mode |
| 48 |
> |
that allows 24-bit addressing, and thus the only mode that allows Mac |
| 49 |
> |
Classic emulation. The 68k processor is emulated with the UAE CPU engine |
| 50 |
> |
and two memory areas are allocated for Mac RAM and ROM. The memory map |
| 51 |
> |
seen by the emulated CPU and the host CPU are different. Mac RAM starts at |
| 52 |
> |
address 0 for the emulated 68k, but it may start at a different address for |
| 53 |
> |
the host CPU. |
| 54 |
> |
|
| 55 |
> |
In order to handle the particularities of each memory area (RAM, ROM and |
| 56 |
> |
Frame Buffer), the address space of the emulated 68k is broken down into |
| 57 |
> |
banks. Each bank is associated with a series of pointers to specific |
| 58 |
> |
memory access functions that carry out the necessary operations (e.g. |
| 59 |
> |
byte-swapping, catching illegal writes to memory). A generic memory access |
| 60 |
> |
function, get_long() for example, goes through the table of memory banks |
| 61 |
> |
(mem_banks) and fetches the appropriate specific memory access fonction, |
| 62 |
> |
lget() in our example. This slows down the emulator, of course. |
| 63 |
> |
|
| 64 |
> |
2. Emulated CPU, "direct" addressing (EMULATED_68K = 1, DIRECT_ADDRESSING = 1): |
| 65 |
> |
As in the virtual addressing mode, the 68k processor is emulated with the |
| 66 |
> |
UAE CPU engine and two memory areas are set up for RAM and ROM. Mac RAM |
| 67 |
> |
starts at address 0 for the emulated 68k, but it may start at a different |
| 68 |
> |
address for the host CPU. Besides, the virtual memory areas seen by the |
| 69 |
> |
emulated 68k are separated by exactly the same amount of bytes as the |
| 70 |
> |
corresponding memory areas allocated on the host CPU. This means that |
| 71 |
> |
address translation simply implies the addition of a constant offset |
| 72 |
> |
(MEMBaseDiff). Therefore, the memory banks are no longer used and the |
| 73 |
> |
memory access functions are replaced by inline memory accesses. |
| 74 |
> |
|
| 75 |
> |
3. Emulated CPU, "real" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 1): |
| 76 |
> |
This mode is intended for non-68k systems that do allow access to RAM |
| 77 |
> |
at 0x0000..0x1fff. As in the virtual addressing mode, the 68k processor |
| 78 |
> |
is emulated with the UAE CPU engine and two areas are allocated for RAM |
| 79 |
> |
and ROM but the emulated CPU lives in the same address space as the host |
| 80 |
> |
CPU. This means that if something is located at a certain address for |
| 81 |
> |
the 68k, it is located at the exact same address for the host CPU. Mac |
| 82 |
> |
addresses and host addresses are the same. The memory accesses of the CPU |
| 83 |
> |
emulation still go through access functions but the address translation |
| 84 |
> |
is no longer needed. The memory access functions are replaced by direct, |
| 85 |
> |
inlined memory accesses, making for the fastest possible speed of the |
| 86 |
> |
emulator. On little-endian systems, byte-swapping is still required, of |
| 87 |
> |
course. |
| 88 |
> |
|
| 89 |
|
A usual consequence of the real addressing mode is that the Mac RAM doesn't |
| 90 |
|
any longer begin at address 0 for the Mac and that the Mac ROM also is not |
| 91 |
|
located where it usually is on a real Mac. But as the Mac ROM is relocatable |
| 104 |
|
other systems, it might be possible to use access exception handlers to |
| 105 |
|
emulate accesses to this area. But if the Low Memory Globals area cannot |
| 106 |
|
be made available, using the real addressing mode is not possible. |
| 107 |
+ |
|
| 108 |
+ |
Note: currently, real addressing mode is known to work only on AmigaOS, |
| 109 |
+ |
NetBSD/m68k, and Linux/i386. |
| 110 |
|
|
| 111 |
< |
3. Native CPU (EMULATED_68K = 0, this also requires REAL_ADDRESSING = 1) |
| 111 |
> |
4. Native CPU (EMULATED_68K = 0, this also requires REAL_ADDRESSING = 1) |
| 112 |
|
This mode is designed for systems that use a 68k (68020 or better) processor |
| 113 |
|
as host CPU and is the technically most difficult mode to handle. The Mac |
| 114 |
|
CPU is no longer emulated (the UAE CPU emulation is not needed) but MacOS |
| 127 |
|
priviledged instructions, mostly for interrupt control). So either |
| 128 |
|
the whole emulator has to be run in supervisor mode (which usually is |
| 129 |
|
not possible on multitasking systems) or priviledged instructions have |
| 130 |
< |
to be trapped and emulated. The Amiga version of Basilisk II uses the |
| 131 |
< |
latter approach (it is possible to run supervisor mode tasks under |
| 132 |
< |
the AmigaOS multitasking kernel (ShapeShifter does this) but it |
| 133 |
< |
requires modifying the task switcher and makes the emulator more |
| 134 |
< |
unstable). |
| 130 |
> |
to be trapped and emulated. The Amiga and NetBSD/m68k versions of |
| 131 |
> |
Basilisk II use the latter approach (it is possible to run supervisor |
| 132 |
> |
mode tasks under the AmigaOS multitasking kernel (ShapeShifter does |
| 133 |
> |
this) but it requires modifying the Exec task switcher and makes the |
| 134 |
> |
emulator more unstable). |
| 135 |
|
c) On multitasking systems, interrupts can usually not be handled as on |
| 136 |
|
a real Mac (or with the UAE CPU). The interrupt levels of the host |
| 137 |
|
will not be the same as on a Mac, and the operating systems might not |
