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.

DearthnVader

Suspended
Original poster
Dec 17, 2015
2,207
6,399
Red Springs, NC
This Wiki thread is to discuss info and experimentation of all the PCI* PowerMacs.

I'll start with saying the PCI-X G5's have two 64bit 3.3v 100Mhz PCI-X Slots and one 133Mhz slot. The PCI-X standard allows backwards compatibility with PCI 2.0 or better cards only and they should function at 66mHz only.

What I do not know is if the three PCI-X slots are segmented by bridge chips, if they are not then the PCI-X slots will function at the speed of the slowest device. One would assume that at least the 133Mhz slot is segregated so as the 100Mhz slots do not slow it down.

One would hope the two 100Mhz slots are also segregated so we could use a 32bit 66Mhz card in one slot and not slow the other.
 
So @joevt @LightBulbFun and I have been trying to test PCI to PCI-E adapters in some Powermacs with some PCI-E cards with a verity of results.

For me in my Beige G3 a LSI 4x PCI-E SAS controller does seem to work as far as OF and the Fcode building the proper .properties for the card. However Mac OS 9 does not seem to be compatible with the PCI to PCI-E bridge and booting halts with a Bus Error on the Mac OS splash screen. This is with or without a PCI-E card in the bridge.

This does not come as a shock to me, OS 9 doesn't know anything about PCI-E bridges and is having issues with it.

Any video card in the PCI-E bridge in the Beige just results in disabling PCI to the point I can't boot OF or the Mac OS ROM with the built-in video of the Beige. I just never get single to the monitor and I'll be doing some further debugging over serial.

On a QuickSilver G4 with this bridge and the SAS card, OF seems to deal with it just fine, but Mac OS X keeps complaining about the watchdog timer for the USB bus being dead and booting either halts or a get a kernel panic with Tiger.

I need to update the LSI driver kext in Tiger from the one in Leopard as it's too old for my LSI cards.

A PC Flashed X1950 XT does show video in the setup in the QS but I have not tried to boot OS X yet.

The MDD G4 can boot Mac OS X Leopard's installer with the SAS card installed, but again I get kernel messages about the watchdog timer for the USB bus being dead, and USB seems to get disabled of only partially functional so I have no input device to start debugging the issue at the OS X level.

X1950 XT video card untested in the MDD.
 
I'll start with saying the PCI-X G5's have two 64bit 3.3v 100Mhz PCI-X Slots and one 133Mhz slot. The PCI-X standard allows backwards compatibility with PCI 2.0 or better cards only and they should function at 66mHz only.
"PCI-X Addendum to the PCI Local Bus Specification" seems to indicate that 33MHz is an option for PCI cards in PCI-X slot. The only requirement is that the PCI card supports 3.3V. A PCI card that doesn't support 3.3V won't fit in a PCI-X slot (unless it's inserted incorrectly).

"Service Source" for "Power Mac G5, Power Mac G5 (June 2004), Power Mac G5 (Early 2005)" says that all the PCI-X slots support 33 MHz. Or maybe it's referring to only the PCI (not PCI-X) Power Mac G5 models...
It says "Computers with four DIMM slots have 33 MHz PCI slots and cannot use PCI-X cards; computers with eight DIMM slots can accommodate 100 and 133 MHz PCI-X cards. See the chart below."
It doesn't say that computers that can accommodate 100 and 133 MHz PCI-X cards cannot also accommodate 33 MHz PCI cards.

What I do not know is if the three PCI-X slots are segmented by bridge chips, if they are not then the PCI-X slots will function at the speed of the slowest device. One would assume that at least the 133Mhz slot is segregated so as the 100Mhz slots do not slow it down.

One would hope the two 100Mhz slots are also segregated so we could use a 32bit 66Mhz card in one slot and not slow the other.
You have to check which PCI host controller listed in the Open Firmware device tree is used for each slot.

For me in my Beige G3 a LSI 4x PCI-E SAS controller does seem to work as far as OF and the Fcode building the proper .properties for the card. However Mac OS 9 does not seem to be compatible with the PCI to PCI-E bridge and booting halts with a Bus Error on the Mac OS splash screen. This is with or without a PCI-E card in the bridge.

This does not come as a shock to me, OS 9 doesn't know anything about PCI-E bridges and is having issues with it.
The PCIe bridge looks like a normal PCI bridge so it should work with Mac OS 9 just as it does in Open Firmware. The Sonnet Tempo Trio has a PCI bridge to support multiple PCI devices and it works fine in Mac OS 9 in my Power Mac 8600.

A B&W G3 with the PCI-PCIe bridge boots Mac 0S 9.2.2. Apple System Profiler doesn't show PCI devices behind a PCI bridge so you have to use a different utility such as "Display Name Registry". Display Name Registry 2.0 exists in the CardBus DDK and an earlier version exists in the PCI DDK. The PCCard SDKs (predecessor to CardBus DDK) has source code.

The MDD G4 can boot Mac OS X Leopard's installer with the SAS card installed, but again I get kernel messages about the watchdog timer for the USB bus being dead, and USB seems to get disabled of only partially functional so I have no input device to start debugging the issue at the OS X level.
Use screen sharing if the USB doesn't work?

Is the SAS card taking too much bandwidth for the USB driver? Is there a way to disable the watchdog or increase its timeout? Maybe check kernel sources.
 
"PCI-X Addendum to the PCI Local Bus Specification" seems to indicate that 33MHz is an option for PCI cards in PCI-X slot. The only requirement is that the PCI card supports 3.3V. A PCI card that doesn't support 3.3V won't fit in a PCI-X slot (unless it's inserted incorrectly).

"Service Source" for "Power Mac G5, Power Mac G5 (June 2004), Power Mac G5 (Early 2005)" says that all the PCI-X slots support 33 MHz. Or maybe it's referring to only the PCI (not PCI-X) Power Mac G5 models...
It says "Computers with four DIMM slots have 33 MHz PCI slots and cannot use PCI-X cards; computers with eight DIMM slots can accommodate 100 and 133 MHz PCI-X cards. See the chart below."
It doesn't say that computers that can accommodate 100 and 133 MHz PCI-X cards cannot also accommodate 33 MHz PCI cards.
Ok, I read something that said PCI-X can only do 66MHz when dealing with PCI cards, that info must have been wrong, but I ran with it anyway.

You'd think I'd learn about things you read on the internet.

Anyway, I thought I'd ask ChatGPT for the fun of it, because I really want to know if 66MHz compatible PCI cards will run at 266MB/s in a PCI-X slot:

Code:
what speed does a PCI 2.0 card run in a PCI-X slot

ChatGPT
PCI 2.0 (also known as PCIe 2.0) and PCI-X are different standards, and they are not directly compatible with each other. Here’s a breakdown of their differences and compatibility:

PCIe 2.0 (PCI Express 2.0)
Data Transfer Rate: 500 MB/s per lane (x1 link), up to 16 GB/s in a x32 configuration.
Slots and Connectors: PCIe slots come in various sizes like x1, x4, x8, x16, etc.
Generation: PCIe 2.0 is a second-generation PCIe standard.
PCI-X (PCI Extended)
Data Transfer Rate: Up to 1.06 GB/s in its fastest version (PCI-X 133 MHz).
Slots and Connectors: Uses a parallel interface with different slot configurations compared to PCIe.
Generation: An enhancement to the older PCI standard (not PCIe).
Compatibility and Performance
Physical and Electrical Compatibility: PCIe 2.0 cards cannot be directly inserted into PCI-X slots due to differences in the physical interface and electrical signaling.
Performance: Since PCIe and PCI-X are not compatible, a PCIe 2.0 card cannot operate in a PCI-X slot, and therefore, it will not function at all, meaning no speed or performance can be realized in this configuration.
If you need to use a PCIe card in a PCI-X slot, you would need a specific adapter or riser card, if one is available and compatible, but performance and functionality cannot be guaranteed.

Alternative Solutions
To use a PCIe card in a system that only has PCI-X slots, consider the following options:

Motherboard Upgrade: Upgrade to a motherboard with PCIe slots.
Adapter/Riser Cards: Look for an adapter that might convert PCI-X to PCIe, though this is uncommon and may not provide the best performance or compatibility.
New System: If the requirement for PCIe is critical, consider upgrading to a more modern system that natively supports PCIe slots.
In summary, a PCIe 2.0 card cannot run in a PCI-X slot as they are incompatible both physically and electrically.
Not PCIe just PCI

ChatGPT
If you have a standard PCI card (not PCIe) and you want to use it in a PCI-X slot, the situation is a bit different. PCI-X slots are designed to be backward compatible with standard PCI cards. Here's how it works:

PCI (Conventional PCI)
Data Transfer Rate: Up to 133 MB/s for 32-bit 33 MHz, up to 533 MB/s for 64-bit 66 MHz.
Slots and Connectors: Standard PCI slots have a specific design that accommodates 32-bit and 64-bit cards.
PCI-X (PCI Extended)
Data Transfer Rate: Up to 1.06 GB/s for 64-bit 133 MHz.
Slots and Connectors: PCI-X slots are designed to be longer and can accommodate both 32-bit and 64-bit PCI cards.
Compatibility and Performance
Physical Compatibility: A standard PCI card can be inserted into a PCI-X slot. PCI-X slots are designed to accept both 32-bit and 64-bit PCI cards.
Performance: When a standard PCI card is used in a PCI-X slot, the card will operate at the PCI speed and not the enhanced PCI-X speed. This means a PCI 2.0 card will run at its native speed, which could be up to 133 MB/s, depending on its specifications.
Key Points
Backward Compatibility: PCI-X slots are backward compatible with standard PCI cards.
Operation Speed: A PCI 2.0 card will run at its own designed speed when placed in a PCI-X slot, not benefiting from the higher speeds PCI-X can offer to native PCI-X cards.
Therefore, a PCI 2.0 card running in a PCI-X slot will operate at the standard PCI speeds (up to 133 MB/s for a 32-bit 33 MHz PCI card). This backward compatibility allows older PCI cards to be used in systems with PCI-X slots without any issues regarding speed or functionality beyond the card's native capabilities.
What if the PCI card is 66 MHz compatible ?

ChatGPT
If the PCI card is 66 MHz compatible, it means it can operate at higher speeds compared to the standard 33 MHz PCI cards. Here’s a detailed breakdown:

PCI (Conventional PCI) with 66 MHz Compatibility
Data Transfer Rate:
32-bit, 33 MHz PCI: Up to 133 MB/s.
32-bit, 66 MHz PCI: Up to 266 MB/s.
64-bit, 66 MHz PCI: Up to 533 MB/s.
PCI-X (PCI Extended)
Data Transfer Rate:
64-bit, 66 MHz PCI-X: Up to 533 MB/s.
64-bit, 100 MHz PCI-X: Up to 800 MB/s.
64-bit, 133 MHz PCI-X: Up to 1.06 GB/s.
Compatibility and Performance for 66 MHz PCI Card in a PCI-X Slot
Physical Compatibility: A 66 MHz PCI card can be inserted into a PCI-X slot. PCI-X slots are designed to accept both 32-bit and 64-bit PCI cards, whether they run at 33 MHz or 66 MHz.
Operational Speed: The PCI card will operate at its maximum supported speed (66 MHz) when inserted into a PCI-X slot, assuming the slot and the motherboard support that speed.
Key Points:
Backward Compatibility: PCI-X slots are backward compatible with standard PCI cards, including those that operate at 66 MHz.
Speed: A 66 MHz PCI card will run at its designed speed of 66 MHz in a PCI-X slot. For a 32-bit card, this means up to 266 MB/s. For a 64-bit card, this means up to 533 MB/s.
System Configuration: The actual speed may also depend on the motherboard's configuration and whether other slower PCI devices are sharing the same bus, as mixing 33 MHz and 66 MHz devices might cause all devices to operate at the lower speed.
Example Scenario:
32-bit, 66 MHz PCI Card in a PCI-X slot will operate at up to 266 MB/s.
64-bit, 66 MHz PCI Card in a PCI-X slot will operate at up to 533 MB/s, if the slot and system support it.
Conclusion:
A PCI card that is 66 MHz compatible will run at its maximum speed (66 MHz) when inserted into a PCI-X slot, taking advantage of the backward compatibility designed into the PCI-X standard. This allows for enhanced performance compared to standard 33 MHz PCI cards, but still within the limits of the card's own specifications.
 
When I run ThroughPut 1.5 in Mac OS 9 in my B&W G3, I only get 111 MB/s using AltiVec. It's a 66 MHz slot and the Radeon 9200 is supposed to support 66 MHz.
ThroughPut incorrectly calculates MB/s by dividing by 1048576 so 111 MB/s is actually 116 MB/s.

One of the examples has a Power Mac 8500 doing only 40 MB/s.
Another example has an 2x AGP Mac doing only 155.1 MB/s.

So maybe ThroughPut isn't very efficient or PCI has more overhead than I thought. Well, ThroughPut documentation says it moves data from RAM so that might add some overhead. If you want to test PCI speed, rather than RAM to PCI speed, then you would probably just load some CPU registers once and time how long it takes to write those registers to PCI. That would measure the PCI write speed. Then you could measure the PCI read speed by just reading from PCI into some CPU registers.
 
When I run ThroughPut 1.5 in Mac OS 9 in my B&W G3, I only get 111 MB/s using AltiVec. It's a 66 MHz slot and the Radeon 9200 is supposed to support 66 MHz.
ThroughPut incorrectly calculates MB/s by dividing by 1048576 so 111 MB/s is actually 116 MB/s.

One of the examples has a Power Mac 8500 doing only 40 MB/s.
Another example has an 2x AGP Mac doing only 155.1 MB/s.

So maybe ThroughPut isn't very efficient or PCI has more overhead than I thought. Well, ThroughPut documentation says it moves data from RAM so that might add some overhead. If you want to test PCI speed, rather than RAM to PCI speed, then you would probably just load some CPU registers once and time how long it takes to write those registers to PCI. That would measure the PCI write speed. Then you could measure the PCI read speed by just reading from PCI into some CPU registers.
I get crazy speeds on my G4 iBook under OS 9 with the R9200 AGP, and SheepShaver gets ridiculous speeds, but none of them exceed the speed of the bus, ram, or vram.

Sheep shaver is just partitioning some systems RAM as VRAM, so it's really just a RAM to RAM copy.

Disk to RAM of disk to VRAM would be a bit better of a real world test, but mostly it scales about the way we would expect. The Old World systems were so limited by the slow 60ns EDO RAM.

Even tho here is what ChatGPT says about 60ns VRAM:

o calculate the speed in MB/s of 60ns EDO RAM, we need to determine the data transfer rate. EDO (Extended Data Out) RAM typically transfers data in bursts, which increases its efficiency compared to standard DRAM.

The calculation involves the following steps:

  1. Determine the Cycle Time:
    • The cycle time for 60ns (nanoseconds) is 60ns.
  2. Convert Cycle Time to Seconds:
    • 60 nanoseconds = 60×10−960×10−9 seconds.
  3. Calculate the Number of Cycles Per Second:
    • Cycles per second=160×10−9=160×109≈16.67×106Cycles per second=60×10−91=601×109≈16.67×106 cycles per second (or 16.67 MHz).
  4. Data Transfer per Cycle:
    • EDO RAM transfers 64 bits (8 bytes) per cycle.
  5. Calculate the Data Transfer Rate in Bytes per Second:
    • Data transfer rate=16.67×106 cycles/second×8 bytes/cycleData transfer rate=16.67×106cycles/second×8bytes/cycle.
    • Data transfer rate=133.33×106 bytes/secondData transfer rate=133.33×106bytes/second.
  6. Convert Bytes per Second to Megabytes per Second (MB/s):
    • 133.33×106 bytes/second÷106=133.33 MB/s133.33×106bytes/second÷106=133.33MB/s.
So, the speed of 60ns EDO RAM is approximately 133.33 MB/s.

So maybe it was HammerHead and the PCI BUS in the Old World that was so slow.

I've often wondered if we could use 50ns EDO RAM and clock chip the FFO in the 8600/9600 to get a little more speed out of the RAM, but maybe that wouldn't do much good as the RAM may not be the bottleneck. I just always assumed it was because of Gage Pro's Moving Memory Rate.

Isn't there a 16.67MHz fixed frequency oscillator in the Old World PCI Mac's that governs the speed of the RAM?

Maybe bumping that to 20MHz would allow for 50ns RAM?
 
Ok so we can test our GF6200 PCI in slot 2 or 3 and the LSI card in the other 100Mhz slot. If disks speeds drop below the 133MB/s we'll know the GF6200 is operating at 33MHz and forcing the LSI card to 33MHz operation.

Or we can just look at the IOReg and see what that reports for frequency.
 
I got the PCI-E LSI SAS controller working in the Beige G3. It's no speed demon, but it does work.

Peak speeds around 60MB/s, so no better than the SiL3112.

But it does have more ports, tho it completely lacks in Classic Mac OS support.

Not sure if the GF6200 having QE enabled it slowing other devices on the PCI bus, but it likely is.
 
Ok, I did a few tests with the PCI-X 100Mhz slots and a few cards. First my PCI to PCI-E bridge is 66MHz compatible and with the GF6600 in it, the slot reported 66Mhz clock-frequency.

The GF6200 PCI, even tho it is 66MHz compatible, the slot only reported 33Mhz mode.

The SiL3112, the slot reported 66Mhz mode.

I wonder why the 6200 didn't want to do 66MHz mode in a PCI-X slot?
 
Ok, I did a few tests with the PCI-X 100Mhz slots and a few cards. First my PCI to PCI-E bridge is 66MHz compatible and with the GF6600 in it, the slot reported 66Mhz clock-frequency.

The GF6200 PCI, even tho it is 66MHz compatible, the slot only reported 33Mhz mode.

The SiL3112, the slot reported 66Mhz mode.

I wonder why the 6200 didn't want to do 66MHz mode in a PCI-X slot?
Need output from lspci -nnvvv and pcitree.sh to be sure.
 
Need output from lspci -nnvvv and pcitree.sh to be sure.
DirectHW still won't build on Tiger PPC.

Code:
make directhw
make -C DirectHW
xcodebuild -alltargets -project DirectHW10.4.xcodeproj 
=== BUILDING NATIVE TARGET KEXT WITH CONFIGURATION Release ===

CompileC build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/i386/DirectHW.o DirectHW.cpp normal i386 c++ com.apple.compilers.gcc.4_0
    mkdir /Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/i386
    cd /Volumes/Untitled/directhw-master-2/DirectHW
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/gcc-4.0 -x c++ -arch i386 -pipe -Wno-trigraphs -fasm-blocks -g -O3 -fno-common -Wformat -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -DMODULE_VERSION=1.6.1 -DPRODUCT_NAME=DirectHW -fmessage-length=0 -fapple-kext -funroll-loops -fvisibility=hidden -fvisibility-inlines-hidden -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/DirectHW.hmap -F/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/Release -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/Release/include -I/Developer/SDKs/MacOSX10.4u.sdk/usr/include -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -I/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/DerivedSources -fno-common -nostdinc -fno-builtin -finline -fno-keep-inline-functions -force_cpusubtype_ALL -fno-exceptions -msoft-float -static -fno-rtti -fcheck-new -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp -o /Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/i386/DirectHW.o
In file included from /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.hpp:21,
                 from /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:18:
/Volumes/Untitled/directhw-master-2/DirectHW/MacOSMacros.h:60:6: warning: #warning i386
/Volumes/Untitled/directhw-master-2/DirectHW/MacOSMacros.h:72:6: warning: #warning SDK 10.4
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers/libkern/c++/OSMetaClass.h:362: warning: unused parameter 'mem'
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers/libkern/c++/OSMetaClass.h:362: warning: unused parameter 'size'
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp: In member function 'virtual bool DirectHWUserClient::initWithTask(task_t, void*, UInt32, OSDictionary*)':
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:160: error: 'kIOUserClientCrossEndianKey' was not declared in this scope
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:165: error: 'kIOUserClientCrossEndianCompatibleKey' was not declared in this scope

CompileC build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/ppc/DirectHW.o DirectHW.cpp normal ppc c++ com.apple.compilers.gcc.4_0
    mkdir /Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/ppc
    cd /Volumes/Untitled/directhw-master-2/DirectHW
    setenv MACOSX_DEPLOYMENT_TARGET 10.4
    /usr/bin/gcc-4.0 -x c++ -arch ppc -pipe -Wno-trigraphs -fasm-blocks -g -O3 -fno-common -Wformat -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -DMODULE_VERSION=1.6.1 -DPRODUCT_NAME=DirectHW -fmessage-length=0 -fapple-kext -funroll-loops -mtune=G5 -fvisibility=hidden -fvisibility-inlines-hidden -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/DirectHW.hmap -F/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/Release -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/Release/include -I/Developer/SDKs/MacOSX10.4u.sdk/usr/include -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -I/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers -I/Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/DerivedSources -fno-common -nostdinc -fno-builtin -finline -fno-keep-inline-functions -force_cpusubtype_ALL -fno-exceptions -msoft-float -static -mlong-branch -fno-rtti -fcheck-new -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp -o /Volumes/Untitled/directhw-master-2/DirectHW/build/build10.4/DirectHW10.4.build/Release/KEXT.build/Objects-normal/ppc/DirectHW.o
In file included from /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.hpp:21,
                 from /Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:18:
/Volumes/Untitled/directhw-master-2/DirectHW/MacOSMacros.h:56:6: warning: #warning ppc
/Volumes/Untitled/directhw-master-2/DirectHW/MacOSMacros.h:72:6: warning: #warning SDK 10.4
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers/libkern/c++/OSMetaClass.h:362: warning: unused parameter 'mem'
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Headers/libkern/c++/OSMetaClass.h:362: warning: unused parameter 'size'
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp: In member function 'virtual bool DirectHWUserClient::initWithTask(task_t, void*, UInt32, OSDictionary*)':
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:160: error: 'kIOUserClientCrossEndianKey' was not declared in this scope
/Volumes/Untitled/directhw-master-2/DirectHW/DirectHW.cpp:165: error: 'kIOUserClientCrossEndianCompatibleKey' was not declared in this scope
** BUILD FAILED **
make[1]: *** [main] Error 1
make: *** [directhw] Error 2
 
I thought I had checked the GF6200 and that it reported 66Mhz compatible, but I did not, and it isn't.

So that explains why it only runs in 33MHz mode.
 
DirectHW still won't build on Tiger PPC.
Are you using Xcode 2.5? Maybe you don't have the latest 10.4u SDK?

The SDK should have this file:
System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/IOKitKeys.h

where it should define kIOUserClientCrossEndianKey and kIOUserClientCrossEndianCompatibleKey

Either download the SDK or add the following lines to DirectHW.cpp:
Code:
#ifndef kIOUserClientCrossEndianKey
    #define kIOUserClientCrossEndianKey "IOUserClientCrossEndian"
#endif
#ifndef kIOUserClientCrossEndianCompatibleKey
    #define kIOUserClientCrossEndianCompatibleKey "IOUserClientCrossEndianCompatible"
#endif
 
Are you using Xcode 2.5? Maybe you don't have the latest 10.4u SDK?

The SDK should have this file:
System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/IOKitKeys.h

where it should define kIOUserClientCrossEndianKey and kIOUserClientCrossEndianCompatibleKey

Either download the SDK or add the following lines to DirectHW.cpp:
Code:
#ifndef kIOUserClientCrossEndianKey
    #define kIOUserClientCrossEndianKey "IOUserClientCrossEndian"
#endif
#ifndef kIOUserClientCrossEndianCompatibleKey
    #define kIOUserClientCrossEndianCompatibleKey "IOUserClientCrossEndianCompatible"
#endif
More better errors that way, I'll try on Leopard...

Seems the X1950 is not a bad performer @66mhz in a Dual G5 2.0GHz.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.