System 6 on a Performa 475

[onlyonemac]

They all say that it cannot be done, but why not? Why can newer hardware not run an older operating system. Surely a Windows 7 computer could run Windows 95? So, I'm convinced there's just one thing that's needed to get this to work, and then I can run it on my Mac. I'm thinking of something like a special enabler or something.

If I can get this to work then that'll be good, because then I can run from a smaller RAM Disk, and have more RAM for programs (I could even do it like they used to-put the program on the boot disk).

onlyonemac

 

[markyb86]

I know this isn't the answer you are looking for. However, while you are waiting on doing something about the hard drive, have you considered filling the void with a zip100?

 

[uniserver]

i use my scsi zip 100 to boot everything from the plus on up, very handy tool!

 

[Mk.558]

If you have a means of acquiring the source code for System 6, making any adjustments (there'll most likely be a lot) needed for the CPU, and compiling it, then yes.

Otherwise, no.

It's a fundamental concern. Remember that System 6 is built for each specific CPU type, although platform had a little bit to do with it.

Likewise, you can't just "install Windows 95 on a 68040" because for one, the kernel is going to be COMPLETELY incompatible. Neither will you be able to "install Palm OS 3.5 on a Macintosh Portable", either.

 

[onlyonemac]

Likewise, you can't just "install Windows 95 on a 68040" because...

I meant 95 on a modern PC, not a 68040.

What changes would be needed-aren't all the CPUs more or less compatible (software developers, and apple, didn't make different versions for different Macs, did they?). That's why I was thinking of an enabler-essentialy something that'll make the changes for us.

 

[gobabushka]

i hate to say it, but i dont think system 6 even supports enablers.

 

[Trash80toHP_Mini]

Does the 475 support 24 bit addressing? ISTR something about Apple II Card support being lost in the Quadra jump for that series, but that's hazy.

Addressing mode incompatibility would be a very hard line drawn in the sand.

 

[Gorgonops]

The LC 475 supports 24 bit addressing and will work with the IIe card *if* it's running MacOS 7.5.5 or earlier. It was MacOS 7.6 and later that removed support for it.

As to why an LC 475 can't run System 6 while (in most cases) newer PCs can run ancient operating systems it's an apple to oranges comparison. In the PC world there's a basic set of hardware functionality, collectively dating to about 1987 or so plus a few later extensions, which all newer machines are expected to support at the bare metal level. (The ridiculously powerful Nvidia card with a gig of VRAM in your brand-new gaming PC still has buried in it the ability to emulate an IBM PS/2's 256k VGA card, and that's the mode it boots up in once the BIOS splash screen is out of the way.) There are holes in this model: for instance, there's no universal network device that newer cards emulate, which means you need a hardware specific driver if you want the ancient OS running on your Intel i7 to be able to surf the web. (Which will probably be impossible to find.) But for the *most part* the hardware and BIOS support will be there and compatible enough to get the OS running to some degree.

The classic MacOS, on the other hand, is a diabolically schizophrenic pile of code in which many of the core functions of the OS actually exist as routines in the computer's ROM. In *theory* if all the hardware-interacting parts of the OS were in ROM and the APIs were completely standardized this would work to make MacOS *more* hardware independent and forward compatible, but in practice Apple didn't leverage that very well. As executed, a release of the Classic MacOS needs to recognize the machine it's running on so it will select the correct code paths, either to adjust itself to the capability of the hardware or enable patches for known bugs. That's why Macs have that "Gestalt ID" system.

There are some instances where "trivial" hacking an OS will enable a machine with an unknown/disallowed Gestalt ID to run it, with various degrees of success. But System 6 on an LC475 is a pretty huge jump. On top of ROM changes (the Quadras have larger ROMs than the Mac II series) Apple officially didn't support the 68040 CPU until System 7. And unlike Intel CPUs Motorola's were usually *not* complete supersets of the earlier models. The 68040 is missing several instructions compared to a 68030+68882 combination, and because of some changes in how the prefetch/caching mechanism works there are several areas of incompatibility related to self-modifying code that are "barely legal" on the 68030 but cause crashes on the 68040. There were third-party upgrades for Mac II-series machines *would* run System 6 on the 68040, but the enablers for those upgrades include patches for several broken areas within the OS.

So... it probably would be *possible* to patch together a working System 6, probably by incorporating code from an accelerator card extension, but the fact that apparently no one has done it yet is sufficient evidence to say that doing so would be "hard".

 

[Trash80toHP_Mini]

Great info, thanks for clearing that up, EudiG! :approve:

 

[bbraun]

The process for booting System 6:

After the ROM initializes the machine, which includes all the hardware specific bits like the memory controller, sets up the MMU with all the correct address mapping, etc. it looks over the list of disk devices it found. It looks for a disk that has valid boot blocks.

When it finds a disk with valid boot blocks, it checks the version number in the boot blocks. Version 0x44 indicates the boot blocks contain executable code. If it's version 0x44, the ROM will load and execute that code. However, System6 does not use that version number (my System 6 boot blocks are version 0x17), which indicates to the ROM it should not execute the boot blocks, rather the ROM will try to boot the system directly.

The boot blocks for booting a particular release of the OS are stored in the System file's 'boot' resource ID 1. When you make a disk bootable, behind the scenes, that resource is being copied to the start of the disk.

System6's boot blocks actually do contain executable code, it's just not executed by a ROM version I am aware of.

The ROM tries to boot the System by finding a blessed folder (HFS filesystem attribute), and then looking for the files specified by the boot blocks (System, MacsBug, Disassembler, Scrapfile, ClipboardFile, and Finder). It then initializes some things like the filesystem, mounts the boot volume, initializes the Resource Manager to use it,

It first loads 'DSAT' resource 0, which acts as an error message table for SysErr. SysErr is the ROM routine for displaying dialogs early in the boot process. You'll notice the error dialogs like the "This startup disk will not work with this Macintosh" and "This Macintosh is set for 32-bit addressing" look a little different than most dialogs on the system. Well, that's SysErr in the ROM being used when nothing else is available.

Earlier ROMs used SysErr to display the "Welcome to Macintosh" screen, but it looks like later ROMs are a bit more complex. Anyway, the "Welcome to Macintosh" screen is displayed at this point.

Then it loads MacsBug and Disassembler, if they exist, initializes more stuff, then more interesting things happen.

'PTCH' resources are loaded and run. Resource ID's -1 and 0 are run unconditionally, and then the resource ID that matches the version number of the ROM is loaded and run to patch the ROM specific bits. Here's a list of ROM version numbers for various machines. Open up your System file in Resedit, and you'll see PTCH resource ID's matching those numbers (resedit displays decimal ID's, the version numbers are displayed in hex).

Then the slot manager is called to invoke the secondary init routines for peripherals.

Then 'ADBS' resources are loaded and run.

Then it switches the 'DSAT' from resource 0 to resource 2, which essentially switches from System error messages to User error messages. We're now in user-space as far as the system is concerned.

And it gets around to loading and executing INIT resources from the System file. Each of these has a defined purpose, and the System file's INIT resource ID 31 is what eventually loads the INIT resources from cdevs, RDEVs, and INIT files.

Some more memory house keeping, scrapbook and clipboards are dealt with, and then Finder is finally loaded with the _Launch trap.

So, that's more or less what happens from boot device selection to Finder.

In System 6, 'PTCH' resource 0 is what puts up the "This disk will not work on this Macintosh/model" dialog, telling you to use a newer System. At offset 0x7C is 0xA9C9. This is the _SysErr A-Trap to put up that dialog. If you replace this with 0x4E71, which is a Nop, that dialog will not be displayed and the system will continue on.

Using that change, I managed to successfully boot System 6.0.8 on an LC III. That's an 030, not an 040, but hey. System 6 on an unsupported machine.

 

[gobabushka]

Do you have a disk image?

 

[Gorgonops]

... then the resource ID that matches the version number of the ROM is loaded and run to patch the ROM specific bits...

That's where the "needs to know which machine it's running on" part is important...

Using that change, I managed to successfully boot System 6.0.8 on an LC III...

Interesting. So did you *just* patch a NOP over the SysErr trap that otherwise would have popped up the "This disk will not work on this Macintosh/model" dialog, or did you do any other patching to the routine that "matches the version number of the ROM is loaded and run to patch the ROM specific bits" to hint that it should try to pick something close-ish, like an LC II?

Bbraun has obviously done some fairly deep hacking of the MacOS, so he's far more qualified than I am to say if there are any theoretical blockers that would make such a patch unworkable on an LC 475s. Off the top of my head two things that it seem *might* cause issues are:

1: The 68040 Macs require that a little chunk of software be present to handle floating point exceptions triggered by trancedental functions present in the 68882 but missing from the onboard FPU. (And I *also* believe there's another wrinkle associated with the LC040s in intercepting floating point operations, but I don't know if that affects MacOS at all.) I imagine said handler is in the ROM, but I have no idea if it actually requires explicit support from the loaded System to work properly.

2. The LC475's devnote says that the version of Quickdraw used on "all 68040 Macs" is enhanced to use a 68040-specific block move instruction. I have *no idea* if said enhanced Quickdraw would cause impossible-to-solve problems with System 6.

By all means it would be interesting to see if you could indeed make it boot *and* determine if it were actually stable/usable on a from-the-factory 68040 machine.

 

[bbraun]

FWIW, everything in your original post still applies, and just booting to a Finder desktop via removing a check shouldn't be considered "working" by any means.

The ROM can be thought of as the actual OS. The System file is very literally just a collection of Resources that get run by various things like the Finder, ROM, etc.

The ROM's memory manager is what initializes the heap before booting. The ROM needs to allocate memory before booting for all kinds of things. For instance it allocates the device driver table, the disk queue, loads device drivers from SCSI disks and Slots into RAM, device drivers need to allocate their own private storage, etc. And these need to continue to run after control is transferred to Finder or another application.

And it's not just the memory manager, all kinds of different parts of the system are working this way. And all of this code is run before the System is loaded, and can patch the ROM. Which also means the System must be compatible with whatever the ROM did. It's straightforward enough for a newer system to know what previous ROM behaviors were, but the opposite is much less likely to work.

In this case, doing much after booting will result in memory manager errors if you're lucky (meaning the memory manager caught internal self-inconsistency and bailed), and if you're unlucky, bus errors, memory corruption, etc.

I just did the NOP, so it's really just removing the check, and if stuff works, it works. If not, boom crash.

The patching process matches on the version number of the ROM, and entire eras of machines have the same version number, despite overall different ROMs. As best I can tell, although there are differences between ROMs of the same version number, the offsets to key areas are kept the same (and in many cases padding has been added to ensure that), which means one patch can apply to multiple distinct ROMs. For the LCIII, it shares the same version number as supported System 6 machines.

It may be possible to just copy/paste a System7 patch from a later system, or just stub it out for other machines, or whatever. It's probably not relevant due to other internal data structure mismatches.

But... Depending on the specifics of ROMs, it may be more viable on some machines than others.

There are other 'ptch' resources (lower case) that are also applied. I think those get applied indirectly by one of the other resources the ROM executes.

Also, this is all way different on System 7, since that uses executable boot blocks by default, and uses 'boot' 1, 2, 3 and 'gbly' resources too. Anyway, that's for another time.

I just started all this because I was curious as to exactly what fails, since most of the hardware specific initialization is handled by the ROM. So, disabling the check allows discovering why it won't work. That and the investigation into the boot process was the real value, IMO. Booting to finder is more an interesting curiosity more than a useful "solution".

 

[Gorgonops]

BTW, don't get me wrong about anything, your technical explanation about the deep details of how the System boots on an old Mac is fascinating. I've always been too intimidated by the nature of the Mac Toolbox to ever do any programming for it (beyond fooling around with a few "Hello World" level programs in MPW, which doesn't really count) so I only know the broad strokes.

The ROM can be thought of as the actual OS. The System file is very literally just a collection of Resources that get run by various things like the Finder, ROM, etc.

It does just really underscore how much difference there is between a 68k Mac and a PC. A PC is for all practical purposes a blank slate, particularly when discussing protected mode operating systems, which is why to this day x86 computers still preserve some fossils of compatibility with laughably ancient hardware. (Heck, even in real mode many if not most DOS programs ignored the BIOS I/O routines for the display hardware in order to get better performance, so video cards *still* need to either directly offer or use tricks to trap and emulate the original VGA register set and memory layout.) An old Mac is completely inside-out compared to that.

(The Linux/BSD mailing list traffic and kernel documentation repositories are of course rife with complaints about how hard ancient Mac hardware is to deal with if you *do* have to bang on it at the register level. Just booting an old Mac from bare metal into an alternative OS without a Mac System file was the holy grail for the longest time.)

 

[onlyonemac]

I'm glad I asked this just for bbraun's explanation of a booting Mac! Wow, I had to read it twice before I got half of it :I ...

Anyway, I'm really interested in this. I'm gonna try removing that check like bbraun suggested. As for the ROM patches, why exactly are they needed? Can't the system just say "Oh, well this machine doesn't exist in my ROM patch table, so I'll just not do any patching"? Or, if it really has to patch, then we can put in a Performa 475 ROM patch, can't we??? (Although, I'm not sure if sys6 will manage that patch.)

 

[onlyonemac]

I tried...

1. Changing the one instruction, as following bbraun's suggestion.

2. Copying any missing ptch, PTCH, ROV# and rovr resources from my System 7 file.

After step 1, I got a flickering "Welcome to Macintosh" box on the emulator, so I think it's rebooting. Step 2 didn't change anything.

So does this mean that it can't initialize something or other, and is rebooting (obviously QuickDraw's working).

 

[bbraun]

The PTCH patch, being based on ROM version number, is the same for a lot of machines. For example, the IIci through Quadra 630 (minus the AV macs) share the same version number. So the Performa 475 already has a patch that will get run, although it predates any knowledge of teh 475, its ROM, processor, or MMU. If it didn't find the patch, it would have displayed the "This is a 'Minimal' system install and doesn't include bits for this machine" or something along those lines.

The patch gets pretty complicated since it runs on so many different machines, but among other things it sets up a bunch of Gestalt values based on various pieces about the system and installs or replaces a bunch of A-Traps.

FWIW, I got a flickering "Welcome to Macintosh" when my ever reliable floppy saved a 0 sized PTCH resource ID 0. I think it's reasonably safe to assume flickering dialog == some sort of crash.

 

[onlyonemac]

I really think we should all take this seriously. I want something in the trails of doug3 and his IIci :approve: ! So let's get going with it !

So, essentialy, how do I get past the flickering box?

 

[Gorgonops]

After step 1, I got a flickering "Welcome to Macintosh" box on the emulator, so I think it's rebooting. Step 2 didn't change anything.

Not to butt in, but what are you using for your "emulator"? If you're using Basilisk II with a Quadra ROM it doesn't support 24 bit addressing, so System 6 is not going to work no matter what you do.