ProTERM without interrupts

Usage

In the Install Modem Port dialog, the entry Apple Super Serial Card must be choosen.
In the Install Printer Port dialog, the entry Apple Super Serial Card must not be choosen (choose Pascal 1.1.1 Printer Driver instead).
If an unusable installation keeps ProTERM from starting up, the file PT3.BIOS must be deleted.

Super Serial Card

The Apple II Super Serial Card (SSC) is built around the 6551 Asynchronous Communications Interface Adapter (ACIA) serial I/O chip.

6551

The 6551 can store only a single received byte. Therefore it is of utmost importance for the Apple II program to retrieve that byte from the 6551 before the next byte is completely received - as this next byte just overwrites the previous byte. Rather simple Apple II programs try to check the 6551 receive status often enough to notice when a byte is completely received and retrieve it then. Sophisticated Apple II programs usually have the 6551 trigger an interrupt when a byte is completely received. The interrupt handler retrieves the byte from the 6551 and stores it in a ring buffer for the main program to read it later.

6551 Interface Emulation

A true 6551 emulation behaves of course like the 6551 in every aspect. In contrast, a 6551 interface emulation has more freedom. A major difference is usually that the interface emulation doesn't only store a single byte but a lot of bytes. Often this isn't a deliberate decission but rather an implcit attribute of the data channel used to feed the emulated 6551. Think of TCP or USB which have significant receive buffers.

A 6551 interface emulation just never overwrites the previous byte with the next byte. It keeps the next byte in some large receive buffer until the Apple II program has retrieved the previous byte.

For a simple Apple II program that periodically checks the 6551 receive status, this works perfectly fine: Everytime the program checks the 6551 receive status, it sees a completely received byte. The program then retrieves the byte and the emulation loads the byte from the receive buffer into the emulated 6551. This way the programs both runs with maximum speed and controls the emulation speed. Usually that results in the unmodified(!) program receiving data much faster than with a true 6551.

But for a sophisticated Apple II program that uses interrupts, things aren't that nice. The emulation needs to decide when to trigger an interrupt without knowing how fast the program retrives bytes from its ring buffer. There are basically two approaches:

Limit the interrupt rate to the byte receive rate of the true 6551. The downside is that the program cannot receive data faster than with a true 6551.
Don't limit the interrupt rate at all. The downside is that bursts of received data larger than the ring buffer of the program cause the program to loose some data.

AppleWin

The SSC emulation of AppleWin can work both as:

True 6551 emulation using a host PC COM port as data channel
6551 interface emulation using TCP as data channel

The AppleWin help file says:

TCP mode doesn't throttle the serial data-rate, so after reading the Status register (to clear the Rx interrupt) the Rx interrupt may get asserted immediately if there is more data in the TCP receive buffer, resulting in a missed interrupt (and therefore missed Rx data).

So it's obvious that AppleWin follows the unlimited interrupt rate approach.

ProTERM

ProTERM is a sophisticated program that uses interrupts. Its interrupt handler stores received data in a 512 byte ring buffer.

So running ProTERM in AppleWin with the SSC emulation in TCP mode means that bursts of received data larger than 512 bytes can't be successfully received. This can easily be verified with this Python script:

import socket, time

data = bytes(b'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz')

sock = socket.socket()
sock.connect(('localhost', 1977))

sent = 0
for i in range(10):
    sent += sock.send(data)
    print(sent)

time.sleep(1)
sock.close()

The script sends a burst of 620 bytes to the AppleWin SSC TCP port. As the screenshot shows, most of those bytes are lost: