Would a PCI-based serial port be available or accessible to a DOS app w/o driver?
DOS Guy
Would a PCI-based com-port board be accessible to a DOS app without
needing to some sort of driver installed during autoexec.bat or
config.sys startup (assuming the board would even have DOS-based
drivers) ???
In other words, if a motherboard with an integrated com port doesn't
need a driver to be seen and be functional for a DOS app, then would a
PCI-based com port behave the same way?
I was thinking of something like this:
H-Man
In order for DOS to see it you'd need to be able to assign it an address
space and an IRQ. Some cards do exist that allow this, but it's been a
while since I've done this so I can't say for sure. IOf the card you're
looking at has a utility that allows setting an address and IRQ then you
can. The crad does say it's designed to work with DOS, but I'd be unsure as
to whether or not it'd need a driver to do so.
--
HK
Zaphod Beeblebrox
"DOS Guy" <D...@Guy.com> wrote in message
news:4A3B9C24...@Guy.com...
Are you talking about actual MS-DOS/PC-DOS/4DOS or a command prompt
(AKA "DOS box") under some variety of Windows?
If you are talking about a command prompt under Windows, I've no idea
what might be needed or how you might proceed.
If actual DOS, I have set up add-in PCI serial port cards to work
under MS-DOS 5.0 and 6.2 before, but it was kind of a hassle as there
were several non-trivial things we had to do.
First was to find out which PCI slots put the card on an IRQ that
would work in a give PC - some of the slots shared the IRQ with the
video card or built-in video, which caused us problems, others used
IRQ 9, which caused problems.
Next, we had to use a utility provided by the board manufacturer
(SeaLevel in our case) to detect the BIOS assigned port address and
re-map it to an unused address below FFFFh.
Finally, we had to modify the software we used to be able to handle
non-standard port IRQs and addresses (most commercial software is
limited to the standard port IRQ and address settings of port 1 = IRQ
4/03f8h, port 2=IRQ3/02f8h, port 3 = IRQ4/03e8h, port 4 = IRQ3/02e8h).
So, unless the board manufacturer provides DOS drivers to put the
IRQ/Address into the range your software can handle or you've got the
ability and resources to do the above yourself you might not be able
to achieve the desired result, and even then it might be more trouble
than it is worth.
Good luck...
--
Zaphod
Arthur Dent, speaking to Trillian about Zaphod:
"So, two heads is what does it for a girl?"
"...Anything else he's got two of?"
Happy Trails
>In other words, if a motherboard with an integrated com port doesn't
>need a driver to be seen and be functional for a DOS app, then would a
>PCI-based com port behave the same way?
In the good old days of DOS, nobody EVER used the BIOS I/O routines of
the PC for ANYTHING. If you wanted to do any serial I/O, you did it
with some sort of serial port driver, either a bunch of routines from
some software company, or some software drivers provided by a serial
port card manufacturer. The best ones I ever used were from
MOXA/Advantech in Taiwan - cards and drivers.
Their drivers would work with ANY cards or the builtin ports on any
motherboard - not just their own.
DOS Guy
I've got a program written in PowerBasic (version 3.5 for DOS). It
opens com1 at 115k baud on PC-1, and checks to see if there are any
characters to be read from the port. Another PC (PC-2) periodically
sends a single character to PC-1 to indicate it's ready to receive data.
When PC-1 receives the character, it sends out a stream of about 38
bytes out the com port and then sits there and waits for PC-2 to send
it's signal that it wants more data. PC-2 is running DOS, and the app
it runs is also written in powerbasic.
I have two types of desktop systems that I can use as PC-1. I have two
systems of each type. Type-1 is based on an ASUS motherboard (circa
2007) based on Nvidia chipset. Type-2 is based on a SOYO motherboard
(circa 2004) based on Intel 845 chipset. Both have a single com port
integrated onto the motherboard.
Type-1 systems are "well used" and very busy developer systems running
XP-pro SP3. Type-2 systems are exact clones of each other (not much
more than fully updated but otherwise vanilla installation of XP-pro
sp2, tweaked by having many services turned off). So Type-1 is is
running SP3, Type-2 is running SP2.
When PC-1 is a Type-2 system booted into dos via floppy, communication
is fine (throughput pretty close to theoretical maximum based on baud
rate). However, when this system has booted into XP and the app is run
from a command shell, the communication rate drops to about 10% of
theoretical maximum.
When PC-1 is a Type-1 system and the app is run from a command shell,
the communication rate is again close to the expected maximum.
In either case, nothing was done to "poke any holes" in the I/O
permission maps for the DOS app running under XP on PC-1. The app was
just the .exe file created by the PB compiler.
So basically I can't figure out why the throughput is so pathetic on one
system but great on another, both running the same PB app in a dos
window.
Hence why I'm exploring the option of turning off the motherboard com
port on the Type-2 system and installing a com port via expansion slot
(most probably PCI).
Michael Mattias
> This is the situation....
Well, now that we know THAT, maybe there's a better alternative...
Since both machines are running Windows/XP why don't you just pop for one
of the PB/Windows compilers and port the application?
Then all these cool I-O port writes (if necessary) can be enabled with all
the libraries which are available to support same.
I'm sure your MS-DOS application has served long and well, but maybe it's
time to grant it an honorable retirement, just as I am about to do for my
1996 Mercury Grand Marquis.
For that matter, you might be able to get a Windows-based comm package 'off
the shelf' for a very reasonable cost.
Of course, if this is a hobby application rather than a production
requirement, this does not apply.
MCM
DOS Guy
> > This is the situation....
>
> Well, now that we know THAT, maybe there's a better alternative...
>
> Since both machines are running Windows/XP why don't you just pop
> for one of the PB/Windows compilers and port the application?
I mentioned that I'm trying to have PC-1 send data to PC-2. PC-1 is
running a compiled PB/DOS app.
I mentioned that when PC-1 is an ASUS mb running XP-sp3, the PB app runs
fine. But when PC-1 is a Soyo mb running XP-sp2, the app runs at 10%
data rate.
I need PC-1 to be using the Soyo mb.
I can't port the app to PB/windows because the app performs a lot of
graphics-based data display in real time, and it performs some direct
I/O reading of an ISA-based card (data rate typically about 100 to 200
kb/sec) and sometimes the app is saving data while it's displaying it.
It's my impression that the PB/windows language is not as "powerful" as
far as defining graphics windows and point-plotting as it's PB/dos
counterpart. The PB-dos source file is about 250kb in size and porting
it to PB/windows is just not an option.
> Then all these cool I-O port writes (if necessary) can be
> enabled with all the libraries which are available to
> support same.
That doesn't explain why I get great serial data communication rates on
one system but not another. The difference being the motherboard and
the version of XP (sp2 vs sp3). I will update one of the systems from
sp2 to sp3 and remove that variable from this situation.
> I'm sure your MS-DOS application has served long and well,
> but maybe it's time to grant it an honorable retirement,
This is a one-off situation, it's not something that I will need to
replicate again.
I basically needed to drive a second monitor from the PB/dos app, and I
asked previously if there was a way (under XP) to have two DOS apps
running full-screen (each on it's own screen) on a dual-monitor PC.
There was pretty much universal agreement that this was simply not
possible (when you put a DOS app in full-screen mode on a two-monitor
system running XP, the DOS app is cloned to both monitors - no way
around that).
The second screen is supposed to also display some of the same data, but
in a different way. So in order to have a second monitor show this, the
only other way is just to have a cheap, surplus PC run it's own app and
have it take data from the primary system and display it on it's own
monitor. How to get the data from PC-1 to PC-2 in a way that PB/DOS can
make happen? RS-232 port.
Bill H
> Michael Mattias wrote:
> I basically needed to drive a second monitor from the PB/dos app, and I
> asked previously if there was a way (under XP) to have two DOS apps
> running full-screen (each on it's own screen) on a dual-monitor PC.
> There was pretty much universal agreement that this was simply not
> possible (when you put a DOS app in full-screen mode on a two-monitor
> system running XP, the DOS app is cloned to both monitors - no way
> around that).
>
> The second screen is supposed to also display some of the same data, but
> in a different way. So in order to have a second monitor show this, the
> only other way is just to have a cheap, surplus PC run it's own app and
> have it take data from the primary system and display it on it's own
> monitor. How to get the data from PC-1 to PC-2 in a way that PB/DOS can
> make happen? RS-232 port.
I had to test this myself, and yes on a dual monitor setup you can not
have two dos apps full screen at the same time displayed, though can
alt-tab between the two full screens. But is it possible to run these
programs in the window maximized and then you can do one on each
monitor (I know this is probably an obvious question, but you never
know unless you ask)?
Bill H
DOS Guy
> I had to test this myself, and yes on a dual monitor setup you
> can not have two dos apps full screen at the same time displayed,
> though can alt-tab between the two full screens.
In my situation, both apps must be visible on their respective screens
at the same time. Alt-tabbing is not an option.
> But is it possible to run these programs in the window maximized
> and then you can do one on each monitor (I know this is probably
> an obvious question, but you never know unless you ask)?
Any DOS app (even if started in a scaled window under win-9x/2k/xp) will
kick the screen into full-screen mode if the app performs a screen
command to set the display mode to VGA graphics mode (684 x 480 x 16).
The app in question does this in order to perform the graphical data
display mentioned in the previous post.
The ONLY time I have seen a VGA-mode DOS app run in a scaled window was
when it was running in a virtual XP session. In that case, it was
indeed running in a 640x480 pixel window (which couldn't be streched or
changed). It was also running pathetically slow.
Bill H
Heres another thought - have you tried using remote desktop,
pcanywhere or radmin? I could see 2 machines that are sing the full
screen doses being accessed as windows on a third machine using one of
these programs.
DOS Guy
> Heres another thought - have you tried using remote desktop,
> pcanywhere or radmin? I could see 2 machines that are sing the
> full screen doses being accessed as windows on a third machine
> using one of these programs.
If my PB app can't write to two VGA screens simultaneously, and if XP
can't run two full-screen DOS sessions independently, simultaneously,
each writing to their own screen on a two-monitor system, then in order
to have a two display solution I must operate a slave PC with it's own
monitor.
In order to modify my PowerBasic app to output the data to a slave
system, the com port seems to be the most straightforward solution.
This solution was implimented and it works if both systems have been
booted into DOS.
However, when the Master system has been booted into XP (as it must be
when this solution is being used by the client) the communication data
rate is about 10% of what it is when the Master system has been booted
into DOS.
This is maddening, as other PC's acting as the Master do not show this
drop to 10% when the app is running under XP. I cannot use those other
PC's because their motherboard does not have ISA slots.
If there is some other way I can have my PB app send data to another
system, via some other communications channel, I don't know what that
could be. Perhaps a bi-directional printer port. I haven't explored
data transfer in PB using the printer port.
DOS Guy
hyperthreading, results in good (or at least normal) com port
performance for a dos app running under XP.
I had been looking at why the com port performance of my app was ok on
some machines and not others. One variable I didn't take into account
was the CPU. Even on a PC with a 3.2 ghz celeron, the com port
performance was about 6% of theoretical maximum, but on a 3 ghz Pentium
with HT it rose to about 85%.
That lead me to look at why the ntvdm behaves this way. Some mention of
it emulating a very primative uart (8250 ?) with no transmit and receive
buffer capability.
It looks like I'll have to use direct port reading and writing to the
uart (and use something like port-talk) as well as uninstall the com
port under XP (so that ntvdm doesn't intercept com port I/O - maybe?).