Mac OS 8 on a Classic II

[jake18125]

I'm actually amazed this worked, but I managed to get Mac OS 8 running on my Classic II! (Ok strictly speaking it is a Performa 200, but come on they are literally identical). 

How did I manage this? 

Well I realised that the Classic II actually has a 32 bit clean rom, so really it should be able to boot Mac OS 8 in a similar process to how SE/30s can run 8 with a clean ROM. 

The only issue is the installer needs 12mb, whilst the Classic II tops out at 10mb. However, in normal operation a basic Mac OS 8 install only uses ~6mb of ram. 

Therefore I only needed to follow this guide:

https://vintageapple.org/gamba2/os8_68030.html

But to get around the 12mb ram limit when installing Mac OS 8, I used my Performa 475 and an external SCSI CD drive to install it onto a Zip Drive. 

I was then able to boot into Mac OS 7 on my Performa 200, make the necessary changes on the zip drive (noting that the value in GUSD that needed to be changed is the Gestalt ID, thankfully a list is provided at the bottom of the page), then use system picker to select the Mac OS 8 system file and cross my fingers. 

Incredibly enough it worked! Hopefully the same method should work on other Macs that have the same ram limit. 

A zip drive isn't really necessary, just so long as you have a bootable drive and a second method of editing the system files as detailed by the guide. I'm also pretty sure "wish I were" isn't necessary as you don't need to fool the installer.

However I am pretty sure you need a Macintosh with a 68040 that can boot/install Mac OS 8. If anyone wants to try it with a PPC mac please let me know how it goes! 

 

[360alaska]

I'm not surprised, I once installed 7.5 on one. I wonder if there is a away to reign in ram usage, have you paired down extensions and control panels?

 

[jake18125]

I'm not surprised, I once installed 7.5 on one. I wonder if there is a away to reign in ram usage, have you paired down extensions and control panels?

Well 7.5 is fully supported by the Classic II, whilst 8 isn't officially supported on any Black and White compact.

Heh a Mac Plus with 4mb of ram can technically run 7.5 , 8 is an entirely different beast!

Also I'm using a completely minimal install of 8, so honestly I'm not sure what else I can remove!

 

[360alaska]

I'm sorry I meant 7.6.1, I can't edit that. Yeah it's like 20 disks, a big pain. You might also be interested to know that Mac os 8 was originally going to be Mac OS 7.7:

https://apple.fandom.com/wiki/Mac_OS_7.7

 

[jake18125]

I'm sorry I meant 7.6.1, I can't edit that. Yeah it's like 20 disks, a big pain.

Ahhh right, currently it also has 7.6.1 on the hard drive

 

[rplacd]

This is beautiful! Now if only there was a way of turning off Platinum...

 

[Elfen]

I'm actually amazed this worked, but I managed to get Mac OS 8 running on my Classic II! (Ok strictly speaking it is a Performa 200, but come on they are literally identical). 

How did I manage this? 

...

..

.

But to get around the 12mb ram limit when installing Mac OS 8, I used my Performa 475 and an external SCSI CD drive to install it onto a Zip Drive.

THAT'S CHEATING!!!  (J/K-LOL!)
Congrats on the good work. Now to blow your mind...

Get/Find PPC/FAT Checker program (also goes by PPC/68K Checker), its a shareware program that allows you to look at you 68K and PPC code on such programs that runs/installs on both systems. Since it is on a 68K machine, use it to remove the PPC Code and Resources from the System and Finder. This will reduce the size of the OS files by 35% to 50%. With the PPC Code reduced, the system will take up a lot less room in RAM and run a bit faster as it does not have to access Virtual Memory as much from the hard drives. You can do the same with various apps you have on the machine's hard drive.

 

[MrFahrenheit]

THAT'S CHEATING!!!  (J/K-LOL!)
Congrats on the good work. Now to blow your mind...

Get/Find PPC/FAT Checker program (also goes by PPC/68K Checker), its a shareware program that allows you to look at you 68K and PPC code on such programs that runs/installs on both systems. Since it is on a 68K machine, use it to remove the PPC Code and Resources from the System and Finder. This will reduce the size of the OS files by 35% to 50%. With the PPC Code reduced, the system will take up a lot less room in RAM and run a bit faster as it does not have to access Virtual Memory as much from the hard drives. You can do the same with various apps you have on the machine's hard drive.

I know this trick works to reduce the size of the files on disk, but I don’t understand how it could reduce a memory footprint on a 68k Mac. The 68k Mac doesn’t load any PPC code into RAM because it wouldn’t know how to deal with it. 

 

[Elfen]

I know this trick works to reduce the size of the files on disk, but I don’t understand how it could reduce a memory footprint on a 68k Mac. The 68k Mac doesn’t load any PPC code into RAM because it wouldn’t know how to deal with it. 

The 68K and PPC Mac will load the file in its entirety into RAM. Lets take this example: You have MS Word 6.5 (made up for the example), and it is a FAT file with both 68K and PPC code and resources in it. It is (lets say) 8mb in size.  You double click that icon, and it will load the entire program - the entire 8MB with both the 68K and PPC code and resources into RAM and the program defines where the CPU goes within the program as needed as per a CPU test in the very beginning. With this program taking up 8MB of RAM, it will also take up 8MB of Virtual RAM on the hard drive if you have that option turned on. This is where the slow down begins.

The OS is not "smart enough" to separate 68K vs. PPC code and resources on the fly and reassemble it in RAM to make a working application once it is finally done. In short, this is compiling the source code into a working app every single time you want to use that app. Compiling programs take a very long time to do even on the fastest of CPUs today. On a 68K Mac? You would double click the icon, go out and get a pizza, and go watch the SuperBowl and then "Movie of the Week" before you can go back to your machine and see if compiling is done, which it probably will not.

Since the 68K does not use the PPC code on any app, in this case MS Word 6.5 - you can use the PPC/FAT checker to remove the PPC Code from it. Like you stated, it will reduce the file size on the hard drive since now the app will only have 68K code on it and nothing more. Lets say it reduces app by 50%; MS Word 6.5 is now 4MB instead of 8MB. Because of that, it also resides in 4MB of Virtual RAM on the hard drive as well, thus 1) freeing up space inside RAM and 2) speeding up access of the file which speeds up its execution on the 68K machine. A ++ there if you think about it.

Also, unless your OS was created for "This Macintosh" (if I remember correctly, it was not as it was made on a LC475), the System and Finder will be loaded with unnecessary color and monitor options your machines does not support. If you are brave enough to use ResEdit and go through the System/Finder files and remove the color, monitors and other system resources not needed by your system, you can reduce your System/Finder size to a manageable size. If you do this, do it on a back up file and test it when you're done.

 

[Dog Cow]

The 68K and PPC Mac will load the file in its entirety into RAM. Lets take this example: You have MS Word 6.5 (made up for the example), and it is a FAT file with both 68K and PPC code and resources in it. It is (lets say) 8mb in size.  You double click that icon, and it will load the entire program - the entire 8MB with both the 68K and PPC code and resources into RAM [...]

The OS is not "smart enough" to separate 68K vs. PPC code and resources on the fly and reassemble it in RAM to make a working application once it is finally done. In short, this is compiling the source code into a working app every single time you want to use that app.

I don't believe this is a correct description of how the Mac operating system works.

Under a 68K-only system, the Segment Loader will typically only load CODE resource 0 (the jump table) and CODE resource 1 (the main segment) into the application heap when you launch an application. If the application has additional CODE segments (and many applications do), they won't be loaded at launch time unless the preload flag is set.

Under a PowerPC system, the PowerPC instructions are stored in the data fork of the application file, and not in CODE resources. The Process Manager calls on the Code Fragment Manager to load PowerPC instructions into memory for execution. Here's a good overview of how it works.

 

[MrFahrenheit]

The 68K and PPC Mac will load the file in its entirety into RAM. Lets take this example: You have MS Word 6.5 (made up for the example), and it is a FAT file with both 68K and PPC code and resources in it. It is (lets say) 8mb in size.  You double click that icon, and it will load the entire program - the entire 8MB with both the 68K and PPC code and resources into RAM and the program defines where the CPU goes within the program as needed as per a CPU test in the very beginning. With this program taking up 8MB of RAM, it will also take up 8MB of Virtual RAM on the hard drive if you have that option turned on. This is where the slow down begins.

The OS is not "smart enough" to separate 68K vs. PPC code and resources on the fly and reassemble it in RAM to make a working application once it is finally done. In short, this is compiling the source code into a working app every single time you want to use that app. Compiling programs take a very long time to do even on the fastest of CPUs today. On a 68K Mac? You would double click the icon, go out and get a pizza, and go watch the SuperBowl and then "Movie of the Week" before you can go back to your machine and see if compiling is done, which it probably will not.

Since the 68K does not use the PPC code on any app, in this case MS Word 6.5 - you can use the PPC/FAT checker to remove the PPC Code from it. Like you stated, it will reduce the file size on the hard drive since now the app will only have 68K code on it and nothing more. Lets say it reduces app by 50%; MS Word 6.5 is now 4MB instead of 8MB. Because of that, it also resides in 4MB of Virtual RAM on the hard drive as well, thus 1) freeing up space inside RAM and 2) speeding up access of the file which speeds up its execution on the 68K machine. A ++ there if you think about it.

Also, unless your OS was created for "This Macintosh" (if I remember correctly, it was not as it was made on a LC475), the System and Finder will be loaded with unnecessary color and monitor options your machines does not support. If you are brave enough to use ResEdit and go through the System/Finder files and remove the color, monitors and other system resources not needed by your system, you can reduce your System/Finder size to a manageable size. If you do this, do it on a back up file and test it when you're done.

So based on your logic, the minimum memory allocation for a Classic Mac application would be the file size of the application?  So let's look at HyperCard 2.4.1, which has an on-disk size of 3.5MB and has a minimum application RAM allocation of 1500kb.  How does this reconcile with what you're saying?

 

[Crutch]

@Dog Cow is correct and @Elfen is not correct.

On a 68K Mac, the Segment Loader loads CODE resources into RAM only as needed, and unloads (purges) them when possible.  That’s the point of breaking 68K code into multiple CODE resources, which was almost universally done in the 68K era.  It is not true that the entire program is loaded into RAM.  Mac compilers from the earliest days provided convenient mechanisms for breaking code up into multiple segments (CODE resources) for this purpose.

In addition, 68K Macs have no idea that the PPC code even exists, since PPC code resides in the data fork (previously traditionally unused for applications), not in the resource fork at all.  (There is no such thing as a “PPC code resource”.)  A 68K Mac’s OS won’t even look in the data fork of an application you run to notice that there is PPC code there at all, much less load it wastefully into RAM.  Stripping PPC code from a FAT binary will have zero impact on the RAM used by a 68k application — it will merely save disk space.

Good background on how PowerPC code is loaded and executed by the OS is here:  https://vintageapple.org/inside_r/pdf/PPC_System_Software_1994.pdf

 

[Dog Cow]

On a 68K Mac, the Segment Loader loads CODE resources into RAM only as needed, and unloads (purges) them when possible.  That’s the point of breaking 68K code into multiple CODE resources, which was almost universally done in the 68K era.  

There's a small detail missing here: the Segment Loader does not unilaterally unload (purge) segments. According to Inside Macintosh, it will only purge a segment by an application's directive: when an application calls UnloadSeg for a particular segment. UnloadSeg marks the segment as unlocked and purgable in the heap. But it won't actually be purged unless more heap memory is needed.

As far as PowerPC code fragments, so long as Virtual Memory is active, these are never truly loaded or purged from the heap in the sense of how things were done under 68K systems. Instead, Virtual Memory uses the application's data fork as its backing store, and maps its code into RAM only when it's executing. With VM on, PowerPC code doesn't occupy any application heap space, which means you can run more applications at once within the same VM size. This is why you should always have Virtual Memory turned on for a Power Mac. 

 

[Crutch]

There's a small detail missing here: the Segment Loader does not unilaterally unload (purge) segments. According to Inside Macintosh, it will only purge a segment by an application's directive: when an application calls UnloadSeg for a particular segment. UnloadSeg marks the segment as unlocked and purgable in the heap. But it won't actually be purged unless more heap memory is needed.

Yes of course, I am assuming UnloadSeg is called appropriately, for example for all segments in the main event loop as suggested in IM.  Assuming that’s done, segments will in fact be purged automatically when necessary (by the Memory Manager, strictly speaking), so this is indeed the outcome in practice.

(In the compact Mac days, for applications of sufficient size, I would argue that failing to call UnloadSeg was morally equivalent to failing to call SystemTask ... not doing so was just wrong.)