Tweet
The following code WORKS (it is in a PBU) in that it correctly
notifies the parent EXE if the user has dropped carrier, so the
EXE (a BBS door) can exit gracefully. However, if I use this
code, then the PB/DOS 3.5 program stops inputting characters from
the user's end. The serial port is opened with PB's builtin
OPEN "COM..." command. I tested it by calling my own BBS with one
of my phone lines, while the BBS node used the other one. The terminal
program I used was Telix for Windows 1.15d (licensed). If I use
PB's sample code that ships with PB/DOS 3.5, in re the Carrier function
contained in COMMUNIT.BAS, then it does work. (had to do minor
additions to the PB code so the function returned 0 if there IS
a valid carrier detect - MY function tells the parent EXE if the
carrier is DROPPED). Does PB's code work because it directly accesses
the modem status register, rather than using INT 14H, as mine does?
In other words, is my code causing a conflict because it uses INT 14H,
and PB's builtin comm functionality also uses it?
OK, 'nuff said. My code follows. I will not spell out the two
$INCLUDE lines - the two included files contain NOTHING but
the appropriate registers' PUSH / POP (save/restore registers):
Any help gratefully received. 
ADDED: further testing has shown that it is NOT an issue with the
PB comm subsystem. It is apparently directly tied to this particular
service of INT 14H. This service's sole purpose is to retrieve the
serial port's status. Maybe the way it is implemented causes it to
"hang" if the port is active (i.e., the modem is online with another
modem)?
------------------
[This message has been edited by Clay Clear (edited November 07, 2002).]
notifies the parent EXE if the user has dropped carrier, so the
EXE (a BBS door) can exit gracefully. However, if I use this
code, then the PB/DOS 3.5 program stops inputting characters from
the user's end. The serial port is opened with PB's builtin
OPEN "COM..." command. I tested it by calling my own BBS with one
of my phone lines, while the BBS node used the other one. The terminal
program I used was Telix for Windows 1.15d (licensed). If I use
PB's sample code that ships with PB/DOS 3.5, in re the Carrier function
contained in COMMUNIT.BAS, then it does work. (had to do minor
additions to the PB code so the function returned 0 if there IS
a valid carrier detect - MY function tells the parent EXE if the
carrier is DROPPED). Does PB's code work because it directly accesses
the modem status register, rather than using INT 14H, as mine does?
In other words, is my code causing a conflict because it uses INT 14H,
and PB's builtin comm functionality also uses it?
OK, 'nuff said. My code follows. I will not spell out the two
$INCLUDE lines - the two included files contain NOTHING but
the appropriate registers' PUSH / POP (save/restore registers):
Code:
$COMPILE UNIT
'
DEFINT I
'
FUNCTION DroppedCarrier%(A%) PUBLIC
I = A% - 1 'my calling code uses actual commport numbers,
'whereas the INT uses commport# - 1
$INCLUDE "push.bas"
REG %AX, &H0300
REG %DX, I
CALL INTERRUPT &H14
I1 = REG(%AX)
$INCLUDE "pop.bas"
SHIFT RIGHT I1, 7
I1 = (I1 AND 1)
FUNCTION = (I1 = 0)
END FUNCTION
ADDED: further testing has shown that it is NOT an issue with the
PB comm subsystem. It is apparently directly tied to this particular
service of INT 14H. This service's sole purpose is to retrieve the
serial port's status. Maybe the way it is implemented causes it to
"hang" if the port is active (i.e., the modem is online with another
modem)?
------------------
[This message has been edited by Clay Clear (edited November 07, 2002).]
Comment