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.1 by cebix, 1999-10-03T14:16:25Z 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
# Line 239 | Line 261 | which are relatively independent from ea
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")
# Line 380 | Line 403 | MacOS floppy driver comes from the fact
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
# Line 404 | Line 439 | install a Deferred Task to do the job. T
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.
# Line 474 | Line 509 | of what happens upon reception of a pack
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
# Line 483 | Line 518 | portable, all device I/O is made via the
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.

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines