My understanding, which isn't great, is that A/ROSE involves a whole "shared processing" concept between the host Mac and the 68k on the card (the "Cathedral" DSP OS on the Quadra AVs is similar but less convoluted). So with the later driver running the NB card in slave mode, I interpret that to mean the 68000 is still doing something. It's just that whatever that is won't be as over-engineered as A/ROSE.
All of the 8390/8390x cards are based on the 3COM/Novell NE2000 design for the PC, which used the same 8390/8390x Ethernet chips. In that design, the 8390/8390x can DMA only to/from the on-card buffer RAM, and the CPU manually copies to/from that RAM. So it's easy to write drivers for but you can't get great throughput.
SONIC, at least on the Quadras and the LC PDS card, can DMA directly to/from anywhere in the Mac's address space, which cuts out a lot of busywork from the host. And opens up weird possibilities like a replacement driver that does primitive streaming video by just DMAing incoming packets to video RAM. 10BaseT probably isn't fast enough to do anything impressive there though.
Indeed, I tried forcing Glenn's driver to load with the A/ROSE card and it hangs forever once it tries to shuffle AppleTalk traffic on boot (I have auto mounts).
Later drivers in OS 8 do appear to be universal, though -- both the A/ROSE and non-A/ROSE cards share the same Sonic 16-based driver. But, interestingly, the original 3/com-based card (EtherTalk) -- which Glenn's driver targets -- does not; it uses a unique, older driver. Even though both the EtherTalk and A/ROSE-based EtherNet NB are both 3960-based.
Loading A/ROSE isn't required at all with these newer drivers, so it's definitely being bypassed. No extension, no Prep. Still works.
All that said it feels somewhat unlikely the universal driver for EtherNet NB cards has some kind of initialization which stubs out the A/ROSE card, so perhaps the Sonic card was always mapped directly on the bus, but differently than the 3/com card so the card initialization works but actual traffic hangs forever in Glenn's driver waiting for packet data it can't see in the buffer?
FWIW, throughput is always dog slow, and definitely seems slower with A/ROSE than without, so I can see why they killed it. But doing something clever like DMA through faster memory might actually make a difference. Then again, OT is always slow, without more offload I'm not sure it buys anything.
As an aside, it's so confusing talking about the revisions of these cards. For reference again:
EtherTalk NB: Original, iirc, 3/com reference-based card (3960)
EtherNet NB: Apple A/ROSE-based card (3960)
EtherNet NB Twisted-Pair: Apple Non-A/ROSE card (3960)
As a second aside, I need to write something up, but quick and dirty: the later drivers have a really clever stub driver which consults mapping data in the extension resources to determine what driver to load. By adding additional resources to the official drivers and changing around some tables, it's really easy to create custom mix-and-match drivers to try things out.
