Mac OS Rom Hacking

[Daniel]

Hello everyone,

I created a custom Mac OS ROM file and thought it might be useful. It does not have the Trampoline or Toolbox data in it. Instead, it loads them from a folder called 'Bootfiles' in the System folder it resides in. The Trampoline and Toolbox are in separate files and can be modified independently. It also loads and runs a Forth boot script from that folder before running the Trampoline.

To use it, just copy the Mac OS ROM file and the Bootfiles folder into your System Folder. It is probably best to save the old ROM file somewhere else and have a second System Folder that can be booted from to restore the first one. I have only tested this on one system. Use it at your own risk.

The Trampoline and Toolbox file are taken from a recent release of CDG5 (it even supports NKDebug if you have it). It probably only works on 9.2.2, but you can swap out the Trampoline and Toolbox for ones that have more compatibility (assuming that you can figure out how to create the separate Trampoline and Toolbox in the first place. It can be trivial or impossibly difficult depending on what tools you have available).

I apologize for the messiness of the custom ROM. I started out with a regular Mac OS ROM file and iteratively modified it until it did what I wanted it to.

I hope that the custom ROM is useful. I would appreciate any feedback on it.
Thank You,
Daniel

Edit:

The version in this message should probably not be downloaded. It is not compatible with every NewWorld Mac. The latest version is attached to another message in this topic. Please download that instead.

[ELN]

Legend. Testing shortly.

[Daniel]

If you try to use the helper functions I made ( $$+ and load-from-path ) for other projects, be careful. load-from-path seems to only work if you use it in chrp files. This is presumably because init-program copies the data in <boot-script> over to another memory region that is not deallocated by release-load-area. If you use it with a forth or fcode script, calling it swaps the loaded data out from under the running program (this seems to not crash it, but makes it return to the program that called the script). ELF and XCOFF files are presumably safe to use load-from-path as well, but I lack the means to test it (also, ELF and XCOFF files are in native powerpc, so it might not make sense to call load-from-path in there).

Also, be careful editing the Mac OS ROM file. Your text editing program might change the file and creator codes after you save it. I am not sure if Simpletext or BBEdit do this, but I know for a fact that Textedit on 10.3.9 does.

[ELN]

Neither QEMU nor my MDD seem to like the image very much. Any ideas? While I notice that the script mixes some LFs in with the usual CRs, Open Firmware usually doesn't mind that. Is the resource fork meant to be missing? The OS usually crashes pretty early if you do that.

But this is very cool, potentially handy for debugging, and easy to integrate into our build system. Which, by the way, does some funky Forth preprocessing that I'd really like your help with. Keen?

[Daniel]

I had no idea that the resource fork was missing. The LFs are probably because I used Textedit on OSX to create the script. For testing the scripts, go into Open firmware and type in " boot [the device alias or path to the device]:[the partition number or ','][the path to the Mac OS ROM file or '\\:tbxi']" . This will show the debugging info for it (assuming it even gets that far). Please send me the entire log or the last line of text in the log. I will look over tomorrow. It is 11:25 PM for me at the moment. I would probably like to help.

[nanopico]

If you try to use the helper functions I made ( $$+ and load-from-path ) for other projects, be careful. load-from-path seems to only work if you use it in chrp files. This is presumably because init-program copies the data in <boot-script> over to another memory region that is not deallocated by release-load-area. If you use it with a forth or fcode script, calling it swaps the loaded data out from under the running program (this seems to not crash it, but makes it return to the program that called the script). ELF and XCOFF files are presumably safe to use load-from-path as well, but I lack the means to test it (also, ELF and XCOFF files are in native powerpc, so it might not make sense to call load-from-path in there).

Pardon me if this is already known and stated and I am just confusing myself.

In the boot script, the stuff loading and claiming memory are for loading the elf file into and then loads it.  The init-program tells OF to actually reads the elf file and puts everything in the proper place.  The trampoline is a non-relocatable file so it will always be loaded at the same spot OF. Thus all the memory claiming and loading stuff.

The OF boot script and trampoline are very important to OS 9.  OS X pretty much doesn't care.  The boot script loads the xcoff file and it's done. No setup.  Straight to the kernel it is.  BootX is pretty much a dummy (I'm exaggerating just a small bit) program that loads the kernel and jumps to it's entry point. The  XNU kernel handles all initialization.  So the drivers for the OS are used during boot. The two are completely different, but it does demonstrate the dependencies of OF in OS 9.

Also just as another note.  Open Firmware can load four types of files for boot. 

• A chrp script that can then call all sorts of Open Firmware stuff via forth and do it's own loading and such.
• An elf program. Mac OS ROM actually uses is a hybrid. Open Firmware can directly load an elf executable and execute it.
• An xcoff program. OS X uses a hybrid chrp script with xcoff, but like elf it loads it and sets it up and jumps to it's entry point
• Raw image.  I think this is pretty neat actually.  I just loads code and assume the first byte is the entry point. Load and start at 0x00000000

[Daniel]

I was not sure if it was already known. It took me a bit of time to figure out that using load from a forth file is unsafe. It makes more sense to put this stuff out in the open to prevent unnecessary roadblocks for anyone trying to use this.

Also, I am rather new here so I do not know about everything that has been discussed.

From what I know, you can load a forth script and run it. The first character in the script has to be a '\' for it to be recognized. Apparantly you can also load a fcode script, but I do not know fcode.

[nanopico]

It's all good. Input is always welcome. It can definitely give a different view point to solve problems.

I was not sure if it was already known. It took me a bit of time to figure out that using load from a forth file is unsafe. It makes more sense to put this stuff out in the open to prevent unnecessary roadblocks for anyone trying to use this.

Actually using load from a forth file/script is not unsafe.  This is actually a way to debug scripts.  There just certain things you need to be careful about. But that is true in any programming language (I personally love infinite loops that bypass certain OS memory control check that allow a program to consume all available RAM in under a second).

Also, I am rather new here so I do not know about everything that has been discussed.

That can work to every one's advantage sometimes since you may describe something already discussed in a different light which may provide an answer.

From what I know, you can load a forth script and run it. The first character in the script has to be a '\' for it to be recognized. Apparantly you can also load a fcode script, but I do not know fcode.

I didn't know anything about it starting with a '\' I have to go play now.  I know that \ is the root selector of the device tree and so not much can be done with the system until you select that root node.
Thinking about it now. I wonder what would happen if you loaded the Mac OS ROM, deleted the root node (and thus everything below it) and then hit go and see what happens.  I'm not about to try that one though.  I've created enough bricks for now doing these kind of things.

Oh yeah. Welcome!

[DieHard]

Mac OS 9.3.1 release date.... soon 

[Daniel]

I believe that I have finally got it working 
The problem was that I was using an undocumented method called " (load) " to load the Toolbox file (the parenthesis are part of the name). It seems to be only implemented on G3s, which is what I was doing the initial tests on. The problem with the regular function loading function " load " is that after loading a file it checks to see if it is a valid program file and unloads the data if it complains. The Toolbox is not a chrp, elf, xcoff, or forth program. To make it so I could use " load ", I had to add a backslash and a space ("\ ") to the front of the Toolbox (right before the "prcl"). This tricks Open Firmware into thinking that the Toolbox is a forth script to avoid "unrecognized Client Program format" errors. Any replacement Toolbox files will also need a "\ " prepended to them, so keep this in mind. The Trampoline does not need any modifications because it is already an elf file.

Now the ROM file works on several different systems. I have also tested unstuffing the file to make sure that Stuffit is not corrupting it somehow. Note that the Mac OS ROM file has no resource fork. At first this was an accident but I found that including one crashes the system during startup 100% of the time. It seems to be fine without one. It has worked on a G4 and several G3s.

To make it really easy to tell if it works, the secondary boot script now paints colored stripes across the screen a few seconds before the happy mac appears. This version of it works pretty much the same as the previous version, except it actually works on non G3s. You just stick Mac OS ROM and Bootfiles in your System Folder and away you go.

As to forth boot scripts, a lot of useful info can be found here:
https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2001.html
https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2004.html
The first link shows how to create and run forth scripts. The second one shows how to get an Open Firmware prompt over telnet. Telnet has been very useful for my work. I can control Open Firmware from my modern laptop and, because of Wifi, I don't even have to be in the same room as the machine I'm debugging as long as it has a wired connection to the network.

Have Fun,
Daniel

[nanopico]

I believe that I have finally got it working 
The problem was that I was using an undocumented method called " (load) " to load the Toolbox file (the parenthesis are part of the name). It seems to be only implemented on G3s, which is what I was doing the initial tests on. The problem with the regular function loading function " load " is that after loading a file it checks to see if it is a valid program file and unloads the data if it complains. The Toolbox is not a chrp, elf, xcoff, or forth program. To make it so I could use " load ", I had to add a backslash and a space ("\ ") to the front of the Toolbox (right before the "prcl"). This tricks Open Firmware into thinking that the Toolbox is a forth script so to avoid "unrecognized Client Program format" errors. Any replacement Toolbox files will also need a "\ " prepended to them, so keep this in mind. The Trampoline does not need any modifications because it is already an elf file.

Now the ROM file works on several different systems. I have also tested unstuffing the file to make sure that Stuffit is not corrupting it somehow. Note that the Mac OS ROM file has no resource fork. At first this was an accident but I found that including one crashes the system during startup 100% of the time. It seems to be fine without one. It has worked on a G4 and several G3s.

To make it really easy to tell if it works, the secondary boot script now paints colored stripes across the screen a few seconds before the happy mac appears. This version of it works pretty much the same as the previous version, except it actually works on non G3s. You just stick Mac OS ROM and Bootfiles in your System Folder and away you go.

As to forth boot scripts, a lot of useful info can be found here:
https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2001.html
https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2004.html
The first link shows how to create and run forth scripts. The second one shows how to get an Open Firmware prompt over telnet. Telnet has been very useful for my work. I can control Open Firmware from my modern laptop and, because of Wifi, I don't even have to be in the same room as the machine I'm debugging as long as it has a wired connection to the network.

Have Fun,
Daniel

load problem solved. 
Besides telnet you can also output to the serial port or get input on it or both! Pretty much useless though on any new world stuff.  Have to go back to when there was a physical port. Or just use the modem port like I think the stealth port does to get a serial connection on the G4/G3 stuff.

[nanopico]

Mac OS 9.3.1 release date.... soon 

Oh sweet! I didn't know about 9.3.1!  Can't wait to see that one.

[DieHard]

Mac OS 9.3.1 release date.... soon 

Oh sweet! I didn't know about 9.3.1!  Can't wait to see that one.

I was counting on you for that release

[nanopico]

Mac OS 9.3.1 release date.... soon 

Oh sweet! I didn't know about 9.3.1!  Can't wait to see that one.

I was counting on you for that release

Oh.  Uhm...  well you see... 
Let's get 9.3.0 First

[Daniel]

Hi again,
I made a slight modification to the custom rom. The previous version was not nearly dangerous enough. This iteration intercepts "quiese", the function that is called to shut down Open Firmware. This could go wrong in so many ways. Specifically, the quiesce function is intercepted so that it will load and run a forth script called "Quiesce-Intercepter" from the Bootfiles folder before actually shutting down Open Firmware. Quiesce is usally called near the end of a bootloader such as the Trampoline or BootX. By intercepting it, we will be able to see the internal structures of the bootloader at the time it tries to shut down Open Firmware.

The "Quiesce-Intercepter" has to be smaller than 4KB in this version (though you could change the limit to an arbitrary value by altering two numbers in the Mac OS ROM file). It is also not enabled unless the secondary boot script "Script" sets the value "Quiesce-Interceptor?" to true.

I have tested this on a G3 and a G4, though no guarantees of it working on anybody else's systems.

Also, can somebody add a "Mad Scientist" smiley face to the list of available emojis? I want to be able to use it in my posts...

[Protools5LEGuy]

Also, can somebody add a "Mad Scientist" smiley face to the list of available emojis? I want to be able to use it in my posts...

Mac OS 9.3.1 release date.... soon 

Oh sweet! I didn't know about 9.3.1!  Can't wait to see that one.

I was counting on you for that release

Oh.  Uhm...  well you see... 
Let's get 9.3.0 First

Shit. I was looking for 9.2.4 because 9.2.3 is already taken... 

[Daniel]

I propose a compromise in the naming schemes. How about we release 9.2.4 for compatablility with more devices and basic stability improvements and the like. We can save 9.3 for major modifications to the core system software(NanoKernal, System Folder, Finder, Etc.). It will probably take a while to get protected memory and multiprocessing working, so these should probably be saved for 9.3. G5 compatablilty and  removal of the 1.5 Gig limit could go in either. I am not sure exactly how much work those would take.

[MacTron]

...
It will probably take a while to get protected memory and multiprocessing working, so these should probably be saved for 9.3. G5 compatablilty and  removal of the 1.5 Gig limit could go in either. I am not sure exactly how much work those would take.

Wow!, This sounds really promising, thank you guys
and keep the hard working !

[ELN]

Looking good! I'm gearing up to give this another try!

A quick note on the resource fork thing. The resource fork of a Mac OS ROM file acts as a System Enabler. Several of its resources are there to patch over System file resources. That way, there was pretty much no need to update the 9.2.2 System as new Macs were released circa 2002.

The addition of a resource fork to this image crashes the system because of the presence of a cfrg resource, which contains the byte offsets of two PEF containers (NQDResidentCursor and ProcessMgrLib) in the data fork. (You might have these mixed in with the Parcels. Let me know if you want a clean Toolbox parcels file.) While PEF containers could live in resources, putting them in the data fork allowed them to be memory-mapped. So much for the Grand Unified Model, alas. The resource fork is necessary for iMic's extra hardware support to work, so consider leaving it in, minus the cfrg resource.

[Daniel]

I knew that some resources had to be referencing the parcels, I just had no idea which ones. Sending me a clean Parcles file would be great. Can you also send me the data fork files? Would I have to modify the cfrg to point to new offsets?

Also, what interesting features would you like to have added to the bootroom? I have already figured something out that lets you load the system folder from somewhere other than where the Mac OS ROM file is (non-interactively. You have to specify the path to the folder in a text file). I haven't posted it here quite yet. Any suggestions? I have no idea how useful my crazy improvements would actually be.