Trap Dispatcher, native interface, and Memory Manager

Although having graphical output in the framebuffer is neat, and for a graphical system such as Mac a required element, the most critical components of the entire Toolbox emulation are definitely the Memory Manager and Trap Dispatcher:

Trap dispatcher

In a rather clever way, Macintosh system programmers used the A-line (line 1010) handler in the 68K CPU to implement all the Toolbox API calls. How this works is that any 68K instruction, which is of the hex form Axxx (from A000 to AFFF), triggers an A-line exception in the CPU. In this situation, the CPU looks up the exception handler routine address from vector table at index #10 (32-bit address at low memory location 0x28), sets up the exception frame, and calls the exception handler.

On the Mac, the trap dispatcher is responsible for handling these A-line exceptions. The actual A-line opcodes, which triggered the trap dispatcher, are divided to OS traps and Toolbox traps based on bit 11, which are handled differently based on their type. More detailed information about how trap dispatcher works is available in Part 3A of the Mac Almanac II at http://www.mac.linux-m68k.org/devel/macalmanac.php

Native interface

As the Toolbox will be implemented in C, another challenge is interfacing the emulated 68K code with C, especially due to the requirement that a 68K application might want to add their own trap handlers, and also call existing native handlers from the 68K code! To solve this, luckily Apple already did a lot of groundwork by introducing the Mixed Mode Manager in the early 1990s, to help interfacing 68K code with the PowerPC code when Macs switched from 68K to PowerPC CPUs. In this emulator, we will attempt to implement the native calls using Mixed Mode-type UPPs, adding the C calls as a completely new “emulator” ISA type (in addition to Apple’s predefined 68K and PowerPC ISAs).

Memory Manager

With the previously added 32 kilobyte RAM block, we could start work on the Memory Manager. As stated in the goals, the first phase aims for 24-bit compatibility, as the “Classic Mac” macs are anyway limited to 24-bit addressing due to the 68000 CPU’s 24-bit bus, and a lot of software from that era is also not 32-bit clean. The groundwork for Memory Manager was done in such a way, that adding 32-bit support next to the 24-bit implementation should be relatively easy. At this point, we don’t yet have a working trap dispatcher, or a 68K CPU for that matter, but rather use direct C method calls to the required Toolbox API calls.

Output from the DumpZone call of one of the first 24-bit memory manager C prototypes