Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Apple IIe Modem Problem
Message-ID: <13867@smoke.BRL.MIL>
Date: 16 Sep 90 00:17:26 GMT
References: <0093CAF8ED1BF900.00000110@dcs.simpact.com> <90257.155707DCS4@psuvm.psu.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 34

In article <90257.155707DCS4@psuvm.psu.edu> DCS4@psuvm.psu.edu (Dave Shaffer) writes:
>Is your IIe enhanced?

The 80-column firmware in the enhanced Apple //e did indeed reduce the
time during which interrupts were disabled while scrolling the display.

In general, high-speed input via a 2-character buffered USART requires
either an interrupt handler that moves the USART data into an external
input buffer, or frequent polling of the USART status in order to ditto
as soon as feasible.  The old 80-column firmware simply took too long
and incoming data could overrun the USART's tiny internal buffer while
the display was being scrolled.  Quite a few Apple II communication
programs therefore performed their own display management rather than
relying on Apple's built-in firmware.

There is a similar problem when attempting to write data to disk while
more data is arriving via USART; because the Disk II relies on exact
CPU cycle counts for the timing of data being written directly to the
disk, interrupts must be disabled for the duration of an entire block,
which is a serious problem when there is a high-speed source of
incoming data that must be captured before it is lost.

These problems were well known in general to the computing community
long before the Apple II was designed; however, the Apple II was meant
to be basically a single-user hobbyist ("toy") computer that could be
sold for a price that an individual could be expected to afford.  Thus,
the somewhat sophisticated techniques used to solve such problems in
real computers were omitted from the Apple II's design.  There have
been some improvements since then to alleviate the problem of
asynchronous (simultaneous channels of) I/O, as can be seen in the
support (such as it is) for application interrupt handlers in ProDOS
and in the addition of automatic buffering options in the IIGS firmware,
but probably compatibility considerations will prevent the problem from
being fully solved in any Apple II family member.