I said the interrupts were probably ok for A,B,C because there's an interrupt pin on OHare for each of them.
Its the GNT and REQ for C that I'm wondering about. Did you find out if A19 and B10 are connected to anything?
TwiSlot PCI Riser and ComSlot2 NIC repro in widened CS riser form factor
- Thread starter Trash80toG4
- Start date
Its the GNT and REQ for C that I'm wondering about. Did you find out if A19 and B10 are connected to anything?
Dunno, I've wrapped this borken test unit project up until I feel the need to bodge connections on one of my three slot PC Risers. Daniël has done so, but not had the ability to test it yet. I'll just tag along after his lead.
There's really no utility in attempting to convert CommSlot II to full-0n PCI. Androda has his new build 10/100 cards available. So even if you could find an OS9 compatible Gigabit NIC for a bodged Slot_E, the difference probably wouldn't be worth the effort in Alchemy/Gazelle.
As I said, confirming the Sot_B setup for custom TwinSlot Risers aimed at my 6360, the 5x00 and TAM was the driving force of this project.
Almost unbearable curiosity was aroused by the A/B/C C-600 Riser @trag posted. This has been satiated and then some.
There's really no utility in attempting to convert CommSlot II to full-0n PCI. Androda has his new build 10/100 cards available. So even if you could find an OS9 compatible Gigabit NIC for a bodged Slot_E, the difference probably wouldn't be worth the effort in Alchemy/Gazelle.
As I said, confirming the Sot_B setup for custom TwinSlot Risers aimed at my 6360, the 5x00 and TAM was the driving force of this project.
Almost unbearable curiosity was aroused by the A/B/C C-600 Riser @trag posted. This has been satiated and then some.
Don't recall which of the many configs I played with last night showed a problem with the mouse freezing. VidCard I've been using is a deader, but ROMs show up just fine. Hooked up an ATI Rage128 with DVD decoder daughtercard. One slot or another (probably E1?) had the mouse/cursor freeze when it hit the edge of its window.
After I get a PC Riser or two up and running it'll be time for methodical troubleshooting. Very curious to see what the results will be with your Open Firmware approach to this. Wishing I'd not concentrated so much on collecting Gazelle boards over the years so I could send an Alchemy board out to someone for using your program. I think I've only got the two Alchemy boards. ;-/
As far as I know, Apple never used more than 2 bridges. The ANS has two Bandit PCI bridges, similar to the PM9500. On the 7500/7600/8500/8600 the video circuitry is the 2nd bridge and the first one is a Bandit PCI controller.
The Apple Hardware Developer Note for the ANS goes into a small amount of discussion about how the concept could have up to four Bandits, but Apple's implementations don't appear to support it, unless there are a bunch of unused INT pins on Grand Central.
The ANS is interesting because using the same hardware found in the PM9500, it puts six devices on one Bandit, suggesting that there are arbitration signals for at least six slots on the arbitration chip (separate chip from Bandit). But the interrupts are still limited by Grand Central, and that is the main reason (I think) that putting a PM9500 ROM in an ANS does not work. The interrupts aren't connected the way the PM9500 ROM expects them to be in the ANS.
You didn't connect an interrupt for E1 so the mouse freezes if you move the cursor onto the GPU that is in that slot. The default interrupt for E1 is the COMM_SLOT_INT. Slot E1 is IDSEL AD17. The interrupt bit is 0x16.
I expect you could connect any number of cards and read config data or setup BARs as long as each card has an IDSEL address line (AD19 to AD31 are available). Multiple cards can use the same interrupt, you just need to have Open Firmware properties for the IDSEL and interrupt numbers. However, there's an electrical limit to the number of devices you can put on a bus.
The following nvramrc patch at https://68kmla.org/bb/index.php?threads/the-great-gazelle-pci-hack-thread-part-2.38360/page-12
sets up IDSEL/interrupts for slot A1 (IDSEL AD13=0x0D, interrupt 0x17) to F1 (except D1 which is OHare).
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-devThis nvramrc patch does what the original Open Firmware code does except it does F1 (the GPU) last instead of first to workaround a bug where doing F1 first causes devices behind PCI bridges to not be enumerated.
So all you have to do to add more slots is extend the list in the patch and choose an interrupt for each new slot. OHare has about 18 different interrupts but only 10 are available externally and probably you don't want to share some of those.
Maybe so. But they did use 3 of the bridge address ranges.
F0000000 for chaos in the 8500.
F2000000 for pci1 in the 8500 and 9500.
F4000000 for pci2 in the 9500.
Interrupts can be shared. For example, every PCI device behind a PCI-PCI bridge uses the same interrupt. A PCI device driver needs to check if the interrupt belongs to its PCI device.
Some Open Firmware patching may be required to setup the slots and interrupt numbers like in the above gazelle nvramrc patch.
I don't know exactly what is required for REQ and GNT signals. GrandCentral in the 9500 specs only has one of each and U13/U15 somehow distributes this to the 6 slots (3 each).
I wonder if they did that so that it would be easier to use the same ROM on all those machines. If it's at F0, it's video circuitry. If it's at F4 its more PCI slots.
It would be interesting to get the Mac OS running on the ANS. However, two of the PCI devices on that six "slot" Bandit are dual 53C825 F&W SCSI chips. Without drivers those are going to be kind of useless under Mac OS. I wonder if patching the firmware for them from the ANS ROM would have any benefit in a Mac conversion. Way into my ignorance with that bit of speculation.
Are you interested at looking at the issues with the S900 slots? It's very similar (in behavior) to the Gazelle. However, there's no built-in video, so the problem isn't the order of initializing a GPU, as there is no GPU until a PCI card is installed.
One of these days, probably in about ten years, I could drag one of my extra S900 boards out of the attic and send it to you...
A little more detail on that. I'm pretty certain those REQ/GNT signals on Grand Central are not used for the six slots. Those signals are to allow Grand Central to be a bus mastering device on one of the PCI busses.
All the GNT/REQ signals from the PCI slots go to little 28 pin PLCC chips labeled 343S0182. As far as I can tell, these chips are the PCI Bus Arbiters. Wherever you find a Bandit, you find one 343S0182 associated with it. I don't know why they didn't put the arbitration function inside of Bandit -- maybe they ran out of pins. In my ancient notes from when I was toning out the pins on these things, I also have a diagram labeled 343S0018 for the arbiter. I don't know if that was a mis-writing by me, or if Apple had two different part numbers.
Anyway, if one traces the GNT and REQ pins from the PCI slots and from Grand Central and from Bandit, they all go to those 343S0182 chips.
Of course, Bandit also has a different set of GNT/REQ (and DGrant?), which go to Hammerhead and arbitrate its use of the CPU bus.
I've always wondered how Grand Central signals the CPU of an interrupt. Does it have to get control of the PCI bus as a master? Or is there a direct wire/signal from Grand Central to the CPU somewhere? There's definitely PINT (primary interrupt) and SINT (Secondary INterrupt) signals in the CPU slot. I assume they're inputs for the CPUs.
It does simplify things.
What ROM does it use? Does it have Open Firmware?
The S900 uses the same ROM as the Power Mac 7200&7500&8500&9500 v2 which doesn't have issues with PCI-PCI bridges. There's an S900 discussion at https://68kmla.org/bb/index.php?thr...irmware-with-the-great-gazelle-pci-hack.45493 but it didn't get anywhere. Unless there is a problem visible in Open Firmware, then I can't fix it.
Right. Probably for the DBDMA stuff that all the macio devices use.
Those are the U13 and U15 in the 9500 schematics shown in the photos in this post:
https://68kmla.org/bb/index.php?thr...s-scans-of-a-powermac-9500-logic-board.39892/
U13 and U15 are wired differently in the 9500 schematics. Maybe they would have needed two different Bandit chips?
Is there a picture with the 343S0018?
The MacIO chips (GrandCentral, OHare, Heathrow, Paddington) have multiple interrupt bits for different devices in MacIO and PCI. I suppose they all need to trigger the same CPU interrupt.
ClassicHasClass answered that better than I could have. Yes, it has OF.
That's a little disappointing, although at this point in time, a solution for the S900 is more of a white whale than a real need.
Still, it's very puzzling. Architecturally, the S900 is like a PM9500 with the second bandit omitted and a PCI-PCI Bridge installed in Slot C1.
It does have a second CPU slot, but there's no active circuitry there unless a secondary CPU card is installed. There is one obscure item in my notes. I think that pins 186 and 187 on Bandit control what address it services. If my notes are accurate then on a 7200 both 186 and 187 are tied to 5V (through R). On the PTP 186 =>5V, 187 => GND for Bandit 1 and both go to 5V on Bandit 2. But on the S900 I show pins 186/187 tied to Gnd.
Would that even work with the same ROM if Bandit 1 was at a different address? Anyway, it's that one weird thing that might be different about the S900... Or a complete red herring.
Do chains of bridges work in the PM 9500 et. al.? This is relevant, because the first level of bridging does work on the S900. There's the PPB on slot C1 and then single function cards in the four dependent slots function just fine. The problem occurs when a second level of bridging occurs, or appears* to occur. Putting cards with PPBs behind the Slot C1 PPB is where the problem happens, unless that PPB-card is the only card installed in the bottom four slots.
*I write "appears" because I suspect dual head video cards and 2 port ATA cards don't actually have a physical PCI-PCI Bridge on board, although I suppose that functionality could be in their main chip.
And the Hardware Developer Notes for the various PowerSurge (X500/X600) and Catalyst (7200) machines clearly show Grand Central as a PCI device.
In my ancient tracings, U13 is connected to the G/R lines for Bandit 1, Grand Central, and Slots A1, B1, C1. U15 is connected to the G/R lines for Bandit 2, and slots D2, E2 and F2. Which makes sense. U13 arbitrates for the PCI bus created/bridged by U12/Bandit 1. U15 arbitrates for the PCI bus created/bridged by U14/Bandit 2.
Are they connected differently in some other way? Reversing Grant and Request lines or some such? That would be bizarre.
My notes also show Frame, IRDY, TRDY and RST connected to 343S0182.
No, I don't have any pictures. I think I miswrote that note and it was probably a 343S1082. I did that signal tracing almost 20 years ago, so memory is very little help...
Yes, it appears that the CPUs have just one incoming interrupt signal and Grand Central and the others collect and perhaps manage in some way the interrupts. Internal register showing which interrupt(s) was triggered?
Sorry for hijacking the thread. We now return you to the regular topic....