Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!codas!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.sys.cbm
Subject: Re: modem woes
Message-ID: <1718@killer.UUCP>
Date: Sat, 3-Oct-87 02:38:57 EDT
Article-I.D.: killer.1718
Posted: Sat Oct  3 02:38:57 1987
Date-Received: Wed, 7-Oct-87 01:47:26 EDT
References: <2442@cbmvax.UUCP>
Organization: Bayou Telecommunications
Lines: 35

in article <2442@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) says:
> Few people realize there is a difference, too, between direct connections
> and communicating with a modem.  A modem typically communicates at the high
> end of the spec-ed range of any data rate.  For example, at a baud rate of
> 1200, a modem communicates with the terminal at something like 1210.  This
> is why you have to "tweak" the C64/128's data rate- it's dead-nuts-on 1200,
> and the +/- range it can accomodate is small.  Hence you see alot of garbage.
> If the terminal package allows you to adjust the rate for communicating with
> a modem you should, especially for the more critical faster rates.

That is one problem, dealing with recieving. There is another problem, fairly
famous and well-documented by Steve Punter, in transmitting characters to the
fake RS232. The way I heard it described was as a synchronization error. I
don't know, but I do know that it is "solved" by just waiting for the current
character to be completely outputted before adding another character to the
output buffer (necessary anyhow for implementing software flow control --
after all, you're sitting in a loop looking for ^S anyhow!). If you dump
characters too fast to the buffer, they get garbled. Steve Punter has a more
sophisticated fix, that, I assume, makes sure that the NMIs don't grab a byte
while the CHROUT routine is trying to save a byte. However, I haven't spent
much time deciphering Punter's routine (the guy documents like a demon -- one
comment per 1,000 lines, just like in Unix sources!).

All of this would, of course, be solved quite readily just by hanging a real
UART off the cartridge port. Only problem is that most disk speedup products
live there, too..... they'd have to be designed to live together in peace.
And, considering that most C-64 terminal software doesn't bother poking the
fake UART with numbers anymore (just shoving numbers into the "user defined
baud rate" bytes), compatibility might be a real problem....

--
Eric Green   elg@usl.CSNET     "... hanging on in quiet desperation
{cbosgd,ihnp4}!killer!elg          is the english way,
Snail Mail P.O. Box 92191          the time is gone, the song is over,
Lafayette, LA 70509                thought I'd something more to say....."