Larry Afrin <lbafrin%clemson.csnet@CSNET-RELAY.ARPA> (01/29/85)
[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
William Chops Westfield <BillW@SU-SCORE.ARPA> (02/04/85)
The problem with bit 8 being set to odd provide odd parity is almost certainly telenet. Most communications programs will strip the parity bit from the characters received individually before putting them on the screen or checking them against special characters. It is not usually practical to do this is basic. What you normally want for any kind of terminal is to read 7 data bits, and ignore the parity bit, but I dont remember offhand whether that is one of the basica options. there may also be a telenet pad command to set the parity and number of databits desired, but I dont know what it would be offhand. BillW