The Final Voyage Mac OS
Wonderful game, but the Mac version isn’t worth it! Syberia is a beautiful, challenging game similar to games like Dracula and Return to Mysterious Island, but unfortunately I was duped into buying it from the App Store because this version has kept Syberia as a single game (other sellers have it divided into 3 “parts”, not the same as Syberia I, II and II). This version has been changed. Operating Systems Mac OS X 10.4 PPC, Mac OS X 10.5 PPC, Macintosh, Mac OS X 10.4 Intel, Mac OS X 10.5 Intel, Mac OS X 10.6 Intel.
Is your Mac up to date with the latest version of the Mac operating system? Is it using the version that is required by a product you want to use with your Mac? Which versions are earlier (older) or later (newer, more recent)? To find out, check which version is installed now.
If your macOS isn't up to date, you may be able to update to a later version.
Which macOS version is installed?
From the Apple menu in the corner of your screen, choose About This Mac. You should see the macOS name, such as macOS Big Sur, followed by its version number. If you need to know the build number as well, click the version number to see it.
Which macOS version is the latest one?
These are all Mac operating systems, starting with the most recent. When a major new macOS is released, it gets a new name, such as macOS Big Sur. As updates that change the macOS version number become available, this article will be updated to show the latest version of that macOS.
If your Mac is using an earlier version of any Mac operating system, you should install the latest Apple software updates, which can include important security updates and updates for the apps that are installed by macOS, such as Safari, Books, Messages, Mail, Music, Calendar and Photos.
| macOS | Latest version |
|---|---|
| macOS Big Sur | 11.2.3 |
| macOS Catalina | 10.15.7 |
| macOS Mojave | 10.14.6 |
| macOS High Sierra | 10.13.6 |
| macOS Sierra | 10.12.6 |
| OS X El Capitan | 10.11.6 |
| OS X Yosemite | 10.10.5 |
| OS X Mavericks | 10.9.5 |
| OS X Mountain Lion | 10.8.5 |
| OS X Lion | 10.7.5 |
| Mac OS X Snow Leopard | 10.6.8 |
| Mac OS X Leopard | 10.5.8 |
| Mac OS X Tiger | 10.4.11 |
| Mac OS X Panther | 10.3.9 |
| Mac OS X Jaguar | 10.2.8 |
| Mac OS X Puma | 10.1.5 |
| Mac OS X Cheetah | 10.0.4 |
2 Years ago11 Feb 2019 7:48 pm by Dog Cow
Apple had already been bitten by the cloners: unscrupulous companies who duplicated the Apple II motherboard and its ROM and sold unauthorized copies. Steve Jobs wasn't going to let that happen again with Macintosh. Per his orders, a small icon which read 'Stolen from Apple Computer' was embedded in the ROM. Unlike the Apple II, whose commented 6502 ROM source was printed in its reference manuals, the Macintosh ROM source was a closely-guarded secret. Thus the Macintosh ROM remains one of the most mysterious aspects of the machine.
But as Sherlock Holmes famously said in The Adventure of the Dancing Men, 'What one man can invent another can discover.' With this adage in mind, let us begin on a voyage of discovery into the Macintosh 64K ROM with MacsBug.
Where is the ROM Located?
This is a question with two answers. If you are asking where is the ROM physically located? the answer is in two chips on the motherboard, labelled ROM HI and ROM LOW, respectively. The 64 kilobytes of data in ROM is split in half between these two chips. The 'HI' chip holds the high-byte of each address in ROM, while the 'LOW' chip holds the low-byte.
To visualize what half means in this case, imagine a book with 64 pages. You take a pair of scissors and cut each page in half vertically. So you have the left half of 64 pages, and the right half of 64 pages. Call the left half 'HI' and the right half 'LOW', and now you have the equivalent of how the Mac ROM is divided.
The HI ROM is Apple part number 342-0220-B while the LOW ROM is 342-0221-B There was an earlier revision of the ROM, with suffix -A. This ROM has a slightly different Sony disk driver which is only compatible with early model Sony OA-D34V 400K disk drives. The -B ROM revision is compatible with both early and later model Sony drives.
The Mac has two ROM chips located near the 68000 microprocessor
Notice one big difference between these two chips and the other 49 on the motherboard: the two ROM chips are the only ones socketed. All other chips are soldered to the motherboard. Macintosh was designed with a future ROM upgrade in mind. The original Macintosh ROM is only 64K in size, but the motherboard has 16 address lines for the ROM sockets, granting a maximum capacity for 128K of ROM.
Where is the ROM logically located?
Now here is the second answer to the question. Where is the ROM logically located within the 68000 CPU's address space? The 68000 has a 24-bit address space meaning there are 16,777,215 memory locations, or 16 MB. This address space is divided into quarters, meaning that 4 MB of space is reserved for ROM.
ROM is mapped into memory starting at address $400000 (decimal 4,194,304). It's physically impossible for there to be 4 MB of ROM (without modifying the logic board), so the 64K ROM ends up being repeated several times. The last byte of ROM is at location $40FFFF. Accessing the next location, $410000, brings you back to the beginning of ROM, and it continues on, wrapping around a dozen or more times.
The ROM's base address is stored in global variable ROMBase which is stored in low-memory at $2AE. Assembly language programmers should use ROMBase to determine the ROM's location. The wrapping around effect described previously is merely trivia and should not be used in any code you write for Macintosh.
At the very earliest stages of system startup, the Mac ROM is also located at address 0. This location allows the 68000 CPU to access some hard-coded vectors, stored in ROM, that it needs for initialization. The Synertek SY6522 VIA vOverlay bit is used only during system startup to cause the ROM to appear at the bottom of memory. After the RAM is tested, the overlay bit is cleared, placing RAM starting at location 0 as usual and ROM at $400000.
What is in the ROM?
ROM is the Macintosh's permanent read-only memory and contains information and instructions that give the Mac its look, feel, and personality. While your data on disk may change and contents of RAM be altered, Apple Computer personally guarantees that the ROM will never change while your Macintosh is running.
There are about 480 routines in ROM, which can be divided into 3 main groups:
- Operating System
- User Interface Toolbox
- QuickDraw
Each of these groups consumes roughly 1/3 of the 64K of ROM. The majority of the Mac's Operating System is in fact stored in ROM, not on your startup disk. The System file merely contains resources for localization, keyboard mapping, desk accessories and fonts, some icons, and other resources that customize the way the Mac works. The Operating System in ROM contains the Memory Manager, Segment Loader, File Manager, Device Manager, Disk Driver, Serial Drivers, Vertical Retrace Manager, among others. These are all low-level routines that don't have any impact on the Mac's user interface.
Now the User Interface Toolbox in ROM gives the Mac its windows, menus, and icons interface! Within the Toolbox are found the Font Manager, Event Manager, Window Manager, Control Manager, Menu Manager, TextEdit, Dialog Manager, Scrap Manager, and so on. These managers control how the user interface works, but not what it looks like. As you may know, there are several types of windows. You can have a window with a black, rounded title bar, or a window with no scroll bars, or a window with no close box. The appearance of each type of window is stored in a WDEF resource in your System file on disk. WDEF stands for Window Definition, and it's these definition routines that determine how the windows, menus, controls (such as scroll bars), and so on look.
Using a WDEF resource that draws round windows in the Finder
The Final Voyage Movie
The Window Manager in ROM does not assume rectangular windows. Its routines will move, close, resize, and redraw any window of any arbitrary shape. For example, it's possible to have round windows, or a window with a hole in it that shows part of the desktop. You can have menus with an icon next to each item. You can have custom controls beyond just radio buttons and scroll bars, such as an analog clock face, or a three-way toggle switch in your application. You could have circular scroll bars to work with your circular windows! These definition routines are all stored as resources on disk, not in ROM, precisely so they can be customized and changed.
The final block of code in ROM is QuickDraw, the patented graphics package for Apple Lisa and Macintosh, written single-handedly by Bill Atkinson. QuickDraw is about 40,000 lines of assembly source code, and is identical on Lisa and Macintosh. It is used to draw everything you see on screen: windows, icons, fonts, shapes, patterns, and so on. It is also used in the Print Manager to reproduce on paper an identical copy of what you see on screen.
Using MacsBug to Disassemble ROM
Now let's use MacsBug, the Macintosh debugger, to disassemble and explore the ROM. If you don't have MacsBug on your startup disk, refer to the MacsBug article on where to get it and how to install it. Among other places, MacsBug can be found on MDS Disk 2.
You should also have the Programmer's switch installed on the left side of your Mac to access MacsBug. In a pinch, you can use the round end of a paperclip to push the Interrupt button, but it's not an ideal solution, as you could hit the Reset button by mistake!
Once you have everything installed, boot your Mac, and at the Finder desktop, press the Interrupt button to enter MacsBug.
First, let's verify ROMBase. We will use MacsBug's DM (display memory) command. Type:
| Code: |
| DM 2AE |
After you press Return, you should see:
| Code: |
| >DM 2AE 0002AE 0040 0000 0000 0B00 |
There will be more to this line after 0B00, but we only care about the first 4 bytes which read $00400000. That's the location of the ROM.
Now let's examine the first 16 bytes of ROM. Type:
| Code: |
| DM @2AE |
This MacsBug command uses @ to make location 2AE a pointer.
You should see the following:
| Code: |
| 400000 28BA 4E50 0040 002A 0069 6000 0038 6000 |
At the far right will be the ASCII interpretation, but it's gibberish. Let's begin by dissecting these first 16 bytes of ROM.
The first 4 bytes $28BA4E50 is the ROM checksum. The next 4 bytes tell the 68000 where its program counter (PC) should initially point after reset. $40002A is the address of the BootStart routine in ROM. We'll explore this routine next.
The following two bytes, $0069 is the ROM version number. In decimal this is 105. $69 corresponds to 6.9 which was the final developmental version number of the Mac ROM. When the ROM was frozen in September 1983, it was called to ROM 7.0. The point is that version numbers $69, 105, 6.9, and 7.0 all refer to the same ROM version: the final release of the original 64K ROM.
The 128K ROM, used in the Macintosh 512Ke and Mac Plus, is version number $0075, or 117 in decimal.
After the 2-byte verion number, the remaining 6 bytes are 68000 instructions. These instructions begin at $40000A. Let's switch to using MacsBug's IL command to disassemble the machine code.Final Voyage Dvd
Type:| Code: |
| IL @2AE+A |
At $40002A, shown with the red arrow in the screenshot above, is the entry point for BootStart. BootStart begins by checking location $F80000 for signature bytes $AA55. This was a hook for debugging hardware or software used in early Macintosh development. If the debugger wasn't found, then execution branches to $400044 to initialize the 68000 status register, address register A5, and continue with the rest of the startup procedures.
A future Mac 512K Blog article will explore the Mac's startup procedures in depth.
Tracing the Trap Dispatcher
Whenever an application or desk accessory wants to use a Macintosh Toolbox routine, it uses a 2-byte trap number to refer to the particular routine. The Trap Dispatcher in ROM looks up this number and calls the appropriate subroutine, which may be located in ROM or RAM. Andy Hertzfeld wrote the Trap Dispatcher, beginning in July 1982.
Here are a few common Toolbox routines and their corresponding trap numbers:
- AddResMenu - A94D
- DrawString - A884
- GetNewDialog - A97C
- InitCursor - A850
- Open - A000
- PackBits - A8CF
To the 68000 CPU, Macintosh Toolbox and Operating System traps look like a special set of instructions. The CPU recognizes, or traps these instructions, and hands them off to the Macintosh Trap Dispatcher for further processing.
The Trap Dispatcher, located in ROM, refers to a table of all possible code numbers with corresponding subroutine locations for each. To save space, the original 64K ROM has only one table to hold both Toolbox and Operating System traps. This table is kept in ROM, in a compressed format. When you startup the Mac, the table is copied into RAM at location $400 so that it may be patched to fix ROM bugs or add new traps.
There is room for only 512 trap entries, and each entry is 2 bytes long, making 1024 bytes total. The 128K ROM in the Mac Plus and 512Ke maintains separate tables for Operating System and Toolbox traps which allows for many more traps.
Let's trace and disassemble the Trap Dispatcher to learn more about how it works!
At the Finder desktop, press the Interrupt switch to enter MacsBug. Type
| Code: |
| AB LAUNCH |
MacsBug should appear immediately and show:
| Code: |
| MACTRAP A9F2 LAUNCH |
| Code: |
| DM DFF1FF |
You are now in the Trap Dispatcher, at its entry point $401018. But how did we get here? The Motorola 68000 CPU stores the location for all A-line traps in low-memory location $28. This vector is one of several for the various errors and exceptions which the 68000 must handle. The Macintosh designers decided to route just about all of the possible exceptions, except for A-line instructions for Toolbox traps, through a central Error Manager. This is the same Error Manager that shows the infamous bomb dialog.
If you type
| Code: |
| DM 28 |
Type
| Code: |
| IL PC |
Type S, then continue pressing Return to step through the Trap Dispatcher and see it in action. You will see that the trap code for Launch, A9F2, is copied from the stack into register D2. The code in D2 is then compared against #$A800. If the trap code is less than A800, it's an Operating System trap. Otherwise it's a Toolbox trap. The two traps are handled slightly differently when it comes to saving and restoring registers.
Launch happens to be a Toolbox trap used to run an application. The Trap Dispatcher computes an index into the dispatch table by first chopping off bits 9 thru 15 to yield an index number from 0 to 511. As mentioned earlier, the trap dispatch table only holds 512 entries. $A9F2 becomes $1F2. Each entry in the table is 2 bytes long, so D2 is doubled by adding it to itself, resulting in $3E4.
The address of the dispatch table, $400 is loaded into A2, and will be used as a base address to find the trap location in the table. The next instruction adds this base address $400 to D2, checks the value in the table, and saves the result, $2609 in D2.
You can verify this operation yourself by typing
| Code: |
| DM 400+3E4 |
Next, this value from the trap dispatch table is also doubled, again by adding D2 to itself, which yields $4C12. This value is an offset from a base address. But from which base address? The trap dispatch table can point to either ROM or RAM. Bit 15 of this offset is a flag: if set, the trap is in RAM; if clear, the trap is in ROM.
In this case, the high-bit is clear in $4C12 meaning that this is a ROM offset. The BCS instruction which tested for the high-bit will not branch. The next instruction will add ROMBase, stored in $2AE, to our offset in D2. ROMBase, as shown earlier in this article, is typically $400000.
At last we have computed the subroutine location for Launch. It is $400000 + $4C12 = $404C12. The next few instructions in the Trap Dispatcher push this address on the stack and then 'fake' an RTS to transfer control to the Launch subroutine in ROM. Apple II users will recognize this programming technique was also used in the Apple II Monitor.
If you have been following along thus far, pressing Return to step through each instruction in the Trap Dispatcher, you should have reached the RTS at $401042. After you press Return, you will see that you are at $404C12. Type
| Code: |
| WH PC |
The Trap Dispatcher has successfully done its job, and we have arrived at the Launch subroutine.
Disassembling a ROM routine
After learning how the Trap Dispatcher works, let's disassemble a ROM subroutine. We could continue using MacsBug's step command to trace through Launch, but let's look at another one instead so we have more opportunity for learning. There is a trap that will allow an application to specify a function that should be called when the Memory Manager needs to allocate more blocks of memory, called SetGrowZone. Let's disassemble this trap.
First we need to know the trap number. Appendix C of Inside Macintosh volume III has a table of trap names to numbers. SetGrowZone is on page III-222. Its number is A04B.
Now we can apply the same transformations as in the Trap Dispatcher. A04B is less than A800, so this is an Operating System trap. For OS traps, bit 8 is a flag to save/restore register A0. After checking this flag, bit 8 is cleared. Clear bits 8 thru 15 to get $4B. Double it to make $96. This is an offset within the trap dispatch table.
Recall that the trap dispatch table begins at $400, so add $400 to $96 to get $496. Type
| Code: |
| DM 496 |
Aha! Because this trap offset is pointing to a RAM location, we know that its address was patched by the System file.
RAMBase is stored at low memory global $2B2. Type
| Code: |
| DM 2B2 |
Due to the limits of a 15-bit offset, RAM patches can only be located within the first 64K of RAM. This limitation is no hardship for a Mac 128K, but it is something to be aware of for the Mac 512K. For this reason, RAM patches are typically loaded into the System Heap, which usually begins at $B00.
If an application patches a trap, it is possible for the patched code, stored in the application heap, to be beyond the 15-bit offset range.
Let's disassemble SetGrowZone by typing
| Code: |
| IL 26B2 |
This subroutine is very short, only four instructions, which makes it good for an example.
This subroutine takes a single argument in register A0, the address to a grow zone procedure. The address of the current heap zone record is loaded from low memory global
The Final Voyage Mac Os Download
TheZone at address $118. The grow zone procedure is stored within this record. The subroutine returns a result code in D0, which is always 0 for success, before returning to the caller with RTS.This routine is so simple; why was it patched in the first place? Let's compare with the original in ROM. SetGrowZone is located at $402C3C. If you disassemble it, you'll see that the only effective difference is the offset in the heap zone record used to store the grow zone procedure. In ROM, it's $10. The patched version was $2C.
Why the change in offset? I'll leave that as an exercise for the reader, with a note that Inside Macintosh, page II-23 for the Memory Manager has a warning not to store directly into the gzProc field, and instead use the InitZone or SetGrowZone procedures. Within the heap zone record, gzProc is offset $10, while $2C points to sparePtr.
Stolen from Apple Computer!
Andy Hertzfeld did a good job of telling the story behind this icon, hidden in the ROM of every Macintosh, in his Folklore blog. The idea was Steve Jobs'. Susan Kare drew an icon showing a face behind jail bars, while Steve Capps wrote a routine to compress the icon and make it difficult to detect.
All that was necessary was to use MacsBug to execute a hidden subroutine to decompress and display this little icon on the screen.screenshot from Andy Hertzfeld's Folklore blog
This icon was later simplified to remove the jail bars, and is just 24 pixels tall instead of the usual 32. The subroutine to display the icon is located at $40AD26 while the icon data is located just beyond, at $40AD40. The icon is 96 bytes long, un-encoded bitmap. Steve Jasik, author of the MacNosy disassembler, was among the first to discover this hidden icon in 1985. An identical icon exists in a prototype Twiggy Mac ROM from mid-1983, suggesting that the jailbar icon antedates it by some months.
In MacsBug, type
| Code: |
| G 40AD26 |
The Final Voyage Mac Os 7
Stolen from Apple Computer! This is the most well-known icon, but a different one lurks in ROM too
Better ROM Disassembly
If you're interested in a better tool for ROM disassembly, try MacNosy by Steve Jasik, the original power-user's disassembler. It has far more tools than MacsBug, and will convert numbers and offsets to symbolic names and equates.
At the tail end of ROM, $40FFF8 are two sets of initials. The first is RHS for Rony H. Sebok. The second is WDA for William D. Atkinson. Enter DM 40FFF8 in MacsBug to see these initials. Earlier or later versions of the Mac ROM may have more initials.
That's all for this Mac 512K Blog article! Join me next time as I experiment with an Micro Asanté Print LocalTalk bridge to connect a Mac 512K to an Ethernet network.
| The Mac 512K Blog wrote: |
| This blog chronicles the Macintosh 512K and my projects with it. We will test software, fix hardware, program it, hack it, and generally take the 512K Macintosh to its limits. Do leave any feedback you may have, either to my email dog_cow@macgui.com or by posting a comment to this article. |