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....
Is there a download link for the ROM? I don't think the archive sites have that one. It might be nice to try and emulate it in DingusPPC.
I'm looking for any Mac ROM that's not in the list at https://www.dropbox.com/scl/fi/jrql...ey=p1ncvzzchppp06wzxo15rorro&st=y4qo179e&dl=0
You can see it in the 9600 schematics though I don't understand the differences.
https://68kmla.org/bb/index.php?threads/schematics-for-power-mac-7600.46119/post-514059
https://www.macdat.net/files/pdf/apple/schematics/apple/
Open Firmware 1.0.5 has pci1 hard coded to 0xF2000000. pci2 is optional and hardcoded to 0xF4000000. vci0 is optional and hardcoded to 0xF0000000.
I think so. Here's a bunch of bridges connected to my Power Mac 8600 (uses the same OF 1.0.5 version as Power Mac 9500 and S900):
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-33188527
but those are mostly PCIe and I only looked at them in Open Firmware. I did boot Mac OS X 10.4.11 with them in a B&W G3 though.
Dual Head Video Cards and 2 port ATA cards don't have a PCI-PCI bridge.
PCIe video cards have a PCIe-PCIe bridge for an audio device used for doing digital audio to DisplayPort or HDMI displays.
PCIe video cards with a USB-C port have a USB XHCI controller behind a PCIe-PCIe bridge.
The Sonnet Tempo Trio (in my Power Mac 8600) has USB and FireWire and ATA controllers behind a PCI-PCI bridge.
Okay, I looked at it. The differences are minimal. Bandit 1 has a GNT/REQ line connected to Grand Central and Bandit 2 does not. Which makes sense. You don't want to put Grand Central or any other PCI device on two different PCI busses. Pins for Bandit on Arbiter 1 are connected to Bandit 1. Pins for Bandit on Arbiter 2 are connected to Bandit 2.
There are a few other pins that looked like they might be different, but they just go to test points.
However, it's interesting, because I only see 5 sets of GNT/REQ and Bandit always uses one set, so only 4 are available. How did they get 6 devices on one Bandit on ANS???
Ah, I see. Pins 8 and 22 are not used on PM9600, so they're not on the schematic, but they are REQ/GNT pins. That gives 5 available. I wonder if the Video chip on ANS does not have bus mastering ability. That would probably make sense.
So each arbiter can do five devices... If the signal quality would handle it, that suggests one could rig up a 9 slot PM 9500; four slots on Bandit 1 (GC uses up one) and five slots on Bandit 2. It would require ROM modification for the machine to see the slots, of course, but it looks like you have that nailed down. I'm not quite sure how one could make it work mechanically.
Also read the rest of the thread you referenced, and found that I probably have SGRAM on hand that can upgrade the 6500 video from 2MB to 4 MB.
Cool, might VRAM loadout be ROM limited to the 2MB or were the higher capacity chips unavailable at release and so not hobbled in ROM. Apple woudd not likely have missed that opportunity to hamstring a mid-range offering. Might they have done so in order to prevent stacking of ICs? I put little past them.
Well in the thread with the 9600 schematic (and 6500 schematic) that joevt referenced above, I posted my thoughts. I concluded that you can probably just solder the chips I have in place of the existing chips, (matching pinouts) but the question is then exactly what you asked.
How does the ATI chip know how much VRAM it has? Since it's an ATI chip, it's entirely possible Apple didn't write the ROM for it and just used the ATI Mac firmware version. Does the ATI graphics chip auto-detect the VRAM or is it set in firmware? It seems to me likely that it auto-detects, since there are so many cards of hte same ilk, with VRAM on board and a VRAM expansion slot.
If I was in a computer project phase I might try the experiment. I'll be stuck in yard work for at least another week or six....
The way I think an arbiter works is, it checks for REQ from a device and gives it GNT to allow the device to do work. When the device releases REQ, the arbiter releases GNT and checks the next device. I suppose the PCI Local Bus Specification will explain it - at least the PCI part. There's probably some extra stuff so that the multiple arbiters of the pm9500 don't GNT at the same time and also don't GNT when the CPU is doing work on the bus.
A video chip doesn't need bus mastering if it doesn't need to read data or write data from RAM or another device, such as for 2D or 3D acceleration.
We don't have schematics from any PCI Power Macs with built-in video except the ones with ATI graphics chips? Well, there is the pm7200 with Platinum video device. It uses the same arbiter next to Bandit and also doesn't use pin 8 and 22.
I think the ATI fcode image from the Mac firmware should detect the RAM or it could be hard coded if it's a fixed amount of RAM and they wanted to save some bytes. In either case, the fcode can be patched by nvramrc script before it is executed. Fcode patching is a different kind of patch compared to compiled fcode patching. The B&W G3 PCI-PCI bridge patch and the OF 1.0.5 version 1 PCI-PCI bridge patch are examples of an fcode patch. The OF 1.0.5 version 3 PCI-PCI bridge patch is a compiled fcode patch - it patches the routine that we want to patch immediately after it's compiled by patching the
b(;) word that is responsible for finishing the compilation.That is my understanding as well. Except I don't think there's any need for coordination between the busses. If a PCI device wants to access RAM, e.g. and the relevant Bandit doesn't have control of the CPU bus, I assume the Bandit would just stall the transaction until it's ready to bridge the busses (has Grant on the CPU bus).
Also, PCI to PCI transactions are possible, although rare, and there's no reason to delay those while CPU transactions are active.
