> 
> In article <4315.855866721@ux2.sp.CS.CMU.EDU> you write:
> > Why is a line discipline not sufficient?  why do you need special
> > interrupt handlers, etc?  I understand that localtalk runs at a high
> > speed (though i forget what exactly the speed is 8-), and therefore
> > the port needs to be configured specially, but i'd think that the line
> > discipline could do the appropriate stuff without relying on special
> > handlers to receive and transmit data.
> 
> LLAP has a peculiar on-the-wire format.  I'm not sure it can even be
> implemented on arbitrary serial chips.  On some chips it may require
> some expensive operations in software (like inserting a zero bit after
> every 5 one bits, and removing a zero bit after five ones on reception). 
> So if the hardware can do anything extra to help out, you'll want to use
> it, and I don't think those things are expressed well in the Unix async
> tty model. It would seem to me that the least gross way to handle it
> would be to think of an AppleTalk-capable serial port as two separate
> pieces of hardware that hapen to only be usable in an either/or way...
> something like the zstty/zskbd/zsms (or whatever they're called) driver,
> but with the ability to switch their use at run-time.

In reverse order, the interrupt-stealing would basically be turning off
the zstty on a mac's serial port, and turning on an LLAP driver.

As mentioned else-where, LocalTalk runs at 230 kb/s, or 28.7 kB/sec. No,
my math is correct. Not only does LocalTalk run faster than most serial
connections, it uses a synchronous communications mode. So each byte
doesn't have a start bit & a stop bit. Also, there is the above-mentioned
zero-bit insertion. All this is done in hardware on the z8530. I think it
can NOT be supported on arbitrary serial chips (they'll be wanting
non-existant start & stop bits).

Looking closer, the format is basically HDLC/SDLC. Apple took a chip
which could run on a token ring, and ran it slower and made a CSMA/CA
network.

So yes, we do have to put the chip in a mode incompatable w/ normal
serial traffic.

> > What kind of support is actually required to use localtalk on a serial
> > port?  _could_ it be done with just a line discipline?
> 
> I don't think so, from my (limited) understanding. At least, it would be
> inneficient and/or not compatible with all tty devices.
> 
> [This is based on q uick refresher read of Inside AppleTalk, 2nd Ed. I
> don't know how up-to-date that is... anyone?]

Since LocalTalk was fleshed out when the original Mac was being designed,
IA 2nd Edition should be up-to-date for this question. In fact, the low-
level interface is going to be HEAVILY inspired by appendix B. :-)

I think most of the macs we currently support will have a hard time with
over 28 thousand interrupts per second. Apple has always done LocalTalk
in polled mode, so I think we will too.

Basically we will have to put the chip into SDLC mode, and play with some
of the registers.

When we get a packet, we start throwing data into a buffer, waiting for
each byte to come in. At some point in the waiting, we also look at the
modem port to make sure that it's still alive. :-) As the z8530 only has
a 3-byte fifo, we can't stand to wait too much. We also have to notice
if we get an end-of-frame. Another part of the problem against being a
tty-level line discipline is that some of the packets require near-
immediate replys. Many data packets are preceded with RequestToSend
and ClearToSend packets. To maintain spec, a CTS must be sent within
35 uS of the receipt of the RTS.

Apple's (published) implimentation was to interrupt on the first
detection of a clock. Then wait for a packet to come. If we get either
a RTS or an ENQ (address enquiry; for dynamic address assignment), we
fire off a reply from the interrupt handler. :-) If it was a data
packet, we send it to the upper layers.

Since we have to deal with timeouts, I don't really see how to do this
just with interrupts, especially on the supported hardware.

Take care,

Bill