Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Anyone have one of the fruit Colored iMacs?

DearthnVader said:
Is there a way to dump a specific fcode image to a file then load it in OF with the byte-load-file command?

In the iMac Bondi Blue FW I'm looking to extract the fcode image for the Rage Pro so I can load it for and AGP Rage Pro PC Card I have.
Click to expand...

if a Rage Pro fCode PCI Card ROM image is what your looking for then I think you might be better off finding a (dump from) a PCI ATI Rage Pro from a G3 Blue and white, certain configurations came with a DB15 Rage Pro card in the 2nd slot, rather then the Rage 128 in the 1st slot they normally came with

but again as above if your dealing with AGP stuff, a dump from a first generation iBook G3 clamshell might be a better bet :)
 
LightBulbFun said:
if a Rage Pro fCode PCI Card ROM image is what your looking for then I think you might be better off finding a (dump from) a PCI ATI Rage Pro from a G3 Blue and white, certain configurations came with a DB15 Rage Pro card in the 2nd slot, rather then the Rage 128 in the 1st slot they normally came with

but again as above if your dealing with AGP stuff, a dump from a first generation iBook G3 clamshell might be a better bet :)
Click to expand...
I'm really wanting to find if we can extract a usable FCODE image from a Mac's BootROM and use those on PCI type devices.

There are a few cards we have no unlocked and a few PCI devices we may want boot support of like USB/FW/Ethernet.

Mostly stuff I wanted to do with Old World Mac's, but it's fun to investigate and see what strange beasts we can come up with.

I don't think the Rage Pro Turbo PCI Fcode is any different than the Rage Pro.
 
DearthnVader said:
Is there a way to dump a specific fcode image to a file then load it in OF with the byte-load-file command?

In the iMac Bondi Blue FW I'm looking to extract the fcode image for the Rage Pro so I can load it for and AGP Rage Pro PC Card I have.
Click to expand...
I wouldn't copy the fcode image directly to a file.
I would copy the Forth code created by DumpMacRom.sh into a new .of file and use toke to create the fcode from that.
toke will verify that the Forth code doesn't use non-standard words that aren't guaranteed to exist in every version of Open Firmware.
toke may shorten the fcode by substituting literals -1, 0, 1, 2, 3 with shorter fcodes numbers.
toke may need to be modified to support adding external words (to define them but not implement them, like a C header file).
toke may need to be modified to support some Mac specific Forth such as support for local variables.
I believe the built-in ATI GPU fcode should work as is without modification to toke.

Nermal said:
Alas, it doesn't seem to work under 10.3.9. It's looking for kextutil, which either doesn't exist or isn't in the default path.

There's probably a way to load DirectHW.kext manually but it's been so long that I can't remember.
Click to expand...
It only uses kextutil if it exists, otherwise it uses kextload.

View the contents of get-new-world-rom.command
The first thing it does is load KextUtil.sh from the same folder.
The first thing that does is check if kextutil exists. If it doesn't exist then it will use kextload.

Is there something wrong with this command in Panther?
command -v kextutil && echo foundit || echo notfound

I haven't done testing in Mac OS X earlier than Tiger 10.4.11. My Panther 10.3.9 doesn't seem to boot currently. I need to reinstall if I can't repair it.[/icode]
 
Yep, looks like that was a red herring: it still reports "command: kextutil: not found" before going down the "echo notfound" path, and I wasn't paying too much attention to what get-new-world-rom.command was actually doing.

However, kextloading it fails with "kextload: cannot resolve dependencies for kernel extension DirectHW.kext".
 
Nermal said:
Yep, looks like that was a red herring: it still reports "command: kextutil: not found" before going down the "echo notfound" path, and I wasn't paying too much attention to what get-new-world-rom.command was actually doing.

However, kextloading it fails with "kextload: cannot resolve dependencies for kernel extension DirectHW.kext".
Click to expand...
Yup, I need to suppress the "not found" message and recompile DirectHW.kext for Panther. I'll work on it tonight.
 
My Panther boots. Now I'm trying to figure out how to make a kext for pre Tiger Mac OS X. Can it be done using Xcode in Tiger, Leopard, or Snow Leopard? Or do I need to use Xcode in Panther? I don't think the MACOSX_DEPLOYMENT_TARGET affects kexts?
 
I tested the attached on my B&W G3 running 10.3.9. DirectHW.kext was rebuilt using Xcode 1.5 in Panther using the 10.3 SDK.

I'm going to do more testing with Xcode 2.5 and 3 in Tiger and Leopard and Snow Leopard before committing the changes to my DirectHW fork.

The issue I was having with 10.3 SDK is that kexts don't like using AvailabilityMacros.h or TargetConditionals.h which aren't really meant for kexts anyway but those headers seem to work for the kexts being built with the 10.4 and later SDKs.
 

Attachments

  • flashrom-joevt-10.3 and 10.4-ppc.zip
    1 MB · Views: 60
Nermal said:
Success!
Click to expand...
Seems to be identical to rom of iMac (233 MHz) Bondi Blue. Is your iMac 266 MHz or 333 MHz?

There is a one byte difference but it's not in the Open Firmware part.

Seems the method used by get-new-world-rom.command doesn't grab NVRAM which is interesting.
 
Last edited:
The one byte difference is in the "Rom Image" part of the ROM but its checksum was not updated with that change. Maybe it's a bad dump?

The "Recovery" part is a copy with the original value for the byte and matches the "Rom Image" and "Recovery" parts of the 233MHz iMac.

The ROM Image / Recovery parts have 3 compressed parts. The first is the main part containing startup code and Open Firmware and some fcode images. The second is another fcode image that I didn't notice previously in the B&W G3 and the Bondi Blue iMac. I don't know what the 3rd part is for. There's a 4th part which doesn't seem to be compressed. It contains the changed byte.
 
joevt said:
Seems to be identical to rom of iMac (233 MHz) Bondi Blue. Is your iMac 266 MHz or 333 MHz?
Click to expand...
It's 333.

joevt said:
Maybe it's a bad dump?
Click to expand...
It took an absurdly long time to copy the file off the iMac once I'd dumped it, but I couldn't be bothered with investigating why. It's possible that it got corrupted during the transfer. I might give it another go later.
 
Last edited:
Nermal said:
It took an absurdly long time to copy the file off the iMac once I'd dumped it, but I couldn't be bothered with investigating why. It's possible that it got corrupted during the transfer. I might give it another go later.
Click to expand...
It could also be bad RAM or bad ROM.

I updated the attachment in #32
It will now output and verify the checksums in the "Rom info" line of the output.
If the checksums are good then it outputs "√".
If the checksums are bad, then it outputs the expected checksum followed by the calculated checksums followed by "x".
The expected checksum is the checksum that is stored in the file.
The calculated checksum is calculated by applying the checksum algorithm to all the bytes of the file.
Old World ROMs have one checksum for the first 3 MB of the ROM.
New World ROMs have 3 or 4 parts with a checksum. The early iMacs and B&W G3 have 3 parts, so one of the 4 checksums is output as 00000000.

Code: 
1999.0423 ""                 1024 7dc7ffc3.00000000.3cc447a3.d62147a3                √ "./ROM iMac (233 MHz) Bondi Blue/ROMs/imacboot.rom"
1999.0423 ""                 1024 7dc7ffc3.00000000.3cc447a3.d62147a3 7dc7ffc3.00000000.3cc447a3.a70847a7 x "./ROM iMac (266,333 MHz)/ROMs/macrom.bin"

The second one is from your ROM dump.
 
I dumped it again and it generated the same file (i.e. openssl sha1 macrom.bin returns the same checksum).

Rom Info: 1999.0423 "" 1024 7dc7ffc3.00000000.3cc447a3.d62147a3 7dc7ffc3.00000000.3cc447a3.a70847a7 x "macrom.bin"
 
It all kind of confirms that the Rage Pro PCI and the Rage Pro Turbo PCI are using the same ROM code unless both ROM's have FCODE for both chips.

Not outside of the realm of possibility as the Rev.A Beige ROM has the FCode and 'NDRV's for both the Rage II+DVD and the Rage PRO PCI.

ndrv_107_ATY_mach64_3DU.per ndrv_108_ATY_RAGEIII.pef
Click to expand...
 
DearthnVader said:
It all kind of confirms that the Rage Pro PCI and the Rage Pro Turbo PCI are using the same ROM code unless both ROM's have FCODE for both chips.

Not outside of the realm of possibility as the Rev.A Beige ROM has the FCode and 'NDRV's for both the Rage II+DVD and the Rage PRO PCI.
Click to expand...
The iMac 233 - 333 MHz Open Firmware has fcode and ndrv property for two ATI graphics controllers:

Code: 
vendor-id       1002
device-id       4756
device-name     ATY,RageIIC_C
model           ATY,GT-Bc
ATY,Rom#        XXX-XXXXX-103
ATY,Fcode       1.63
driverID        iMAC 1.0f8
driver name     .Display_Video_ATI_mach64

vendor-id       1002
device-id       4750
device-name     ATY,RagePro_C
model           ATY,GT-C
ATY,Rom#        XXX-XXXXX-107
ATY,Fcode       1.64
driverID        iMACPro 1.0FE
driver name     .Display_ATImach64_3DR3

The iMac slot loading has 5 fcode drivers (same number as all the Macs from Pismo to MDD except with different version numbers for MDD).
See my "List of PowerMacs.txt"
 

Attachments

  • List of Power Macs.txt
    15.1 KB · Views: 41
You know the iMac's with the IRDA have a 8PIN Mac Serial connector running from the IRDA to the powerbord/HD catty.

I wonder how we can hack this?
 
DearthnVader said:
You know the iMac's with the IRDA have a 8PIN Mac Serial connector running from the IRDA to the powerbord/HD catty.

I wonder how we can hack this?
Click to expand...
The Griffin gPort and GeeThree Stealth Port use the modem port (ch-a) and the Griffin iPort uses the IrDA port (ch-b = printer port).

The iPort has a Control Panel to allow switching between IrDA and the printer port but there might be an issue with some classic macOS versions.
https://68kmla.org/bb/index.php?thr...or-a-item-that-uses-the-mezzanine-slot.39077/
https://www.cnet.com/tech/computing/griffin-iport-disables-infrared-port-in-mac-os-8-6/

Here's an interesting hack which allows both the iPort and a Mezzanine-Slot card to be used simultaneously:
http://web.tiscalinet.it/lellos/iPort-hack/
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back