--- BasiliskII/TECH 1999/10/03 14:16:25 1.1.1.1 +++ BasiliskII/TECH 2001/02/10 09:20:54 1.5 @@ -38,35 +38,54 @@ compatibility and speed of this approach Basilisk II is designed to run on many different hardware platforms and on many different operating systems. To provide optimal performance under all -environments, it can run in three different modes, depending on the features -of the underlying environment (the modes are selected with the REAL_ADDRESSING -and EMULATED_68K defines in "sysdeps.h"): +environments, it can run in four different modes, depending on the features +of the underlying environment (the modes are selected with the REAL_ADDRESSING, +DIRECT_ADDRESSING and EMULATED_68K defines in "sysdeps.h"): 1. Emulated CPU, "virtual" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 0): This mode is designed for non-68k or little-endian systems or systems that - don't allow accessing RAM at 0x0000..0x1fff. This is also the only mode that - allows 24-bit addressing, and thus the only mode that allows Mac Classic - emulation. The 68k processor is emulated with the UAE CPU engine and two - memory areas are allocated for Mac RAM and ROM. The memory map seen by the - emulated CPU and the host CPU are different. Mac RAM starts at address 0 - for the emulated 68k, but it may start at a different address for the host - CPU. All memory accesses of the CPU emulation go through memory access - functions (do_get_mem_long() etc.) that translate addresses. This slows - down the emulator, of course. - -2. Emulated CPU, "real" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 0): - This mode is intended for big-endian non-68k systems that do allow access to - RAM at 0x0000..0x1fff. As in the virtual addressing mode, the 68k processor - is emulated with the UAE CPU engine and two areas are set up for RAM and ROM - but the emulated CPU lives in the same address space as the host CPU. - This means that if something is located at a certain address for the 68k, - it is located at the exact same address for the host CPU. Mac addresses - and host addresses are the same. The memory accesses of the CPU emulation - still go through access functions but the address translation is no longer - needed, and if the host CPU uses big-endian data layout and can handle - unaligned accesses like the 68k, the memory access functions are replaced - by direct, inlined memory accesses, making for the fastest possible speed - of the emulator. + don't allow accessing RAM at 0x0000..0x1fff. This is also the only mode + that allows 24-bit addressing, and thus the only mode that allows Mac + Classic emulation. The 68k processor is emulated with the UAE CPU engine + and two memory areas are allocated for Mac RAM and ROM. The memory map + seen by the emulated CPU and the host CPU are different. Mac RAM starts at + address 0 for the emulated 68k, but it may start at a different address for + the host CPU. + + In order to handle the particularities of each memory area (RAM, ROM and + Frame Buffer), the address space of the emulated 68k is broken down into + banks. Each bank is associated with a series of pointers to specific + memory access functions that carry out the necessary operations (e.g. + byte-swapping, catching illegal writes to memory). A generic memory access + function, get_long() for example, goes through the table of memory banks + (mem_banks) and fetches the appropriate specific memory access fonction, + lget() in our example. This slows down the emulator, of course. + +2. Emulated CPU, "direct" addressing (EMULATED_68K = 1, DIRECT_ADDRESSING = 1): + As in the virtual addressing mode, the 68k processor is emulated with the + UAE CPU engine and two memory areas are set up for RAM and ROM. Mac RAM + starts at address 0 for the emulated 68k, but it may start at a different + address for the host CPU. Besides, the virtual memory areas seen by the + emulated 68k are separated by exactly the same amount of bytes as the + corresponding memory areas allocated on the host CPU. This means that + address translation simply implies the addition of a constant offset + (MEMBaseDiff). Therefore, the memory banks are no longer used and the + memory access functions are replaced by inline memory accesses. + +3. Emulated CPU, "real" addressing (EMULATED_68K = 1, REAL_ADDRESSING = 1): + This mode is intended for non-68k systems that do allow access to RAM + at 0x0000..0x1fff. As in the virtual addressing mode, the 68k processor + is emulated with the UAE CPU engine and two areas are allocated for RAM + and ROM but the emulated CPU lives in the same address space as the host + CPU. This means that if something is located at a certain address for + the 68k, it is located at the exact same address for the host CPU. Mac + addresses and host addresses are the same. The memory accesses of the CPU + emulation still go through access functions but the address translation + is no longer needed. The memory access functions are replaced by direct, + inlined memory accesses, making for the fastest possible speed of the + emulator. On little-endian systems, byte-swapping is still required, of + course. + A usual consequence of the real addressing mode is that the Mac RAM doesn't any longer begin at address 0 for the Mac and that the Mac ROM also is not located where it usually is on a real Mac. But as the Mac ROM is relocatable @@ -85,8 +104,11 @@ and EMULATED_68K defines in "sysdeps.h") other systems, it might be possible to use access exception handlers to emulate accesses to this area. But if the Low Memory Globals area cannot be made available, using the real addressing mode is not possible. + + Note: currently, real addressing mode is known to work only on AmigaOS, + NetBSD/m68k, and Linux/i386. -3. Native CPU (EMULATED_68K = 0, this also requires REAL_ADDRESSING = 1) +4. 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 @@ -105,11 +127,11 @@ and EMULATED_68K defines in "sysdeps.h") 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). + to be trapped and emulated. The Amiga and NetBSD/m68k versions of + Basilisk II use the latter approach (it is possible to run supervisor + mode tasks under the AmigaOS multitasking kernel (ShapeShifter does + this) but it requires modifying the Exec 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 @@ -239,6 +261,7 @@ which are relatively independent from ea - floppy driver ("sony.cpp") - disk driver ("disk.cpp") - CD-ROM driver ("cdrom.cpp") + - external file system ("extfs.cpp") - serial drivers ("serial.cpp") - Ethernet driver ("ether.cpp") - system-dependant device access ("sys_*.cpp") @@ -380,7 +403,19 @@ MacOS floppy driver comes from the fact Mac models was custom-built for Apple by Sony (this was one of the first applications of the 3.5" floppy format which was also invented by Sony). -6.10. Serial drivers +6.10. External file system +-------------------------- + +Basilisk II also provides a method for accessing files and direcories on the +host OS from the MacOS side by means of an "external" file system (henceforth +called "ExtFS"). The ExtFS is built upon the File System Manager 1.2 interface +that is built into MacOS 7.6 (and later) and available as a system extension +for earlier MacOS versions. Unlike other parts of Basilisk II, extfs.cpp +requires POSIX file I/O and this is not going to change any time soon, so if +you are porting Basilisk II to a system without POSIX file functions, you +should emulate them. + +6.11. Serial drivers -------------------- Similar to the disk drivers, Basilisk II contains replacement serial drivers @@ -404,7 +439,7 @@ install a Deferred Task to do the job. T MacOS when it returns to interrupt level 0. This mechanism sounds complicated but is necessary to ensure stable operation of the serial driver. -6.11. Ethernet driver +6.12. Ethernet driver --------------------- A driver for Ethernet networking is also contained in the NuBus slot ROM. @@ -474,7 +509,7 @@ of what happens upon reception of a pack For a more detailed description of the Ethernet driver, see "Inside AppleTalk". -6.12. System-dependant device access +6.13. System-dependant device access ------------------------------------ The method for accessing floppy drives, hard disks, CD-ROM drives and files @@ -483,14 +518,15 @@ portable, all device I/O is made via the implemented by the (system-dependant) "sys_*.cpp" modules which provides a standard, Unix-like interface to all kinds of devices. -6.13. User interface strings +6.14. User interface strings ---------------------------- To aid in localization, all user interface strings of Basilisk II are collected -in "user_strings.cpp" and accessed via the GetString() function. This way, -Basilisk II may be easily translated to different languages. +in "user_strings.cpp" (for common strings) and "user_strings_*.cpp" (for +platform-specific strings), and accessed via the GetString() function. This +way, Basilisk II may be easily translated to different languages. -6.14. Preferences management +6.15. Preferences management ---------------------------- The module "prefs.cpp" handles user preferences in a system-independant way.