> 
> 
> Localtalk is synch.  AFAIK, the traditional Mac implementations were a
> ``squashed stack'' that interleaved reading bytes from the SCC and
> interpreting those bytes as Localtalk.  Interrupts were effectively
> disabled for an entire packet time.  Given that LocalTalk is
> synchronous and _needs_ to preserve packet boundaries -- i.e., AFAIK,
> one can't leave the serial line idle, as one can with asynch protocols
> -- there may be no *alternative* to disabling interrupts for an entire
> packet time, at least on transmit.

Yep, though the interpretation was done after the packet arrived, it
was all done w/ interrupts off.

> Erik Fair writes:
> 
> >My bet for the wide range of platforms that NetBSD runs on is that you will
> >have do to it:
> 
> Well, you forgot
> 
> 4) NetBSD platforms with `standard' memory-mapped 8530 chips and drivers,
>    that *also* have motherboard DMA engines that can feed entire packets
>    to the 8530, as long as the host CPU isn't also trying to drive the
>    serial chip.

Do we have any such beasts??? All of the 8530 drivers I've seen run in
P-DMA mode. That's why I haven't considered the pmax & alphas. The dec
implimentation actually accepts an external clock source, but since the
chip's interrupt seems to be low on the totem pole, I've not thought
about it.

Am I wrong? I'd be happy to be corrected.

> Also: What's the interrupt latency on the hardware for which Bill
> wants to implement LocalTalk? How deep are the transmit and receive
> FIFOs on the serial hardware on those platforms (3 chars comes to
> mind.)  Is it feasible to keep an SCC running flat-out, using
> interrupt-driven code, even with PDMA?
> 
> I don't know, and so I'm asking.  I suspect the answer on
> 68k Macs may be `no'.

I feel the answer is so close to 'no' on non-DMA macs (all 68k except
for the Q660 & Q840) that I'm not even going to try.

Take care,

Bill