• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Patched 6.0.8L for more Macs

joshc

Well-known member
Once again David you’ve outdone yourself. I always, incorrectly, assumed that system enablers were a bit of a black box and I wasn’t aware there would be much documentation or that looking at the resources would tell us this much. If anything this teaches me to start being more curious and to start poking at bits of System 6/7 even more as I do find this stuff really interesting.
 

zefrenchtoon

Well-known member
System Enablers Research

I am investigating the approach that a number of newer Macintosh computers can be made to run on System 6.0.8L by porting the System Enabler launching code from System 7.1, thereby allowing you to drop-in an off-the-shelf enabler for your computer.
Here is my preliminary research on System Enablers so far. This is subject to change as I haven’t had the chance to step through the code, and Macsbug isn’t loaded until after most of this stuff happens.

1. In Apple Engineering, System Enablers were called “gibbly” or “gibblies” (hard g) because the words “extension” and “addition” were already in use. See “Be Our Guest” Develop issue 14. So, when searching code and resources, you need to use the engineer’s term to find anything.

2. Each System Enabler file is of file type ‘gbly’. Guess why? And, within each System Enabler is also a resource of type ‘gbly’ id -16385. The resource starts with a structure version number, then a date-time in Mac seconds format, followed by a count of supported machines, and followed by the BoxFlag id number of each machine that this System Enabler supports. The example below is from System Enabler 003 v1.1. It is structure version 1, internally built on April 12, 1994 at 4:51.26 ($A9D0820E), and supports 2 machines: LC III ($15=21) and LC III+ ($38=56)
View attachment 62187

3. The System itself has a ‘gbly’ resource. It describes which machines it natively supports without the need for an enabler.

4. When the computer boots, after the ROM starts, it loads the boot code from the drive’s boot blocks. The boot code finds the System file. This is how you are able to choose between multiple system folders on the same disk, because the boot block code and globals indicates where to look.

5. In System 6.0.8L (and likely earlier), the OS also stores this exact same boot-blocks code in the System file as resource ‘boot’ ID 1. It appears that the system installer and/or system folder blessing code copies the System file ‘boot’ ID 1 code to the boot block of the drive. Two important hacking notes: a) If you alter the System file ‘boot’1 resource code, something needs to be triggered to copy that to the boot blocks or the changes won’t take effect. B) The code must be 1024 bytes or less to fit in the boot blocks.

6. In System 6.0.8L, at the end of the boot block code, it runs ‘INIT’ 0 in the System File to continue the startup process. A long time ago, commercial developers created their own ‘INIT’ resources and shoved them into the System file to be part of the boot process. Apple didn’t like the System file being altered, so they created ‘INIT’ 31 to run external INIT files in the System folder, which later became called System Extensions.

7. In System 7.0, the boot code is different. Instead of calling ‘INIT’ 0, the boot-blocks code loads and runs the resource ‘boot’ id 2. This is very smart, as the boot block code can be kept small and simple enough just to locate and start the System file code. The code in ‘boot’ id 2 can now be long and specific to that OS. In System 7.0, ‘boot’ 2 does some of the stuff taken out of ‘boot’ 1, and then does System 7 stuff, and finally does the work of the old ‘INIT’ 31 by running all the external System Extensions.

8. In System 7.1, which is the first system with System Enablers, the boot code is improved again. ‘boot’ 1 remains simple enough just to call ‘boot’ 2, just like System 7.0. But, now, ‘boot’ 2 looks for and loads the System Enabler, which then calls the newly existing ‘boot’ 3. If the System Enabler exists and contains a ‘boot’ 3, then it takes over. Otherwise, the ‘boot’ 3 in the System file runs and does the normal stuff that the System 7.0 former ‘boot’ 2 code did with loading extensions, etc.

9. Put simply, System 7.1 has the most basic part of starting System 6 and System 7.0 in ‘boot’ 1 (which is then copied to the boot block). System 7.1 then has the System Enabler find/load code in ‘boot’ 2. Finally, System 7.1 has the run the rest of the system startup code in ‘boot’ 3 (which was at the end of ‘boot’ 1 in System 6 and used to be ‘boot’ 2 in System 7.0).

10. Let’s take a close look at the System Enabler code in System 7.1. This is ‘boot’ resource id 2...

a) Check the System file ‘gbly’ resource for a computer id match. If so, remember this and the date stamp. Because of the date stamp, a newer system enabler can override the system for machines which the system already supports. For example, you could make a System Enabler for an SE/30, which is already supported by System 7.1, and put SE/30 improvements in there.

b) Check the ROM for a ‘gbly’ resource. That’s right! Apple could build enablers to allow a newer computer to run on an older or existing OS (starting in 7.1) without shipping a System Enabler file.

c) Search every file in the root System directory. If it is a ‘gbly’ file type and NOT INVISIBLE (good try virus writers), then it is opened to see if it has a computer id match. If so, remember this and the date stamp.

d) If any matches were found, clear bit 2 (systemEnableBit) of $B20 (ExtensionsEnabledByte). If no matches were found, set this to 1. Weird huh? 1 is ‘no match’. Aside: This byte holds startup global flags. For example, whether you held down the shift key at startup.

e) Go through all the matches and close each file that is older than the best time stamp so far. This leaves us with the newest System Enabler that matches this computer with its resource file open.

f) Load ‘boot’ 3 from this System Enabler. Show restart dialog if the resource isn’t found. This is a mistake in my opinion. If a System Enabler simply consists of a new DRVR or some string resources, why does boot code have to be included?

g) Move the System Enabler resource file handle under the System resource chain in memory. This eventually will be moved in front of the System file to allow overriding of System resources without altering them on disk.

h) Run ‘boot’ 3. This will either be from the System file, ROM, or a System Enabler, depending on who matched and had the most recent timestamp. Remember, ‘boot’ 3 does all the remaining normal boot stuff like load system code and run extensions. Unfortunately, this is a headache as now the System Enabler must reproduce all the standard startup code. Instead, I wish that ‘boot’ 3 was an optional step to make programmatic changes, then there could have been a ‘boot’ 4 in the System to set up normal OS stuff. Then ‘boot’ 5 in the enabler to make any changes. And finally, ‘boot’ 6 could be loading and extensions and launching the Finder. Instead, it’s all or nothing with ‘boot’ 3.

11. When ‘boot’ 3 is done, in System 7 it runs the Process Manager, which later launches MultiFinder (or whatever startup application) as one of the processes.

12. Now for the cool part, the source to this code exists in the Apple code floating around in the files Boot1.a, Boot2.a, and Boot3.a. This will make it much easier to understand and port.

Based on this information, here is one possible approach to porting to System 6.0.8L
i. Snap off the second half of the System 6.08L ‘boot’ 1 code and put it into a new ‘boot’ 4.
ii. Copy the ‘boot’ 1 code and ‘boot’ 2 code from System 7.1 to System 6.0.8L.
iii. When it is finished, modify ‘boot’ 2 code to load ‘boot’ 4, not ‘boot’ 3.
iv. Append code to the beginning of ‘boot’ 4 to rearrange the System resource map order to present the System Enabler resources.
v. Insert code somewhere in ‘boot’ 4 to load and call a new ‘boot’ 5 in the System Enabler if it exists. And then, have ‘boot’ 4 finish up the standard System 6.0.8L startup sequence.

This would allow the off-the-shelf System Enabler to be selected by System 6 at startup. It would allow resources from that enabler to override existing System 6 resources, such as newer DRVR and strings. This might get some Macintosh models (like the LC III or Color Classic) working. Custom code for any tweaks could then be inserted into the System Enabler in our new ‘boot’ 5 code resource. This would allow different developers to independently hack code to get their favorite models working. Also, this keeps the memory/disk size of System 6 small, since you only need to add the single enabler of your choice.

I recognize that it is likely that later System Enablers rely on System 7 traps, bug fixes, and functionality. Also, it may be a pain to extract machine-specific code from generic ‘boot’ 3 startup code within a System Enabler. However, if we can get a couple of simpler machines working, a pattern may emerge.

- David
As already said, thank you ... this is an amazing research result !!

I had the same idea I try to get a look into enablers this week-end but I lacked time and knowledge to find something really useful. I've found the "gbly" resource and I thought it was something important but I did not imagine how much.

I will share your results on macos9lives because I think that it should be a way to explore to make os9 working on "unsupported" G4 without hacking ROM.

I have a question you may be able to answer I think. During my research, I was looking at the icons used in the "About this Macintosh" dialog. I've found some of them in the Enable 065 for the Q605 but where are the others already "known" by the System ? :unsure:
I wanted to cross the information you found about boxFlag, gestalt id, Machine name, Machine configuration and icons.
 

cheesestraws

Well-known member
I have a vague memory you might need to do something a bit more subtle here but I like the idea of adding system enablers to system 6. It's been a while since I read that code, but I seem to remember quite a lot of changes between the way that 7 boots and 6 - not just in terms of code being moved around, but in the relationship between ROM and disc code. But you might want to pre-emptively resign yourself to likely needing significant changes to the enablers - then at least it will be a nice surprise if I'm wrong :).
 

David Cook

Well-known member
The second reason why you might want this is because it likely supports the PowerBook 140/145/145B/170 computers

Good news! System 6.08L (with the startup blocker disabled) does in fact natively support the PowerBook 170!
PowerBook-170-Works-on-6.0.8L.jpg

Aside: Thanks for all the comments so far. I haven't put much time into this project since my initial posting. I received a few new machines that needed recapping and other attention.

- David
 

Snial

Well-known member
12. Now for the cool part, the source to this code exists in the Apple code floating around in the files Boot1.a, Boot2.a, and Boot3.a. This will make it much easier to understand and port.

Based on this information, here is one possible approach to porting to System 6.0.8L
i. Snap off the second half of the System 6.08L ‘boot’ 1 code and put it into a new ‘boot’ 4.
ii. Copy the ‘boot’ 1 code and ‘boot’ 2 code from System 7.1 to System 6.0.8L.
iii. When it is finished, modify ‘boot’ 2 code to load ‘boot’ 4, not ‘boot’ 3.
iv. Append code to the beginning of ‘boot’ 4 to rearrange the System resource map order to present the System Enabler resources.
v. Insert code somewhere in ‘boot’ 4 to load and call a new ‘boot’ 5 in the System Enabler if it exists. And then, have ‘boot’ 4 finish up the standard System 6.0.8L startup sequence.
Wow, this is genius! Universal System 6.0.8L. Now all we need is a port to PowerPC, Intel and ARM ;-) !
 

Phipli

Well-known member
Wow, this is genius! Universal System 6.0.8L. Now all we need is a port to PowerPC, Intel and ARM ;-) !
PPC might be possible, I mean, a IIci runs System 6, and can have a PPC processor. System 6 understands everything other than the processor, and the 68k emulator was originally developed in the days before System 7. It would be much more difficult to get later systems running though. Every year further more hardware changed.

I mean... Has anyone tried this unlocked version of 6.0.8 on a PPC upgraded IIci?

Edit - ah, 24bit addressing might be an issue?
 

Snial

Well-known member
PPC might be possible, I mean, a IIci runs System 6, and can have a PPC processor. System 6 understands everything other than the processor, and the 68k emulator was originally developed in the days before System 7. It would be much more difficult to get later systems running though. Every year further more hardware changed.

I mean... Has anyone tried this unlocked version of 6.0.8 on a PPC upgraded IIci?

Edit - ah, 24bit addressing might be an issue?
Is it? PPC System 6.0.8L would be entirely done in emulation, and would be as small as real System 6. So, if it can't see more than 16MB is that a problem? Oh, you mean that addresses would contain flags in the top byte so that would mess up memory access anyway?
 

Phipli

Well-known member
Is it? PPC System 6.0.8L would be entirely done in emulation, and would be as small as real System 6. So, if it can't see more than 16MB is that a problem? Oh, you mean that addresses would contain flags in the top byte so that would mess up memory access anyway?
PPC machines won't boot in 24bit mode is what I meant.
 

3lectr1cPPC

Well-known member
The 2nd-gen PowerBook 100 series laptops have a substantially redesigned logic board, and I'd assume pretty different ROMs too, so that's hardly a surprise to me. It would certainly be nice to have it running on them though. That would open the possibly to a color System 6 laptop, if someone could get it booting on the 165c or 180c.
 

croissantking

Well-known member
The 2nd-gen PowerBook 100 series laptops have a substantially redesigned logic board, and I'd assume pretty different ROMs too, so that's hardly a surprise to me. It would certainly be nice to have it running on them though. That would open the possibly to a color System 6 laptop, if someone could get it booting on the 165c or 180c.
Newer memory management, video and power management circuitry I would think?
 

Arbee

Well-known member
Power management is back compatible across the 100 series machines except the 150 and 190 (which use the 6805 based PG&E PMU instead of the 6502 based original PMU). The same PMU commands work from the Portable up to the 160/180, just more were added for the 140/170 and then again for the 160/180. The 140/170 revision of the PMU code added a more efficient way to poll ADB but it uses a new command and I believe the old one will still work.

Video is quite different though, especially on the 165c/180c (which use an off-the-shelf PC VGA chip).
 

3lectr1cPPC

Well-known member
While we're on this topic, I'm curious about one thing. Anyone who's used both generations of 100 series PowerBooks knows that the 140/145/170 systems all make a loud speaker pop when they start, and the later ones don't. I do wonder why they designed things that way. In fact, there's a loud speaker pop every time one of those PowerBooks initialize the speaker.
 
Top