Date   : Mon, 28 Jan 1985 21:05:00 EST
From   : Larry Afrin <lbafrin%clemson.csnet@CSNET-RELAY.ARPA>
Subject: Need Help on BASICA Comm Support

[Preface:  I've already bounced the following problem off of info-ibmpc@
usc-isib with no luck (my thanks anyway).  Does anybody on info-micro or
info-cpm have any suggestions short of getting in touch with IBM, Microsoft,
or Andy Fluegelman (sp?)?  -- Thanks, L.A.]

I'm having problems trying to get BASICA to deal with the Async Comm Adapter
at 1200 baud, no parity, 8 data bits, and 1 stop bit.  After I do an
'open "com1:1200,n,8,1"' statement, I send my Hayes Smartmodem 1200 a couple
of "AT"'s to set it straight as to what the communications parameters are,
and then I send it the command to dial the local TELENET access point.
So far, so good -- everything the modem has echoed back to the PC has been
interpreted perfectly with regard to the comm parms.  But from the very
beginning of my TELENET dialogue, something goes amiss.  Everything I send
to TELENET is sent correctly and interpreted correctly, but I have problems
when I try to receive data from TELENET.  It seems that the BASICA comm
support software insists on setting the high bit in the 8-bit data byte I'm
receiving in order to bring the total number of data bits to an odd number.
If the data byte already has an odd number of data bits, then the high bit
is left alone as a zero-bit.  For example, if TELENET tries to send me an
upper case A (ASCII 65 -- the 64 bit and the 1-bit), then what BASICA
delivers to my program in response to an "input$(1,#1)" is an ASCII 193 --
the 128 bit is set to bring the total number of data bits up to 3, an odd
number.  I know this is starting to sound like a parity problem, but is it?...

I've done some investigation and found the following things out.  For one,
TELENET isn't the problem, and neither is my modem or the Async Adapter
card, because when I try to talk to TELENET using the 1200-N-8-1 configuration
through a non-BASIC program (e.g., PC/Intercomm or Smartcom II), everything
works fine.  I've even checked the Line Control Register on the INS8250
chip after opening COM1:1200,N,8,1, and it correctly reports a value of 3,
regardless of whether the comm port was opened by BASIC or a non-BASIC program.
Therefore, it really does appear like the problem is with the input part of
the BASIC comm routines (output at 1200,N,8,1 works fine).  What really makes
this weird is that PC-TALK III uses 1200,N,8,1 for transmitting and receiving
binary and XMODEM files, and as far as I know, I've never seen any reports of
those routines failing because of this apparent error.  That's why I'd like
to think that I'm just doing something ridiculously wrong.

If anybody's got any ideas on what the problem is and/or how to solve it,
*please* let me know.

                                       -- Larry Afrin
                                          Dept. of Computer Science
                                          Clemson University

Please send replies, if any, to:
lbafrin@clemson                 if you're on CSNet
lbafrin.clemson@csnet-Relay     if you're on ARPANet