What support does MSDOS have for COM ports?
I believe you can copy a file with a destination of COM1: and it
will write to the COM port, but I don't know what speed/parity/bits
it uses when you do that, and I've never heard of facilities to set
those things.
What support does MSDOS have for COM ports?
The ports are supported as devices.
I believe you can copy a file with a destination of COM1: and it
will write to the COM port, but I don't know what speed/parity/bits
it uses when you do that, and I've never heard of facilities to set
those things.
Utilities to manage the ports are a different matter.
I think I was always using some other program to configure / manage the
port as well as do the requisite communications.
Though, from a very deep dark and difficult to access memory, which
could easily be wrong, I want to say that mode had the capability to configure ports.
I would say check the help command, but I think that was introduced in 6.<something> and you've listed 3.2 in the subject. That's way before I started messing with DOS.
So is there a DOS interrupt to do the equivalent of the mode command?
Note that although I'm interested in DOS 3.2 (which is when I started),
if there is a solution in a more recent version of DOS, I'm interested
in that too, because I can backport it to PDOS/86:
Could you please explain what this means? A program wishing to open
a COM port is meant to do a special "device open" or something?
Thanks for the pointer to the "mode" command.
So is there a DOS interrupt to do the equivalent of the mode command?
Note that although I'm interested in DOS 3.2 (which is when I started),
if there is a solution in a more recent version of DOS, I'm interested
in that too, because I can backport it to PDOS/86:
I can remember when I wrote a comms program for MSDOS, I bought
a comms package, can't remember the name, from the guy who created
"Texas Zmodem", and he mentioned to me that there shouldn't be a need
for a comms package like his, it should be built into MSDOS. And I'd
like to understand what the issue was.
Could you please explain what this means? A program wishing to open
a COM port is meant to do a special "device open" or something?
Well, NUL, CON, COM1, COM2, COM3, COM4, LPT1, LPT2, and LPT3 are special reserved device names in DOS. (I think COM goes up to 4.)
You could do something crude like "COPY CON MYFILE.TXT" start typing,
and copy would copy from the CONsole into MYFILE.TXT. I think you use Control-D to indicate end of file.
Similarly, you can use "COPY MYFILE.TXT CON" as an alternative to TYPE.
DOS dutifully copies MYFILE.TXT to the CONsole.
So is there a DOS interrupt to do the equivalent of the mode command?
I have no idea.
I can remember when I wrote a comms program for MSDOS, I bought
a comms package, can't remember the name, from the guy who created
"Texas Zmodem", and he mentioned to me that there shouldn't be a need
for a comms package like his, it should be built into MSDOS. And I'd
like to understand what the issue was.
I wonder if he was implying that the MS-DOS was missing some
functionality or what.
Technically speaking, I suspect that you /can/ interact with a modem, a
la. a serial device, via the COM# port. But copy, as outlined above is inherently uni-directional.
So is there a DOS interrupt to do the equivalent
of the mode command?
Muta,
So is there a DOS interrupt to do the equivalent
of the mode command?
No, as the "mode" program has bundled up a slew of different settings.
*One* of them being the serial port
Question : Do you already have a copy of Ralf Brown's Inerrup List ? If
not, I strongly advice you to get yourself one.
INT 14 - SERIAL - INITIALIZE PORT
AH = 00h
AL = port parameters (see #00300)
DX = port number (00h-03h) (04h-43h for Digiboard XAPCM232.SYS)
Return: AH = line status (see #00304)
various network and serial-port drivers support the standard BIOS
functions with interrupt-driven I/O instead of the BIOS's polled I/O
Interestingly I couldn't find this table online:
http://www.ctyme.com/intr/rb-0811.htm
But it is in the disk files:
Bitfields for serial line status:
This is one of the things that interests me - how were
MSDOS programs ideally meant to be written that
would benefit from replacing polled I/O with interrupt-
driven I/O?
Note that my original question was about MSDOS.
This is a BIOS function.
I tried doing an fopen() of "COM1:" for "w" on Freedos
and I was surprised to find that it failed.
Furthermore, this would involve blocking reads,
so what I would like is to posit the existence of
a sophisticated BBS (in reality it will just be my
Windows box), that would coddle my comms
program that uses fopen().
I think I just want to inherit whatever parameters
were set by the MODE command rather than
attempting to manipulate that myself.
On the page you linked to : "AL = modem status (see #00305)". I just
clicked the "(see #00305)" link and got what you posted (as part of the "get port status" (int 14/AH=03h) page). :-)
This is one of the things that interests me - how were
MSDOS programs ideally meant to be written that
would benefit from replacing polled I/O with interrupt-
driven I/O?
The moment you write an interactive program (read: non-commandline) you most always need to have stuff happening "in the background" to keep the user-facing side (the "gui") responsive.
I tried doing an fopen() of "COM1:" for "w" on Freedos
and I was surprised to find that it failed.
Try removing the ":" at the end of the device name.
Also, COM1 is not actually a file, so what you can do with it is limited
(you can't "seek" it).
Furthermore, this would involve blocking reads,
so what I would like is to posit the existence of
a sophisticated BBS (in reality it will just be my
Windows box), that would coddle my comms
program that uses fopen().
You asked about when interrupt-driven I/O would be called for ? Well,
there you go. :-)
And not to be a party-pooper, but depending on the C environment you work in you still might be, in regard to the serial port, working with simple, blocking I/O ...
In that regard it would not be a bad idea to search for drivers which will give you interrupt-based serial-port handling. IIRC "Fossil" is one of
those drivers (its named it Ralf Browns Interrup List).
Ok, 304 was difficult to see.
Isn't this more a function of multitasking? Given that
MSDOS wasn't multitasking, was there a problem?
The C standard requires you to do a seek before
switching modes.
I want blocking I/O. I want the external "BBS" to
deal with timeouts etc and provide a clean data
stream to my applications running on PDOS/x86.
The C standard requires you to do a seek before
switching modes.
Than you should at least try if it works that way. :-)
I want blocking I/O. I want the external "BBS" to
deal with timeouts etc and provide a clean data
stream to my applications running on PDOS/x86.
The problem with blocking I/O is, as you have probably already noticed, that if you are waiting for something (to arrive or be (fully) send) you cannot
do anything else. And for some reason when humans press a key they
normally expect a direct response. :-)
Any reason why I shouldn't expect a direct response
from the BBS running on my Windows machine?
And if my BBS is in turn waiting on the news server
on the internet, I don't see that there is much choice
but to wait for that.
And if my BBS is in turn waiting on the news server
on the internet, I don't see that there is much choice
but to wait for that.
For either of the above examples I gave I can press ctrl-c to abort. I
can easily imagine that a BBS would accept a key stroke or command to do the same. But as your client program is using blocking I/O you could be
pressing keys all you want, but those won't be send until after you got your response back from the BBS ...
Granted, blocking I/O is much easier to work with
But keep the downside of it in mind.
A long-running "grep -R" running within PDOS, forget
about the BBS, would be considered to be using
blocking I/O (on the disk, not the BBS), wouldn't it?
Interrupting either the disk or the BBS is an independent
activity, isn't it?
Are you talking about from an application programmer's
perspective, a user's perspective, or something else?
But keep the downside of it in mind.
Can you list those? It might be possible to
overcome them.
I guess it depends on what we're trying to achieve.
What would be a sensible achievement in your eyes?
BTW, I started this project in 1994.
A long-running "grep -R" running within PDOS, forget
about the BBS, would be considered to be using
blocking I/O (on the disk, not the BBS), wouldn't it?
Yes, and no.
No : As mentioned, on your own *local* machine you can most always use
ctrl-c to abort (force-closing the program).
Yes : As long as your program doesn't output anything you cannot stop it
(the ctrl-c checking is done inside (some of) the character output BIOS
INTs)
Interrupting either the disk or the BBS is an independent
activity, isn't it?
And just ask yourself : Your BBS listens to your client-programs communications and does whatever it says. How's that independant ?
Are you talking about from an application programmer's
perspective, a user's perspective, or something else?
both (though for different, opposite reasons), and what else is there ?
But keep the downside of it in mind.
Can you list those? It might be possible to
overcome them.
Whut ? What didn't you understand from what I already said :
[quote=me, parent post]
But as your client program is using blocking I/O you could be pressing keys all you want, but those won't be send until after you got your response back from the BBS ...
[/quote]
Again: as long as you are in a blocking wait (for data to come in) *you
can't do anything else*. Your 'puter is effectivily frozen. How do you
think you can overcome that ?
I thought all keyboard strokes resulted in
an interrupt?
Isn't it a simple matter of hooking into that interrupt
and doing the ctrl-c checking?
And just ask yourself : Your BBS listens to your client-programs
communications and does whatever it says. How's that independant ?
ctrl-c checking is independent of the application
being run.
What's the technical barrier?
On 4/23/21 5:19 PM, muta...@gmail.com wrote:
What support does MSDOS have for COM ports?
The ports are supported as devices.
I believe you can copy a file with a destination of COM1: and it
will write to the COM port, but I don't know what speed/parity/bits
it uses when you do that, and I've never heard of facilities to set
those things.
Utilities to manage the ports are a different matter.
I think I was always using some other program to configure / manage
the port as well as do the requisite communications.
Though, from a very deep dark and difficult to access memory, which
could easily be wrong, I want to say that mode had the capability to configure ports.
I would say check the help command, but I think that was introduced in 6.<something> and you've listed 3.2 in the subject. That's way before
I started messing with DOS.
I thought all keyboard strokes resulted in
an interrupt?
Yeah, they do. A *hardware* one. Which dumps the keystroke into a small buffer which you than read from with a few of the BIOS INTs.
Isn't it a simple matter of hooking into that interrupt
and doing the ctrl-c checking?
Yeah, thats a good idea : you just, somewhere in the middle of whatever your 'puter is busy with - even harddisk writing ! - hard-abort it. Nope, I
would not suggest doing that.
I already mentioned that : while you can just have your client program crash-and-burn by pressing ctrl-c, it won't stop the server (the BBS) from continuing what its busy with.
IOW, you need to figure out a "soft" method to stop whatever your client is doing (*not* aborting the program or interrupting it in the middle of something important), and than *ask* the server to stop what it busy with - 'cause thats the only thing you can do : ask..
The first thing I'd like to know is if my program goes
into a hard loop, with:
for (;;) ;
ie no input or output I/O to any device, is there a technical
barrier on either 8086 or 80386 to allowing the hardware
interrupt of ctrl-c being pressed aborting the application?
Or at least letting the timer interrupt detect that ctrl-c has
been pressed and waiting two more timer interrupts and
then actioning the abort.
You mentioned that you shouldn't be aborting a hard \
disk write.
The OS will always be the one who initiates that.
Or alternatively, the OS will know whether it is in the
middle of doing any OS work at all, or whether it is an
application being run.
When doing a blocked read from a COM port (assuming
such a BIOS call exists, which doesn't seem to be the
case),
And then finally moving on to the BBS - remembering
that it is a cooperative BBS - the OS can be set to
send the ctrl-c out the COM port as part of aborting
the application.
The first thing I'd like to know is if my program goes
into a hard loop, with:
for (;;) ;
ie no input or output I/O to any device, is there a technical
barrier on either 8086 or 80386 to allowing the hardware
interrupt of ctrl-c being pressed aborting the application?
That fully depends on how you define "technical". Using it that way and leaving your (and perhaps another) machine in an unstable state is what I would definitily call a technical barrier.
Or at least letting the timer interrupt detect that ctrl-c has
been pressed and waiting two more timer interrupts and
then actioning the abort.
Sigh. You do *NOT* leave it up to some random factor to force your program
to abort whatever it is busy with. Doing so is simply asking for trouble.
You mentioned that you shouldn't be aborting a hard \
disk write.
As an example, yes. Same goes for your connection to that BBS of yours too though
The OS will always be the one who initiates that.
No. *Your program* initiates it. It also holds the to-be-written data.
Just imagine what happens when the OS-based disk-write routine is reading whatever you want to have written, and you just yank that buffer away from under it.
Have you ever heard about how a use-after-free is something that should /never/ happen ? You would be opening up yourself to the same. Bonus
points if some other program allocates that same buffer space and overwrites it.
Or alternatively, the OS will know whether it is in the
middle of doing any OS work at all, or whether it is an
application being run.
:-) Now you are trying to offload the problem to an imaginary (future)
(D)OS. Thats not the way to go I'm afraid. For one, further
development of your client would need to stop until those OS features are available ...
When doing a blocked read from a COM port (assuming
such a BIOS call exists, which doesn't seem to be the
case),
Actually, its the opposite. Blocking calls are the default. The
non-blocking ones - or the ones that have a timeout - are, especially under BIOS / DOS, the exception of the rule.
You might not directly notice a COM port blocking I/O effect, but thats most likely either because most of todays UARTs have a (small) internal buffer,
or your C{something} function-library is buffering it for you (yes, your C{something} programming environment might actually already carry an interrupt-driven COM library).
But yes, there is a possibility that your C{something} based COM access will (be configured to) return immediatily - regardless of if all the data has been received or not. And that ofcourse means that you (again) need to
poll to get all the transmitted-to-you data ...
And then finally moving on to the BBS - remembering
that it is a cooperative BBS - the OS can be set to
send the ctrl-c out the COM port as part of aborting
the application.
:-) You *say* you're "moving on to the BBS", but directly mock those words
by only talking about something the OS your client is running on is supposed to be doing.
Also, how would that OS know that there is a serial connection active, or
what exactly to say (and when!) to that BBS ?
No, you're fantasizing about OS capabilities I'm afraid.
*You* have to write it.
Either as part of your client, or as part of your future OS.
I suggest you keep focussed on your client.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 228:37:02 |
| Calls: | 6,624 |
| Calls today: | 6 |
| Files: | 12,171 |
| Messages: | 5,318,994 |