> 
> LocalTalk tops out around 230Kb/s. In principle, you could do this in a
> line discipline, IFF:
> 
> 1. The line discipline is fast enough (for whatever value of "fast enough"
> you need on the processor you're gonna run it on)
> 
> 2. The rest of the kernel does not lock out interrupts so long that you
> miss bytes.
> 
> The question is, at a given clock rate for a given processor, how many
> instructions do you get to execute before you start losing bytes out of the
> UART FIFO? The entire execution path for handling bytes off the serial I/F
> must be smaller than that. This is the same class of problems as serial
> PPP, except that the data rate is between four and five times faster.
> 
> My bet for the wide range of platforms that NetBSD runs on is that you will
> have do to it:
> 
> 1. In dedicated hardware that handles the individual bytes, and presents
> whole DDP packets to the rest of the kernel.
> 
> 2. in specially optimized P-DMA code that "knows" about DDP frames.
> 
> 3. without interrupts on while fetching a frame off the serial I/F (same as
> #2?).

Since LocalTalk uses HDLC framing (realistically in hardware) with a
230 kb/s rate from the Digital PLL, there has to be a 3.67 MHz clock
going into the DPLL input. I know of no other chip than the z8530 which
supports this & is a serial controller. Ports which don't feed clocks
to either of the external clock inputs to the chip & don't already
have the right clock there can't do it. Also, interrupt latency needs
to be fast-enough so that the start of frame is seen. mac68k has good
hardware, ISA cards can do it, w/ a little add-on, I think the Atari
hardware could do it (basically a RS232 <-> RS 422 convertor, with
tri-statable transmit buffers run off of RTS). I'm not sure about
the sun3(x) and sparc serial ports. The z8530 chip is running quickly-
enough, but I'm not sure about the clock source. Oh, powermacs w/
MacI/O will certainly do it. They'll be the easiest as they have
DMA and some little hooks which look PERFECT for LocalTalk. :-)

I think options 1) and 3) (and 4) - special DMA) are the likely ones.

> Now, an Alpha or a high-end SPARC might do OK as is, but the rest of the
> platforms that NetBSD runs on will have to be checked for long sections of
> code where serial I/F interrupts are disabled, and those sections will have
> to be (ideally) removed, or (at least!) minimized.

Basically interrupts can't be off for more than about 100 uS or you loose
the whole thing.

> Bill has heard this litany from me before on port-mac68k...

Yes, and I've seconded it. Since I'm about to make it all worse, some
of my suggestions were aimed at keeping things alive during transfer.

Take care,

Bill