• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

The Great Gazelle PCI Hack Thread, Part 2


Hanlon's razor applies here. In the absence of any evidence to the contrary, cock-up is more likely than conspiracy.
Hanlon's razor is a wonderful principle, thanks for the lesson. The linked article's timeline explains why it didn't make its way into my 1970s Philosophy courses. Given Apple's history of bus choking, limiting memory in firmware and its underclocking of the IIsi in keeping the low end and mid-range down, I thought it stupid not to pose the question.

I'd be sure you're right given the evidence, but malice in this situation would be ascribed to marketing intent, not Firmware cock-up. ;)

Sorry for the tangent.
Last edited:


Well-known member
I think it would be unwise to think too hard that this was a super clever dastardly plan to "intentionally hobble" the expansion capacity of these machines.

For a handful of reasons, I think it's better to presume that this is a genuine mistake.

Especially, given that the same mistake exists in the "professional" x500/X600 machines. The difference being that it happens with one level of PCI-PCI Bridges in the Gazelle and it happens with two "daisy chained" PCI-PCI Bridges on the X500/X600.

Most folks never run into it, because multi-function PCI cards tend to just have one PCI-PCI Bridge. But the S900/J700, 8500/9500 clone uses a PCI-PCI Bridge to create the lower four slots out of what would normally be slot C1 amongst the upper slots. Then if you install a multi-function PCI card in one of those four lower slots, you've got two daisy chained PCI-PCI Bridges.

However, I suspect that it is exactly the same problem and that internally, Gazelle has all it's PCI slots behind what is logically a PCI-PCI Bridge. But I haven't checked the Hardware Developer Note to see if that hypothesis is supported.

I know that the Developer Notes show some of the G4 PCI slots are definitely behind PCI-PCI Bridges, with the upper "PCI slot" being a much higher bandwidth flavor than the downstream. However, I think that by the time of the G4s (or somewhere amidst them) the bug as resolved.

More importantly, support for PCI-PCI Bridges is part of the PCI specification. Up to 256 PCI slots expanded in 4-slot chunks is in the specification. Apple claims to support the PCI specification. They should support PCI-PCI Bridges, including many levels of them.

I suspect the difference between Alchemy and Gazelle is:
1) The same dumb-a#$#@ who screwed up the X500/X600 code worked on Gazelle, but didn't work on Alchemy.
2) All the machines from this era have the same problem, but Gazelle has an internal equivalent of a PCI-PCI Bridge before you get to any of its PCI slots, and Alchemy's slots did not.


Daring Pioneer of the Future
Staff member
jt: you're correct that the only bad question is one not asked. My apologies if my response was a bit terse or severe.

2) All the machines from this era have the same problem, but Gazelle has an internal equivalent of a PCI-PCI Bridge before you get to any of its PCI slots

I don't have the machine's dev-notes in front of me, but, for a PCI device on the motherboard, like, say, an ATi Rage graphics chip.


Well-known member
So, to draaaaaag this thread back on topic, here's how to modify the patch for other combo cards based on the Hint HB1 or its successors. You can try this with other bridge chips but it may not work. For devices with two other PCI devices behind the bridge (or for cards where you are happy with only two of them working), this is absolutely trivial. For devices with more, it can get arbitrarily tricky.

We'll take the second-revision Sonnet Tango 2.0 as an example. The first thing you need to do is to stick the card in another machine with OpenFirmware (in my case, I used a beige G3), and get the following things:
  1. The list of devices behind the bridge (as shown in 'ls')
  2. The properties for the bridge itself
  3. If there are more than two devices, the properties of each device will help you work out which ones you need to enable in your patch.
The first thing to do is to get the vendor and device ID of the bridge. This is in the .properties output from the other machine. For the Tango, it looked like this:

0 > .properties
vendor-id               00003388
device-id               00000021
revision-id             00000011
class-code              00060400
devsel-speed            00000001
AAPL,interrupts         00000017
AAPL,slot-name          A1
name                    pci-bridge
device_type             pci
reg                     00006800 00000000 00000000  00000000 00000000
#address-cells          00000003
#size-cells             00000002
ranges                  82000000 00000000 81800000  82000000 00000000 81800000 
bus-range               00000001 00000001
power-consumption       007270E0 007270E0

You need to take the top two numbers and put them into the check-node word definition in the patch, replacing 1668 and 100. So, for the Tango 2.0, check-node looks like:

: check-node 
my-space " config-l@" $call-parent 
dup d# 16 >> swap h# 0000FFFF and my-space d# 8 + " config-l@" $call-parent d
# 8 >> h# 60400 = swap h# 3388 = and swap h# 21 = and ;

Then, you need to work out which devices you're enabling. To do this, look at the 'ls' output you collected from your other OF machine. Here was mine:

FF842A70:   /pci-bridge@D
FF8437A8:     /pci1033,ce@8            [pci1033,ce]
FF843AA0:     /pci1033,35@9            [pci1033,35]
FF843D68:     /pci1033,e0@9,1          [pci1033,e0]

We are here interested in the numbers after the @ sign. (Note that these are in hex, so they may be A-F; they're still numbers). The Tango 2.0 is easy because there are only two "top level" devices (I don't know what the proper term is), at 8 and 9. The one at 9,1 we ignore.

Now you go into the patch and look at the make-nodes definition. In that, you'll find two invocations of new-device, each followed by two zeros and then a quoted string. The first quoted string is 0,0, the second is 1,0. You should change the first digits of these to be the device numbers that you spotted above. So for the Tango 2.0, we want to change them to 8 and 9, so the code near new-device looks like:

new-device 0 0 " 8,0"


new-device 0 0 " 9,0"

Don't forget that the opening quote needs a space after it: just forth things.

If only some of the USB ports on your card work, then you probably have multiple OHCI hosts on the card (this is what happened with the Kalea). I'll talk about dealing with that in a subsequent post. If, when you restart the computer after applying the patch, the devices appear properly in 'ls' in OF but the machine crashes hard during boot, then it's possible you have a bridge that needs to be initialised differently. Still thinking about that case.


Well-known member
Then, you need to work out which devices you're enabling. To do this, look at the 'ls' output you collected from your other OF machine. Here was mine:

FF842A70: /pci-bridge@D
FF8437A8: /pci1033,ce@8 [pci1033,ce]
FF843AA0: /pci1033,35@9 [pci1033,35]
FF843D68: /pci1033,e0@9,1 [pci1033,e0]
We are here interested in the numbers after the @ sign. (Note that these are in hex, so they may be A-F; they're still numbers).

I wonder if these numbers represent the IDSel(ect) lines on the client chips. If so, it would be possible to determine them with an ohmmeter, rather than inserting the card in another machine. It's probably easier just to insert and read, but it makes me wonder.

IDSEL is how PCI determines which slot is which. Every slot has an IDSEL pin and each IDSEL pin (at a given level of bridges) must be tied to a unique address line in the PCI bus.

At boot time the host polls each PCI address bit one at time and checks IDSEL lines to see who responds.

All with a big IIRC.

Great work, with nice details on how to implement.


Another thought: Has anyone looked into the quasi PCI CommSlot II as a problem specific to PCI implementation in Gazelle machines? Any changes to its implementation in the migration from Alchemy could be an avenue of exploration.

That quirkiness of the Gazelle bug might be attributed to its concurrent development in the pro series machines? CommSlot II implementation is interesting in and of itself, the way this partial PCI slot is shoehorned into the system might be worth a look?
Last edited:


Well-known member
Hard to take good pictures of the CRT.
Hope it’s readable at least.


  • 24C61784-A0C2-4942-A720-18CA8F67887F.jpeg
    6.8 MB · Views: 14
  • 879CEC76-5AF6-4267-A949-0E03EC297284.jpeg
    6.1 MB · Views: 20


Well-known member
cpoke is to get output on the internal CRT of the 5500.
Ah yes, before "hex". I'll give it a go right away.


Well-known member
@Knez ok, have a go at this. What I want you to do is this:
  1. Install this patch
  2. Reboot into OF
  3. Type 'qqq' (without the quotes) and press return, and send me a photo of what it says.
Note this patch doesn't even attempt to fix up the devices, it should just provide debugging info...


  • testpatch.txt
    465 bytes · Views: 0


Well-known member
Sorry, that patch won't work because I wasn't paying proper attention. Try this one instead.


  • testpatch.txt
    463 bytes · Views: 3


Well-known member
OK, if anyone wants to have a go at either of these: I've tested these on my TAM here, but I can't test it on any other Gazelleish machines.

These are self-applying applications: the second should apply the patch to make the second-revision Tango 2.0 work; the first should enable Firewire and USB on the ST-200 available from Kalea (and a couple of other places).

If it tells you you have an invalid nvram checksum, do not apply the patch! And please let me know what you're installing it on.


  • KaleaST200.sit
    24.5 KB · Views: 0
  • Tango2.0new.sit
    24.5 KB · Views: 0