Erik,

Again, great info. I thank you for the education. :-) ==Don

>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>