Re: Ethernet card?

[derek@slab.cisco.com (Derek Taubert)]

In <53lg7j$d56@alpha.vaxxine.com> Michael Hackett wrote:
> Marc Sira (toh@freenet.Victoria.BC.CA) wrote:
> > 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.
> 
> Yes, this has always been my biggest complaint about the RamFast, that it
> has no generic device interface (or so I've been told), so it only
> supports the devices the ROM knows about, and at this point an update from
> Sequential seems unlikely. I think the Apple card would support the
> Ethernet adaptors fine with a suitable driver.

Read my previous post about interrupts.  I'm sorry, but you just can't write 
a driver that continuously polls the ethernet device.  You'll either spend 
all of your time polling, or you'll loose packets while you're off doing 
something else.  The GS is not a fast machine, and the OS is far from being 
pre-emptive.

> > 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. Basically the problem 
is
> > that this might require rewriting much of the GSOS networking code from 
the
> > ground up, to get a nice layered network model you can work with. Perhaps
> > someone familiar with how Localtalk is done on the GS could comment?
> 
> Could be, I didn't get that far.

Remember the Apple EtherTalk card?  There is a way to use a different 
interface with the Appletalk stack.  However, I think you have to implement a 
good deal of the protocol stack to hook into the same location.  The Apple 
EtherTalk card took care of several low level protocols with its on-board 
65816.

> > I don't know how much I can offer in the way of writing an actual GS 
driver
> > for this thing, but I think I do have a good chance of sussing out the 
API
> > for Linux, and I'd be happy to give anything I come up with to a GS
> > developer. All I need now is time to work on it. :O
> 
> Getting the protocol documented would be a good first step at least.

Figure out the entry points to the driver and you'll understand what I'm 
talking about regarding interrupts.

--
 _             ___                    
| \ _ ._ _ |    | _.   |_  _ ._ _|_   taubert@jacobs.geeks.org
|_/(/_| (/_|<   |(_||_||_)(/_|   |_   NeXTMail welcome