Re: Ethernet card?

[dempson@actrix.gen.nz (David Empson)]

Marc Sira <toh@freenet.Victoria.BC.CA> wrote:

> I get a maximum of about 80KB per second with FTPs on a 100MHz PPC
> Powerbook, even with the Mac's cooperative multitasking and the EN/SC's
> drivers running in (ick) 68K emulation. This is pretty respectable,
> considering the circumstances (for comparison, I get way over 500KB per
> second from a crappy 16-bit ISA ethernet card in a 100MHz Pentium running
> Linux, but only about 60KB per second on the same machine in the
> cooperative multitasking environment of Windows 3.1 or 95 (your choices
> are yuck, or yuck). I've no idea what sort of throughput one might expect
> from the GS - if a decent DMA driver could be written, it might actually
> be respectable. :)

You will get DMA transfer as a freebie if you use the Apple High-Speed
SCSI card.  All the low-level stuff is handled by the card firmware
under ProDOS-8, or by the SCSI Manager under GS/OS, so you only need to
concentrate on the command set and interacting correctly with the rest
of the IIgs system software.

> The only issue I can think of with such a driver on the GS is that the
> Ramfast appears to have specific device support built into the ROM, and
> this might interfere with an unexpected device like a communications
> adaptor. The more generic Apple HS SCSI might be better suited, though I'm
> sure it has its own issues.

Possibly.  The only one of significance is that the SCSI Manager on the
IIgs relies on the SCSI device type to identify devices.  It presents
this to drivers in a modified form to allow them to pick which devices
they will support.

> The EN/SC on the Mac requires two drivers; one ethernet driver resource
> (probably something of a stub to plug into the existing network support on
> the Mac) and one SCSI driver that loads as an extension. I've also noticed
> that it apparently predates SCSI-II, and doesn't report itself to the host
> as a nice SCSI-II COM device (it has garbage in the device type field).

Do you mean random garbage or consistent garbage?  If it is random, then
it will probably not be possible to use this - another driver might
claim it if it ever reported that it was a hard drive.

If it is consistent (but undocumented) then the SCSI Mangaer may report
it as an "unknown" device.  The device driver could claim all unknown
devices then do SCSI I/O calls to get more specific information, and
un-claim devices which turn out to be something else.

> I can actually think of one other issue - the Appletalk support on the GS
> is likely to be totally tied to the Localtalk port, so providing Ethertalk
> support with a third-party driver might be tricky.

There is no documentation on how to replace the lowest levels of the
AppleTalk protocols, short of patching out all the entry points to the
LocalTalk Link Access Protocol (this is reasonably straightforward, but
there will be other issues such as internal operation and interaction
with other interrupt handlers).  Another issue is how the low-level
protocols deliver packets to DDP (Datagram Delivery Protocol, which is
the network layer of AppleTalk).  There is no documented call for this.

Apple had implemented support for their EtherTalk card in System 6.0.1,
and 6.0.1 was shipped with this support included, with the exception of
the actual device driver and the modified "Network" control panel which
would have allowed selecting between LocalTalk and EtherTalk.

Some disassembly may be in order...

If you wanted to support protocols other than AppleTalk, it would be
necessary to include some kind of low-level protocol routing facility,
which would identify which protocol stack was to be used for each
incoming packet.  A totally different protocol stack mechanism would be
needed for TCP/IP support.

-- 
David Empson
dempson@actrix.gen.nz
Snail Mail: P.O. Box 27-103, Wellington, New Zealand