Hello,

> This particular card is specific to the Umax S900 - I've never seen 
> any other variant of the PowerMac 9500 motherboard that has that 
> strange little slot behind the PCI slot.
Thought so, UMAX seemed to be particulary proud of it.

>  Also, the S900 is the only 9500 variant that uses a PCI-PCI bridge to 
> get six PCI slots; all the others use a mainbus to PCI bridge. I 
> worked for Apple Computer during the "clone era" and have examples of 
> a number of these in my collection of antiques.
Well, the PCI-bridge hack was more of a bugfix than a hack actually - 
the new code just barfed when OF didn't offer usable IRQ information, 
all I added was a fallback that allows the lower 4 slots to inherit 
their IRQ from the bridge like in 1.6.2 - this code shouldn't do 
anything bad on other platforms.

> All PCI PowerMacintoshes (and clones) use OpenBoot Firmware (IEEE 
> 1275) and specifically identify themselves in the device tree. That 
> being the case, any strange hacks needed to make the E100 card work 
> can be executed contingent on the system identifying itself as a Umax 
> (SuperMac) S900.
Ok, I'll see if I can do it that way.
Do you have any idea if the interrupt assignment is static ( read: will 
the E100 slot always use IRQ 23 ) ?
Hmm, so I'll add something to pci_machdep.c which is only active on 
S900s and configures the ethernet part so the tulip driver can run 
almost unchanged - only with an additional quirks line ( there are 
already a lot of them and are selected by the first 3 bytes of the MAC 
address )
maybe something like
#ifdef E100_HACK
check for a DEC 21140 on PCI 0:11:0 - there's either the E100 or 
nothing at all
configure it with some hardwired values, maybe with values derived from 
PCI 0:0d:0 - this should definitely be the ISP in this case - at least 
the IRQ entry could be copied.
#endif
in ficpci() ?
The quirks entry in the tulip driver is almost identical to the Asante 
quirk - only a different name and a different trigger, but it needs 
it's own one because of the different MAC address ( and you don't 
really want to see your E100 identified as some Asante board, do you? )

> I have two of these systems, but I haven't loaded NetBSD on them yet. 
> Both are dual processor 604e's, one is 2x200 MHz, and the other is 
> 2x250 MHz. Both have E100 cards, so I have a definite interest in 
> seeing this work. Please do file a PR with the diffs.
cleaning it up will take a while, I could mail you a preliminary 
quick-and-dirty version if you want.
( my S900 was 2x604e@233MHz, now it's 300MHz G3 - too bad there are no 
G3 cards for the Gemini slot... )

> Have you had any luck with the Qlogic isp(4) driver yet?
Nope, although I didn't really try yet. This is an entirely different 
problem - the isp driver attaches just fine but barfs after trying to 
load some firmware into the chip ('RAM checksum error'). There are 
several weird things about it:
- the driver thinks it's a fast-wide ISP1020 while it's labeled as as 
1040A and definitely ultra-wide
- the PCI device ID indeed seems to indicates a 1020
- skipping the firmware update hoping that OF already initialized it 
properly didn't help, the OF entry doesn't support booting anything 
else than MacOS so maybe it's not initialized after all.
So it seems that the ISP runs in some quite unusual environment, 
probably with a non-standard amount of RAM which lets the check with 
the standard firmware ( which probably has some hardwired value for RAM 
size ) fail - I seriously don't know. Maybe I should try to extract the 
firmware image from the UMAX updater and compare it with the different 
images that come with the isp driver - UMAX claims to use the latest 
firmware from QLogic - so does the NetBSD driver.
I'll definitely spend some more time with it, even if it will never be 
able to boot NetBSD directly - although the ROM is flashable, maybe 
there's a working FCode image for it somewhere...
The OF entry is FWB,JackHammer - maybe bugging FWB yields some details.

have fun
Michael