Question about COM port I/O, interupt handlers and powerbasic
DOS Guy
Does DOS or the system BIOS contain RS232 communication routines, and if
so - does something like a compiled PowerBasic progam use them when it
performs instructions like "Open Com1: ..." or when it performs com port
reads and writes?
And the $COM statement in PowerBasic - which allocates the size of the
receive buffer for the serial ports - just where / how is that buffer
used?
Is that buffer used by the com port interrupt handler? If so, what (or
where) is that handler? Does the BIOS contain a com port interrupt
handler? Does DOS? Or does Powerbasic install it's own interrupt
handler?
It seems that the powerbasic library (pb35.pbl or pb35.inc) includes
it's own com port handlers written in assembly language, and the linker
function $LIB tells PB to link in it's own com port code.
So I'm wondering
(a) is a compiled PB program self-contained as far as com port
functionality goes (does it contain it's own com port setup and access
code) and does it even contain it's own interrupt handler service?
(b) even when porttalk is used to give a compiled PB program access to
various hardware ports, and even the interrupt chip (PIC), I have yet to
come up with a solution that gives the program something resembing full
or "pure" access to the com port when running under XP. Some say the
win32 API is the reason. So what would happen if I uninstalled the com
port (or otherwise deactivated the com port driver) in XP? Can I trick
XP into thinking that it has no installed com port? Would I still be
stuck trying to deal with the IRQ issue?
Michael Mattias
> it's own com port handlers written in assembly language, and the linker
> function $LIB tells PB to link in it's own com port code.
$LINK *is* used to bring in the routines from a PBL (or OBJ or PBU) file,
but $LINKed modules are always user-created modules. The file PB35.INC file
supplied with the compiler contains some headers used by other unit source
code files, eg. COMMUNIT.BAS
> (a) is a compiled PB program self-contained as far as com port
> functionality goes (does it contain it's own com port setup and access
> code) and does it even contain it's own interrupt handler service?
"How" the intrinsic functions (e.g., "OPEN COM...") work is proprietary;
"what" those functions do is the documented, warranted and supported feature
set. The patina of proprietariness extends to the compiler directives
(e.g.. $COMM ) That is, the user does not know (and probably should not
care) if it uses port access or interrupt handlers or purple cheese curls to
get the job done.
>
> (b) even when porttalk is used to give a compiled PB program access to
> various hardware ports, and even the interrupt chip (PIC), I have yet to
> come up with a solution that gives the program something resembing full
> or "pure" access to the com port when running under XP.
That's because you are not meant to have "pure" access to the hardware...
that's a design feature (and I do mean "feature") of the Windows' operating
system.
I think if you want to get that close to the hardware running under the
Windows O/S you should probably download the DDK (Driver Development Kit)
from Microsoft (it's free) and start from there.
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmat...@talsystems.com
wolf3y3
returned either when opening "COM1" or "COM2", or when
read/writing to file handle 3 "AUX" which usualy is an
alias to COM1.
DOS must process the request and translate it into calls
to the BIOS (qwite slow), and DOS does not contain
code to check if a byte is available, trying to read from
the serial port with DOS when a byte is not available
will cause the system to hang until a byte becomes
available.
The BIOS contains crude routines for accessing the
serial port, and for checking if a byte is available.
But these are not adequate for high-speed communications
as the modern PC demands.
Thus, most MS-DOS communications programs directly
access the hardware using IN/OUT instructions.
Sjouke Burry
Ian Spencer
"Sjouke Burry" <burrynu...@ppllaanneett.nnll> schrieb im Newsbeitrag
news:4a74dd5a$0$1655$703f...@textnews.kpn.nl...
He doesn't have a question he was just answering the original question very
effectively.
Basic Guy
> >> DOS contains code to access the serial port via file
> >> handles returned either when opening "COM1" or "COM2"
> >> or when read/writing to file handle 3 "AUX" which
> >> usualy is an alias to COM1.
> >> DOS must process the request and translate it into calls
> >> to the BIOS (qwite slow),
> >> (...)
> >> Thus, most MS-DOS communications programs directly
> >> access the hardware using IN/OUT instructions.
> > And your question is??
>
> He doesn't have a question he was just answering the original
> question very effectively.
No, that's not true.
The original question pertained to a compiled PB/dos app that opens a
com port at 115k-baud and sends data through that port to another PC at
a very acceptible rate if the app is running on a machine that has been
booted into DOS, but at a very poor rate if the app is running under
XP's NTVDM.
The explanation given by wolf3y3 says nothing about how PowerBasic
performs com port I/O (through it's own handler, or through DOS/bios
calls?) and says nothing about how that I/O is affected or handled by
XP's ntvdm dos shell.
Todd Vargo
From the headers, Basic Guy and DOS Guy are the same person, but the
original post asked several questions which were crossposted to groups not
related to PowerBasic. The response from wolf3y3 applied to the DOS side of
the question while you expected a PB focused answer. Crossposting, in this
case, to the msdos groups was less effective than you had hoped for.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
wolf3y3
for communications it will have to do the I/O itself
via IN/OUT instructions under DOS.
The DOS emulation under windows is implemented
by software and the V8086 mode of the processor,
whence I/O through the 16-bit I/O address space
is trapped by windows software and is translated
into calls to actual drivers running in Ring 0 of the
processor,
a little rough but I think I got it right.
And this process would OBVIOUSLY slow down
a DOS application accessing the serial port.
Basic Guy
> For any application to effectively use the serial port
> for communications it will have to do the I/O itself
> via IN/OUT instructions under DOS.
Does a compiled powerbasic app perform "the I/O itself via IN/OUT
instructions under DOS" ???
> The DOS emulation under windows is implemented by software
> and the V8086 mode of the processor, whence I/O through the
> 16-bit I/O address space is trapped by windows software and
> is translated into calls to actual drivers running in Ring 0
> of the processor,
Yes - the ntvdm does a lot of unecessary stuff to essentially delay what
will turn out to be the same data being output or read from the same
port.
You can't virtualize a com port. If an app wants to send data out of
com1, then it's eventually going to make it's way out of the computer's
com1 port. You can't virtualize that output.
> And this process would OBVIOUSLY slow down
> a DOS application accessing the serial port.
Funny thing is that I've run the exact same dos app on the exact same XP
PC but with one difference:
When the CPU is a single-core 2.6 ghz Celeron, the com output is about
6% the pure DOS-mode throughput rate.
When the CPU is a 2.5 ghz pentium with HT, the com output is about 98%
the pure DOS-mode throughput rate.
Anyways, given a serial port that's been re-wired to a different
(non-standard) I/O address, and given the use of the port-talk utility,
a 16-bit DOS app can easily perform direct I/O while running under XP,
without XP interfering with it. Type of CPU doesn't matter (single or
dual core) because there is no interference from ntvdm.
Substituting inp and out instructions for the Powerbasic Open com,
read-com and write-com statements is trivial, and no real serial-port
driver is needed, even for a baud rate of 115k, and sustained /
tokenized data transfer of 8kb/sec is easily possible. No interrupts or
interrupt-handlers used.
Bill H
Do these boards had a true serial port or is it one of those "intel"
chips that do everything? Have you tried a serial card?
Bill H
Basic Guy
> > Anyways, given a serial port that's been re-wired to a different
> > (non-standard) I/O address, and given the use of the port-talk
> > utility, a 16-bit DOS app can easily perform direct I/O while
> > running under XP, without XP interfering with it. Type of CPU
> > doesn't matter (single or dual core) because there is no
> > interference from ntvdm.
> >
> > Substituting inp and out instructions for the Powerbasic Open com,
> > read-com and write-com statements is trivial, and no real serial-
> > port driver is needed, even for a baud rate of 115k, and
> > sustained / tokenized data transfer of 8kb/sec is easily
> > possible. No interrupts or interrupt-handlers used.
>
> Do these boards had a true serial port or is it one of those
> "intel" chips that do everything? Have you tried a serial
> card?
The above was tested on two different serial port expansion boards:
The first was a very old 2-port 8-bit ISA-slot card (I'm thinking circa
1990). Address line 5 was inverted off the ISA bus in order to make the
board respond to a "unique" set of I/O addresses. The card had the
functionality (according to msd.exe) of a 16550 uart (this type of uart
has a 16-byte read and 16-byte write buffer unless I'm mistaken).
The second board was a PCI-based dual com-port card. The card's native
(unmapped) address is something like d800h, and the powerbasic app
talked to it directly at that port. This card has a 16950 uart with a
128 byte read/write buffer, and a few extra registers for enhanced
operation (baud-rate multiplier). The card will apparently do
1-mega-baud.
The bottom line is that the standard 4 com port addresses (corresponding
to com1 through com4) are trapped by ntvdm and there's nothing that
anyone's been able to do to get around that.
So what's needed is a serial port that's located at an address that is
not one of the standard addresses. Once you have that, and port-talk,
your 16-bit app can talk to it no problem. When it comes to any
compiled basic apps, I don't think you can tell them what your new com
address is, so that's when you just replace the standard basic
serial-port commands with inp and out instructions.
wolf3y3
a 16-bit .exe) it would contain the routines for I/O in its own
executable
code.
It just like any other high-level language, the code to all the
functions which
the code depends is placed in the executable, unless they are loaded
as an overlay (from a separate binary file).
wolf3y3
exactly what is done
in x86 architecture emulators (which interpret binary files), all data
out to the ports
of the video card,keyboard,etc... are all simulated and interpreted by
software,
and hence are virtual.
I program in 8086/8088 assembly language, the actual code your
programs get turned into when they
are compiled for DOS.
I know programming at the low-level can be complex, but I enjoy it.
If you would like to get into the more low-level,hardware-level,
aspects of programming,
which it looks like you do, I would suggest you learn assembly
language.
In fact, to really understand DOS you have to know assembly language.
wolf3y3
have to
go to actual hardware (giving flexibility) or to the same hardware
that is being
emulated (like in computer emulators).
wolf3y3
hardware (giving flexibility) or
to the same exact model of hardware (as with computer emulators).
wolf3y3
prohibited in User Mode (ring 3)
and has to be translated to calls to drivers running in ring 0, which
in turn accesses the
actual hardware.
This, and the fact that a bulky Windows system is running are two
reasons communications
would be slower.
wolf3y3
I/O through the I/O port address space would have to be
sent to the actual hardware by the emulation software.
wolf3y3
but instead each yields the processor one at a time,
giving the effect of running simultaneously.
Hence, the processor has to interpret thousands of instructions
before reaching your DOS app in the emulator, and after reaching
your DOS app it goes through the cycle again.
Before your DOS app can be accessing the hardware it must be
being executed by the processor.
Please, take this into account.
Basic Guy
you'd think he'd know how to properly quote when constructing a usenet
reply. You'd certainly expect him to use a real usenet client, instead
of posting through the hideous and lame google-groups interface to
usenet.
wolf3y3
I take no offence at all from you.
Oh, wow you take the time to use a news reader, big deal.
Using software isn't the test of technical capabilities,
this is why script-kiddies are thrown out of the hacker
community.
"Basic Guy" (lame name), you are just wasting peoples
time by writing posts attempting to disrupt or discredit
other people.
Good bye.
wolf3y3
I didn't mean all that.
Basic Guy
> Your just a newbie, and a anti-social one.
A google-grouper is calling a 20-year usenet veteran a newbie.
> I take no offence at all from you.
Then why do you go on to say this:
> "Basic Guy" (lame name), you are just wasting peoples
> time by writing posts attempting to disrupt or discredit
> other people. Good bye.
Why the bad attitude from you? Why did you leave?
I thought you said you took no offence.
Basic Guy
> I came back to say I'm sorry,
> I didn't mean all that.
I guess I should read all the posts before replying...