COM port functionality (powerbasic program wrapped for use on XP)
DOS Guy
communicating with each other over the com port. I open the ports at
115k-baud. Data is transfered mainly from one system to the other
(although there is some bi-directional coordination).
I get pretty close to the theoretical max transfer rate when both
systems have booted into DOS to run the app.
Now this app talks to some custom hardware in one of the PC's using some
machine code and i/o reads and writes. This app was made XP-compatible
by "wrapping" it in a port-mapper (I forget the name - port-talk I
think). This allows the app to function perfectly when running under
XP.
However, the serial communications aspect of the program functions
extremely poorly. At first I thought that XP was interfering with the
app's ability to talk to the com port via BIOS calls, but then I
realized that PowerBasic probably has it's own com port interface and
interrupt handler.
So, I'm wondering if anyone out there has any experience with a compiled
basic DOS app (powerbasic or otherwise) that performs serial I/O and
running such an app under win-XP.
Or if I'll have to poke more holes in the I/O permission table in order
to give the app full access to the serial ports - and how do I "remove"
XP's influence or control over the ports?
Sjouke Burry
It should enable full port access.
Gerard Bok
>I'm working with a DOS app (written in PowerBasic) where two PC's are
>communicating with each other over the com port.
>So, I'm wondering if anyone out there has any experience with a compiled
>basic DOS app (powerbasic or otherwise) that performs serial I/O and
>running such an app under win-XP.
When porting a DOS application to Win32 I found out, that
although the serial control stuff compiled without a single error
or warning, it didn't function at all ;-)
Reading some help subjects and adapting the syntax solved all
problems :-)
--
Kind regards,
Gerard Bok
DOS Guy
> > So, I'm wondering if anyone out there has any experience with a
> > compiled basic DOS app (powerbasic or otherwise) that performs
> > serial I/O and running such an app under win-XP.
>
> When porting a DOS application to Win32
I am NOT porting a DOS app to win32.
I am trying to run a DOS-compiled PowerBasic program in XP.
Tim Meddick
Since XP is a Win32 OS
==
Cheers, Tim Meddick, Peckham, London. :-)
"DOS Guy" <D...@Guy.com> wrote in message
news:4A304B96...@Guy.com...
DOS Guy
> > I am NOT porting a DOS app to win32.
> >
> > I am trying to run a DOS-compiled PowerBasic program in XP.
> Isn't that 'porting a DOS app to Win32' ???
>
> Since XP is a Win32 OS
Win-98 is also a Win32 OS (which irks many 2K/XP sycophants because they
try so hard to deny that fact).
I think of "porting" as an excercise that involves recompilation of
source code on a compiler running on the target system or OS, which
usually involves some degree of "tweaking" the code to get it to compile
and function as intended.
ArarghMai...@not.at.arargh.com
>Top-poaster Tim Meddick wrote:
>
>> > I am NOT porting a DOS app to win32.
>> >
>> > I am trying to run a DOS-compiled PowerBasic program in XP.
>
>> Isn't that 'porting a DOS app to Win32' ???
>>
>> Since XP is a Win32 OS
>
>Win-98 is also a Win32 OS (which irks many 2K/XP sycophants because they
>try so hard to deny that fact).
Well mostly. :-) Sort of a slightly API challenged Win32 OS. And
parts of it show up as 16-bit code wend viewed with the proper process
viewer.
>
>I think of "porting" as an excercise that involves recompilation of
>source code on a compiler running on the target system or OS, which
>usually involves some degree of "tweaking" the code to get it to compile
>and function as intended.
--
ArarghMail906 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Sjouke Burry
DOS Guy
> > I am trying to run a DOS-compiled PowerBasic program in XP.
> So get userport.zip.
How does userport.zip handle hardware interrupts, such as those
generated by the com port?
If this app is going to work properly when run on XP, it must be allowed
to set up it's own interrupt handler and com port buffer as I presume it
does when it operates under DOS.
I see no reference to interupt handling in the userport documentation
file.
Michael Mattias
>>
>> I am trying to run a DOS-compiled PowerBasic program in XP.
> Isn't that 'porting a DOS app to Win32' ???
No.
Under MS-DOS comm ports are ultimately accessed via interrupts, which are
directly available to the application programmer, and MS-DOS compilers are
based on using these interrupts. And while interrupts are interrupts, they
are generally not available to the programmer under Win/32, and comm ports
are generally accessed via provided API functions, of which WIndows'
compilers take advantage.
And under MS-DOS (or the CMD.EXE MS-DOS emulator), the application only uses
the 16-bit registers of the CPU; Win/32 software uses the 32-bit registers.
There's lots of stuff you do one way under MS-DOS and a different way under
Windows.
MCM
DOS Guy
> Under MS-DOS comm ports are ultimately accessed via interrupts,
Um, I don't think that's correct.
The hardware of the com ports are capable of generating interrupts, and
interrupt handlers may be set up to efficiently capture data from the
ports, but it's up to the application or the operating system to set up
an interupt handling facility (no such facility exists in the BIOS as I
understand it).
Serial I/O was mostly used by PC's to send data, not to receive it, and
hence they did not need to use the interupts to more efficiently capture
data from the ports. And when serial I/O was typically running at 300
baud, polled I/O was capable of doing the job.
Later versions of the 8250 uart came with a buffer of 15 or 16 bytes,
which again alleviated the need for interupt usage.
> And under MS-DOS (or the CMD.EXE MS-DOS emulator), the
> application only uses the 16-bit registers of the CPU;
> Win/32 software uses the 32-bit registers.
What does that have to do with the price of tea in China?
> There's lots of stuff you do one way under MS-DOS and a
> different way under Windows.
I'm sure that not even DOS itself offers interupt handlers (and the
requisit buffer structures) for com-port communications. Any facility
that DOS has for com port I/O is probably designed more for sending data
than receiving it.
Michael Mattias
> Michael Mattias wrote:
>
>> Under MS-DOS comm ports are ultimately accessed via interrupts,
>
> Um, I don't think that's correct.
>
> The hardware of the com ports are capable of generating interrupts, and
> interrupt handlers may be set up to efficiently capture data from the
> ports, but it's up to the application or the operating system to set up
> an interupt handling facility (no such facility exists in the BIOS as I
> understand it).
Ok, so under MS-DOS you can use interrupts OR direct port I-O to effect
serial communications.
Doesn't change my point: Running a program created for use with MS-DOS
under the CMD.EXE emulator of Windows/XP is NOT the same as "porting the
application to Win/32"
CMD.EXE may be close, but it is NOT MS-DOS.
MCM
Sjouke Burry
access ports without windows blocking the normally illegal
instructions.
Tim Meddick
==
Cheers, Tim Meddick, Peckham, London. :-)
"DOS Guy" <D...@Guy.com> wrote in message
news:4A305AC5...@Guy.com...
DOS Guy
> > How does userport.zip handle hardware interrupts, such as those
> > generated by the com port?
> It opens port access , so that dostype software can
> access ports without windows blocking the normally illegal
> instructions.
That doesn't answer my questions regarding the com port interrupt
handling.
Do any of those port-mapping or port-access utilities allow a DOS app
running under XP to set up it's own com port interrupt handler?
Access to the com port I/O addresses is useless without the ability to
set up an interrupt handler too.