One more word of warning about LocalTalk:

Real network interfaces deal in packets - one interrupt for receiving a
packet, one interrupt for transmitting a packet. Packets contain tens,
hundreds, or low thousands of characters, each. This is efficient and low
overhead. Ethernet works this way.

Asynchronous PPP deals in characters, one interrupt per character. It has
high overhead, but we don't care all that much because we generally don't
speak it faster than 57600 bps (call it 5760 cps, if you want, or 5760
interrupts per second), and if you can tweak your serial interface drivers
to handle it, all is well (and it does perform an important function: cheap
access to the Internet). The overhead is there, but bearable. The turning
this trick tends to be a question of how many instructions you can bum out
of the serial driver interrupt service routines (Pseudo-DMA, anyone?).

LocalTalk is also serial based, but at a factor of four faster than typical
asynchronous communications - ~237,000 bits per second, or 23,700
interrupts per second (prolly not quite that many, since it is synchronous
and you're not wasting 10 bits per 8 bit character like asynch, but it's
certainly of that order of magnitude), if you can even deal with interrupt
overhead (save context, restore context, repeat, repeat) at that speed.
Most of the older Macs just plain can't, so, under MacOS, you don't - you
drop into a tight loop of a minimum number of instructions that sucks
characters out of (or shoves them into) the SCC chip as fast as the
processor can manage that, with all interrupts disabled. On a single-user
machine with synchronous, non-pre-emptive multitasking OS, this is probably
OK - after all, the user asked us to transfer or print that file, didn't
he? He can wait for it to complete!

The upshot is that the principal advantage of LocalTalk (it's CHEAP, and
"fast enough" for lots of things) is paid for in processor performance. We
can probably (with some effort) make LocalTalk/AppleTalk work under NetBSD,
but using it will suck the performance of whatever machine you have, a lot.
Given the implementation technique I've described, the machine will seem to
freeze when LocalTalk is being used.

There are only two exceptions that I know of: the Mac IIfx and the Quadra
900/950; they both have 6502 CPUs (Apple ][ lives!) as I/O processors, to
relieve the main processor of the aforementioned per-character overhead. If
IOPs are properly programmed and used, those would make really kick-ass
LocalTalk machines (hell, externally clocked, those SCC's can do a megabit
per second; I've seen it done, and with an IOP to do the byte stuffing...).
Just a "small matter of software" (and, as always with Apple, hardware
documentation).

So, for those of you clamoring for LocalTalk, beware - the reality of
having a working LocalTalk network under NetBSD may not be as nice as you
think it will be.

	g'night,

	Erik E. Fair <fair@clock.org>