Those card works fine, afaik - it’s the one that additionally has SATA onboard that allegedly has problems.
The "820-0961-A" mystery G3 3.3V FlashRom
- Thread starter stynx
- Start date
A user of a rev C ROM Beige G3 reports that applying the cache line size and master latency timer fix that exists in the rev D ROM for PCI bridges improves performance.
You can test this on a Beige G3 or any Power Mac.
First, find the config address of the PCI bridge that contains the controllers (SATA, USB, FireWire, etc.) that you want to test/improve.
Code:
dev pci/pci-bridge
.propertiesResult:
Code:
reg 00006000 00000000 00000000 00000000 00000000Look at the
reg property. You want the non-zero address that ends in 00 which in the above example is 6000.Now go to the PCI host device that is the parent of the PCI bridge to read the PCI config registers. Offset 0 is the device and vendor IDs. offset 0xC is the cache line size and the master latency timer.
Code:
dev pci
\ get the vendor and device IDs and verify that they match those of the PCI bridge.
6000 config-l@ 8 u.r
\ get the cache line size and the master latency timer.
600c config-l@ 8 u.rResult:
Code:
00012008In this example, the cache line size is 0x08 and the master latency timer is 0x20. 0x01 is the PCI header type (0x01 = PCI bridge).
To change the cache line size and the master latency timer, use this:
Code:
0000 600c config-l! \ set cache line size and master latency timer to 0.
Code:
2008 600c config-l! \ set cache line size to 32 and master latency timer to 8.Then continue booting into Mac OS and run some benchmarks. You'll want to run benchmarks for 0000 and 2008. I wonder if other values can be used?
Probably not. I did find an issue with PCI controllers that don't have a PCI Option ROM with Open Firmware fcode (USB and FireWire controllers). I made a patch to fix this which I added to the ROM extender that I mentioned at
https://68kmla.org/bb/threads/mathey-msata-13umac-ide-sata-card.47740/page-5#post-578415
I've attached the updated version. The source directory has a list of patches. The one discussed here are:
create-defaults patches.of
pci-pci-config-patches.of
Good to know. I only have one multifunction card, a USB 2.0/Firewire, it has a bridge chip on it. It would be easy for me to benchmark throughput as I can just swap out the ROMs between reboots.
Necroing this thread a bit.
When you folks were combining the chip contents into a full ROM dump, did you swap every pair of bytes?
The chips are 16 bits (2 bytes wide). A ROM dump from the machine interleaves the four chips, taking two bytes at a time from each chip, but.....
the ROM dump from the machine has each pair of bytes swapped in order from how they are stored on the chips.
So, if you had:
(read from chips on chip reader)
Chip 1: ABAB ABAB ABAB ABAB
Chip 2: CDCD CDCD CDCD CDCD
Chip 3: EFEF EFEF EFEF EFEF
Chip 4: FAFA FAFA FAFA FAFA
When read directly from the machine (with ROM dumping utility), the corresponding addresses would show:
BADC FEAF BADC FEAF BADC FEAF BADC FEAF BADC FEAF BADC FEAF BADC FEAF BADC FEAF BADC FEAF
BTW, do not install these modules in anything but a Beige G3. They're pinned to take power from 3.3V. They'll fit in the X100, X500/X600, ANS and PowerExpress machines, but all of those power their ROMs with 5V. Best result is they just won't do anything, won't power up, because the 3.3V pins aren't powered in those machines' ROM slots (I hope).
Last edited:
Now on to the real reason I hunted down this thread.
I bought one of these in late 2024. I can't find the darned thing. Can I please get someone to check the resistance between...
Never mind. Typing that out seems to have triggered a memory. Found the thing on top of my Beige G3. Duh. Two many boxes of snips and snails distracted me as possible hiding places.
What are you checking?
How the WE_ pins are wired. I know where they are on the chips and on the DIMM edge. Are the connected? Or do they run through some of those blank resistor positions on the board? Are the chip WE_ tied high? If so, how high (with what resistance)?
The chips must be held high during operation (reads) or they wouldn't work. Does the DIMM do that, or does it rely on the host machine to supply HIGH on the WE_ pins of the DIMM?
Wouldn't the G3 DIMMs be wired similar to PowerSurge DIMMs (except the voltage source)? Schematics at:
https://bitsavers.org/pdf/apple/powerpc/PowerSurge/ROM_Flasher/
G3 and PowerSurge/TNT/8600 schematics are at:
https://www.macdat.net/repair/apple_schematics.html
Both G3 and PowerSurge have a programmable write enable bit which allows the ROM DIMMs to be flashed while running Mac OS so the WE signal is probably not wired high or low. The signal probably just comes directly from the chip that has the write enable bit - HammerHead for PowerSurge (TNT) and MPC106 Grackle for Beige G3 (Gossamer). The B&W G3 firmware updater has Open Firmware Forth code that shows how to enable flashing for MPC106. The Apple Flasher Utility has PPC assembly that shows how to enable flashing for various Mac models or memory controllers:
Code:
read 'XCOF' (128) ":Objects:xcoffResources:CopyToFlashPDM.xcoff";
read 'XCOF' (129) ":Objects:xcoffResources:CopyToFlashTNT.xcoff";
read 'XCOF' (130) ":Objects:xcoffResources:CopyToFlashCAT.xcoff";
read 'XCOF' (131) ":Objects:xcoffResources:CopyToFlashPBX.xcoff";
read 'XCOF' (132) ":Objects:xcoffResources:CopyToFlashM2.xcoff";
read 'XCOF' (133) ":Objects:xcoffResources:CopyToFlashPSX.xcoff";
read 'XCOF' (134) ":Objects:xcoffResources:CopyToFlashTanzania.xcoff";
read 'XCOF' (135) ":Objects:xcoffResources:CopyToFlashOpus.xcoff";
read 'XCOF' (136) ":Objects:xcoffResources:CopyToFlashGossamer.xcoff";
read 'XCOF' (137) ":Objects:xcoffResources:CopyToFlashPEx.xcoff";