One of the promises of the Mac 512K Blog is that we're going to take the Mac 512K to its limits, and we'll exceed the limits if necessary!

Now let's take a look at the maximum System Software version that Apple says the Mac 512K can run. Apple says the limit for a Mac 512K is System 4.1/Finder 5.5. Everyone, the entire world, says we can't do any better than this.

Is this really the limit?

No!

There is no technical limitation preventing the Macintosh 512K with its 64K ROM from running newer System versions. Read on, and we'll see how to run later System versions on a stock Mac 512K, up to System 6.0.3/Finder 6.1! Let's begin with a


Brief Overview of Macintosh System Software

A couple months ago we took a trip inside the System resource file, explaining why it's necessary, and what resources it contains. In that article, we mentioned that the System file has both a data and a resource fork, but we only examined the resource fork.

About a year ago was an article with a list of System/Finder versions and an explanation of why System and Finder files had differing version numbers for many years. The reason is that the Macintosh Operating System is split between what's in ROM and what's on disk. The Finder is technically not part of the Macintosh Operating System; it's merely a graphical shell which can be replaced with any other application using the Set Startup command in the Special menu.

Now let's take a look at this division of the OS between disk and ROM. The first thing to know is that the majority of the Mac OS resides in ROM: the Memory Manager, Segment Loader, Device Manager, disk drivers, etc. Also in ROM are QuickDraw and the Macintosh User Interface Toolbox.

Putting as much as possible in ROM saves RAM space, which was limited and expensive in the 1980s, and it also saves disk space. It's less information that has to be loaded from disk, and less that needs to be kept in RAM. It means the Macintosh starts up faster too. Furthermore, code in ROM executes faster than code in RAM because the 68000 CPU doesn't have to compete with the screen refresh for access to RAM.

All in all, this is looking like a pretty good scheme. Keep as much of the OS as possible in ROM, because it runs faster, leaves more RAM for running applications, and results in less information to be loaded from disk on system startup.

But what's the downside? Bugs! The 64K Macintosh ROM was frozen in mid-September 1983. But within weeks, some bugs were found.


ROM Freeze Party for version 4.4. The final ROM version 7.0 freeze was in September.

Fortunately, the ROM was designed so that applications and even the Operating System itself do not call subroutines directly. Instead, there is a ROM dispatch table kept in low RAM. This table maps each system trap number to a memory address. Because the table is kept in RAM, it can be modified to point elsewhere. This means that a routine in RAM can be substituted for one in ROM. Any application can modify the dispatch table to patch the ROM this way.

When the Macintosh shipped in January 1984, the System disk contained a number of ROM patches to correct bugs found since September. The data fork of the System file on disk contained these patches. And yet there were still more bugs left in ROM.

Now that we know about patches to ROM, let's take a look at system startup. How are the ROM and RAM-based system married?


System Startup: Basic Overview

We're only going to cover the basics in this article, so as not to get too bogged down, but a future Mac 512K Blog article will dive into the details of system startup.

It's 1984. You power on your Mac 512K, and here's what happens:

1. The Mac begins executing code in ROM to perform some system tests, detect how much RAM is installed, and initialize some low-level OS components such as the dispatch table, mouse cursor, and Sony disk driver.
   
   
2. If everything checks out OK, the screen is cleared to gray, and the question-floppy icon appears on the screen.
   
   
3. You insert a startup disk (let's say it's System 1.0/Finder 1.0) and the Sony disk driver reads blocks 0 and 1 into RAM at $10000. These are the Boot Blocks.
   
   
4. Assuming that the boot blocks are valid, the Mac jumps to them in RAM and begins executing the code that they contain. The Happy Mac icon appears. Among other things, the boot blocks code sets system heap size, initializes the file system and mounts the startup disk, initializes some more managers, loads the debugger, and draws the startup screen (if any).
   
   
5. However, one other important task that the code in the boot blocks performs is to open the data fork of the System file on disk and begin executing the code stored there.
   
   
6. In the System file, the first thing this code does is to check the ROM version number at $400008 and ensure it's $69. If the version number doesn't match, then none of the following patches will load, under assumption that a future ROM has fixed the bugs. Then the code begins patching the dispatch table to patch various ROM routines, over 40 in total. These include SystemEvent, FlashMenuBar, InitWindows, and SystemClick.
   
   
7. After all the patches have been installed, control returns back to the code in the boot blocks. The system is all ready to go. The final act is to call Launch, which starts the initial application, usually the Finder.
   

To condense and summarize, the startup sequence runs like so:

1. ROM -> Load Boot blocks
   
2. Boot blocks -> Load System file
   
3. System file -> Load patches
   
4. Back to boot blocks -> Load initial application (ex: Finder)
   
5. Finder

Changes with the Mac Plus and 128K ROM

This method of maintaining ROM patches in the data fork of the System file was continued throughout Systems 1.1 through 2.1 in late 1985. But with the introduction of the Mac Plus and its new 128K ROM in 1986, now there were two ROM versions which needed to be patched (the Mac Plus ROM was frozen in fall 1985).

Thus was born the PTCH resource. Beginning with System File version 3.0 in January 1986, ROM patches were moved out of the data fork and into PTCH resources. The code in the data fork of the System file was simplified to instead open and execute the PTCH resource corresponding to the Mac's ROM version number, either $69 or $75. PTCH 105 was for the 64K ROM, while PTCH 117 was for the 128K ROM. There were also patches for a Macintosh XL running MacWorks, contained in PTCH 28927.


PTCH resources in System File version 3.0

The PTCH resource actually made its debut a few months earlier in fall 1985 with the release of the Hard Disk 20 in September. The HD20 shipped with System 2.1/Finder 5.0, the first HFS-aware versions of the Macintosh System Software.

In fall 1985, the Mac Plus was still a few months away from release, so there was only one ROM to patch, and thus the patches were maintained in the data fork of the System file as always. The one difference is that the code in the System file was amended to open the Hard Disk 20 file and execute the PTCH resources there. One of them installed RAM-based HFS, the other installed the improved Sony driver capable of accessing 800K disks and the Hard Disk 20. Both HFS and the Sony driver were loaded in the system heap, and the trap dispatch table was patched to point to them.

However, the twist is that the code in the System file only loads the Hard Disk 20 patches if the Macintosh has both the original version $69 ROM and has at least 512K of RAM installed. If a Mac Plus, 512Ke, or newer machine were used, the Hard Disk 20 file and its patches aren't loaded, nor is it loaded on a Mac 128K.


Mac Plus and Beyond: Keeping Compatibility

The 64K ROM had a few resources stored within, such as the arrow cursor, but not much else would fit. With double the size, the new 128K ROM in the Mac Plus and 512Ke stored even more resources, such as additional cursors, the system font, RAM serial driver, and some utility packages, which all previously had to be loaded from disk. For compatibility with the original Mac 128K and Mac 512K, these resources were also kept in the System file on disk. But on the Mac 512Ke and Plus, they were unnecessary, and weren't loaded.

The Mac SE and Macintosh II of 1987 each sported a 256K ROM, which stored even more resources formerly loaded from a floppy disk. System file version 4.1 now had patches for four different ROM versions: the original 64K ROM, the Mac Plus ROM, the SE, and now the Macintosh II ROM. To keep compatibility with the Mac 512K and Plus, Apple maintained all resources in the System file, even if later ROM versions had them built-in. The only cost was disk space, and by now the 800K disk was standard.


PTCH resources in System File version 4.1

Thus we see Apple's scheme for maintaining compatibility across the Macintosh line in spite of newer ROM revisions which introduced new and changed routines, and more resources. The System file held both patches for older ROMs to add the new and changed routines, as well as the new ROM resources. Newer Macs with newer ROMs simply didn't load the older ROM patches, nor the resources from disk which were already stored in ROM.

The result is that the main factor limiting which system version a particular Mac could run is how much RAM it had to store all these patches, resources, and other system data structures. This is why the Mac 128K ran into limits early on: there was simply not enough RAM to load all these needed patches and resources to keep current with newer ROMs. The patch-loading code in the System file could be modified to ignore the RAM size check before loading the Hard Disk 20 patches, but then there would barely be any space left over in the application heap.


Drop the Patch, Drop Compatibility

So far we have seen how Apple kept older Macintosh models compatible with newer System software releases: ROM patches and storing ROM-only resources in the System file too.

Apple dutifully maintained support for the Mac 512K and its old 64K ROM up through System 4.1/Finder 5.5, released in August 1987. This system was distributed on 800K HFS disks, but you could copy a System and Finder to a 400K MFS disk and it would start up a Mac 512K without a hitch.

This was the last system release to do so. With System file 4.2 and Finder 6.0 in October 1987 (unhelpfully branded as "System version 5.0"), 64K ROM support was officially dropped. If you managed to squeeze System 4.2 and Finder 6.0 onto a 400K floppy to boot your Mac 512K, you'd be greeted with a System bomb, ID = 12, immediately after Welcome to Macintosh.

Not very welcoming.

It's not hard to understand why Apple chose to drop support for the Mac 512K in late 1987. By then, the 512K was quite limited: no SCSI, no ADB, and 512K of RAM was not enough to support large databases, spreadsheets, or word processing documents. Furthermore, the System and Finder overfilled a 400K MFS disk! The only way to get both on one disk was to remove nearly every font and desk accessory, leaving room for little else.

Eliminating support for the Mac 512K also meant that the System file no longer needed the patches and extra resources for the 64K ROM, saving some disk space for the newer Mac models.

Most people accepted this and stopped here. System 4.1 is the limit for a Mac 512K, because Apple says so. Well here at the Mac 512K Blog, we don't accept Apple's limits, and we won't stop here. Let's use the knowledge that we have gained thusfar to restore support for the Mac 512K.


How to Modify System 4.2 to Support the Mac 512K

As we asserted at the beginning of this article, there is no technical limitation preventing the Macintosh 512K with its 64K ROM from running newer System versions.

First, we should open System file 4.1 to look at its patches, and see why it will run on the Mac 512K. Using ResEdit, open the System file. Scroll down to the PTCH resource type and open it. Following 0, you should see resource IDs 105, 117, 376, and 630. These are patches for the Mac 512K, Mac Plus and Mac 512Ke, Mac SE, and Macintosh II, respectively. PTCH 0 is for all ROMs.

Now let's compare with System file version 4.2, and see why it won't run on a Mac 512K. Open the System 4.2 file using ResEdit. Open the PTCH resource type. Here you should see resource IDs 0, 117, 376, and 630. But no 105! Nothing for the Mac 512K's 64K ROM!


System Files 4.1 and 4.2 PTCH comparison

Can we simply copy PTCH resource #105 from the System 4.1 and paste it into System 4.2? Is it that simple to restore compatibility with the Mac 512K? Let's try it and find out.

With both PTCH resource windows open in ResEdit, copy PTCH #105 from System 4.1 to System 4.2. Save changes, and eject the System 4.2 disk. Now boot up your Mac 512K using that disk.

Yes, it really is that simple! The Finder desktop appears. Choose About the Finder... from the Apple menu to prove that you are running System 4.2 and Finder 6.0 on your Mac 512K, even though Apple and everyone else said you couldn't!



System 4.3/Finder 6.0 (released as "System Software 5.1" in December 1987), can be made to run on the Mac 512K by following the same procedure: simply copy PTCH #105 from System 4.1 into System 4.3. Save changes, reboot, and there you are!


Now Let's Run System 6 on the Mac 512K

So far it's been pretty easy to get newer System versions to run on the Mac 512K. All it takes is a single PTCH resource added, and presto! Probably other hackers discovered this trick 30 years ago to run newer systems on their Mac 512K.

But let's up the ante! Let's see if we can run System 6 on a Mac 512K. Can it be done?

For no particular reason other than that I have it in my box of disks in front of me, let's use System 6.0.3/Finder 6.1, announced January 1989 with the Mac SE/30. System 6 is a bigger and more complicated operating system. Merely copying the single PTCH resource is not sufficient. There are more resources which must be added. Inside Macintosh volumes IV and V tell which resources are in ROM for the Plus, SE and Macintosh II, respectively. This is a good starting point.

Pages 32-34 of Inside Macintosh V have a list of which resources are in the SE and Macintosh II ROMs. This list includes resources of the following types: CDEF, CURS, DRVR, FONT, KCHR, KMAP, MBDF, MDEF, NFNT, PACK, SERD, and WDEF. The Macintosh II has a few additional resource types in ROM to support the Color Manager: cctb, clut, gama, mitq, and wctb. And lastly, the Macintosh II ROM contains an snd resource, "Brass horn."

Let's compare the differences between System files 4.1 and 6.0.3. Specifically, let's see what's not included in 6.0.3 compared to 4.1. Then, check it with the list of in-ROM resources given in Inside Macintosh volume V.

• For DRVR, both .MPP (#9) and .ATP (#10) have been dropped from 6.0.3. These were RAM-based drivers for AppleTalk on the Mac 128K and 512K, but were included in the 128K ROM. They're only needed if you plan to use AppleTalk.
  
  
• One INIT resource, ID #2, was dropped from System 6.0.3. This INIT is responsible for showing the System bomb dialog.
  
  
• System 4.1 has two NBPC resources that are not in System 6.0.3. These are used by AppleTalk.
  
  
• Three PACK resources were eliminated from System 6.0.3: 4, 5, and 7. These are Floating-Point Arithmetic, Transcendental Functions, and Binary to Decimal Conversion. All three packages are in ROM in the Mac Plus, SE, and Mac II.
  
  
• PTCH #105, the necessary patches for the 64K ROM, is also missing from 6.0.3. But we already anticipated that.

Copying these nine resources from System 4.1 to System 6.0.3 is enough to get System 6 to boot on your Mac 512K! Success!

If you're running out of disk space, remember that you'll have to use the Font/DA Mover to remove as many fonts and desk accessories as you can from System 6.0.3. You can also delete PTCH numbers 376 and 630 (for SE and Mac II, respectively) to save about 51K.

After deleting those two PTCH resources, you should have enough room on the 400K floppy to copy in PTCH 105 to the System file, and copy Finder 6.1 to the disk as well. I ended up having 21K free space on my floppy.

Choose About the Finder... from the Apple menu and take a look. The system heap is just 73K, leaving 439K free for applications.



Long-time System 6 users will notice that the miniature Finder icon looks different. I think this is due to differences in the original 64K ROM version of QuickDraw, compared to later versions of QuickDraw.

Also, the System Folder does not show a small Finder icon to indicate that it is the blessed folder. This is almost certainly because I am using an MFS disk, which has no concept of a blessed folder (because MFS doen't have folders!).


Concluding Notes and Thoughts

The first concluding note and thought is that next time someone tells you that you can't run System 6 on a Mac 512K with 64K ROM and 400K MFS floppy, refer him or her to this article.

But on that note, the 400K floppy does become the limiting factor here. As we learned from an earlier article on using the 800K drive with Mac 512K, you can make an 800K MFS disk, and if you're using the Apple 3.5" drive (A9M0106) you can boot from that double-sided MFS disk too.

HFS isn't necessary to running System 6, and moreover you can't boot a Mac 512K from an HFS disk anyway. This is one limitation that we can't so easily overcome, but perhaps with modified boot blocks, it could be achieved.

System 6.0.3 will load the Hard Disk 20 file. If you delete the other PTCH resources and some of the snd resources too, you'll have about 85K of free space on a 400K floppy, and you can copy the Hard Disk 20 file and some CDEV (Control Panel) files too. I copied MultiFinder, but was not able to get it to work. It crashes with a system bomb ID #3, Illegal instruction. If you need even more disk space, delete all the snth resources and every snd resource except for Simple Beep.



With Hard Disk 20 patches loaded, the system heap expands to 122K, leaving only 390K free for applications. Still not too bad.

Using a Hard Disk 20

But why limit ourselves to a 400K or 800K MFS floppy? We can easily install System 6.0.3 on a Hard Disk 20, copy the necessary resources into the System file to restore 64K ROM compatibility, and run System 6 off the hard disk.

The Hard Disk 20 Startup disk will cheerfully load whichever System is on the HD20. This way, we can have a universal System Folder on the HD20 that will boot a Mac 512K, 512Ke, and Macintosh Plus!

Would anyone else like to experiment with MultiFinder or newer versions of System 6 and see if it will run too? Let us know if you get MultiFinder or a newer version of System 6 to run on the Mac 512K. Or let's see if MacTCP will load. I put MacTCP v1.1.1 on the disk, and it appears to load into the system heap, consuming almost 100K, but when I load the Control Panel, I get a system bomb. It's ID #2, which is an address error. If I had room on the disk for Macsbug, I would debug this and see what's going on.

MultiFinder always required 1MB of RAM and the 128K ROM or better. It extends the Macintosh Operating System to allow multiple applications to be launched at once, by partitioning the application heap and providing multiple A5 worlds. It will probably be quite a challenge to get it to run in only 512K of RAM.


That's all for today. The next Mac 512K Blog article will show how to use Macsbug for debugging and other nefarious purposes!

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 by posting a comment to this article.