When we last left Our Hero, he was frustrated by Virtual PC's inability to
successfully probe any PCI devices (including the emulated Ethernet) by using
PCI Configuration Mode 2, which it apparently fooled NetBSD into thinking
it could use.

Thanks to Patrick Welche, I now have an i386 SSTO 1.2G boot floppy from around
July 7th, which was compiled with "options PCI_CONF_MODE=1" to force a
configuration mode 1 PCI bus probe.  The results are a little more interesting
now ...

NetBSD 1.2G (INSTALL) #4: Fri Jul 18 12:08:20 BST 1997
    prlw1@quartz.newn.cam.ac.uk:/usr/src/sys/arch/i386/compile/INSTALL
cpu0: family 5 model 3 step 5
cpu0: ConnectixCPU  (586-class)
real mem  = 14286848
avail mem = 10510336
using 200 buffers containing 819200 bytes of memory
mainbus0 (root)
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0
pchb0: vendor 0x8086 product 0x122d (rev. 0x00)
vendor 0x8086 product 0x122e (ISA bridge, revision 0x02) at pci0 dev 7 function 0 not configured
vendor 0x8086 product 0x1230 (IDE mass storage, interface 0x80, revision 0x02) at pci0 dev 7 function 1 not configured
vendor 0x5333 product 0x88b0 (VGA display) at pci0 dev 8 function 0 not configured
de0 at pci0 dev 9 function 0: can't read ENET ROM (why=-4) (000000000000000000000000000000000000010100050228c304004100444534
de0: 21041 [10Mb/s] pass 1.1
de0: address unknown	[NB: Real Ethernet address of Mac is 0:5:2:28:c3:4]
isa0 at mainbus0
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 0x378-0x37b irq 7
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0: <CntxCorpHD>
wd0: 104MB, 973 cyl, 13 head, 17 sec, 512 bytes/sec
wd0: using 16-sector 16-bit pio transfers, lba addressing
wdc1 at isa0 port 0x170-0x177 irq 15
npx0 at isa0 port 0xf0-0xff: error reporting broken; not using
pcprobe: reset error 3
pc0 at isa0 port 0x60-0x6f irq 1: color
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
biomask c040 netmask c040 ttymask c0c2
md0: internal 1537K image area
boot device: fd0
root on md0a dumps on md0b
root file system type: ffs
Enter pathname of shell or RETURN for sh:

The net result, as can be seen, is that the emulated PCI devices (ISA bridge,
IDE, and VGA display) are now all correctly found, and the emulated Ethernet
is *almost* successfully probed and configured.

One of the interesting things about the de0 message ("can't read ENET ROM")
is that the string embedded with it does, actually, contain the real Ethernet
address of the PowerMac (0:5:2:28:c3:4).

Looking in /usr/src/sys/dev/pci/if_de.c I find

[...]
    if (bcmp(&sc->tulip_rombuf[0], &sc->tulip_rombuf[16], 8) != 0) {
	/*
	 * Some folks don't use the standard ethernet rom format
	 * but instead just put the address in the first 6 bytes
	 * of the rom and let the rest be all 0xffs.  (Can we say
	 * ZNYX???) (well sometimes they put in a checksum so we'll
	 * start at 8).
	 */
	for (idx = 8; idx < 32; idx++) {
	    if (sc->tulip_rombuf[idx] != 0xFF)
		return -4;
	}

and when it returns

    if ((retval = tulip_read_macaddr(sc)) < 0) {
        printf(": can't read ENET ROM (why=%d) (", retval);
        for (idx = 0; idx < 32; idx++)
            printf("%02x", sc->tulip_rombuf[idx]);
        printf("\n");

So my guess here is that the way that Virtual PC emulates the ROM for the
DEC 21041 Ethernet is in yet another non-standard format that doesn't catch
any of the cases that Matt Thomas' driver works for.  Hellllloooooo Matt  :-)

I think if there was a way to modify if_de.c to handle this wacko case and a
way to detect the Virtual PC (dunno how) and force PCI Configuration Mode 1
automagically, we might really be able to get somewhere with this thing ...

Getting closer,

	- Greg