ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/cebix/BasiliskII/TECH
(Generate patch)

Comparing BasiliskII/TECH (file contents):
Revision 1.2 by cebix, 1999-10-21T18:29:06Z vs.
Revision 1.5 by gbeauche, 2001-02-10T09:20:54Z

# Line 38 | Line 38 | compatibility and speed of this approach
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
# Line 85 | Line 104 | and EMULATED_68K defines in "sysdeps.h")
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
# Line 105 | Line 127 | and EMULATED_68K defines in "sysdeps.h")
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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines