This article addresses Macintosh computers slower than the Macintosh IIfx. For those systems, the information from the following "d e v e l o p" magazine article presented is accurate.
For 68040 and PowerPC based desktop Macintosh computers, the limit is higher. While no official testing has been done to identify the exact limit of each platform, customers have reported error-free 14.4kbps, 19.2kbps, and 28.8kbps connections with simultaneous LocalTalk connectivity.
All 68030 based Macintosh PowerBook computers are impacted by the 9600bps limit. The 68040-based PowerBook computers have a higher limit (56.6kbps) and customers have reported successful 28.8kbps connections with simultaneous LocalTalk connectivity.
Maximum communication speeds of the Macintosh Serial Ports are limited when both ports are used simultaneously.
What follows is an article from issue 9, Winter 1992 (pages 86-88), of "d e v e l o p - The Apple Technical Journal."
Question: When my hardware device sends data to a Macintosh at 57.6 kbps, characters can get lost if LocalTalk is on and a file server is mounted. Does Apple know about the problem? Is there a solution?
Answer: The specification for the top speed of the serial port on a Macintosh is an absolute maximum given that no other processing or use of the SCC are present. Although the speed of the Macintosh IIfx has now allowed this ceiling to be reached in the presence of other processing, it is just not attainable on other models of the Macintosh except when the machine is dedicated to this purpose.
While AppleTalk remains active there is no guarantee on serial port data transmissions over 2400 bps. The same processor must handle the OS, the Serial driver and the AppleTalk driver (with no advantage of DMA), so the overhead is considerable. Because of the AppleTalk driver's considerations for incoming serial data, users can usually work at up to 9600 bps without any problems. All models in the current product line, except the Macintosh IIfx, are unable to sustain throughput with baud rates beyond 19.2 kbps except when exclusively dedicated to that task.
There is essentially no way to guarantee 100% serial data acquisition when using AppleTalk. This is due to the fact that while the Macintosh is receiving an AppleTalk packet, interrupts are disabled for the duration of packet transmission. What this means in a "worst case" situation is that a 603-byte packet (the largest possible AppleTalk packet) sent to the serial port would take approximately 26 milliseconds to receive. Compare this with asynchronous serial data transmitted at 9600 bps which would only take 1 millisecond to receive. A very realistic situation arises in which 26 bits could be lost during a concurrent AppleTalk/Serial Device transmission. The possibility is further strengthened when there are routers on the network, which send out large RTMPs (Routing Table Maintenance Packets).
To alleviate possible data loss, the AppleTalk driver interrogates the serial port at key times that won't interfere with packet reception. However, the checks are not at regular intervals; they are encoded in the driver as stated above. This means that these random checks may not coincide with the demands of the serial driver, and an occasional character is lost.
This same loss of characters may also occur in conjunction with the Sony driver. If a disk is inserted and it requires special attention (like formatting) then the odds of losing characters is increased. The Sony driver has built-in considerations like the AppleTalk driver (although not as frequent). So you can still lose data at high transfer rates if a disk is inserted during the transfer.
The character dropout also occurs on systems which are not currently running AppleTalk but are receiving serial transmissions from high-speed devices (57.6 kbps) and are performing CPU tasks which require a high amount of memory access (such as a CPU like the Macintosh IIsi or IIci running on-board video in 8-bit mode, or a CPU using VM).
There is, however, a way to ensure reception of high-speed serial data without character lossthrough the use of a Serial NuBus card or other third-party NuBus cards with a dedicated processor necessary to provide higher speeds. The cards in essence operate as dedicated port-handling circuitry. They are able to perform necessary buffering while the processor is servicing other interrupts. This is the reason that network cards such as EtherTalk and TokenTalk can accomplish lossless transactions; they do at least some of their own buffering until being serviced to avoid interference with other operations like receiving serial data.
Alternatively, you may want to develop a custom card yourself that exactly fits the needs of your product. In this case you should look into the Macintosh Coprocessing Platform (MCP) and Apple / Real-time Operating System Environment (A/ROSE) as a basis of this line of development. Development packages for both these products are available from APDA.