Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.

LeoI07

macrumors member
Original poster
Jul 8, 2021
57
45

Original Question​

I have an old Power Macintosh G3 Minitower (266 Mhz) and I'm looking to install a GPU upgrade so the G3 can output higher resolution video at higher color depths. However, I don't know of any specs for what the max working graphics card specs (mainly VRAM) work for a beige G3. All I know is that the GPU would be installed in a PCI slot. Does anyone know of the maximum graphics card requirements for beige G3s? I could use those to search for graphics cards that would work (preferrably ATI since Apple used graphics cards from them back in the late 90s and early 2000s).

Simple Answer​

Radeon cards works in all PCI Macs but don't support Core Image. #2
Quartz Extreme may be enabled manually. #6
  • Rage 128
  • Radeon 7000
  • Radeon 7500
  • Radeon 8500
  • Radeon 9000 - #213
  • Radeon 9000 Pro - HERCULES #7 #9 #26 #205 #206
  • Radeon 9200 - most powerful video card an OldWorld Mac can use #4 #8 #228
Some Nvidia cards also work but are not as good as some of the Radeons #13

Complicated Answer​

Nvidia cards that support Core Image can work if their PCI ROM is modified for Old World Macs (see below). #2
When a GPU that supports Core Image exists, Core Image will be enabled for all GPUs #482 .
Quartz Extreme is enabled by default. #6
  • GeForce 5200
  • GeForce 5500
  • GeForce 6200 - PNY GeForce 6200 PCI, flashed and working fine in G4 towers. #32 #66 #68 #101 #223
    • Modified ROM #15 for @flyproductions 's PNY : #386
    • Modified ROM #16 for @DearthnVader 's PNY : #388
    • Modified ROMs #17b for those two which should work in all versions of Apple Open Firmware (not suitable for OpenBIOS unless it implements us for microsecond delays): #415
    • Modified ROM #18,19 for @domii's BFG 6200 bfgr62256ocp: #436 (may require nvstrap/clocks modification #446 ) -> #449 -> #450
    • Modified ROM #20 for @DearthnVader 's EVGA 6200 512MB (512P1N402LR) (for all versions of Apple Open Firmware) #656
  • GeForce 6600 - #228
  • GeForce 7800 GT - #234
    • Modified ROM #26 from Mac Edition, 64KB compressed and 128KB uncompressed versions (modified for all versions of Apple Open Firmware but only tested in Quad G5) : #28
  • GeForce 7800 GTX

Benchmarks​

While OpenMark-results are more or less resolution independent, those of OpenGL Extensions Viewer depend very much on the settings! So only same settings (resolution, color-depth etc.) can be compared to each other. Settings used are: Given resolution and color depth, Fullscreen, Standard-Framebuffer, anything else turned off. Also using the same version of the app is recommended, if results shall be compared. The respective versions of OpenGL Extensions Viewer for testing can be downloaded from post #718.
  • OpenGL Extensions Viewer 3.0 or 3.1.1 (OpenGL 1.1 scores)
    • 166 fps (1680x1050x32) (OpenGL 2.1) - GeForce 6200 PCI in G4 Sawtooth #223
    • 170 fps (1680x1050x32) (OpenGL 2.1) - GeForce 6200 AGP in G4 Sawtooth #223
    • 172 fps (1680x1050x16) (OpenGL 2.1) - GeForce 6200 PCI in Beige G3 #410
    • 240 fps (1920x1080x32) (OpenGL 1.5) - Radeon 9200 in G4 MDD #309
    • 269 fps (1680x1050x32) (OpenGL 1.5) - Radeon 9000 Pro PCI in G4 Sawtooth #223
    • 296 fps (1680x1050x32) (OpenGL 1.5) - Radeon 9000 Pro AGP in G4 Sawtooth #223
    • 278 fps (1920x1080x32) (OpenGL 1.5) - Radeon 9000 Pro in G4 MDD #309
    • 307 fps (1680x1050x16) (OpenGL 1.5) - Radeon 9000 Pro in Beige G3 #410
    • 824 fps (1680x1050x32) (OpenGL 2.1) - GeForce 6600GT in G4 QuickSilver #687
    • 849 fps (1680x1050x32) (OpenGL 2.1) - Radeon RX 6800 XT in G4 Sawtooth #223
    • 1041 fps (1280x1024x32) (OpenGL 2.1) - Radeon 9800 Pro in G5 1.8 #612
    • 1668 fps (1280x1024x32) (OpenGL 2.1) - GeForce 7800 GT in G5 1.8 #612
    • 2399 fps (1680x1050x32) (OpenGL 2.1) - Gainward Bliss 7800GS 512MB in G4 QuickSilver #687
    • 1331 fps (2560x1600x32) (OpenGL 2.1) - GeForce 7800 GTX 512MB in G5 Quad #731
    • 4021 fps (1344x1008x32) (OpenGL 2.1) - GeForce 7800 GTX 512MB in G5 Quad #731
  • OpenMark
    • 3612 (1280x1024x32) - GeForce 6200 in PowerTower Pro #685
    • 4147 (1680x1050x32) - GeForce 6200 in Beige G3 #413
    • 9331 (1280x1024x32) - Radeon 9800 Pro in G5 1.8 #612
    • 14709 (1280x1024x32) - GeForce 7800 GT in G5 1.8 #612
    • 19468 (2560x1600x32) - GeForce 7800 GTX 512MB in G5 Quad #731
  • xbench 1.3 (OpenGL Graphics Test - Spinning Squares)
    • 18.22 - 23.12 fps - GeForce 6200
    • 11.36 - 11.36 fps - Radeon 9200

PCI Adapters​

There exist adapters that may allow using PCIe/AGP/PCI-X/PCI cards in a different kind of slot. #228 #233 #237
  • PCI to AGP - Use an AGP card (e.g. Radeon 9800) that doesn't use AGP features in a PCI slot #38 #346
  • AGP to PCI - Use a PCI card in an AGP slot.
  • PCIe to AGP - Use an AGP card in a PCIe slot.
  • PCIe to/from PCI - PLX PEX8111 or PLX PEX8112 or IDT Tsi381 has PCIe 2.5 GT/s x1, 32-bit 33 MHz. The IDT has better performance than the PEX8111.
    • PCIe to PCI - Use a PCI card in a PCIe slot. ASMedia ASM1083 has PCIe 2.5 GT/s x1, 32-bit 33 MHz (forward only).
    • PCI to PCIe - Use a PCIe card (e.g. GeForce 7800 GT or Quadro FX 4500) in a PCI slot. #133
  • PCIe to/from PCI-X - PI7C9X130 or PLX PEX8114 has PCIe 2.5 GT/s x4, PCI-X 64-bit 133 MHz. #704
    • PCI-X should also allow PCI

PCI Speeds​

PCI
- 32-bit 33 MHz = 133 MB/s - original PCI Power Macs (7500, 8500, 9500, 9600, etc)
- 32-bit 66 MHz = 267 MB/s - Power Mac G3 (Blue & White), Power Mac G4 (PCI Graphics)
- 64-bit 33 MHz = 267 MB/s - Power Mac G3 (Blue & White), Power Mac G4, Power Mac G5 (PCI)
- 64-bit 66 MHz = 533 MB/s
AGP
- 32-bit 66 MHz 1X = 267 MB/s
- 32-bit 66 MHz 2X = 533 MB/s - Power Mac G4 (AGP Graphics), G4 (Gigabit)
- 32-bit 66 MHz 4X = 1067 MB/s - Power Mac G4 (Digital Audio), G4 (Quick Silver), G4 (Quick Silver), G4 (MDD), G4 (FW 800)
- 32-bit 66 MHz 8X = 2133 MB/s
PCI-X
- 32-bit 100 MHz = 400 MB/s
- 32-bit 133 MHz = 533 MB/s
- 64-bit 100 MHz = 800 MB/s - Power Macintosh G5 (PCI-X)
- 64-bit 133 MHz = 1067 MB/s - Power Macintosh G5 (PCI-X)
PCI-X 2.0
- 32-bit 266 MHz = 1067 MB/s
- 32-bit 533 MHz = 2133 MB/s
- 64-bit 266 MHz = 2133 MB/s
- 64-bit 533 MHz = 4267 MB/s
PCIe
- 2.5 GT/s x1 = 250 MB/s - Power Mac G5 Dual or Quad Core
- 2.5 GT/s x2 = 500 MB/s
- 2.5 GT/s x4 = 1000 MB/s - Power Mac G5 Dual or Quad Core
- 2.5 GT/s x8 = 2000 MB/s - Power Mac G5 Dual or Quad Core
- 2.5 GT/s x16 = 4000 MB/s - Power Mac G5 Dual or Quad Core
- 5.0 GT/s x16 = 8000 MB/s
...

PCI ROM Modifications​

Power Macs use Open Firmware in their Boot ROM. Old PCs use BIOS. Intel Macs and newer PCs use UEFI.
A PCI card (this includes AGP and PCI-X and PCIe) contains a ROM that has one or more PCI Expansion ROM images. Each image has a type (BIOS, Open Firmware, EFI).
Any GPU that is going to work in a Power Mac requires a ROM that contains an Open Firmware image (also called FCode ROM).

Nvidia cards with 256 MB VRAM like the GeForce 6200 can be used, but they need modifications to their FCode ROMs to work with Old World Macs #386 . Example modified ROMs are linked above.

Old Worlds Macs are those with Open Firmware version 1.x or 2.x. New World Macs have Open Firmware 3 or 4. For Power Macs with Open Firmware 1.0.5, 256 MB doesn't work without the nvramrc patches that are usually added automatically by Mac OS 9 or Mac OS X or XPostFacto. This means the card could stop working after zapping the PRAM until you successfully boot into the Mac OS again.
...add links to XPostFacto nvramrc patches...

Nvidia cards with 512 MB VRAM only work with New World Macs that have Boot ROMs created September 23 2004 or later unless an nvramrc patch is used (with the modified FCode ROM in the case of Old World Macs). #460 #483
Is 512 MB VRAM useful? In some cases, yes #707 . Use OpenGL Driver Monitor to view the VRAM usage. #482

The nvramrc patch depends on the version of Open Firmware:

nvramrc Patches for PowerPC Macs to support GPUs up to 512MB​

for Power Mac 7500, 8500, 9500, 8600, 9600, Power Tower Pro, ...

The patch requires all the other map-in and map-out fixes from the Mac OS 9 or Mac OS X default nvramrc.
The default nvramrc added support 256MB BAR (up from 128MB). It should include:
- the helper functions (or aliases) $R and & (so you can remove those from my patch here).
- the mmr replacement (with mi) for fcode 89B map-range
- the two patches for fcode 8cb (map-in) which uses mcm and y
- the two patches for fcode 8c9 (allocate-addresses) which uses maa Note: maa needs to have 1D changed to 1E to support 512MB BAR.
- the patch for fcode 8cd probe-alloc
- the patch for fcode 8cc (map-out) which uses z.
- the patch for fcode 8c6 (alloc-mem-addr). This patch is separate from my patch of the same fcode.
(those names are from the XPostFacto nvramrc which may differ from the Mac OS 9 or Mac OS X version).
Code:
: $R BRpatch ;
: & get-token drop ;
: m5 { m } dup 1 1c << mmr 1 1c << + m 4+ ! 0 ;
8c6 & dup 58 + ' m5 4c + swap $R d0 + ' m5 10 + $R
Don't forget to also change maa as noted above.
for Beige G3

It reserves 2000 MB at the start instead of just 256 MB at a time so the first 5 lines for the patch for fcode 96e (alloc-mem-addr) might not be required.
The patch for fcode 971 (allocate-addresses) allows 512MB BARs to be included in assigned-addresses property.
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 944 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
96e & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R
1e 971 & 1c + code!
for Power Mac 4400 and 7220 and some Motorola StarMax
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 940 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
96a & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R
1e 96d & 1c + code!
for Power Mac 5500, 6500, and TAM

It includes a patch that changes the order of PCI slot probing. It probes the ATI GPU (device @12) last instead of first. This fixes a problem where Open Firmware would not probe devices behind a PCI bridge (e.g. the USB and FireWire and ATA controllers of a Sonnet Tempo Trio). The patch should work with any such PCI card (the patches from Sonnet only worked with specific Sonnet cards). See #232
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 940 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
96a & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R
1e 96d & 1c + code!

dev pci1
defer ?p
a3b & to ?p
: ps
0d 17 -1 ?p
0e 19 -1 ?p
0f 1c -1 ?p
11 16 -1 ?p
12 18 -1 ?p
;
' probe-slots dup
284 + ' ps blpatch
dup 288 + swap 2FC + $R
unselect-dev
for Power Express
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 970 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
99a & dup 3c + ' m5 44 + swap $R 9c + ' m5 c + $R
1e 99d & 1c + code!
for Beige G3
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 948 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
973 & dup 3c + ' m5 44 + swap $R a8 + ' m5 c + $R
1e 976 & 1c + code!
for Power Mac G3 (B&W)
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 8BA & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
8E3 & dup 3c + ' m5 44 + swap $R a8 + ' m5 c + $R
1e 8E6 & 1c + code!
for Power Mac G4 (AGP) Sawtooth, Power Mac G4 (Gigabit), Power Mac G4 (Digital Audio)
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 8e1 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
90a & dup 3c + ' m5 44 + swap $R a8 + ' m5 c + $R
1e 90d & 1c + code!
for Power Mac G4 (Mirrored Drive Doors)
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 1707 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
1732 & dup 3c + ' m5 44 + swap $R a8 + ' m5 c + $R
1e 1735 & 1c + code!
for Power Mac G4 (FW 800)
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 17df & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
180a & dup 3c + ' m5 44 + swap $R c8 + ' m5 c + $R
1e 180d & 1c + code!
for Power Mac G5 1.6 (PCI)
Code:
: $R BRpatch ;
: & get-token drop ;
defer mr 18e1 & to mr
: m5 { m } dup 1 1c << mr 1 1c << + m 4+ ! 0 ;
190c & dup 3c + ' m5 44 + swap $R c8 + ' m5 c + $R
1e 190f & 1c + code!
Has support for up to 512MB BAR built-in.
for Power Mac G5 Quad

Has support for up to 512MB BAR built-in.

Tested PCI cards​

  • 6200 512MB in G4 Sawtooth #605
  • Quadro FX 4500 512MB in G3 (Blue & White) #651 (using PCI to PCIe adapter)
  • EVGA 6200 512MB (512P1N402LR) in Beige G3 may have problems #686

Notes​

  • The default nvramrc stored by Mac OS 9 or Mac OS X may already have parts of the provided patches (such as : $R BRpatch ;).
  • Since Mac OS 9 or Mac OS X may overwrite the nvramrc, you may want to include the patch in the Ofpt resources that the nvramrc contents originate from. #465 #475 #477
  • For some unknown reason, (allocate-addresses) for firmwares starting from September 2005 (such as for G5 Quad) loops through BARs by size in reverse order (starting from 512MB) when there's a 512MB BAR. I did not include that change in these patches. (allocate-addresses) for older Macs always loops from small (16 bytes) to large (128MB originally for OF 1.0.5, then 256MB with the OF 1.0.5 Mac OS 9/Mac OS X nvramrc patch, then 256MB for OF 2.0 and later, now 512MB with this patch or for firmwares starting from September 2004.
  • Open Firmware 3 is used by Macs with G3 or G4. Open Firmware 4 is used by Macs with G5. Both Open Firmware versions continued to be developed in parallel until their last versions created around at least the end of September 2005 or beginning of October 2005. Open Firmware 3 has versions 4.x.x while Open Firmware 4 has versions 5.x.x. #627

Troubleshooting​

  • Test the patch without the 512MB GPU. The Power Mac should boot into Mac OS 9 or Mac OS X.
  • Provide output from dev / ls unselect-dev " devalias" evaluate " printenv" evaluate dump-device-tree words. This will provide info about the hardware and some info about the Open Firmware environment. printenv outputs nvramrc only in some versions of Open Firmware. If the words we want to patch are not in the words output, then the get-token method of finding the words to patch will be used.
  • For a specific GPU device the output of .properties before and after the patch may be interesting. In particular, we want to see a BAR in the reg and assigned-addresses properties with size of 20000000 or larger.
  • Provide a rom dump (4MB for Old World Macs and 1MB for New World Macs #88 #95 ). A rom dump gives access to fcode images which can be translated to Open Firmware Forth code for easier readability. It will include visible and invisible forth word definitions. A rom dump will also include nvramrc contents. See "Dumping the New World Rom.txt" in the attachment at #137 . Also see #682 .
    Some Mac ROMs:Mac Open Firmware disassemblies and Forth code: #543
  • Provide a Open Firmware dictionary dump. See #137 #506 #682 . The fcode images are compiled into the Open Firmware dictionary as PowerPC instructions. The patches modify the PowerPC instructions in the Open Firmware dictionary.
  • Have a method of zapping the pram ready (how do you zap the pram of B&W G3 if the keyboard's not working? unplugging the power and battery for awhile should work).

List of Open Firmware versions​

Code:
                                                                                                  BAR   Boot   Boot   Boot   Sound
Mac                                         OF version             ATY,Fcode versions             max   FW     USB    GPT    Arch             Notes
==============================================================================================================================================================================================================                                     
TNT Development A5c1                        Open Firmware, 0.992j  None                           128   No     No     No                                                                                        
7500,9500,8600,9600,Power Tower Pro, etc.   Open Firmware, 1.0.5   None                           128   No     No     No                      256MB requires Mac OS 9 or Mac OS X nvramrc patches (see PowerSurge.of of joevt/XPostFacto for documentation of patches)
Power Mac 5400,6400                         Open Firmware, 2.0     None                           256   No     No     No                      
Beige G3 Desktop                            Open Firmware, 2.0f1   1.49, 1.49                     256   No     No     No                      
Beige G3 Minitower                          Open Firmware, 2.0f1   1.49, 1.53                     256   No     No     No                      
PowerBook G3 Wallstreet                     Open Firmware, 2.0.1   1.54                           256   No     No     No                      
PowerBook G3 Wallstreet PDQ                 Open Firmware, 2.0.1   1.54, 1.59                     256   No     No     No                      
Power Mac 4400 and 7220, Motorola StarMax   Open Firmware, 2.0.2   APL-1.0b33                     256   No     No     No                      
Power Mac 6500,TAM                          Open Firmware, 2.0.3   APL-1.0b33                     256   No     No     No                      
Power Express                               Open Firmware 2.0a9    None                           256   No     No     No                      
Power Express                               Open Firmware 2.3      None                           256   No     No     No                      
Beige G3 (v3)                               Open Firmware, 2.4     1.49, 1.53                     256   No     No     No                      
Power Mac G3 (Blue & White) Yosemite        OpenFirmware 3.1.1     None                           256   No     No     No                      Apple PowerMac1,1  1.1f4   BootROM built on 04/09/99 at 13:57:32
Power Mac G4 (PCI Graphics) Yikes           OpenFirmware 3         ?                              256   ?      ?      No                      Apple PowerMac1,2
PowerBook G3 (FireWire) Pismo               OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   ?      ?      No     0x0e+0x12        Apple PowerBook3,1 4.1.8f5 BootROM built on 03/21/01 at 11:49:53
iMac iMac G3 (Slot Loading)                 OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   Yes    Yes    No     0x0e+0x12        Apple PowerMac2,1  4.1.9f1 BootROM built on 09/14/01 at 13:18:04
Power Mac G4 Cube                           OpenFirmware 3         ?                              ?     ?      ?      No     ?                Apple PowerMac5,1  3.2f1   BootROM built on 07/10/00 at 17:11:57
                                            OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   Yes    Yes    No     0x0e+0x12        Apple PowerMac5,1  4.1.9f1 BootROM built on 09/14/01 at 13:18:04
Power Mac G4 (AGP Graphics) Sawtooth        OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   Yes    Yes    No     0x0e+0x12        Apple PowerMac3,1  4.2.8f1 BootROM built on 10/11/01 at 14:12:47
Power Mac G4 (Gigabit Ethernet)             OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   Yes    Yes    No                      Apple PowerMac3,3  4.2.8f1 BootROM built on 10/11/01 at 14:12:47
Power Mac G4 (Digital Audio)                OpenFirmware 3         1.69, 1.69, 1.73, 1.77, 1.77   256   Yes    Yes    No                      Apple PowerMac3,4  4.2.8f1 BootROM built on 10/11/01 at 14:12:47
Power Mac G4 (Quicksilver)                  OpenFirmware 3         ?                              256   ?      ?      No                      Apple PowerMac3,5  4.2.3f1 BootROM built on 08/01/01 at 11:14:42
                                            OpenFirmware 3         ?                              256   ?      ?      No                      Apple PowerMac3,5  4.2.5f1 BootROM built on 08/16/01 at 22:19:35
Power Mac G4 (Mirrored Drive Doors)         OpenFirmware 3         1.73, 1.77, 1.83, 1.86, 1.86   256   Yes    Yes    No     0x0e+0x12        Apple PowerMac3,6  4.4.8f2 BootROM built on 09/30/02 at 10:24:31
Power Mac G4 (FW 800)                       OpenFirmware 3         None                           256   Yes    Yes    No     0x0e+0x12        Apple PowerMac3,6  4.6.0f1 BootROM built on 02/20/03 at 13:52:27
iMac G4/1.0 17" (Flat Panel)                OpenFirmware 3                                                                                    Apple PowerMac6,1  4.6.8f4 BootROM built on 08/22/03 at 13:45:20
Power Mac G5 1.6 (PCI)                      OpenFirmware 4         None                           256   Yes    Yes    No     0x0e+0x12        Apple PowerMac7,2  5.1.5f2 BootROM built on 09/21/04 at 11:58:53
Power Mac G5 1.8 (PCI-X)                    OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,2
Power Mac G5 2.0 DP (PCI-X)                 OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,2
Power Mac G5 1.8 DP (PCI-X)                 OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,2
iBook G4                                    OpenFirmware 3         1.94                           512   Yes    Yes    No     0x0e+0x12        Apple PowerBook6,5 4.8.7f1 BootROM built on 09/23/04 at 16:13:38
Power Mac G5 ? (one of the following 3)     OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,3  5.1.8f7 BootROM built on 10/26/04 at 16:30:32
Power Mac G5 1.8 DP (PCI)                   OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,3
Power Mac G5 2.0 DP (PCI-X 2)               OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,3
Power Mac G5 2.5 DP (PCI-X)                 OpenFirmware 4         ?                              ?     ?      ?      No                      Apple PowerMac7,3
PowerBook G4 15 inch Early 2005 A1106       OpenFirmware 3         ?                              ?     ?      ?      No                      Apple PowerBook5,6 4.9.1f1 BootROM built on 01/21/05 at 10:51:16
Mac mini G4                                 OpenFirmware 3         1.95                           512   Yes    Yes    No     0x0e+0x12        Apple PowerMac10,1 4.8.9f4 BootROM built on 03/23/05 at 14:22:23
Mac mini G4 1.5GHz Radeon 9200              OpenFirmware 3         1.95                           512   Yes    Yes    Yes    0x0e+0x12        Apple PowerMac10,1 4.9.4f1 BootROM built on 07/12/05 at 16:57:27  ; last firmware to always allocate BARs by ascending size
PowerBook G4 DLSD                           OpenFirmware 3         1.95                           512   Yes    Yes    Yes    0x0e+0x12        Apple PowerBook5,8 4.9.5f3 BootROM built on 09/22/05 at 16:17:32  ; allocates BARs by descending size when 512MB BAR exists
Power Mac G5 Quad                           OpenFirmware 4         None                           512   Yes    Yes    Yes    0x0e+0x12|0x12   Apple PowerMac11,2 5.2.7f1 BootROM built on 09/30/05 at 15:31:03  ; allocates BARs by descending size when 512MB BAR exists
PowerBook ?                                 OpenFirmware 3         ?                              ?     ?      ?      ?                       Apple PowerBook5,9 4.9.6f0 BootROM built on 10/05/05 at 16:45:50
==============================================================================================================================================================================================================
- BARs are allocated by ascending size except where noted.
- Patches exist to support 512MB BARs on all Power Macs.
- sound-architecture is in the config-block (0x100 bytes at 0xfff03f00 in the ROM) at offset 0x0e in the 3 most significant bits. If that is 7 than the byte at 0x12 is added.

NVStraps​

Every Nvidia card is different. You may need to modify the Nvidia soft straps in the Open Firmware image using the same info from a BIOS image. #243

For 512MB VRAM, you may need to modify the Nvidia soft straps to make sure the BAR1 reports as 512MB. #578 #581

The soft straps has a checksum #586 . There are some bytes that are unknown #631 .

Here's a script for dumping soft straps and checksum from a ROM file #589 #594 #601 .

The ROM code creates an NVDA,BMP property which contains performance info. This may also need to be updated #32 . Check the ROM Maker thread. #430

Incorrect info in the straps or BMP may cause issues in some apps. #410 #446 #449 #451

Also check device-id, subvendor-id, and subsystem-id #654

More info:
http://themacelite.wikidot.com/nv-rom

Editing nvramrc in Open Firmware​

Use the nvedit command in Open Firmware. There are special keys for navigation #185 . Type Control-C when done. Type nvstore to save changes. See below for more nvramrc notes.

Disabling a PCI device​

You may find it useful to disable the onboard graphics. This can be done by setting pci-probe-list. #11 #15 #18 #20 #156 XPostFacto might reset pci-probe-list #22 Therefore, you may want to put the setenv command in the nvramrc #29 . XPostFacto may change the nvramrc, so you may want to put the setenv command in the OFpt resource of XPostFacto where the nvramrc originates. #24 #25 Or maybe you don't have to #26 . Or maybe you do #58 #61 #87 .

The setting is renamed pci-probe-mask on New World Macs. #28 #137 #158

There exists pci-probe-history in some versions of Open Firmware. Bits can be set to cause probe-all to skip or redo a device. #49

OS Support​

The ROM of a Power Mac PCI card has an Open Firmware image which contains code for outputting video to a display connected to the GPU while in the Open Firmware environment.

Power Mac GPUs may include a NDRV in the Open Firmware image which contains code that is used by Mac OS 9 or Mac OS X for outputting video to a display connected to the GPU while in the OS environment. If it doesn't include an NDRV, then one from the OS may be used. The OS might not have an NDRV to use. #409 #455 #470 #472

Additional code is required in the OS for 3D acceleration, etc. You may need to run an Nvidia or Radeon installer for anything that is not included in the OS. #13

In a New World Mac, the Mac OS 8.6 TBXI Version 2.5.1 won't work with a GeForce FX 5200 or 6200 so I'd not be surprised if the even older Old World TBXI's also don't work so Mac OS 9 not booting may be a separate issue. #389 #194
New World Macs running Mac OS 9.2 should have no problem with the 6200 or 6600GT AGP (except there's no acceleration though). #391 #392 #411

Old World Macs have no boot picker, so holding the Option key just load defaults. #394

For 6200, I get CI support as long as I don't connect a display to an AGP CI supported card when I'm using the PCI card too. Seems to be a bug in OS X. #401

You may need to delete the kext cache #403 #407 .

In my brief testing with a G3 Blue & White a few years ago, you can boot 10.4.11 with a GeForce 6200 with a G3 CPU, but some 3D applications may fall over and die IIRC #408 .

One further quick note after "using" the Beige with the 6200 for a few days now:
- Dual displays works fine!
- If the Mac was turned off for some time, at the first attempt it allmost allways boots into a black screen. A second boot, either by holding the power button to hard shut down or rebooting via Screen Sharing when fully booted, usually brings it back to life. #425 #474

CPU Support​

A G4 may be required for OpenGL with the GeForce 6200. #458

Open Firmware Tools​

  • In Open Firmware
    • Some newer versions of Open Firmware may have a fcode-verbose? option to help debugging Open Firmware code. The way to use it is not documented. #40 Instead, Trace for Open Firmware was created. It works in all versions of Apple's Open Firmware. This has evolved starting from #123 #331 #356 #361
    • lspci for Open Firmware can list all PCI devices in Open Firmware for the currently selected PCI root. It extracts all PCI configuration space values and tests all the BARs. A bash script can interpret the results using lspci from pciutils. This has evolved starting from #50 #55 #64 #87 #97 #144 #273 #565
      • Sawtooth with 6800 xt on AGP, 6200 on the second of the PCI slots, a SATA controller on the last one #150
    • list-partitions - lists partitions of a hard disk in Open Firmware. #222 #225
    • dump-fields - list fields of some structures in Open Firmware. #25
  • In macOS #543
    • detok - from OpenBIOS - modified for Mac Boot ROM or PCI expansion ROM dumping.
    • toke - from OpenBIOS - modified for creating PCI Expansion ROMs from Open Firmware code. #129
    • lzss - from Apple Open Source - modified for decompressing Open Firmware stuff from New World Macs. #147 #151
    • DumpMacRom.sh dumps the Open Firmware parts of Mac ROMs (both Old World and New World).
    • DumpPCIRom.sh converts PCI Expansion ROM to Open Firmware Forth code which can be converted to FCode using toke #129 . The script can also extract individual images and concatenate them into a single expansion ROM #643 #720 .

Open Firmware Notes​

  • Open Firmware stacks #356
  • Open Firmware device nodes #25

Using dingusppc for Open Firmware Development​

dingusppc is a new emulator currently in development. I don't think it boots into Mac OS 9 or Mac OS X yet but it is useful for doing Apple Open Firmware testing. It works with Open Firmware 1.0.5, 2.0f1, and 2.4. I used it to develop some of the Open Firmware tools. #88 #117 #120 #124

Connecting to Open Firmware​

Connect to the Power Mac that will be running Open Firmware using serial or telnet #54 so you can paste commands from the other Mac or copy the output of Open Firmware commands.
  • Telnet only works with newer Power Macs (G4 and later) that have a telnet package. #60 #130 #131
    The Terminal.app doesn't have useful text pacing options so you may need to copy commands one line at a time #574 .
  • Serial: Use a Mac printer cable #62 .
    • The devalias is either ttya or scca #167 .
    • The default baud rate is 38.4Kbps but you can set 57.6Kbps. A nvramrc patch can be used to get 115.2 Kbps or 230.4 Kbps #64 #70 #76 #90 #107 #110 #112 . The patch depends on the version of Open Firmware.
    • Some Power Macs with a serial controller don't have a serial port. You may be able to install an adapter attached to an internal modem port. #615
    • For modern Macs that you want to connect to the Power Mac that is running Open Firmware, you can use a USB to serial adapter. These will be limited to 115.2Kbps. #196
    • Serial apps: #196
      • cu - terminal command
      • screen - terminal command
      • Z-Term - for old macOS
      • Serial.app - for modern macOS

Loading Files in Open Firmware​

In New World Macs, you can load files in Open Firmware from HFS+ formatted hard disk partitions.

In Old World Macs, this might be possible from FAT formatted floppy disks #59 #73 or from IDE CD-ROM drive with ISO9660 formatted CD #263 . floppy-emu might be convienent #272 .

The bootx file will load Open Firmware code for additional file systems #61 but I don't know how to get back into Open Firmware when that's loaded.
The load command can load an Open Firmware Forth script (begins with a comment which in Forth is a \ followed by a space) or it can load FCode. #71
load hd:,\6200debug.rom
The file is loaded at load-base and has size load-size

If you load a PCI ROM file which begins with a PCI header, then the load command may report an error and it will unmap the memory region (doesn't happen with OF 1.0.5 #267 ). You may be able to remap it using load_alloc. Examine the start to see if it contains the PCI header.
load-base 50 dump
The PCI Header starts with 55 AA. There's a PCIR signature at the start of the PCI Data Structure. The FCode starts with an F1 at offset 0x40 for the Nvidia ROMs we're testing.
Code:
00800000: 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 |U.@.............|
00800010: 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 |........ .......|
00800020: 50 43 49 52 de 10 92 00 00 00 20 00 00 00 00 03 |PCIR...... .....|
00800030: a8 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 |................|
00800040: f1 08 16 5b 00 01 4f 4c 12 2a 00 00 00 00 00 00 |...[..OL.*......|

Instead of using load, you may be able to use (load) (which only works if (load) is a visible word, such as in Open Firmware 2.4) #305 #326 :
" ide0/@0:1,\TEST5.ROM" (load)

Executing Files in Open Firmware​

Once the file is loaded (see above), it can be executed.

If the code in the loaded file is to be applied to a specific device (such as for a PCI device), then before you execute it, you may need to do the following:
Select the device:
dev pci/@e
Override the default open word:
: open true ;
Fix some properties that the driver will expect (for example, the 7800GT Mac ROM requires subsystem-id to match the PCI config space value which is 0x52 - the driver will change this property to 0x10):
52 encode-int " subsystem-id" property
Open an instance and store the result in my-self #77 :
" pci/@e" open-dev to my-self
Optionally, set fcode-debug? so any named words will keep their names even if they are not external:
setenv fcode-debug? true

If it's a Forth script, then this will execute it:
load-base load-size evaluate

If it's FCode, then this will execute it:
load-base 1 byte-load

If it's a PCI option ROM where the FCode image starts at offset 0x40 (as it does in the PowerMac Nvidia ROMs we're testing), then this will execute it:
load-base 40 + 1 byte-load
Another option would be to remove the first 0x40 bytes. #266

After executing the ROM, undo some stuff #270 :
Code:
unselect-dev \ This should be all that is needed
device-end \ but we do this to be sure
0 to my-self \ and we do this too, just to be sure

PCI ROM Flashing​

After creating a ROM and testing it using file loading or emulator, you'll want to flash the ROM to the PCI card. A PCI card's ROM chip has a maximum size #141 #142 #165 . It might be 64K or 128K. A 128K ROM chip may allow both a BIOS and Open Firmware image. Some Nvidia ROM patchers require the first ROM image to be a BIOS image. See DumpPCIRom.sh above for a method to combine ROM images.

Testing ROMs in Open Firmware​

After doing the file loading method for testing ROMs, you will eventually want to test the ROM flashed to the PCI card. When Open Firmware starts, it initializes the Open Firmware dictionary and device-tree, executes the contents of nvramrc, then probe-all, install-console, banner in that order. The order can be changed (see #80 ). probe-all is when the ROM is executed. Any output emitted by the ROM is buffered and will not appear until install-console happens. I don't know what the limit is for buffered output #175 so it would be best to not have it buffered - make the output happen as the ROM is being executed. Add the following to nvramrc:
Code:
install-console
probe-all
banner
For Open Firmware 2.4, install-console in the nvramrc should be changed to (install-console) #123 #129 #178

Testing Display Output in Open Firmware​

While using telnet or serial, you can open a display device in Open Firmware and draw to the display.

For Open Firmware 2.x, draw color bars to screen without changing output #120 #191 :
Code:
screen open-dev drop
dev screen
10 0 do i i 28 * 0 28 d# 480 fill-rectangle loop
 
Last edited:
Radeon 9200 is about the best you can do. That's the card I typically put in my "hot" beige builds. It works fine in all PCI Macs.

Core Image compatible GPUs won't work in Old World ROM systems, so cards like the Geforce 5200 and 6200 are off limits(not that either is a great idea with as congested as the PCI bus is).

Mac edition Radeon 9200s have gotten a bit hard to find and expensive...

Other good cards:

Rage 128(actually not that great, but better than the onboard graphics and has VGA)
Radeon 7000(fairly easy to find)
ATI Radeon
Radeon 7500

I'm drawing a blank at the moment on other OWR-compatible PCI cards aside from ones like what shipped in the 9500/9600, which are inferior to the Rage 3D onboard the G3.
 
Radeon 9200 is about the best you can do. That's the card I typically put in my "hot" beige builds. It works fine in all PCI Macs.

Core Image compatible GPUs won't work in Old World ROM systems, so cards like the Geforce 5200 and 6200 are off limits(not that either is a great idea with as congested as the PCI bus is).

Mac edition Radeon 9200s have gotten a bit hard to find and expensive...

Other good cards:

Rage 128(actually not that great, but better than the onboard graphics and has VGA)
Radeon 7000(fairly easy to find)
ATI Radeon
Radeon 7500

I'm drawing a blank at the moment on other OWR-compatible PCI cards aside from ones like what shipped in the 9500/9600, which are inferior to the Rage 3D onboard the G3.
would a radeon 9250 be able to be flashed for these machines? those were all over the place last i checked
 
would a radeon 9250 be able to be flashed for these machines? those were all over the place last i checked
Dunno about a 9250 but I flashed a 9200 PCI and there are two things to consider: You will have to do some soldering of the resistors to make the card Mac compatible and you stand to lose half of your VRAM as Macs are picky about all sorts of RAM. The flashed card worked well in my 9600 otherwise.
 
No way to get this to work? Not even with the CPU swapped for a G4?

I'm not aware of any way, and I have some decently well upgraded beiges I'd have done this on long ago if possible.

@LightBulbFun or @Intell would have the details as to why.

There aren't exactly a ton of PCI cards that will support CI in any case. I have an FX5200 kicking around that worked fine for me, but there's been some discussion also that even on computers like the B&W G3 you can still run into bus congestion issues especially with a 6200.

Some people even discourage enabling QE on compatible PCI cards out of the same concerns. Funny enough, if you install something like a Radeon 9200, you have to enable QE manually. If you fit a CI card, both CI and QE are enabled by default.
 
  • Like
Reactions: flyproductions
I'm not aware of any way, and I have some decently well upgraded beiges I'd have done this on long ago if possible.

@LightBulbFun or @Intell would have the details as to why.

There aren't exactly a ton of PCI cards that will support CI in any case. I have an FX5200 kicking around that worked fine for me, but there's been some discussion also that even on computers like the B&W G3 you can still run into bus congestion issues especially with a 6200.

Some people even discourage enabling QE on compatible PCI cards out of the same concerns. Funny enough, if you install something like a Radeon 9200, you have to enable QE manually. If you fit a CI card, both CI and QE are enabled by default.
Thanks for your quick reply to this old thread! 👍

I have a nice PNY GeForce 6200 PCI, flashed and working fine in G4 towers. But no signal to the display in the beige. CPU is upgraded to G4 400 , pulled of a tower, running smoothly at 433.

What exactly does "bus congestion" mean?

Edit: I managed to boot 10.4.11 to the desktop with the display connected to some HERCULES Radeon 9000 pro and the 6200 sitting in one of the other PCIs. But the card is not even seen by System Profiler.
 
Last edited:
If I remember correctly, CoreImage cards like the GeForce 5200 cannot work in OldWorld Macs like the beige G3 because of an incompatibility between the card's ROM and OpenFirmware. This makes the PCI ATI 9200 the most powerful video card an OldWorld Mac can use.

PCI bus congestion means that the PCI bus (like lanes on a road) are full or crowded (lots of cars and traffic). This can cause things such as overall slower performance for devices connected to the PCI bus, instability, or in rare cases cards to not be seen at all.
 
If I remember correctly, CoreImage cards like the GeForce 5200 cannot work in OldWorld Macs like the beige G3 because of an incompatibility between the card's ROM and OpenFirmware.
Thanks for your reply too! Sad story. So the old world macs use some other version of OF than the B&W or G4 towers?
This makes the PCI ATI 9200 the most powerful video card an OldWorld Mac can use.
I have a somehow exotic 9000 PRO pci from HERCULES, which runs fine in the beige. Shouldn't this be "better" than the 9200, as the 9000 PRO/8500 AGP where mostely seen as "stronger" than the 9200?
 
Thanks for your reply too! Sad story. So the old world macs use some other version of OF than the B&W or G4 towers?

I have a somehow exotic 9000 PRO pci from HERCULES, which runs fine in the beige. Shouldn't this be "better" than the 9200, as the 9000 PRO/8500 AGP where mostely seen as "stronger" than the 9200?

all New world Macs run OpenFirmware 3 or later

but Old world Macs run OpenFirmware 1.x or 2.x depending on exactly which Beige mac is being talked about

and these old OpenFirmware implementations lack the necessary words that the GeForce ROM's uses

I have heard that the OpenFirmware 2.4 implementation of the Rev C G3 beige was able to partly enumerate a GeForce FX 5200, but I have never been to verify these claims myself or have them verified by someone else
 
I have heard that the OpenFirmware 2.4 implementation of the Rev C G3 beige was able to partly enumerate a GeForce FX 5200, but I have never been to verify these claims myself or have them verified by someone else
Thanx for your reply too!

My board seems to be Rev C. At least the graphics chip has "Rage Pro Turbo" printed on it.

Also i googeled across this guy, claiming to have just my card, a GF 6200 with 256 Mb of vram running in a beige upgraded with a G4 533. But, as this was the only mentioning of a configuration like this, i do not know, if it is just fake.

One more question:
You mentioned some OF-command to completely erase the entry for the onboard graphics from the PCI-list in some other thread. i would really do this too, as the onboard seems to constantly causing irritation when booting to tiger and i don't need it at all. But i don't know if i got the steps to go right and don't want to do any harm. So could you give a dummy-explanation of the process?

Thanks in advance!

Edit:
Fond the thread/comment again, but am not sure if i relly get it right.

"so I brute force disabled it using " " delete-property (example: dev /pci/ATY,mach64_3DUPro [eneter] " name" delete-property [enter]."

So has the name to be followed by the command or just the other way around? I. e. for deleting ATY,mach64_3DUPro would the right command be

dev /pci/ATY,mach64_3DUPro delete-property [enter]

or

delete-property dev /pci/ATY,mach64_3DUPro [enter]

Edit 2: I get a Stack Underflow! error for both of them ☹️
 
Last edited:
I also have an ELSA Gladiac 511 GeForce 2MX PCI, which also works fine in the beige. But sadly only has VGA output. And Dual Displays does not work. 😕
That would be a first, sadly it's slower that the Radeons and doesn't support Core Image.

I've been thinking of a work-a-round for the Beige G3's and other Old World Mac's, if we just build all the properties the FCode ROM builds the Nvidia Resource Manager Extension in OS X should make the card work, it just would not work for boot video, it would only start working when the desktop loads.

Arti Itra was able to get a GF5200 to work in a Beige G3 to boot into Open Firmware, but it would not boot into Mac OS X. I'm unsure what ROM rev. he had on his Beige G3 or exactly how he did it, but I think he just defined a few words as colon definitions in OF.

If you detok the nVidia FCode ROM's you can see all the words they use such as config-l! then use the see command in OF to see if your version of OF has that word in the dictionary. If it doesn't you get a default-catch! and the FCode ROM stops there.

Sadly Apple's implementation of OF does not include fcdoe-verbose?, as that is the true way to debug this.

If anyone wants to donate a Geforce 6200 PCI to the pot chances are with a little help from @joevt and others we maybe able to get the card to work to output video under OS X.

The main trouble is these old versions of OF have a unique way of loading a command script that I have not figured out yet, and I really need to be able to populate the .properties using a floppy based script because it's just too many properties to manually type into OF each boot.
 
That would be a first, sadly it's slower that the Radeons and doesn't support Core Image.
...and it seems to have died on the shelf! 😥
Today i wanted to test it again and it doesn't boot to the desktop anymore. In none of my machines. Not even the G4 towers. Shows the grey screen with the Apple logo and spins the wheel. But as soon as it should boot the system, screen turns black.

Also, if i boot the machine with some other card with the ELSA in it, System Info shows the card, but doesn't see the vram size anymore.
Arti Itra was able to get a GF5200 to work in a Beige G3 to boot into Open Firmware, but it would not boot into Mac OS X. I'm unsure what ROM rev. he had on his Beige G3 or exactly how he did it, but I think he just defined a few words as colon definitions in OF.
Yes, Arti! The one the credits for all the Mac roms for PPC cards belong to.
If you detok the nVidia FCode ROM's you can see all the words they use such as config-l! then use the see command in OF to see if your version of OF has that word in the dictionary. If it doesn't you get a default-catch! and the FCode ROM stops there.

Sadly Apple's implementation of OF does not include fcdoe-verbose?, as that is the true way to debug this.
All this seems far beyond my knowledge. 😟
If only i could permanently remove the onboard video of OF, which constantly gets in the way.
If anyone wants to donate a Geforce 6200 PCI to the pot chances are with a little help from @joevt and others we maybe able to get the card to work to output video under OS X.
This one here is part of my "collection". But i'll have a look on ebay, to see if one appears again. Gettin kind of rare these days.

I don't know if this is of any help. But at least every now and then the card appears in system info. Also can bes selected in XPostFacto as output device. But - ofcourse - shows no picture when trying to boot it.

system_info.png
 
If only i could permanently remove the onboard video of OF, which constantly gets in the way.
The pci-probe-list is your friend, but none of us ever figured what bit was the builtin video for the Beige G3. Without a good way to load the defaults in Open Firmware on these Old World machines it's a dodgy hack, because we'd need to use trial and error until we found the proper bit, and that would end up disabling devices we did not want to disable.

Code:
setenv pci-probe-list 0x0fffffff
setenv pci-probe-list 0xf0ffffff
setenv pci-probe-list 0xff0fffff
setenv pci-probe-list 0xfff0ffff
setenv pci-probe-list 0xffff0fff
setenv pci-probe-list 0xfffff0ff
setenv pci-probe-list 0xffffff0f
setenv pci-probe-list 0xfffffff0

One of those will disable the builtin video, but it will also like disable 3 other PCI devices, once you find the one that disables built in video, then you enable the other bits until you find the bit that is the builtin video, but having to wait for the NVRAM to discharge between each command that renders the machine unbootable isn't really something I feel like doing, too time consuming.
 
The pci-probe-list is your friend, but none of us ever figured what bit was the builtin video for the Beige G3. Without a good way to load the defaults in Open Firmware on these Old World machines it's a dodgy hack, because we'd need to use trial and error until we found the proper bit, and that would end up disabling devices we did not want to disable.

Code:
setenv pci-probe-list 0x0fffffff
setenv pci-probe-list 0xf0ffffff
setenv pci-probe-list 0xff0fffff
setenv pci-probe-list 0xfff0ffff
setenv pci-probe-list 0xffff0fff
setenv pci-probe-list 0xfffff0ff
setenv pci-probe-list 0xffffff0f
setenv pci-probe-list 0xfffffff0

One of those will disable the builtin video, but it will also like disable 3 other PCI devices, once you find the one that disables built in video, then you enable the other bits until you find the bit that is the builtin video, but having to wait for the NVRAM to discharge between each command that renders the machine unbootable isn't really something I feel like doing, too time consuming.
The Beige G3 seems to completely ignore the pci-probe-list command. That would likely be the reason no one ever was successful in disabling the built-in video.

I found an old post by @joevt where he said "the Beige G3 doesn't refer to pci-probe-list by name"

I just don't think the command is enabled in OF 2.x.x?
 
The Beige G3 seems to completely ignore the pci-probe-list command. That would likely be the reason no one ever was successful in disabling the built-in video.
Yes. But the most commonly suggestet command to "disable" the onboard is "setenv pci-probe-list fffbffff". Would that be the case, if no one ever had success with it? Anyway, for me it didn't do anything. As it did for @LightBulbFun. But he claims to have had success by deleting all the properties of the device, n this case ATY,mach64_3DUPro. I tried this too. But also with no success. But maybe i was just doing it wrong. What i did was...

dev /pci/ATY,mach64_3DUPro [enter]
" " delete-property [enter]

...as mentioned, with no success at all.

What else came to my mind: Isn't it possible to not disable the particular device but completely deactivate/hide PCI F1 by OF as this can and will never be used for anything else but stupid onboard video, which i will never ever neeed.

By the way: My machine is definitely Rev. C, OF-version is 2.4.
 
Last edited:
I just don't think the command is enabled in OF 2.x.x?
For Beige G3's, I think pci-probe-list works in "Open Firmware, 2.4" but not "Open Firmware, 2.0f1" or I can't find how pci-probe-list gets used in 2.0f1.

What Beige G3's have 2.0 and what Beige G3's have 2.4?

I suppose one could create a probe-slot patch if nothing else works.
 
Slot F1 where the ATY,mach64_3DUPro is located is PCI device number 0x12, interrupts 0x16.
In Open Firmware 2.4, the device number appears to be used for the bit number to test in the pci-probe-list variable. This is only true for the 5 probed slots.
Code:
    0c 1c                   -1 ?probe-slot \ 0c = PERCH
    12 16                   -1 ?probe-slot \ 12 = F1
    0d 17 prsntbits      3 and ?probe-slot \ 0d = A1
    0e 18 prsntbits 2 >> 3 and ?probe-slot \ 0e = B1
    0f 19 prsntbits 4 >> 3 and ?probe-slot \ 0f = C1
Open Firmware 2.0f1 has the same 5 probed slots but it does PCI device number 0x12 last.

So setting pci-probe-list to fffbffff should disable PCI device number 0x12, at least in Open Firmware 2.4.

dev /pci/ATY,mach64_3DUPro [enter]
" " delete-property [enter]
Did you delete all the properties or some of them?
Code:
0 > dev /pci/ATY,mach64_3DUPro ok
0 > " vendor-id" delete-property  ok
0 > " device-id" delete-property  ok
0 > " class-code" delete-property  ok
0 > " name" delete-property  ok
.properties
I don't know if you need to delete any properties or all the properties.
 
Last edited:
  • Like
Reactions: flyproductions
So setting pci-probe-list to fffbffff should disable PCI device number 0x12, at least in Open Firmware 2.4.
So this "should" work for me, as i, for sure, do have 2.4. Machine originally was G3/300 Desktop. Don't know what i'm messing up.
Did you delete all the properties or some of them?
Code:
0 > dev /pci/ATY,mach64_3DUPro ok
0 > " vendor-id" delete-property  ok
0 > " device-id" delete-property  ok
0 > " class-code" delete-property  ok
0 > " name" delete-property  ok
.properties
I don't know if you need to delete any properties or all the properties.
I was just copying what i read somewhere @LightBulbFun did. But maybe i was just doing it wrong, as i sadly just know nothing of the OF-syntax. So my thinking was, just a blank between the quotes deletes them all. Also i ended "device-end" (without the quotes) instead of ".properties" and did not put the "0 >" at the beginning of each line.

I think, i'lll give the setenv-comand another try.
 
Last edited:
For Beige G3's, I think pci-probe-list works in "Open Firmware, 2.4" but not "Open Firmware, 2.0f1" or I can't find how pci-probe-list gets used in 2.0f1.
Don't know what i did wrong before, but now the pci-probe-list command with fffbffff worked! No video from the onboard anymore and also F1 does not appear in system profiler anymore. At least in OS 9. Will check X later.

For the moment, thanks!

Edit: For OS X it is there again! 😟 Has this to be done for every reboot? I there any permanent way?

Edit 2: I can reboot to OS 9 with the onboard video / PCI F1 still gone. But as soon as i use XPostFacto to boot to OS X, it reappears.
 
Last edited:
dev /pci/ATY,mach64_3DUPro [enter]
" " delete-property [enter]
you need to put a property between the quotes that you wish to delete, you cant just leave it blank, I just systematically went through and nuked everything LOL

but I do believe there is a way to just nuke the entire node in one go rather then individually nuke each property, see post 2 in the link bellow


you could also try and lookup the pinout of the Rage video chip and see if theres a Chip enable pin you can lift up and insert a switch in-between for enabling/disabling
 
Thanks again!
Inbetween i had partial success with the pci-probe-list command editing into the nvram via nvedit. Was a bit more permanent over several reboots and in OS X the onboard video was gone too. But as soon as i swapped a vid card or in any way touched XPostFacto’s OF-settings, it was there again. So still far from optimal.
but I do believe there is a way to just nuke the entire node in one go rather then individually nuke each property, see post 2 in the link bellow

Had a look at it. So to delete PCI F1, command has to be " /pci@12000000/mac-io"... right?
you could also try and lookup the pinout of the Rage video chip and see if theres a Chip enable pin you can lift up and insert a switch in-between for enabling/disabling
Yes, a hardware solution, even a permanent one, would be favourable. I can not imagine ever to make use of this sh*tty onboard graphics in any way.
 
I was just copying what i read somewhere @LightBulbFun did. But maybe i was just doing it wrong, as i sadly just know nothing of the OF-syntax. So my thinking was, just a blank between the quotes deletes them all. Also i ended "device-end" (without the quotes) instead of ".properties" and did not put the "0 >" at the beginning of each line.
The 0 > is the Open Firmware prompt, like joevt@Joes-Mac-Pro ~ % is the prompt in Terminal.app in macOS. Don't type the prompt part. Also don't type the ok response.
.properties is a command to list the properties of the currently selected device. Use the list to decide what properties you want to delete.

Maybe when booting using XPostFacto, you should examine the nvramrc script to see if it has anything. Also check the pci-probe-list to see if it still has the value you want.

So to delete PCI F1, command has to be " /pci@12000000/mac-io"... right?
You need to change /pci@12000000/mac-io to the path of the device you want to delete.
This should work:
screen find-package drop delete-node
if devalias shows that screen points to the correct device /pci@80000000/ATY,mach64_3DUPro@12

Open Firmware 1.0.5 doesn't have a delete-node command. Neither does 2.0f1 or 2.4. I suppose delete-node is a requirement for Macs that have USB where devices can be hot-plugged - removed and connected while the computer is on?

To make your own delete-node command, I suppose you need to know how the device tree exists in the dictionary - a series of linked device nodes where each node has a pointer to parent and first or last child (I didn't check which) and next sibling and previous sibling. For Open Firmware 2.4 (PowerMac G3) and Open Firmware 4 (PowerMac Quad G5), the fields of a device node are named:
Code:
>dn.check
>dn.parent
>dn.child
>dn.peer-nxt
>dn.peer-bak
>dn.properties-hd
>dn.properties-tl
>dn.methods
>dn.instance-offset
>dn.instance-bfr-ptr
>dn.#acells
>dn.#scells
>dn.assd-addrs
>dn.probe-addr
Guessing sibling = peer. next = nxt. previous = back = bak.
First child is one with no >dn.peer-bak
Last child is one with no >dn.peer-nxt
I don't know if dev / ls outputs first child first or last child first.

At first guess, at a minimum, to delete a device node, you need to adjust >dn.peer-nxt of device-node >dn.peer-bak and >dn.peer-bak of device node >dn.peer-nxt. If there's no >dn.peer-nxt or no >dn.peer-bak then you will need to adjust >dn.child of device node >dn.parent depending on whether >dn.child of device node >dn.parent points to the device-node to be deleted.

The following code can dump fields of a device node or instance or startvec. It is specific to Open Firmware 2.4. The FCode numbers need to be changed for other versions of Open Firmware. This will not work for versions of Open Firmware that hide the names of the fields.
Code:
: dump-fields { addr fcodestart fcodeend ; token }
    cr
    fcodeend 1+ fcodestart do
        i ." 0x" 3 u.r space
        i get-token drop -> token
        0 token execute 4 u.r space
        addr token execute dup 8 u.r space
        token name.
        #out @ d# 42 < if d# 42 #out @ - spaces then
        @ dup 8 u.r space
        \ check if the field might point to a xt token and if so, output its name
        dup @startvec u> if
            dup dup xt>hdr 4+ dup c@ + 8 + -8 and = if name. else drop then
        else
            drop
        then
        cr
    loop
;

: dump-startvec
    \ Dump all fields of @startvec
    @startvec 488 4d5 dump-fields ;

: dump-device ( phandle )
    \ Dump all fields of a device node
    516 523 dump-fields ;

: dump-instance ( ihandle )
    \ Dump all fields of an instance node
    525 529 dump-fields ;

dump-startvec
 
Last edited:
  • Like
Reactions: flyproductions
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.