Discussion:
COM port functionality (powerbasic program wrapped for use onXP)
(too old to reply)
Basic Guy
2009-07-18 15:55:57 UTC
Permalink
IMO, your best bet would be to use what us BBS sysops call a FOSSIL
driver to handle communications type applications.
Remember the following points:

1) I am running a compiled PB/dos app under XP. The app performs I/O
calls to some custom hardware, so port-talk is already used to give the
app full and unrestricted access to specific I/O addresses. These I/O
calls are not trapped or monitored by XP's virtual DOS machine (ntvdm)
from what I can tell because of port-talk.

2) A modified version of the app was written to communicate data via com
port to another PC. In spite of altering port-talk settings, ntvdm
still intercepts I/O calls to addresses that correspond to the
traditional com-1 through com-4 I/O addresses. In order to circumvent
this, an dual port ISA RS232 card was modified such that it responded to
a slightly different set of I/O addresses (that didn't seem to interfere
with anything else) and port-talk was modified for those addresses.
Also, the app was modified such that all com port statements (open com,
input and print statements) were modified and replaced with direct inp
and out statements directly to the modified com-port I/O addresses. The
end result is that the PB app now has full and complete access to the
modified com port and NTVDM does not interfere with it when running
under XP.

3) There is absolutely no interupt handling or triggering capability
with this setup. The app running under XP does mostly data-sending
through the com port - any recieving being done would not be enough to
overwhelm the uart's 16-byte internal buffer from what I can tell.

4) I have done additional testing with a PCI-based serial card that has
a uart with a 256-byte buffer (the card is capable of 1-mega-baud data
rate because of additional registers that perform baud-rate
multiplication). I've discovered that the default I/O location for that
card is something like D400h, and (again using port-talk) the PB/dos app
can communicate with that card just fine when running under XP. No
additional driver (DOS or XP) was required.

5) Since I have implimented a solution for this situation, I'm not
looking for any more help. But I offer this information to others that
are having problems getting decent serial-port throughput for a DOS or
PB/Dos app running under XP's NTVDM.

6) It's not clear to me how a fossil driver would help, given that it
would somehow still have to "fight" with ntvdm over access to the serial
port anyways.
Robert Wolfe
2009-07-19 18:38:26 UTC
Permalink
On 7/18/2009 11:55 AM, ***@Guy.com wrote to All:

-> 5) Since I have implimented a solution for this situation, I'm not
-> looking for any more help. But I offer this information to others that
-> are having problems getting decent serial-port throughput for a DOS or
-> PB/Dos app running under XP's NTVDM.

Okay, but it would have been better if you had mentioned this in the
newsgroup.

-> 6) It's not clear to me how a fossil driver would help, given that it
-> would somehow still have to "fight" with ntvdm over access to the serial
-> port anyways.

Actually, it just depends on what FOSSIL driver you use. Again, just as a
point of information here, BNU works very nicely under Windows XP's NTVDM.
Loading...