Larry Afrin <lbafrin%clemson.csnet@CSNET-RELAY> (01/30/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
mlsmith@NADC (01/30/85)
What else is the basic program doing? To get a good communications set both transmit and receive, the basic has to be back to the interface quick enough to catch the echoed characters. If not a control-s and control-q flow control is needed, so data in and data out do not occur at the same time. If all this fails look in writing a machine language I/O handler or compiling basic. I had this problem with a Digital Group computer and their stupid operating system did not set up the Uart's properly. I doubt that's the problem here since the other software works. good luck, mlsmith@nadc.ARPA