localtalk, was Re: pcmcia ethernet card support for m68k?
On Tue, 11 Aug 2020, Brad Boyer wrote:
> I suspect Apple just hogged the CPU during data transfer.
>
Your suspicion is confirmed by Apple's literature. Inside Macintosh:
Devices, p. 7-10, says appletalk "is not interrupt-driven" and "The Guide
to Macintosh Family Hardware", ch. 10, says,
"AppleTalk operates at a nominal data transmission rate of 230.4
Kbaud. This higher rate is possible because AppleTalk communications
are not interrupt driven; during AppleTalk communications, the
AppleTalk Driver has complete control of the computer. Although
AppleTalk uses a synchronous communication protocol, the AppleTalk
Driver runs the SCC chip in asynchronous mode, timed by the 3.672 MHz
clock.
"The maximum possible transmission rate for serial data ranges from
approximately 500 Kbaud on the Macintosh Plus and Macintosh SE to 900
Kbaud on the Macintosh II family. To achieve such data transmission
rates, the SCC would have to be operated in synchronous mode timed by
an external clock, and the serial driver would have to have complete,
uninterrupted control of the computer."
Tech note HW 545 has more.
"If the period of time interrupts are not serviced becomes too great,
the 3-byte receive buffer in the serial chip overflows with incoming
data and characters are lost. This is known as a hardware overrun.
AppleTalk works a little differently. When a packet comes across the
network, an interrupt alerts the processor to that event. AppleTalk
code then disables interrupts and polls in the entire packet without
multiple successive interrupts. This is necessary because of the high
speed at which data is received: 230.4 kilobaud. The overhead of
processing an interrupt for each byte of data would be prohibitive. A
'worst case' situation is that a 603-byte packet (the largest possible
AppleTalk packet) sent to the LocalTalk port takes approximately 26
milliseconds to receive."
This 26 ms interval will cause missed timer interrupts and system clock
drift, unless the timer interrupt was polled too. (We could probably poll
all of the VIA 1 interrupt sources for the duration of the packet, but not
with Egret hardware because of delays in that interrupt handler.)
Another consideration is raised in tech note TB 570. It says, "system
services like AppleTalk require that interrupts not be disabled for much
more than 1/1000th of a second usually. This means if you are doing
something large during your interrupt routine (when all interrupts may be
turned off), you could delay the AppleTalk interrupt so long that data
gets lost."
I think this is quite feasible for the majority of systems. A minority
might drop some packets depending on hardware configuration, etc.
Reply to: