Mac OS 9 Lives
Mac OS 9 Discussion => Mac OS 9, Hacks & Upgrades => Mac OS 9 on Unsupported Hardware => Topic started by: iMic on March 11, 2015, 08:12:13 AM
-
As some may have noticed, I haven't been around in a while. The development of additional ROM and extension modifications has been halted for the time being.
Of course that doesn't mean this project is finished. Should new developments or discoveries come to light, I don't see why we can't continue to experiment with these modifications to the Mac OS as time allows.
This is a rather time consuming project, and recent events have moved this one down the list of priorities somewhat. Between running ThinkClassic, my studies and finding time to spend with my significant other, dedicating several hours or even days to disassembling the Mac OS has become a rather tall order.
That said, another round of updates was made available two months ago in January. These were mostly overlooked however, buried deep within the forum thread over on ThinkClassic, so I'm making them known here officially with this thread.
I have omitted the download links for these packages from the post below. The reason for this is nothing personal - I'm hosting them from my own private account, and I can't guarantee that they will remain there (as a matter of fact, I'm almost certain they will eventually be moved elsewhere). Since I have greater control over that thread and can update it as necessary, I'll direct members from here to that post for up-to-date information on where to find these packages.
https://www.thinkclassic.org/viewtopic.php?pid=4504#p4504 (https://www.thinkclassic.org/viewtopic.php?pid=4504#p4504)
Cheers,
~ iMic.
Time for another release. I wanted to release these now in their current form since I won't be able to commit to a time-frame for another release. Significant life events and recent difficulties have moved development of these down the list of priorities somewhat.
Macintosh ROM 10.2.1v1 "Generic"
* This release replaces the "Mac OS ROM 10.2.1 (Generic)" ROM.
These enhancements for the Macintosh operating system allow for the installation and use of Mac OS 9 on hardware released after Apple ceased support for Mac OS 9, henceforth referred to as unsupported machines.
Release 10.2.1v1 allows some unsupported Macintosh models to boot into Mac OS 9. This "Generic" release does not have any hardware-specific optimisations, and works best on machines like the Power Macintosh G4. While it can be used across a number of models of Macintosh desktops and notebooks, some features like notebook-specific power management or built-in display backlight control may not function correctly on some systems.
Changes
10.2.1v1 introduces a number of revisions from the standard Macintosh system, including:
Mac OS ROM
- Enables OS 9 as a valid boot option on MacRISC3 systems
- Bypasses supported machine checks to attempt startup on unsupported models
- Added model identifier names for Apple System Profiler:
- PowerMac6,1 iMac
- PowerMac6,3 iMac
- PowerMac6,4 eMac
- PowerBook6,3 iBook G4
- PowerBook6,5 iBook G4
- PowerBook6,7 iBook G4
- Updated ROM version in About This Mac to Macintosh ROM 10.2.1v1
- Previously Mac OS ROM 10.2.1
- Updated Package Info to Macintosh System Component
- Previously Mac OS CPU Software 5.9
Insomnia
- Prevents computer from automatically entering sleep mode (see Known Issues in included Read Me First)
This release is also recommended for users of the Mac OS ROM 10.2.1 (Generic) release as it contains a number of bug fixes:
- Fixed incorrect string length for PowerBook6,3 iBook G4 in ntbl resource
- Fixed incorrect number of ntbl entries
Download
(See ThinkClassic thread (https://www.thinkclassic.org/viewtopic.php?pid=4504#p4504) for information)
Macintosh ROM 10.2.1r1 "iBook"
This release contains the complete set of files from my PowerBook6,3 iBook G4.
These enhancements for the Macintosh operating system allow for the installation and use of Mac OS 9 on hardware released after Apple ceased support for Mac OS 9, henceforth referred to as unsupported machines.
Release 10.2.1r1 is specifically intended for use on the iBook G4. It contains a customised version of the Mac OS ROM with improvements specific to the iBook G4, system extensions to provide limited support for the iBook's built-in video hardware and display, and a ColorSync profile to correct gamma for iBook displays that appear overly bright or "washed out".
Changes
10.2.1r1 introduces a number of revisions from the standard Macintosh system, including:
Mac OS ROM
- Enables OS 9 as a valid boot option on MacRISC3 systems
- Bypasses supported machine checks to attempt startup on unsupported models
- Patched backlight NDRV to enable brightness control with mnca backlights
- Added model identifier names for Apple System Profiler:
- PowerBook6,3 iBook G4
- PowerBook6,5 iBook G4
- PowerBook6,7 iBook G4
- Updated ROM version in About This Mac to Macintosh ROM 10.2.1r1
- Previously Mac OS ROM 10.2.1
- Updated Package Info to Macintosh System Component
- Previously Mac OS CPU Software 5.9
ATI Via Driver
- Custom NDRV extracted from OS X Panther enables basic framebuffer support
- Resolution Switching Enabled (640x480, 800x600, 1024x768 on iBook)
- Color Mode Switching Enabled (256 Grays, 256 Colors, Thousands and Millions on iBook)
- Hardware Scaler (Lower Resolutions scale up to fit the entire LCD)
- Backlight Control (when used in conjunction with 10.2.1r1 ROM on iBook)
- Display Sleep and Backlight Dimming Enabled
- VRAM amount detected correctly
ATI Resource Manager
- v3.1.6, Mac OS CPU Software 5.9 included (unmodified)
Insomnia
- Prevents computer from automatically entering sleep mode (see Known Issues in included Read Me First)
This release is also recommended for users of the Mac OS ROM 10.2.1 (Generic) release as it contains a number of bug fixes:
- Fixed incorrect string length for PowerBook6,3 iBook G4 in ntbl resource
- Fixed incorrect number of ntbl entries
Download
(See ThinkClassic thread (https://www.thinkclassic.org/viewtopic.php?pid=4504#p4504) for information)
-
Your contributions are greatly appreciated :)
Take all the time off you need; your previous work has helped (and will help) many others in the future. We can mirror any files you wish here. Your studies are very important (and so is keeping your girl happy), so we all understand... at least until the new improved Hologram Slut Systems come out in 2020, then we will not be as dependent on the ladies.
-
Your contributions are greatly appreciated :)
Take all the time off you need; your previous work has helped (and will help) many others in the future. We can mirror any files you wish here. Your studies are very important (and so is keeping your girl happy), so we all understand... at least until the new improved Hologram Slut Systems come out in 2020, then we will not be as dependent on the ladies.
you better hope your wife doesnt read your posts :D lol
-
I'm sure that the "H.S.S." will be a big hit!!! ;D
-
To understand what machines are OS9'able with this updates:
Previous MDD FW800
PowerBook6,3 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,3 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,3)
ATI Mobility Radeon 9200
PowerBook6,5 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,5 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,5)
ATI Mobility Radeon 9200
PowerBook6,7 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,7 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,7)
ATI Mobility Radeon 9550
So, All iBooks G4?
eMacs PowerMac6,4 eMac are 2 models http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerMac6,4 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerMac6,4)
Apple eMac G4/1.25 (USB 2.0) http://www.everymac.com/systems/apple/emac/specs/emac_1.25.html (http://www.everymac.com/systems/apple/emac/specs/emac_1.25.html) This model has ATI Radeon 9200 graphics with 32 MB of dedicated DDR SDRAM. There were OS9 drivers for 9200 not mobility. It could be the best supported unsupported machine (aside the first iMac G4 "X-only"). It has PowerPC 7447a and 512k on-chip level 2 cache runs at processor speed. Stronger than a cube, for example. Probably slower than a 1GHz Ti Powerbook (?). But this thing supports 3.5'' IDE with 7200rpm
Apple eMac G4/1.42 has ATI Radeon 9600 graphics with 64 MB.
-
Your contributions are greatly appreciated :)
Take all the time off you need; your previous work has helped (and will help) many others in the future. We can mirror any files you wish here. Your studies are very important (and so is keeping your girl happy), so we all understand... at least until the new improved Hologram Slut Systems come out in 2020, then we will not be as dependent on the ladies.
It has been a difficult time since my last round of updates here, especially the last few weeks in particular. She's been keeping me going through all of it though. (Cue Awwwwww.)
I'm not opposed to the idea of having these files mirrored here. They're self contained archives containing the necessary extensions and some documentation about what they do, how to use them and how to install them, so they should already contain everything most users would need.
To understand what machines are OS9'able with this updates:
From what I can tell:
Previous MDD FW800 - Confirmed Working.
PowerBook6,3 iBook G4 [ http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,3 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,3) ]
Mostly Working. ATI Mobility Radeon 9200 framebuffer is usable but lacks hardware 2D/3D acceleration. Sleep Mode is not supported, the system will sleep but be unable to wake, requiring a hard reboot. AirPort Extreme does not work. All other functions of the machine work correctly.
PowerBook6,5 iBook G4 (Early/Late 2004) [ http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,5 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,5) ]
Mostly Working. PowerPC 7447A processor requires OF commands to identify to Mac OS 9 as an older G4 CPU. Multiprocessing folder must be removed from Extensions folder prior to first boot. ATI Mobility Radeon 9200 framebuffer is usable but lacks hardware 2D/3D acceleration. Sleep Mode is not supported, the system will sleep but be unable to wake, requiring a hard reboot. AirPort Extreme does not work. All other functions of the machine work correctly.
PowerBook6,7 iBook G4 (Mid 2005) [ http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,7 (http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerBook6,7) ]
Unlikely to work. Initial testing shows the machine hangs during startup. Possibly requires further investigation to determine if this machine is capable of booting into Mac OS 9. ATI Mobility Radeon 9200 extensions are unlikely to work with the Mobility Radeon 9550 without further modification.
I haven't tested the eMac models personally, but I'm hearing some success with earlier OS X-only models. The ATI Radeon 9200 extensions still need to be patched to determine whether they can be made to work with the onboard graphics in these models.
Some PowerBook G4 models, including the earlier 12", 15" and 17" models, also appear to work in a limited capacity. The main issue there seems to be the graphics hardware, and while I've looked into nVidia's extensions to see if they could be tweaked to work, they're a completely different beast to ATI's extensions and somewhat harder to understand and work with.
-
Fairly new here. Is there any harm in upgrading the graphics card on my FW 800 1.25 G4? I currently have the standard Radeon 9000 Pro but I know that Radeon makes better cards and so does NVIDEA. I have it booting 9.2.2 using the 10.2.1 ROM supplied here. I don't know if that would throw off anything? Thanks!
-
possibly ill buy a G4 Mirror DP 1.42 PowerMac 3.6. are there any issues running os9 on this using the hacks here? :-\
could i even run the swedish os? :-\
-
me time is short. i bet Gary can help me out on this one if nobody else will. :)
-
me time is short. i bet Gary can help me out on this one if nobody else will. :)
Bu, I'm not sure if that's a compliment because you think I can help you or an insult because I'm your last resort…
Buy the machine. Use the OS9 on file here specifically for it. The FW800 ports will operate as FW400 so all you need there is a couple of 3-dollar adapters. English, Swedish, whatever will work if you have the language pack installed. Boot it and enjoy your 1.42gHz OS9 computer.
-
thank you!
that was intended a compliment for you; mocking everybody else. ;)
tomorrow i will see my new friend.
-
i wonder if anyone sgot successful doin this unsupported journey on a non-english OS. my cloudy brain realized "language pack" is not the same thing as the language specific Mac OS ROM. i did try cheating (putting the updated ROM in the swedish system) but for one thing the sound panel settings locked as if occupied by an application. for some reason i find the swedish OS cute compared.
else i have to start learning some english...
-
whatever a "language pack" for OS9 is, but the ROM contains close to nothing in a specific language.
-
whatever a "language pack" for OS9 is, but the ROM contains close to nothing in a specific language.
You are wrong. There are ALRT, DLOG, STR, STR# etc... resources in localized languages.
-
Since Open Firmware stuff is still double Dutch to me, I have a couple of questions to our resident Open Firmware masochists :D :
Am I right in my assumption that the lines on the right are responsible for loading checksum routine? I see Adler32 there..
Can these lines be deleted like I've shown on the left?
Is "then" before "hex" needed there or can it be omitted too?
The idea behind this is simple - if it is known that checksum will be wrong, why load the routine and then end it with "clear", like iMic did in his original mod? Maybe it's better not to load it at all?
I looked at nanopico's ROM mod and this checksum stuff is not present in his version. But then, he added a bunch of other commands - see my post here:
http://macos9lives.com/smforum/index.php/topic,6744.msg51429.html#msg51429
-
Am I right in my assumption that the lines on the right are responsible for loading checksum routine? I see Adler32 there..
It runs the adler32 checksum method for bytes starting at load-base and ending at load-base + load-size - 14.
Then it evaluates the 12 bytes at load-base + load-size - 12. Is it code that outputs the expected checksum? What was loaded? I guess it's the Mac OS ROM file that was loaded (by Open Firmware) and it is checksumming itself. I have an unmodified MAC OS ROM file where the last 14 bytes are:
\ h# 198BF23F
Can these lines be deleted like I've shown on the left?
Is "then" before "hex" needed there or can it be omitted too?
Depends on what the rest of the code is doing.
then is supposed to end an else or if. You didn't include all the code so I can't tell if the then belongs there.
The code would be easier to read if it was indented correctly.
The idea behind this is simple - if it is known that checksum will be wrong, why load the routine and then end it with "clear", like iMic did in his original mod? Maybe it's better not to load it at all?
clear just empties the stack. The original code has an abort here which would also clear the stack. The change to clear removes the abort so it ignores the checksum error.
I suppose if you don't care about the checksum then you don't need to calculate it - assuming the adler32 method doesn't do anything other than calculate a checksum.
The original code in my Mac OS ROM file looks like this:
decimal
1 load-base load-size 14 - adler32
load-base load-size + 12 - 12 ['] eval catch if
2drop ." , bad checksum value" -1
then
<> if
." , checksum error"
abort
then
hex
Removing the checksum check would make it look like this:
hex
-
Thank you!
In my previous post, on the right is a unmodified 10.2.1 Mac OS ROM file. I suppose you have the same one.
I have an unmodified MAC OS ROM file where the last 14 bytes are:
\ h# 198BF23F
Same here.
I suppose if you don't care about the checksum then you don't need to calculate it - assuming the adler32 method doesn't do anything other than calculate a checksum.
I don't know. What else could adler32 be calculating? It's a ROM, not some form of copy protection ;)
Removing the checksum check would make it look like this:
hex
So, if I understood it correctly, everythig from "decimal" to "then" can go, leaving only "hex" in place, right? I am willing to try it out.
Also, as an alternative, can't the checksum be calculated anew after modifications and put into the last 14 bytes in the file?
-
"then" is paired with a preceding "if", and you can't simply omit one and leave the other without breaking the code.
The best manual for OpenFirmware is hosted by Oracle, if you want to truly master the language:
https://docs.oracle.com/cd/E19620-01/805-4436/6j4719cc1/index.html#6j4719cd6
Note that your diff is full of "<>" and so on, which are not valid OpenFirmware. Those are HTML entities to escape the less-than and greater-than characters which cannot be typed literally in web pages.
-
Note that your diff is full of "<>" and so on, which are not valid OpenFirmware. Those are HTML entities to escape the less-than and greater-than characters which cannot be typed literally in web pages.
The Mac OS ROM file begins with some stuff that looks like XML or HTML and the Open Firmware code is contained within that, so < and > are replaced with < and > It's part of the CHRP spec I guess. I didn't research that. That's just what's in the file. I replaced them in my code examples to make them easier to read but they need to be there in the Mac OS ROM file.
So, if I understood it correctly, everythig from "decimal" to "then" can go, leaving only "hex" in place, right? I am willing to try it out.
I think so. The adler32 call is removed. The checksum get catch if then is removed. The checksum compare if then is removed.
Also, as an alternative, can't the checksum be calculated anew after modifications and put into the last 14 bytes in the file?
Sure. You can load the Mac OS ROM file manually into Open Firmware and do the adler32. First you need to load the file. There's some notes at https://forums.macrumors.com/threads/question-how-powerful-of-a-graphics-card-will-work-in-a-beige-power-macintosh-g3.2303689/
Search for "Loading Files in Open Firmware"
When you load a file, it may report the adler32. Ignore that since it is calculate for the entire file instead of what we want which is the entire file minus 14 bytes:
1 load-base load-size 14 - adler32 8 u.r
Then paste the result at the end of the Mac OS ROM file.
-
"then" is paired with a preceding "if", and you can't simply omit one and leave the other without breaking the code.
That's why I asked in the first place. I find it difficult to locate the pairs of those in ROM file in question.
Note that your diff is full of "<>" and so on, which are not valid OpenFirmware. Those are HTML entities to escape the less-than and greater-than characters which cannot be typed literally in web pages.
Swine tool! ;D
-
Here's a script to calculate and check the checksum.
romfile="/Volumes/Classic/System Folder/Mac OS ROM"
python3 -c '
import os
import sys
import zlib
f = open(sys.argv[1], "rb")
file_stats = os.stat(sys.argv[1])
fileContent = f.read(file_stats.st_size - 14)
expectedChecksum = zlib.adler32(fileContent)
f.seek(file_stats.st_size - 8)
fileContent = f.read(8)
print("Current checksum is %s" % fileContent.decode("utf-8"), end = "")
currentChecksum = int(fileContent.decode("utf-8"), 16)
if currentChecksum != expectedChecksum:
print(" but it should be %08X." % expectedChecksum)
else:
print(". Checksum is good.")
' "$romfile"
-
Here's a script to calculate and check the checksum.
romfile="/Volumes/Classic/System Folder/Mac OS ROM"
python3 -c '
import os
import sys
import zlib
.....
Hang, on. On what system are you suggesting to do this? I've said it before that I'm not a programmer by trade, but:
1. We're not running OS9 in Classic mode.
2. If you mount OS9 volume from OSX side, that volume is screwed.
3. I see Python 3 mentioned. Even my 10.10.5 (ouch) comes stock with Python 2.7
There must be a Mac friendlier way to do this - you know, with GUI, freeware/donateware, drag and drop and so on. Like it was back in the day in Mac users community. :)
P.S. At worst, a single CLI executable would do. I'll see what I can dig up
-
I use macOS Monterey on a MacPro3,1. Of course it's likely you'll need to find a different solution for different OSes.
I don't know about OS X screwing OS9 volumes. They both use HFS+.
The adler32 checksum is super simple. You could write it in C. You can find C implementations in open source projects.
The python code should work with older versions of python with some minor changes.
This version will work with python 2 (tested on Quad G5 running 10.5) and python3:
romfile="/Volumes/Classic/System Folder/Mac OS ROM"
python -c '
import os
import sys
import zlib
f = open(sys.argv[1], "rb")
file_stats = os.stat(sys.argv[1])
fileContent = f.read(file_stats.st_size - 14)
expectedChecksum = zlib.adler32(fileContent)
f.seek(file_stats.st_size - 8)
fileContent = f.read(8)
sys.stdout.write("Current checksum is %s" % fileContent.decode("utf-8"))
currentChecksum = int(fileContent.decode("utf-8"), 16)
if currentChecksum != expectedChecksum:
sys.stdout.write(" but it should be %08X.\n" % expectedChecksum)
else:
sys.stdout.write(". Checksum is good.\n")
' "$romfile"
-
Nah, lets do it old school Macintosh style :)
I assume, we all will be doing this on one of the OSX versions, PPC included. We will need two tools in addition to hex editor.
First one is called Jacksum - https://sourceforge.net/projects/jacksum/files/jacksum%20fbi/
It's a Java app. Java was installed in older OSes by default, so there's no need to fiddle around. Legacy Java can still be downloaded from Apple for newer OSes (10.8 and up).
Here's the direct download link to version that should work from OSX 10.4 and up.
https://sourceforge.net/projects/jacksum/files/jacksum%20fbi/jacksum-1.7.0-macosx-finder-integration-1.0.2.tar.bz2/download
The other one is Base Converter - https://sayware.com/mac-osx-software/
Direct download link to Universal Binary (10.4 and up) without using Apple Store - www.sayware.com/baseconverter/BCLatest.dmg
You will understand later why it is needed..
Decompress Jacksum archive, but do not run the "install.command" - it's not really needed for our simple job.
I will use the original 10.2.1 ROM for illustration purposes to verify that the Adler32 checksum is calculated correctly.
1. Make a copy of your ROM file. Original will be needed later.
2. Open a copy of ROM file in hex editor of your choice and delete the last 14 bytes.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12248;image)
3. Open the Terminal and type:
java -jar
4. Drag the jacksum.jar file to the Terminal window.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12262;image)
5. After doing so, type
-a adler32
6. Then drag the "shortened" ROM file to the Terminal window.
7. Press enter
Voilà! (or Viola?), here's our checksum! The other number is lenght of (ROM) file in bytes.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12256;image)
The only problem is that it is in decimal form, but we need that value in hex for our modified ROM. This is where Base Converter comes into play. Copy the result from Terminal window and paste it into Base Converter. Then copy the hex string and paste it into full lenght ROM file.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12258;image)
That's all, Folks!
-
I don't know about OS X screwing OS9 volumes. They both use HFS+.
Yeah, right.. Try to use Norton or DiskWarrior on that volume using real OS9 and you will see ;)
-
I don't know about OS X screwing OS9 volumes. They both use HFS+.
Yeah, right.. Try to use Norton or DiskWarrior on that volume using real OS9 and you will see ;)
If both use HFS+ there is not problem with DiskWarrior, but if any drive use HFS+ Journaled then there will be problem.
Have to understand HFS, HFS+ and HFS+ Journaled
are three different filesystems and you don't have to use HFS+ Journaled for OSX.
-
teroyk, HFS+ Journaled is what one usually uses in OSX...
Anyway. I am fiddling with 10.2.1 ROM file and making my own version. This time I left all Adler32 stuff in place, including abort command, but calculated a new checksum as I described two posts above.
My PowerBook G4 boots happily! :)
I think, this method is more elegant that changing abort to clear or yanking Adler32 completely, so this is what I will use from now on.
@joevt - thanks for participating in the discussion, it beared fruit! 8)
-
Anyway. I am fiddling with 10.2.1 ROM file and making my own version. This time I left all Adler32 stuff in place, including abort command, but calculated a new checksum as I described two posts above.
My PowerBook G4 boots happily! :)
I think, this method is more elegant that changing abort to clear and this is what I will use from now on.
In functionality, is your ROM and the iMic ROM identical ? too clarify, Does your ROM have any bug fixes over the iMic ROM ?
Either way, it sound more "eloquent" from a programming perspective. I am glad we have these discussions because it may lead to progress on the FW issue you mentioned on the FW800 towers and other issues.
-
Well, I don't know if it could be called a "bug fix", but my version only minimally deviates from original 10.2.1 and it doesn't contain a single instance of "MacRISCx" in it + all original resources remain untouched.
That's all I can say at the moment. It still is work in progress as I am learning things.
Also, be aware that iMic's ROM 10.2.1v1 (Generic), which he recommended to use in place of 10.2.1 (Generic) is not for every G4 out there. It disables backlight control on my PB G4, for example.
It happens so because he reversed the order of ati and mnca in latter ROM.
As to the FireWire issues, I think we need new/different set of extensions.
And, the issue of FW800 appearing on FW400 port sub-tree (or something like that) in OpenFirmware, that someone in this forum mentioned, should be adressed.
-
Nah, lets do it old school Macintosh style :)
Not sure why replacing a single python call with java, a java app, and two Mac apps makes things better or more Mac style.
The python code can be easily modified so it opens the rom file as read/write and writes the updated checksum to the end of the file. Or it could write to a new rom file if you don't want to modify the original rom file (though I don't know why one would want to keep a rom file that has a bad checksum).
-
joevt, you still don't get it ;D
We, as in "old farts Macintosh users", move stuff around. We drag and drop. We don't live inside the command line Terminal. We didn't have one and used to laugh at those who did back in the day. That's why computing on a Mac was so much more fun than on any other platform. For the rest of us, that is. We (still) think different despite the presence of Unix stuff.
No offence ;)
I'm much faster with two or three GUI apps than with command line where I have to remember all switches, punctuation etc. In fact, I know several Mac users, who make a living on a Mac for at least three decades, who try to avoid Terminal and command line like plague. And they're big guns in their field. That says something.
Not every Mac user out there, even "power user", has programming skills. What is easy for you, might be a nightmare for someone else. I'm used to suggest solutions to others in a way that even grandma on the other end with a Mac could do it. Imagine grandma's reaction if I would throw a bunch of lines of code at her and say that it is all there is, but easy to modify..
Nuff of OT stuff.
Peace!
Over and out.
-
@ssp , I get it - apps with GUIs are nice. I was just confused because your instructions still include a command line although it's a little shorter than my command line - but the length doesn't matter because we have copy and paste. I don't expect grandma to modify code. Someone has to create the code just as someone created those GUI apps and the jacksum.jar. Then someone like yourself has to create the instructions about how to use the code/app/command.
So I created the code (attached) and here's the instructions (like your jar instructions except we're using python):
You type python or python3 into Terminal.app (depends on macOS version). Then you dray the .py file. Then you drag the ROM file that you want to update. Then press return. It will tell you if the checksum is ok. It will update the checksum if it's not ok.
-
This is more like it! Cool 8)
Except that it produced different result than my method and it was a negative number. ;D
The current checksum is 198BF23F but it should be -4E673F3F.
The checksum has been updated.
Traceback (most recent call last):
File "/Users/xx/Downloads/FixMacRomChecksum.py", line 9, in <module>
f = open(sys.argv[1], "r+b")
IndexError: list index out of range
-
In fact, I know several Mac users, who make a living on a Mac for at least three decades, who try to avoid Terminal and command line like plague. And they're big guns in their field. That says something.
And I know Mac user who has programmed with 68K-assembler before used any Terminal. And as one Atari ST user said, "there is something wrong with OS, if it has command line by default". On MacOS9 if needs piping or something fancy "commands" there is apple script where to start, before touch terminal.
-
Except that it produced different result than my method and it was a negative number. ;D
Looks like a python 2 issue where the adler32 function returns a signed number instead of an unsigned number.
It seems that this forum doesn't let you modify attachments of a post, so I've attached the update to this post.
-
Cool, joevt, cool! 8) This one works! Python 2 is what we get installed by default on systems at least up to 10.10, so it's better to stick to it.
Now I have this one in the works. "For the rest of us", so to say. :D
It's preliminary, but it's working. Universal Binary, 10.4 and up.
I'll see what I can do about the wrapper's default window size in Interface Builder and its original texts. I know, the line "Drop MAC OS ROM here to fix checksum" sounds a bit awkward, but that's all I could squeeze in place of wrapper's original characters using hex editor. I probably have to look at both, PPC and Intel binaries in disassembler to see what else could be done.
If anyone have/can make a nice icon for it, let me know. I couldn't find anything interesting that I could borrow. Picture/jpeg/png will do too. I'll make the icon myself then.
-
@joevt, can you modify your script further, so that it rejects all files that do not begin with, say
<CHRP-BOOT>
I've got the wrapper app more or less done. It reacts correctly with "This in not a MAC OS ROM file" to some non-ROM files, but with some others, like jpeg, for example, it (Python) spits out all sorts of funny things.
It is not absolutely necessary, it is only to make the little app "fool-proof". File recognition within the wrapper app relies on either suffixes or file types. ROM files have none of these, therefore the app is set to allow any file as input.
-
@ssp, I've attached an update. It adds more error checking so the jpeg shouldn't cause python to spit out funny things.
It checks for the <CHRP-BOOT> at the beginning of the file and the checksum at the end of the file.
It will also warn if the type and creator are not correct (expects type:"txbi" and creator:"chrp") or if the resource fork is missing.
I don't think the creator matters. The type is necessary for Open Firmware to find it.
It should work with python and python3 (tested in Leopard and Monterey). It's kind of annoying some of the changes you need to make for compatibility between versions.
-
Thanks, joevt! I'll make a new one as soon as the issue below is solved.
Please check how you are parsing the rom file. On all rom files that I have here - modified and original, your script issues following warnings:
The current checksum is FFDBF67A (ok).
Warning: got type:"74 6" and creator:"2 78" but expected type:"txbi" and creator:"chrp").
The current checksum is 198BF23F but it should be FFDBF67A.
The checksum has been updated.
Warning: got type:"74 6" and creator:"2 78" but expected type:"txbi" and creator:"chrp").
I've checked all my rom files with four different apps by three different creators and they all showed that rom file's Type and Creator are present and set correctly. Check it for yourself, this one is free: http://frederikseiffert.de/filetype/
I personally think this all creator/type part is not needed. Why issue a warning if the script can't fix it. It will only confuse users. Lets stick to checksum/fool-proof part only. :)
Correction to my previous post - Apple rom files DO have "Type". I've missed that before. My mistake.
-
@ssp , it looks like xattr -p is inconsistent across macOS versions. In Leopard (10.5) it outputs strings. In Yosemite (10.10) it outputs hex. In Monterey and Ventura it outputs strings again. Now I try xattr -px first which should always give hex and if that's unsupported, then it falls back to xattr -p | xxd -p
-
I'd be more concerned about Tiger users than Ventura-schmentura..
(Now I understand why and how applications start to bloat and then drop support for older OSes). ;D
You have "txbi" is several places in your script, but correct Type is "tbxi" according to all rom files that I've seen. I've fixed this in my app, the info is just for your reference.
Also, there are several conditions where printed out message does not correspond to what's really going on. For example:
1. If checksum has more characters (bytes) than required, it says that rom file has no checksum at the end.
nanopico's ROM for unsopported machines from 2016 is one such example - it has one byte extra.
2. If checksum has less characters than required, it also says that there is no checksum. It doesn't say that the rom file is too short.
3. If I delete a bunch of zeroes somewhere in the middle of rom file, it also doesn't say that the file is too short but happily updates the checksum instead.
Question: doesn't the Mac rom files always have to be exactly in one specific size?
All this checking, double and triple checking of all possible variations is very time consuming.
Making the text messages look "nice" to fit application's window takes some time too.
I am at the stage where I would like the input from other users, especially from those who are on older systems, therefore I will upload a fully working, but sort of, kind of beta version later tonight for others to test.
Cheers!
-
So, here it is. Simple drag and drop application.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12301;image)
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12303;image)
Just drop your created/modified rom file into application window and it will do the rest.
Make sure to make a backup copy of your rom creation first, because this app will update the checksum no matter what.
PPC/Intel. Should be OK starting from 10.4. I've tested it on PowerBook G4 Leopard, MBP2011 Snow Leopard and MBP2011 Yosemite.
Feedback on how it works on other systems and suggestions are welcome.
Happy patching!
Now I expect that any grandma will be able to operate this thing :P
A couple of screenshots of various app's / system messages. Text can be copied, btw.
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12305;image)
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12307;image)
(http://macos9lives.com/smforum/index.php?action=dlattach;topic=2337.0;attach=12309;image)
-
I'd be more concerned about Tiger users than Ventura-schmentura..
(Now I understand why and how applications start to bloat and then drop support for older OSes). ;D
I'm using python from tigerbrew so I don't know for sure if it works in Leopard in Tiger. I use tigerbrew to install dependencies for pciutils and flashrom on Tiger and Leopard.
For Tiger, I have to bypass the file type check since there's no xattr command and I don't want to make the user install GetFileInfo or whatever. I've attached an update for that.
You have "txbi" is several places in your script, but correct Type is "tbxi" according to all rom files that I've seen. I've fixed this in my app, the info is just for your reference.
In two places. Inside the message string. It checks for the correct type and only mentions the wrong type if the file type is wrong. Fixed.
Also, there are several conditions where printed out message does not correspond to what's really going on. For example:
1. If checksum has more characters (bytes) than required, it says that rom file has no checksum at the end.
nanopico's ROM for unsopported machines from 2016 is one such example - it has one byte extra.
Nanopico didn't follow exactly the format that exists in a real Mac OS ROM file.
Use xxd or a hex editor to show the last 14 bytes. Don't use a text editor since not all the bytes of the Mac OS ROM are text.
2. If checksum has less characters than required, it also says that there is no checksum. It doesn't say that the rom file is too short.
The attached update now says "Error: the file doesn't have a checksum at the end or it is not in the expected format."
3. If I delete a bunch of zeroes somewhere in the middle of rom file, it also doesn't say that the file is too short but happily updates the checksum instead.
I'm not going to verify the contents of the embedded ELF image.
Question: doesn't the Mac rom files always have to be exactly in one specific size?
I guess maybe the ELF image needs to start at a 4K boundary and it should be a valid ELF image that can be loaded by the ELF loader in Open Firmware.
Actually, I see there's some hard coded values in the code:
h# 005000 constant elf-offset
h# 017008 constant elf-size
h# 01C008 constant parcels-offset
h# 261958 constant parcels-size
h# 27D960 constant info-size
I suppose one could find the elf-offset and verify that the ELF image begins there (just look for "ELF" characters at elf-offset + 1) without verifying that the ELF image is valid.
The ELF image starts at offset 0x5000 (20K). The existing Open Firmware code in the ROM file begins at ≈8K and is ≈4K in size. There's ≈2K after the existing Open Firmware code before the filler that exists before the ELF image. So you have ≈6K bytes to add more Open Firmware code. If you need more than 6K or if you change the size of anything after the first 20K then you'll need to change some values.
-
Thanks! I'll wait for the input from others before any further changes. The thing works anyway.
Use xxd or a hex editor to show the last 14 bytes. Don't use a text editor since not all the bytes of the Mac OS ROM are text.
Do you really think that I am THAT DUMB? ;)
See below.
-
If I write something that makes you think that I think that you are dumb, then pretend that I wrote it for someone else who might be reading this thread.
This is the the last 14 bytes of the original rom:
2796808: 0d5c 2068 2320 3139 3842 4632 3346 ".\ h# 198BF23F"
Remember that the code executes the last 12 bytes, which means it executes this:
279680A: 2068 2320 3139 3842 4632 3346 " h# 198BF23F"
nanopico's ROM mod adds an extra carriage return (0x0d) at the end:
2796808: 0d5c 2068 2320 3139 3842 4632 3346 0d ".\ h# 198BF23F."
which means the last 12 bytes are these:
279680B: 68 2320 3139 3842 4632 3346 0d "h# 198BF23F."
It will execute without error because Open Firmware treats all white space the same, including carriage returns. However, remember that the checksum is calculated from all the bytes except the last 14. Since an extra character was added at the end, the checksum now includes the initial carriage return at the beginning (at 2796808) so the checksum cannot be 198BF23F even if nothing else was changed.
-
joevt, relax, it was a joke :D :D :D
-
@ssp3 , I did see the smiley winky face. Perhaps I should have added one of those to my reply. ;)
-
Question: where does 10.2.1 MAC OS ROM file originate from? MDD installer? I got mine from I can't remember where.
I am going to make a patcher to create a PowerBook 5,1 ROM from it for the others to try, but I'd like to have original for the patcher to work correctly.
On related note. Besides 9.6.1 and 10.2.1 what other versions are available and where to find them.
-
Question: where does 10.2.1 MAC OS ROM file originate from? MDD installer? I got mine from I can't remember where.
I am going to make a patcher to create a PowerBook 5,1 ROM from it for the others to try, but I'd like to have original for the patcher to work correctly.
On related note. Besides 9.6.1 and 10.2.1 what other versions are available and where to find them.
macintoshrepository.org has a list of roms under "All Macintosh ROMs (68K + PPC)".
There's rom files at https://github.com/sentient06/MacROMan/tree/master/TestImages/New%20World%20ROM
which includes origins for most off them except 10.2.1.
10.2.1 is the last in those lists. Googling "rom" "10.2.1" says it's from Mac OS 9.2.2 retail.
-
Thanks, but both links have ROM files that have their Resource forks chopped off! WTF, as they say.. >:(
-
So far I was able to dig up 9.2.1; 9.3.1 and 9.7.1.
9.5.1; 9.8.1 and 10.1.1 would be most interesting for me.
Downloading ~4GB images from various places is very time consuming. And very frustrating after you find out that it contains the same 10.2.1 version.
MacTron, do you still have these somewhere available for download? Quote is from 2014.. :)
This is what I have:
Mac OS ROM 8.8.1
Mac OS ROM 10.2.1
Mac OS ROM 10.1.1
Mac OS ROM 10.2.1
Mac OS ROM 9.1.1 *
Mac OS ROM 1.8.1
Mac OS ROM 2.0.2
Mac OS ROM 2.3.1
Mac OS ROM 2.5.1
Mac OS ROM 3.0
Mac OS ROM 3.7
Mac OS ROM 6.1
Mac OS ROM 7.5.1
Mac OS ROM 8.4
Mac OS ROM 8.6.1
Mac OS ROM 9.7.1
Mac OS ROM 9.8.1 Custer
Mac OS ROM 9.5.1
I'm uploading it to my FTP folder...
-
OS9 ROM Fixer does not appear to work on Tiger - I'm installing Sorbet Leopard to see if it works on that. The app shows an error regarding a missing module which I'm sure is due to the default python 2.x on Tiger not having the necessary modules installed by default.
-
I can confirm that OS9 ROM Fixer does indeed work on Leopard :) I used it to try and fix a ROM patched using ataboot.py but it said it was already OK. My issue now is that the ROM file does not contain the resource fork or info data. There's two extra files it generated with .idump and .rdump extensions but I don't know what to do with them / how to import them into the ROM file :(