| 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 |
| 261 |
|
- floppy driver ("sony.cpp") |
| 262 |
|
- disk driver ("disk.cpp") |
| 263 |
|
- CD-ROM driver ("cdrom.cpp") |
| 264 |
+ |
- external file system ("extfs.cpp") |
| 265 |
|
- serial drivers ("serial.cpp") |
| 266 |
|
- Ethernet driver ("ether.cpp") |
| 267 |
|
- system-dependant device access ("sys_*.cpp") |
| 403 |
|
Mac models was custom-built for Apple by Sony (this was one of the first |
| 404 |
|
applications of the 3.5" floppy format which was also invented by Sony). |
| 405 |
|
|
| 406 |
< |
6.10. Serial drivers |
| 406 |
> |
6.10. External file system |
| 407 |
> |
-------------------------- |
| 408 |
> |
|
| 409 |
> |
Basilisk II also provides a method for accessing files and direcories on the |
| 410 |
> |
host OS from the MacOS side by means of an "external" file system (henceforth |
| 411 |
> |
called "ExtFS"). The ExtFS is built upon the File System Manager 1.2 interface |
| 412 |
> |
that is built into MacOS 7.6 (and later) and available as a system extension |
| 413 |
> |
for earlier MacOS versions. Unlike other parts of Basilisk II, extfs.cpp |
| 414 |
> |
requires POSIX file I/O and this is not going to change any time soon, so if |
| 415 |
> |
you are porting Basilisk II to a system without POSIX file functions, you |
| 416 |
> |
should emulate them. |
| 417 |
> |
|
| 418 |
> |
6.11. Serial drivers |
| 419 |
|
-------------------- |
| 420 |
|
|
| 421 |
|
Similar to the disk drivers, Basilisk II contains replacement serial drivers |
| 439 |
|
MacOS when it returns to interrupt level 0. This mechanism sounds complicated |
| 440 |
|
but is necessary to ensure stable operation of the serial driver. |
| 441 |
|
|
| 442 |
< |
6.11. Ethernet driver |
| 442 |
> |
6.12. Ethernet driver |
| 443 |
|
--------------------- |
| 444 |
|
|
| 445 |
|
A driver for Ethernet networking is also contained in the NuBus slot ROM. |
| 509 |
|
|
| 510 |
|
For a more detailed description of the Ethernet driver, see "Inside AppleTalk". |
| 511 |
|
|
| 512 |
< |
6.12. System-dependant device access |
| 512 |
> |
6.13. System-dependant device access |
| 513 |
|
------------------------------------ |
| 514 |
|
|
| 515 |
|
The method for accessing floppy drives, hard disks, CD-ROM drives and files |
| 518 |
|
implemented by the (system-dependant) "sys_*.cpp" modules which provides a |
| 519 |
|
standard, Unix-like interface to all kinds of devices. |
| 520 |
|
|
| 521 |
< |
6.13. User interface strings |
| 521 |
> |
6.14. User interface strings |
| 522 |
|
---------------------------- |
| 523 |
|
|
| 524 |
|
To aid in localization, all user interface strings of Basilisk II are collected |
| 525 |
< |
in "user_strings.cpp" and accessed via the GetString() function. This way, |
| 526 |
< |
Basilisk II may be easily translated to different languages. |
| 525 |
> |
in "user_strings.cpp" (for common strings) and "user_strings_*.cpp" (for |
| 526 |
> |
platform-specific strings), and accessed via the GetString() function. This |
| 527 |
> |
way, Basilisk II may be easily translated to different languages. |
| 528 |
|
|
| 529 |
< |
6.14. Preferences management |
| 529 |
> |
6.15. Preferences management |
| 530 |
|
---------------------------- |
| 531 |
|
|
| 532 |
|
The module "prefs.cpp" handles user preferences in a system-independant way. |
