Re: Original Apple IIc serial inaccuracy (?)

[dempson@actrix.gen.nz (David Empson)]

Mitchell Spector <mitch2gs@hotmail.com> wrote:

> schmidtd <schmidtd@my-deja.com> wrote:
> 
> >Strangely enough, trying out ADTPro with it on both Windows and OSX,
> >this little IIc was able to transfer disks back and forth flawlessly
> >all the way up to 115.2kbps.  Have computers become more tolerant of
> >timing inaccuracies over time?  Or was the problem only with more
> >hardware-ish devices like modems and printers?
> 
>     It only affected specific manufactures. For example the Apple 
> 1200 baud modem had no issues with the serial port, but certain 
> third party modems (e.g. Hayes, USR, Packard Bell) rated at 1200 
> baud or higher may have run into problems. It was really a hit or 
> miss thing, as the timing deviation was *just* outside the specified 
> operating range. Some  devices could cope, others could not.
> Apple unfortunately only tested their own modems at the time.
> 
>     I don't think it affected serial printers as much as it did modems
> (if at all), as they were less particular about timing.

Modems tend to be fussier because they may be doing bit-level conversion
of an asynchronous data stream to analog modulated signals, with very
strict timing, rather than doing standard asynchronous character
assembly and disassembly, which allows for a fair degree of timing slop.

A 300 bps modem uses FSK modulation (frequency shift keying) which is a
simple voltage to frequency conversion, so it cares nothing about bit
timing and just forwards all high and low levels intact, to the
resolution achievable by the carrier frequency (just over 300 bps is
OK). You can actually transmit any baud rate from 0 to 300 bps through a
300 bps modem, and it is the responsibility of the DTE at the other end
to decode it correctly.

The same technique is used by 1200/75 modems, but they can only transmit
1200 bps in one direction at a time (with a 75 bps reverse channel). I
think this mode might be used by early fax machines, but it wasn't
common with general computer modems.

A 1200 bps full duplex modem uses DPSK modulation (dual phase shift
keying) which uses a single frequency, transmits at 600 baud (600 state
changes per second) and does a phase shift between four states depending
on pairs of received data bits. This means it has to receive two bits
and encode them as a specific phase shift with precise timing. This is
much more likely to be affected by out of tolerance bit timing.

2400 bps has a more complex modulation scheme (QAM = Quadrature
Amplitude Modulation) which involves both amplitude and phase shifts at
600 baud, with 16 possible combinations (encoding four bits per state
change). Faster speeds got even more complex (e.g. Trellis coding, which
I've not looked at to understand it well enough).

Newer modems may do better as they support features like error
correction and data compression. This requires assembling bytes and
grouping them into packets, so they probably have standard asynchronous
buffering on the receive side and would be able to cope with an
unmodified IIc, unless you operated the modem in a special "raw" mode,
or perhaps if it dropped back to raw mode due to the other end not
supporting error correction.

It was probably only the original 1200 and 2400 bps modems (without any
kind of compression or correction) which failed to operate with a IIc.

> I remember some documentation of the issue claiming it only affected port
> 2 (modem) but then the same 6551 ASIC did control both ports 1 and 2. At
> best guess they were simply referring to modems as that is what normally
> would connect to port 2.

Agreed. (Incidentally, in case anyone else is confused - there are two
separate 6551s, one for each serial port.)

-- 
David Empson
dempson@actrix.gen.nz