• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Quake RAVE or GLQuake will freeze a PowerMac 6500 if a dedicated graphics card is used

phlogios

Member
Let's try to solve this problem once and for all!
PowerMac 6500 has a bug that causes a total system freeze if you try to run Quake RAVE, GLQuake or Hexen II for a few seconds. The freeze always happens at different times, but it *always happens* eventually. This bug has been confirmed by me and a friend on 2 separate PowerMac 6500's with 3 different graphics cards, on a many different MacOS versions and driver versions.
Here's what we've tested:
ATI Rage 128 from a B&W G3
ATI Radeon 7000 Mac Edition
Sapphire ATI Radeon 7000 PC Edition flashed with reduced Mac rom

There are clues in this old page:
https://web.archive.org/web/20210604194019/http://www.zone6400.com/files/Radeon_in_6500.html
In which a user called Yoshihide did some investigation. The "conclusion" at the end by "JJ" is false, as he does not try Quake. There was never a problem with CineBench to begin with.

I'm looking for two things here at 68kmla:
Knowledge about the problem (for example does the TAM also freeze?) and knowledge about possible solutions or workarounds.
It is already known that the PowerMac 6400 does NOT have this problem, so testing on that machine does not help.
 

phlogios

Member
I have tested installing MacBugs but it does not help as the system freezes without displaying MacBugs and becomes completely unresponsive so MacBugs cannot be invoked manually. The only thing that the computer responds to is the force reboot key combo.
 

Phipli

Well-known member
There is something odd about the Rage II in the 6500, it was causing the combo card issues. But the patch might be assuming the Rage II is being used, so might not be perfect for you. I can't help but feel the ethernet issue isn't 100% related... that kind of doesn't make sense, but I'm willing to be surprised.
I have tested installing MacBugs but it does not help as the system freezes without displaying MacBugs and becomes completely unresponsive so MacBugs cannot be invoked manually. The only thing that the computer responds to is the force reboot key combo.
When does it freeze? When it reaches the desktop, or while actually loading extensions? ATi drivers are a pain, I've seen both of these issues within the last month, solved by using different driver versions. Older versions tend to work better, not newer.

Try this version perhaps?
 

phlogios

Member
The issue with loading extensions was resolved by undoing the patch (zapping PRAM).
I did try that version of the driver you linked now, but it does not display an image on my monitor unless I also install the 9200 firmware upgrade (rom extender) from gona.mactar.hu
 

phlogios

Member
With the ATI Rage 128, multiple drivers work, I have tried every driver version from the oldest to the newest I think. But they all freeze in quake - I have not been able to fix that issue. If anyone here has a 6500 or a TAM, please try running Quake RAVE with a dedicated GPU and let me know if it freezes for you.
 

Phipli

Well-known member
The issue with loading extensions was resolved by undoing the patch (zapping PRAM).
I did try that version of the driver you linked now, but it does not display an image on my monitor unless I also install the 9200 firmware upgrade (rom extender) from gona.mactar.hu
@joevt are you able go disable the rage II completely in the NVRAM script you did previously? Or skip over it if it doesn't have a display connected to it? Bit of an off chance.

@phlogios I'd see if you could get a version of the drivers working alongside the patch, just on the off-chance.

The patch makes the Rage load up last instead of first, but there is some kind of bug in the Rage firmware, so it might still mess with other cards.

If you need something connected to the Rage graphics to spoof a screen, a trick is to plug a VGA adapter into the built in video. It thinks there is a monitor connected then.
 

Phipli

Well-known member
Also, "it doesn't work" is a possibility - it took 20 years to sort the combo card issue.
 

joevt

Well-known member
@joevt are you able go disable the rage II completely in the NVRAM script you did previously? Or skip over it if it doesn't have a display connected to it? Bit of an off chance.
I suppose we could just make it not probe the Rage II at all. Below, I commented out (with a \) the part that probes slot device 0x12 which is the device number for the Rage II.
Code:
dev pci1
defer ?p
a3b get-token drop 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 + brpatch
unselect-dev

For the following, I may be misinterpreting how pci-probe-list works. I suppose setting it to 0 and seeing what exists in dev / ls after a restart should prove if I'm correct.

To disable probing of a slot, one would nomally clear a bit in pci-probe-list but none of the bits correspond to a pci slot on the 6500. For each bandit PCI host controller, the bandit fcode image is loaded. The probe-slots method in that fcode image only tests a single bit - the least significant bit of the nibble that corresponds to the bandit bus number (the least significant nibble is for bus #0, the next nibble is for bus #1, etc). Since the 6500 has only one bandit, and that bandit is for pci1 then it's bus# is 1 (not 0). Therefore, the only bit that does anything is bit 4 = 00000010 hex. If you change that 1 to a 0, then the bandit PCI device pci106b,1 is not added.

Note 1: The bandit host controller bus number is not the same as the PCI bus numbers assigned to PCI devices. Host controllers are not PCI devices - they are the device through which communication between the CPU and PCI devices occur. For example, Intel Macs have an ACPI PCI root device for the PCI host controller. Apple Silicon Macs have a platform device for PCI host controllers.

Note 2: The PCI bus number corresponding to a PCI host controller is not necessarily a property of the host controller - it is a property of the driver. In the case of bandit, the PCI bus number for directly attached PCI devices is considered to be 00. In a Power Mac 9600, the second bandit (or vci0 in a Power Mac 8600) would have a bus number corresponding to the first PCI bus number not used by the first bandit. This is because directly attached PCI devices use PCI Type 0 configuration requests which don't include a bus number. A PCI Type 1 configuration request includes a PCI bus number to access devices connected to PCI bridges. The reg property of a PCI device has a config address which is based on PCI bus number, device number, function number, and base address register offset. The bandit host controller driver looks at the bus number encoded in the config address to determine if a PCI Type 0 or Type 1 config request should be made. I suppose there's no reason why multiple bandits can't be PCI bus number 00 - they could then have 255 bus numbers each instead of dividing a single range of bus numbers. Apple Silicon Macs start PCI bus numbering at 00 for all host controllers (there's one host controller for each Thunderbolt port, plus other PCI host controllers for internal devices such as WiFi/Bluetooth and Ethernet).
 

Phipli

Well-known member
I suppose we could just make it not probe the Rage II at all. Below, I commented out (with a \) the part that probes slot device 0x12 which is the device number for the Rage II.
Code:
dev pci1
defer ?p
a3b get-token drop 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 + brpatch
unselect-dev

For the following, I may be misinterpreting how pci-probe-list works. I suppose setting it to 0 and seeing what exists in dev / ls after a restart should prove if I'm correct.

To disable probing of a slot, one would nomally clear a bit in pci-probe-list but none of the bits correspond to a pci slot on the 6500. For each bandit PCI host controller, the bandit fcode image is loaded. The probe-slots method in that fcode image only tests a single bit - the least significant bit of the nibble that corresponds to the bandit bus number (the least significant nibble is for bus #0, the next nibble is for bus #1, etc). Since the 6500 has only one bandit, and that bandit is for pci1 then it's bus# is 1 (not 0). Therefore, the only bit that does anything is bit 4 = 00000010 hex. If you change that 1 to a 0, then the bandit PCI device pci106b,1 is not added.

Note 1: The bandit host controller bus number is not the same as the PCI bus numbers assigned to PCI devices. Host controllers are not PCI devices - they are the device through which communication between the CPU and PCI devices occur. For example, Intel Macs have an ACPI PCI root device for the PCI host controller. Apple Silicon Macs have a platform device for PCI host controllers.

Note 2: The PCI bus number corresponding to a PCI host controller is not necessarily a property of the host controller - it is a property of the driver. In the case of bandit, the PCI bus number for directly attached PCI devices is considered to be 00. In a Power Mac 9600, the second bandit (or vci0 in a Power Mac 8600) would have a bus number corresponding to the first PCI bus number not used by the first bandit. This is because directly attached PCI devices use PCI Type 0 configuration requests which don't include a bus number. A PCI Type 1 configuration request includes a PCI bus number to access devices connected to PCI bridges. The reg property of a PCI device has a config address which is based on PCI bus number, device number, function number, and base address register offset. The bandit host controller driver looks at the bus number encoded in the config address to determine if a PCI Type 0 or Type 1 config request should be made. I suppose there's no reason why multiple bandits can't be PCI bus number 00 - they could then have 255 bus numbers each instead of dividing a single range of bus numbers. Apple Silicon Macs start PCI bus numbering at 00 for all host controllers (there's one host controller for each Thunderbolt port, plus other PCI host controllers for internal devices such as WiFi/Bluetooth and Ethernet).
Thank you joevt, much appreciated as ever.
 

Forrest

Well-known member
When Quake was released, the best way to run it on your Mac was to install a 3Dfx Voodoo 2 card. I think they cost about $150 when new, and you didn’t need to install a Mac specific card in your machine, as the Mac drivers were freely available. I just checked eBay - slim pickings and these boards are still selling for $150 to $200.
 

Byrd

Well-known member
Similar to Forest, it was usually a non-ATI branded card that was installed in these Macs, like a Voodoo 2 or 3 at the time.

Adding to this my experience with any PCI ATI video card installed in a TAM (I’ve tried 128, Mac 7000, flashed 7000) doesn’t play nicely with the onboard Rage II. It all came down to extension conflicts conflicting with the new and old ATI cards - you could get one working well and accelerated (onboard or PCI) but not at the same time. The OS also got very confused about which display to output to. Have also tried many versions of drivers and Mac OS to test.

My TAM does work well with a Voodoo 1 or 3 card, but gets too hot for my liking so only for short bursts. I’m now using an Apple DB15 mirroring adapter which outputs to external display should I have the need.
 

MacJunky

Well-known member
I gave this a shot on a 6500, and then removed all ATI-named extensions and ran the Oct 2002 installer.
However I am not getting very far into the first demo. I tested Quake RAVE first and it froze before the console slid up, OpenGL was no better.
As for the games bundled with the 6500... Weekend Warrior froze on the Bungie intro screen. MechWarrior 2 ran the longest, almost made it to the second nav point in the cadet training! MW2 was the only game to run longer than before the patch.

6500 antiRAGE Patch code.gif6500 antiRAGE Patch.gifPXL_20230525_053344572.NIGHT.gif
 

phlogios

Member
Thank you Joevt and thank you MacJunky for taking the time! I don't understand much about how the PCI stuff works so I'm super impressed by what you are doing. I'm going to be able to test a voodoo2 card in a few days to verify that at least those work on 6500 (and not just on 6400 and TAM).
It would be so cool if the community could solve this problem and enable the use of ATI cards, which aren't rare, as accelerators for 6500's.
 

Phipli

Well-known member
Thank you Joevt and thank you MacJunky for taking the time! I don't understand much about how the PCI stuff works so I'm super impressed by what you are doing. I'm going to be able to test a voodoo2 card in a few days to verify that at least those work on 6500 (and not just on 6400 and TAM).
It would be so cool if the community could solve this problem and enable the use of ATI cards, which aren't rare, as accelerators for 6500's.
Perhaps a Geforce 2 might be a reasonably common PC card. Some of them are easy to flash to be mac cards. I don't have any to try.
 

Byrd

Well-known member
Geforce 2 PCI cards were pretty unpopular for some reason. @phlogios yes any Voodoo 1/2/3 card will work well in the 6500, but I'd have a slow fan nearby blowing air around it.
 

Forrest

Well-known member
I don’t believe Apple ever shipped a machine with a GeForce 2 PCI card. The G4 iMac had a GeForce 2 MX built-in, and they were on the AGP bus?
 

Byrd

Well-known member
@Forrest no not in PCI, this would be a flashed card from a PC. All Geforce 2s in Macs were AGP. As mentioned the GF2 PCI was uncommon for what it was then (ATI PCI GPUs have always been in abundance) and a flashed card probably wouldn't play too happily either.
 

phlogios

Member
Do we know the actual cause of the freeze, and if not, is there a way to find out what exactly is happening at the moment of freezing?
 
Top