Pete's QBASIC Site

I'm trying to update a program written in 1992, supposedly in QuickBasic. Most of it ported just fine into Freebasic (with the -lang qb option), but the compiler didn't recognize two commands sprinkled around the serial I/O subroutines:

COM(1) ON
....
COM(1) OFF

I rem'd all those out, and it compiles (but I can't try it until I've fixed the software timing loops written for a 286), but what in heck did I delete? I don't remember any such commands, and my one surviving QuickBasic book doesn't list them. There are also OPEN ... #1 and CLOSE statements in the program, so it isn't doing that. Could it possibly be toggling the hardware handshaking bits? (The device I'm controlling does need hardware handshaking.)

File Edit View Search Run Debug Calls Options Help
┌──────────────────── HELP: COM(n) Statement QuickSCREEN ──────────────────┤↑├─┐
│ ◄QuickSCREEN► ◄Details► ◄Example► ◄Contents► ◄Index► ↑
│──────────────────────────────────────────────────────────────────────────────░
│COM(n) - an event trapping statement that enables, disables, or inhibits ░
│ event trapping of communications activity on a specified port ░
│ ░
│Syntax ░
│ COM(n) ON ░
│ COM(n) OFF ░
│ COM(n) STOP
│ ░
│ ■ n is the number of the communications port, either 1 or 2 ░

◄QuickSCREEN► ◄Details► ◄Example► ◄Contents► ◄Index►
─────────────────────────────────────────────────────────────────────────────
ON COM(n) - Event trapping statement that specifies a subroutine to
branch to when characters are received at communications port n
Syntax
ON COM(n) GOSUB {linelabel | linenumber}
■ n, an integer expression, indicates one of the serial ports,
either 1 or 2
■ linelabel or linenumber is the first line of the event-handling
subroutine

Thank you, Burger. There not being any ON COM or any other event-trapping code in the program, those COM(n) ON/OFF commands weren't doing anything. Maybe the original author started to use event-trapping, but gave up on getting it to work and changed to polling the port. (It seems like I've been through that, myself - and in assembly language!)

You can get data from the port directly if you use OUT or INP, but you need to know the port addresses. Windows can tell you that, but only COM 1 or 2 can be used when you OPEN COM.

NT or XP computers need PortTalk, which is free download

Ted

The handshaking routine does use an INP to poll the RTS handshake, and that's where it's stopping. I can see that the address is within the COM 1 I/O address range of 03F8-03FF, but to really understand this I need to know the definition of each byte in there, and even how some of them break down into bits.

Do you know an on-line reference that would show that? My books with such things for PC's are long gone, and I've tried to google for it, but haven't figured out a search that's specific enough to not list thousands of different instructions on how to reach the Windows port settings, not to mention serial adapters for sale...

If you're interested, here's the original code:

SUB RTS '********************************************************************
CLOSE #1, #2
OPEN "COM1:9600,N,8,1, CS" FOR RANDOM AS #1
FOR I = 1 TO 400 'zeitverz?gerung bis RTS "0" ist
J = 1 + I
NEXT

COLOR 23, 0
RWA: Y = INP(&H3FE) 'RTS testen
LOCATE , 65: PRINT "Please wait!";
IF Y = 48 THEN GOTO ROK ELSE GOTO RWA

ROK: COLOR 7, 0
LOCATE , 65
PRINT SPACE$(14);
PRINT #1, DC2$; '(DC2)

'****************************************************************************
END SUB

This is called between sending or receiving each string. The bits of documentation that came down from 1992 indicate that the FOR delay loop has to be tuned to the computer speed by trial and error; I can do much better than that once I figure out what the delay ought to be in milliseconds or time ticks... (That German comment says something like "time delay until RTS is 0", but I think what it's really doing is giving the device at the other end time to see whatever is toggled by the CLOSE...OPEN and set the RTS/CTS handshake bit.)

Currently it's hanging up at the loop with the INP(), reading 0b10110000 forever when it expects 0b00110000. That might be because the timing is wrong, or because the device I'm trying to control has a bad serial port, but I'd like to know what the wrong bit means. I need to find a breakout box or build a three-headed cable and get out the oscilloscope to see what response we're getting from the device, if any.

Try looking at my Q-Basics program dowloadable here:

http://www.qbasicstation.com/index.php? ... &filecat=3

Place the program files into your QB45 folder.

Chapter 11 (QBasic11.bas) has port information............There are a couple of different ways to acess Serial port information.

Ted

The device I was trying to connect had a dead serial port, but I found another sample device and I'm getting further with it.