> If the Mach64 is not recognized as a PCI device, what is getting recognized as
> 
> 	pc0 at isa0 port 0x60-0x6f irq 1: color

the Mach64 also presents the standard VGA interface; that's what is
beeing seen there.

the case of PCI (E?)IDE controllers that show up as normal ISA "wdc"
controllers is similar.


> Will I be able to get XFree86 to run on the Mach64 if it's coming up as
> "not configured"?  I guess for some weird reason I would have expected to see
> something like
> 
> 	pc0 at pci0 bus 0 device 6: ATI Mach64, <...>: color

That's almost The Right Thing To Do, actually...
In my little world, it would be:

pcivga0 at pci0 device 6: ATI Mach64 (rev. 0x??)

then maybe:
pcivga0: color

or other relevant information.  (pci0 should imply the PCI bus number,
so it shouldn't be stated in the autoconfig message.  each pci bus
(i.e. primary and potential secondaries) should be its own "pci" unit.


on PCI Alphas, dmesg output looks like:

NetBSD 1.1-NetBSD_Alpha-951127+ (TOMMY) #248: Sat Dec  9 18:08:01 EST 1995
    cgd@bunnahabhain.pdl.cs.cmu.edu:/usr/src/sys/arch/alpha/compile/TOMMY
AlphaStation 200 4/233 ("Mustang II"), 233MHz
8192 byte page size, 1 processor.
real mem = 67108864 (2064384 reserved for PROM, 65044480 used by NetBSD)
avail mem = 56926208
using 409 buffers containing 3350528 bytes of memory
mainbus0 (root)
cpu0 at mainbus0: EV45 (21064A), Pass 3
cpu0: VAX FP support, IEEE FP support, has I/O access
apecs0 at mainbus0: DECchip 21071 Core Logic chipset
apecs0: DC21071-CA pass 2, 64-bit memory bus
apecs0: DC21071-DA pass 2
pci0 at apecs0 bus 0
ncr0 at pci0 device 6
ncr0: restart (scsi reset).
scsibus0 at ncr0
ncr0 targ 0 lun 0: <DEC, RZ26L    (C) DEC, 442D> SCSI2 0/direct fixed
sd0 at scsibus0: 1001MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sec
sio0 at pci0 device 7: Intel 82378IB PCI-ISA Bridge (System I/O) (rev. 0x03)
isa0 at sio0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
lpt0 at isa0 port 0x3bc-0x3c3 irq 7
pckbd0 at isa0 port 0x60-0x6f irq 1
wsc: pckbd0 attached as input device
clock0 at isa0 port 0x70-0x71: mc146818 or compatible
de0 at pci0 device 11: DC21040 [10Mb/s] pass 2.3 Ethernet address 08:00:2b:e5:11:0c
de0: enabling 10baseT/UTP port
tga0 at pci0 device 12: DC21030 step C, board type T8-02
tga0: 1280 x 1024, 8bpp, Bt485 RAMDAC
wsc0: tga0 attached as output
wsc0: console
ppb0 at pci0 device 13: Digital Equipment DECchip 21050 PCI-PCI Bridge (rev. 0x02)
pci1 at ppb0 bus 1
ppb1 at pci1 device 4: Digital Equipment DECchip 21050 PCI-PCI Bridge (rev. 0x02)
pci2 at ppb1 bus 2
pci2 device 7: NCR 53c825 (class: mass storage, subclass: SCSI, revision: 0x02) not configured
pci2 device 8: NCR 53c825 (class: mass storage, subclass: SCSI, revision: 0x02) not configured
pci2 device 9: NCR 53c825 (class: mass storage, subclass: SCSI, revision: 0x02) not configured

etc.

some of that (wsc-related stuff) needs fixing up, but most of it's OK.
(I don't currently have a PCI VGA controller in any of my boxes...
it's buried under about a foot of paper here on my desk...  8-)

the code that implements the PCIVERBOSE kernel option gets you "device
name" printed for unconfigured devices whose info is known (e.g. the 3
NCR 53c825s i've got, which i removed from my kernel configuration
since i'm not using them right now and the ncr driver ... freaks out
with them...  8-)

Note that some of the code that implements these drivers,
e.g. "pcivga" and "ppb", is meant to work on all devices of that type
(i.e. all PCI VGA boards should work with pcivga)...

Because of the way the autoconfig code works, it's possible to have a
"generic" pcivga driver, to write more specialized drivers for certain
boards that pcivga recognizes, and have everything work out the "right
way."


chris