Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[joevt]

Here's a script to calculate and check the checksum.

Code: [Select]

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"


[ssp3]

Here's a script to calculate and check the checksum.

Code: [Select]

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

[joevt]

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:

Code: [Select]

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"


[ssp3]

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.



3. Open the Terminal and type:

Code: [Select]

java -jar

4. Drag the jacksum.jar file to the Terminal window.




5. After doing so, type

Code: [Select]

-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.



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.




That's all, Folks!

[ssp3]

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

[teroyk]

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.

[ssp3]

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! 

[DieHard]

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.

[ssp3]

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.

[joevt]

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).

[ssp3]

joevt, you still don't get it 

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.

[joevt]

@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.

[ssp3]

This is more like it! Cool 

Except that it produced different result than my method and it was a negative number. 

Code: [Select]

The current checksum is 198BF23F but it should be -4E673F3F.
The checksum has been updated.


Code: [Select]

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


[teroyk]

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.

[joevt]

Except that it produced different result than my method and it was a negative number. 

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.

[ssp3]

Cool, joevt, cool!  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. 

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.

[ssp3]

@joevt, can you modify your script further, so that it rejects all files that do not begin with, say

Code: [Select]

<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.

[joevt]

@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.

[ssp3]

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:

Code: [Select]

The current checksum is FFDBF67A (ok).
Warning: got type:"74 6" and creator:"2 78" but expected type:"txbi" and creator:"chrp").


Code: [Select]

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.

[joevt]

@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