Three PCI Slot Hack For PM6400?

[trag]

Last night I just noticed that the Umax C600 has three PCI slots and a comm slot. The C600 is based on the PM6400 architecture. That is, it uses the same chipset and ROMs.

So the resources for a third PCI slot must be present in the PM6400 without even stealing anything from the comm slot.

Depending on the changes from the 6400 to the 6500, that might also mean that the resources for a third PCI slot are present in the 6500.

Anyone seen any work on this anywhere?

Also, BTW, the C600 has 16MB of RAM on the logic board, which means that the 8MB Apple put on the 6400 is not the limit. I suspect that one could put at least 32MB on the logic board, but getting it wired into place would probably be a nightmare.

 

[Trash80toHP_Mini]

Very interesting . . . hrmmm? :?:

If you've got "SlotInfo" (?) from the Gauge Utilities, run that and post the results. If not, get the Gauge Series, TechTool or something else that'll let you know what hardware is using what addresses as "real" or "pseudo" slots on the C600 as compared to your 6400's slot assignments.

I'll try to do the same on my 6360 and 6500 boards, which haven't been up and running since I moved this summer. :-/

I'm beat, so don't hold me to this, but the COMM Slot on the 6360/6400 was a half-assed PCI "Slot" and the PCI controller only handled three slots/addresses, IIRC.

Dunno . . . zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

 

[Bunsen]

What's actually on the Apple OEM 1- and 2-slot PCI risers, anything? Could it be as simple (hah!) as putting a generic 3-slot riser in there and disabling/re-routing the Comm slot?

 

[MacJunky]

Not much; just traces. At least in the 6500's.

*Edit

 

[Unknown_K]

Is there a need for another PCI slot in those machines? If you want to do some hacking convert that slot to cardbus or make it mini PCI and then connect a wireless card to it

 

[MacJunky]

With another PCI slot we could certainly have more fun! I know I want another.

Someone needs to come up with a good fix for the 6500's 30 seconds of 3D = lockup with a Radeon 7000 problem though. :<

I cannot remember exactly what was changed.. I need to take another visit to zone6400.com I guess. (presuming that simply swapping the components they indicated as changed on the boards would rectify the issue)

 

[Trash80toHP_Mini]

What's actually on the Apple OEM 1- and 2-slot PCI risers, anything?

Nope, it's a Passive Backplane Extender/RA adapter board in all the P6360 based PCI MoBos.

Could it be as simple (hah!) as putting a generic 3-slot riser in there and disabling/re-routing the Comm slot?

HRMMM . . . depends . . . if the empty COMM Slot shows up as a PCI Device in SlotInfo, that'd be a no, AFAIK. If it DOESN'T show up (not bloody likely as the PCI addressing info is on the card as opposed to on the MoBo for NuBus) and it's a "Pseudo Slot" address, there might be some hope.

IIRC the PCI controllers in question (as were most) were 3 slot/address limited. I'll dig through my boxes for my copy of DC&DftMFH when I get a chance, I'm pretty sure it covers PCI Cards & Drivers.

Interesting topic! }

 

[trag]

Apple's documentation may not be all that informative about whether the hack is possible.

There are three things which must be present in order for more PCI slots to be supported:

The REQ# and GNT# signals must be available for additional slots.

An Interrupt must be available.

The ROM/firmware of the computer must have an entry for the extra slot and associate the interrupt with that slot, since the PowerMacintoshes (AFAIK) don't dynamically detect slot/interrupt associations at POST.

For example, on the PM7500/8500/9500 family. There are at least six sets of REQ/GNT wires. How do I know? The Apple Network Server uses the same chipset and one of its Bandit chips has six PCI devices attached.

Yet, Apple doesn't advertise that a single Bandit could control six PCI devices in that family (would require a ROM entry though).

Apple probably won't mention if there's an unused set of REQ/GNT/Interrupt wires in the 6400 architecture. Yet, Umax found them. Of course, Umax had access to teh actual data sheets for the chipset involved.

The COMM slot isn't a half-buttoxed PCI slot. It contains all the signals of a regular PCI slot (accoding to the Hardware Developer Notes), plus some serial bus signals. At the very least, one could plug an adapter into the COMM slot (just wires, no circuitry) to route the PCI signals to a standard PCI connector so that one could plug a third PCI card into the COMM slot.

But Umax's C600 raises the bar a little further. With it's three PCI slots *AND* a comm slot, it suggests that there are REQ/GNT, interrupts, and ROM resources for what amounts to four PCI slots.

The difficulty would be in determining where the extra REQ/GNT signals and the Interrupt come from. They may not be present in the 6400/6500 PCI riser connector and even if they are, how would you know which pins they are?

On the 6500, the REQ/GNT signals must originate at the PSX+ chip which is a BGA chip. The interrupt signals come from O'Hare I/O controller, which is a QFP. The interrupts could be traced back to O'Hare, but the pins on the PSX+ are not accessible.

I'm not sure if the 6400 is similarly arranged, but if so, one would need to kill a C500/C600 board to figure out where the REQ/GNT signals come from. I.e. desolder the PSX+ chip, trace the REQ/GNT signals back to the pads for the PSX+.

But then, how would one find access to those signals on a 6400? And how would one even know where to look on the 6500? One could guess by analogy. Hardware designers to tend to reuse chip pinouts and designs where they can and the 6500 is very similar to the 6400. But one would ultimately be guessing.

I don't think there's any such thing as a "Standard" riser card. Any time a machine goes from a slot on the logic board to multiple PCI slots, one can never be sure how the signals were arranged in the slot on the logic board. It's not as simple as PCI to PCI, because the logic board connector must have unique interrupts and REQ/GNT wires for each slot which get split out on the riser and routed to just one slot each.

 

[Trash80toHP_Mini]

Actually, the PCI Slot Architecture uses a passive backplane, IIRC, otherwise PCI Towers and Extender cards wouldn't work.

http://www.sharpened.net/helpcenter/answers/increase_pci_slots

I don't have the PCI spec handy, but I was under the impression that addressing info for slots is not dependent on info at the slot signal level.

DC&DftMFH only covers Designing Cards and Drivers for the NuBus/PDS architecture, but the same "book" for PCI Macs is available on one of the developer CD's, IIRC. What's a good/available CD Cataloging utility for 9.2 or 10.4.11? I have one somewhere, but heaven only knows which box it's in!

 

[trag]

I don't have the PCI spec handy, but I was under the impression that addressing info for slots is not dependent on info at the slot signal level.

In theory, it isn't. There's a clever IDSEL scheme which is still kind of at the slot signal level, but it just involves tieing one of the slot signals to one of the addressing lines. So no unique signal, just an extra pin to let a slot listen to an address line through a different wire.

However, the interrupts on Apple machines are slot unique. There are four interrupts per slot in the PCI spec. and they can be shared from slot to slot. The typical recommendation is to rotate the available interrupts amongst the four signals pins from one slot to another. So, CPU_INT(1) connects to INTA in slot 1 and INTB in slot 2 and INTC in slot 3, etc. Similarly for CPU_INT(2).

But that's not what Apple did. Apple ties all four interrupt pins together in each slot and gives each slot its very own unique interrupt signal line. In the X500 family, that's a wire back to Grand Central per PCI slot. In the 6500 that's a wire to Heathrow per PCI slot.

I guess in non-Apple systems there's some method to poll the interrupts when you run the IDSEL thing to tell which slots are using which interrupts, but Apple's machines don't have that intelligence.

And yes, if one uses a PCI-PCI bridge (expansion chassis) all of the downstream slots end up using the interrupt of the host slot, but that's built into the PCI spec. and expected.

Additionally, bus mastering requires a bus arbitration scheme. In order to arbitrate who has control of the bus, there must be unique GNT and REQ wires to each slot. And yes, on Apple machines, every single PCI slot is a bus mastering slot. I see the term get thrown around a lot (especially on xlr8yourmac.com) talking about this or that slot being a mastering slot, but that's a red herring. They're all capable of bus mastering. They all have GNT and REQ signals.

On the x500 machines, PCI bus arbitration is handled by a little PLD separate from Bandit. It's something like 341S0088. It's a little 20 pin thing, IIRC. On the 6500 it's probably all built into PSX+.

When one uses a PCI-PCI Bridge (expansion chassis) the slot arbitration for downstream slots is handled by the bridge. That's part of what a PCI-PCI Bridge does.

What's a good/available CD Cataloging utility for 9.2 or 10.4.11? I have one somewhere, but heaven only knows which box it's in!

That's irony.

 

[Trash80toHP_Mini]

: :approve:

 

[Bunsen]

Or Catch-22

 

[trag]

More thoughts...

Anyone know if the PM6400 and PM6500 riser cards are interchangeable?

My thought is to trace out the C600 riser card connections. If they match (as far as the two PCI slots go) the PM6500 riser card connections (have a 6500 on hand, but no 6400), then I might risk trying the C600 riser card in the PM6500. Testing the functionality of its slots will tell me whether the needed resources actually go to the riser connector or must be hunted down near the chip where they originate.

 

[Gil]

Anyone know if the PM6400 and PM6500 riser cards are interchangeable?

Yes.

 

[trag]

Thank you, Gil. Now I just need to make time to do the work...

But first, the PEX ROM module.

 

[Trash80toHP_Mini]

But first, the PEX ROM module.

First off, that'd be PEx . . . . . . and second, I didn't know you had one too! 8-o

My board has the ROM development sockets populated and gives me a startup chime with the two ProcCards I had.

The Crescendo G3 Accelerator I'd pinned my hopes upon for auto-booting into OS 9.x does the same, but still won't give me video or access a startup disk.

How much luck have you had with yours? :?:

Methinks it's time for a new PEx thread. [] ]'>

 

[trag]

But first, the PEX ROM module.

First off, that'd be PEx . . . . . . and second, I didn't know you had one too! 8-o

My board has the ROM development sockets populated and gives me a startup chime with the two ProcCards I had.

The Crescendo G3 Accelerator I'd pinned my hopes upon for auto-booting into OS 9.x does the same, but still won't give me video or access a startup disk.

How much luck have you had with yours? :?:

Methinks it's time for a new PEx thread. [] ]'>

Oh, I don't have a PEx. I'm building this for a fellow in the UK who has one. It makes it a bit more challenging, that the PEx is over the ocean.

Our first thought was to build a ROM module with PSOP-44 sockets and then he could burn his own Flash chips and experiment until he got something working. However, when I built the ROM module with sockets and tested it in a 9500 (with 9500 programmed ROM chips) it did not work. I just cannot get the ROM (Flash) module to work with socketed chips.

So leaving out a lot of intermediate testing having to do with it being a really long time since I built any of htese, I'm going to solder flash chips directly to the module which are programmed with code from a downloaded (CopyROM) PEx ROM image.

The thing that worries me about this approach is that when I use CopyROM to extract the 9600 ROM, it does not match the images whcih I read directly from the desoldered 9600 ROM chips. CopyROM images from the IIci match images read directly from the IIci chips. So, hmmmm.

Yes, I'm taking the interleaving into account. My chip programmer will take a complete ROM image and interleave it across four (or more) chips.

Yes, the PEx ROM module seems to be identical to the x500/x600 family ROM module and the ANS ROM module for that matter.

Does your PEx have a ROM? I don't mean the two little PLCC32 chips, but the actual ROM DIMM that goes in a socket on the board?

 

[Trash80toHP_Mini]

hrmmm . . .

First, my PEx board has the two small sockets filled, I believe these sockets were intended for ROM development. My PEx board faithfully gives the proper startup chime, at power on, EVERY TIME! But gets stuck there, even with a Sonnet Crescendo G3 Accelerator Card that ought to work in it!

IIRC, there were pads on the MoBo for for the shipping unit's ROMs and the ROM DIMM was only intended for ROM upgrades, as was Apple's usual practice.

Back on topic: 8-o

There are a LOT of 1 & 2u PCI risers available for a reasonable amount of money. Hopefully I'll be getting a Micro ATX Dual Core Atom board and a 2 GB stick of RAM for it tomorrow. It may wind up in the ComPaq Portable II hack or in the very interesting digital STATION 910 case that's been busy snaring dust bunnies ever since I gutted it. It's a mid-tower design, pre ATX, with a center mounted riser setup for the slots that's perfect for what I'd like to do. The first test I'll do on the Intel board is try out a 6500 or 6400 riser in it after I've checked out the power spec. It's likely 32 bit 3.3v from the looks of the documentation, but I haven't got it nailed down yet. The 6x00 boards are right angle, but the rackmount PCI risers are "left angle" to have the slots hang off the other side of the riser. One could conceivably test one card in the bottom slot of the standard 6x00 riser and put a rackmount riser in the top slot to give one or two extra PCI slots in order to test the actual addressing limitations of the 6x00 with cards sticking up perpendicular to the MoBo. Might even make for an interesting RetroNeXTCubeHack™ or just use a 3 slot "left angled" riser and forgo COMM-Slot card access with the third full PCI slot, using that address over the PCI Bus. Dunno, it's late and my vacation ends soon. Gotta get some sleep . . .

 

[Trash80toHP_Mini]

OOOOOOHH!!!!!!!!!!!!!!! 8-o

+

=

:?:

The Left Angle Riser looks like it'll probably clear the COMM Slot II Ethernet card! [] ]'>