Move to SDL2

Until now, the testbed was running inside a Cocoa application, but the need for a platform-agnostic implementation was already putting pressure on adding an abstraction layer between the host and the emulated environment. At this point, we took this as a possibility to switch to SDL2, changing the test environment at the same to the SDL2 library but also at the same time adding the abstraction layer on top of it.

This was accomplished by adding “Platform” layer, which abstracts the creation of sound devices, graphics context and input handling into a set of calls which the Toolbox emulator uses. In future, this layer can be extended to support other platforms, so someday we can add again Cocoa layer to handle platform-specific stuff like, like seamless desktop integration.

At this point, we added page switching support to the VIA memory page handler, which is the “Classic Video” hardware abstraction layer to choose active video buffer. The above video demonstrates results of the page-switching test.

The “Fake” ROM

An interesting feature of the original Macintosh system is how the onboard ROM was able to contain majority of features of the operating system, reducing the unpatched code loaded from disk to a minimum. As we attempt to replicate system startup as closely as possible with our architecture, an interesting point came up: On real Mac, the boot process is kicked off by ROM doing a POST hardware check, initializing a bunch of stuff in the memory, and loading a stage 1 boot loader from the disk using the disk and file system drivers in ROM. As our goal is to actually use a virtual file system, we need to have a way to kick-start this filesystem. What we decided to do, is to actually simulate ROM resources, and add our native filesystem driver as a DRVR resource which will be loaded by the device manager, and which file manager will use to actually mount the virtualized disk.

Another benefit of the “Fake” ROM is, that it provides us with neat place to store the UPP records for our trap handlers. As trap dispatch tables contain only 32-bit pointers to the handlers, which for native calls only point to the UPP records, we could now install these dynamically into the “ROM” address space, with additional benefit that if any curious applications would snoop for the address of trap handlers, they would to be above ROMBase, like on a real Mac.

The “Fake” ROM format follows closely the one used by Apple, with the exception that we only use the ROM resources, and preallocate a certain size of image for the UPP records. Thanks to this, we were able to start implementation of first parts of Resource Manager support, starting with creation of ROZ (ROM resource zone), which is created inside system zone to hold the master pointers and resource map which are “mapped” to the ROM space using a very weird and clever hack like on real Mac

A fun fact: A Mac can have multiple types (24 vs 32 bits) of zones active at once – The ROM has resources formatted either to 24 or 32 bits, but as the ROM cannot be changed when the 32-bit mode is toggled on real Mac using the Memory control panel, the ROZ will always be in the format for which ROM resources were created for.

For now, we just use the “fake” ROM to hold fonts and cursors, adding more stuff there as needed.