DOS ain't dead

The MODE command goes something like:

MODE COM1:9600,N,8,1

This then needs to be translated into a call
to this BIOS interrupt:

http://www.ctyme.com/intr/rb-0811.htm

9600 is actually the maximum allowed value
for that interrupt, but I believe I read
somewhere that some implementations redefine
those values. Also I see here that there are
extensions available - not sure how you know
when they can be used:

http://www.ctyme.com/intr/rb-0823.htm

Regardless, I was thinking that the MODE
command should allow a speed of "MAX" instead
of needing to code an actual value.

Because the serial port in some implementations
is going to be emulated by qemu or whatever, and
the speed doesn't have a lot of meaning.

What do you think "best practice" should be?

I need to implement this for PDOS/386. Currently
I have a "portinit" command and usually give it
a value of 0xe3.

Thanks. Paul.

> The MODE command goes something like:
>
> MODE COM1:9600,N,8,1
>
> This then needs to be translated into a call
> to this BIOS interrupt:
>
> http://www.ctyme.com/intr/rb-0811.htm

I'm not so sure that's true. Here's an excerpt from the MS_DOS 7.1 HELP for the MODE command:

***

Syntax
MODE COMm[:] [b[,p[,d[,s[,r]]]]]
MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s] [RETRY=r]

Parameters
COMm
Specifies the number of the serial (COM) port. Valid values for m are in
the range 1 through 4.

If you omit any of the following five parameters, MODE uses the most
recent setting for the omitted parameter. If you are using the shorter
form of the syntax (without the words BAUD=, PARITY=, DATA=, and so on),
the MODE command "recognizes" the parameters by their positions. Thus,
if you do not specify a value for a parameter, you must still type the
comma that precedes the next parameter.

BAUD=b
Specifies the first two digits of the transmission rate in bits per
second. The following list shows each valid value for b and its related
rate:

11 110 baud
15 150 baud
30 300 baud
60 600 baud
12 1200 baud
24 2400 baud
48 4800 baud
96 9600 baud
19 19,200 baud

The b value of 19 is not supported on all computers (check your hardware
manual). You can abbreviate this parameter by omitting BAUD= and
specifying a value for b.

***

Based on this description, MODE is not necessarily supposed to initialize the Serial Port, but merely change its parameters. If you want to only change one specific parameter from what it already is, you just provide the one parameter. This may mean MODE may need to keep track of whether the port is already initialized or not, or at least read all the existing parameters and not change the ones the user isn't requesting to be changed.

Also, it appears that it will theoretically accept almost any value for the Baud Rate if you leave out the "BAUD=" and just give it a number. Also, I've seen some serial port hardware that supports 230400 bps.

I work in the communications industry, and the incorrect use of the word "Baud" is one of my pet peeves. What you're changing is the Bit Rate, not the Baud Rate. I could go into a long explanation if anybody cared, but nobody probably does.

> one parameter. This may mean MODE may need to keep track of whether the
> port is already initialized or not,

I think this is correct.

> or at least read all the existing parameters

I don't see a BIOS call to do this.

> Also, it appears that it will theoretically accept almost any value for the
> Baud Rate if you leave out the "BAUD=" and just give it a number. Also,
> I've seen some serial port hardware that supports 230400 bps.

Ok, I don't see a BIOS call for that, and I
thought that the UART divisor couldn't handle
more than 115200.

> I work in the communications industry, and the incorrect use of the word
> "Baud" is one of my pet peeves. What you're changing is the Bit Rate, not
> the Baud Rate. I could go into a long explanation if anybody cared, but
> nobody probably does.

I thought that people in the industry used symbols/sec
rather than "baud" now, and that the English language
has changed such that the very definition of "baud"
is "bps"? English is *defined* by common usage.

BFN. Paul.

> > one parameter. This may mean MODE may need to keep track of whether the
> > port is already initialized or not,
>
> I think this is correct.

How would MODE do that, though, if it's not a TSR? There's nowhere in memory it can store the data, and another program could directly change the parameters in hardware without MODE ever knowing about it. The only way it could work properly is to not depend on the BIOS.

> > or at least read all the existing parameters
>
> I don't see a BIOS call to do this.

If not, you'll need to work directly with the hardware (I/O ports).

> Ok, I don't see a BIOS call for that, and I
> thought that the UART divisor couldn't handle
> more than 115200.

SOME hardware can support 230400 but not all. For the ones that support 230400 you set the Divisor to 0.

> I thought that people in the industry used symbols/sec
> rather than "baud" now, and that the English language
> has changed such that the very definition of "baud"
> is "bps"?

No, the definition of baud has not changed. In certain contexts baud and bps can be the same, but they are not synonymous.

> English is *defined* by common usage.

No, words are not defined by common usage. Words can be used correctly or incorrectly, and usage can be contextual, but that doesn't change the definition.

> > > one parameter. This may mean MODE may need to keep track of whether
> the
> > > port is already initialized or not,
> >
> > I think this is correct.
>
> How would MODE do that, though, if it's not a TSR? There's nowhere in
> memory it can store the data, and another program could directly change the
> parameters in hardware without MODE ever knowing about it. The only way it
> could work properly is to not depend on the BIOS.

MODE can do an OS call and the OS can keep
track of the situation. I assumed that is
how it was done in MSDOS too, but maybe not.

> SOME hardware can support 230400 but not all. For the ones that support
> 230400 you set the Divisor to 0.

Cool, thanks.

> > I thought that people in the industry used symbols/sec
> > rather than "baud" now, and that the English language
> > has changed such that the very definition of "baud"
> > is "bps"?
>
> No, the definition of baud has not changed. In certain contexts baud and
> bps can be the same, but they are not synonymous.
>
> > English is *defined* by common usage.
>
> No, words are not defined by common usage. Words can be used correctly or
> incorrectly, and usage can be contextual, but that doesn't change the
> definition.

Sorry, but that is exactly how English is defined.
Most other languages have a body that decides
official definitions of words, but there is no such
body for English. The dictionary-writers just look
at how words are being used by the public and add
any new words, or new definitions of words, or
changed definitions of words, to the dictionary.
It's not the other way around.

If someone is selling a 2400 baud modem, you
shouldn't assume they are talking about the
number of symbols per second and that it's
actually a 9600 bps modem or whatever. It means
it's a 2400 bps modem. Always. Every time. That's
the meaning of the word. Whoever gave the word
"baud" to the public is responsible for the word
being commandeered and no longer belonging to the
technical people in its original meaning.

BFN. Paul.

> MODE can do an OS call and the OS can keep
> track of the situation. I assumed that is
> how it was done in MSDOS too, but maybe not.

I'm not sure how MS or Free or any other DOS actually does it. But I think if I were implementing it I would just read the UART data directly from the I/O port. Even though there's not a standard BIOS (INT 14h) call you can use, the base I/O addresses of the four serial ports are stored in the BIOS Data Area (BDA) at 0040:0000 so they are part of the BIOS. It odes seem weird that there isn't an INT 14h call to read the current status, almost as if they expect you to use direct I/O.

I've only messed around with serial ports a little bit, and when I did I always used direct I/O. I wrote a TSR called SERIAL that monitors the status of a serial port in "real time" on the screen, which you can download from my website (bretjohnson.us) if you're interested. I also know in the old days at least some of the BBS's used FOSSIL, which is an "upgraded" INT 14h, but that won't help you here.

> > MODE can do an OS call and the OS can keep
> > track of the situation. I assumed that is
> > how it was done in MSDOS too, but maybe not.
>
> I'm not sure how MS or Free or any other DOS actually does it. But I think
> if I were implementing it I would just read the UART data directly from the
> I/O port. Even though there's not a standard BIOS (INT 14h) call you can
> use, the base I/O addresses of the four serial ports are stored in the BIOS
> Data Area (BDA) at 0040:0000 so they are part of the BIOS. It odes seem
> weird that there isn't an INT 14h call to read the current status, almost
> as if they expect you to use direct I/O.
>
> I've only messed around with serial ports a little bit, and when I did I
> always used direct I/O. I wrote a TSR called SERIAL that monitors the
> status of a serial port in "real time" on the screen, which you can
> download from my website (bretjohnson.us) if you're interested. I also
> know in the old days at least some of the BBS's used FOSSIL, which is an
> "upgraded" INT 14h, but that won't help you here.

PDOS/386 uses the BIOS for everything, which gives
it a benefit that a BIOS vendor can implement the
serial port on INT 14H as some other device, like
Bluetooth or Wifi.

My dumb phone (an Alcatel Onetouch) supports Bluetooth
plus has an internet connection, and it would be great
if I could boot PDOS/386 on the metal, point my BIOS to
my phone, and be able to contact a newsgroup. I was
hoping that SeaBIOS could help with that, but the
bottleneck is apparently Bluetooth being undocumented.

The next best thing is for me to buy a computer with a
real serial port, and connect that to another computer
running Linux or whatever and presenting me with the
newsgroup capability by forwarding on my requests.

Or simply continue as now which is to run PDOS/386
under Bochs or qemu or Virtualbox under Windows.

BFN. Paul.

> PDOS/386 uses the BIOS for everything, which gives
> it a benefit that a BIOS vendor can implement the
> serial port on INT 14H as some other device, like
> Bluetooth or Wifi.
>
> My dumb phone (an Alcatel Onetouch) supports Bluetooth
> plus has an internet connection, and it would be great
> if I could boot PDOS/386 on the metal, point my BIOS to
> my phone, and be able to contact a newsgroup. I was
> hoping that SeaBIOS could help with that, but the
> bottleneck is apparently Bluetooth being undocumented.

Oh, a nice dream but only a dream. Any BIOS vendor would not implement a BIOS service for embedded BT/WiFi whatever module. And because it's almost undocumented you couldn't implement the service by yourself. Except if you will design your own OpenHW/FW machine :) Or you have to use some transparent UART-BT module with serial profile attached to your COM port.

Even setting higer baudrates over standard 115200 is problematic as there are different UART controllers (some devices can do up to 1Mb/s) that need to be set by HW specific routine and it may not be possible to autodetect it. In case of additional multiuart PCI card it is possible to scan a specific PCI VID, PID and then know what UART you have and how to setup the speed correctly.

---
DOS gives me freedom to unlimited HW access.

> The MODE command

I am never keep this program on my hard drive (answer from 199x years)

> What do you think "best practice" should be?

(IMHO)
If you want develop in modern way - you must extend MODE and invent something new for BIOS call.
If you want develop in oldschool way - forget about MODE+BIOS and provide FOSSIL-driver api (MODE+FOSSIL ?).

FOSSIL-driver strong used in FTN-software (and many BBS).

C. Basic principles of a FOSSIL driver

    1)  Interrupt 14H.

    The one basic rule that the driver depends upon,  is the ability for ANY
    target machine to allow the vector for INT 14H (usually pointing to BIOS
    comm functions) to be "stolen" by the driver.  In a system where the INT
    14H vector is used already, it must be possible to replace the "builtin"
    functionality with that of a FOSSIL,  when an application that wants the
    use of a FOSSIL is to be run on the target machine.

...

D. Functions currently defined for FOSSILs

    AH = 00H    Set baud rate
                Input:  AL = baud rate code
                        DX = port number

    This works the same as the  equivalent IBM PC BIOS call,  except that it
    ONLY selects a baud rate.  This is passed in the high order 3 bits of AL
    as follows:

                010 =   300 baud
                011 =   600  ''
                100 =  1200  ''
                101 =  2400  ''
                110 =  4800  ''
                111 =  9600  ''
                000 = 19200  '' (Replaces old 110 baud mask)
                001 = 38400  '' (Replaces old 150 baud mask)


etc

http://ftsc.org/docs/fsc-0008.001
http://ftsc.org/docs/fsc-0015.001

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> (IMHO)
> If you want develop in modern way - you must extend MODE and invent
> something new for BIOS call.
> If you want develop in oldschool way - forget about MODE+BIOS and provide
> FOSSIL-driver api (MODE+FOSSIL ?).

> 000 = 19200 '' (Replaces old 110 baud mask)
> 001 = 38400 '' (Replaces old 150 baud mask)


Ok, what the OS does is transparent to the
applications. Applications just fopen("com1", "r+b")
and it is the OS that arranges the BIOS INT 14H call.
That can indeed be the Fossil-style of doing a blocking
read as opposed to the non-Fossil style of timing out.
Currently PDOS/386 has a loop so that apps block, with
the OS dealing with the timeouts. That hard loop can
be changed to an interrupt-driven routine at any point
in the future. Or maybe the BIOS setup in the future
will allow me to make the read call block (as well as
redirect to bluetooth or whatever).

So I'm only interested in what the user or apps see.
Unless you can see a problem with the fopen() above,
there is no need to change apps. Apps rely on the
COM port already being initialized correctly, although
I could change that string from "com1" to
"com1:19200,N,8,1". But I'm more inclined to keep
low-level details like what speed your modem is
(assuming it isn't bluetooth/wifi) outside of the
application (or application's config file). What do
you think?

And the user setting the speed of his modem is something
that should probably be done in the autoexec.bat rather
than every single comms program. In fact, even "com1"
should be abstracted and changed to perhaps
"external:eternal-september.org:119" and the OS is
responsible for realizing this is a request for an
external connection, and the OS knows that it has a
modem on COM1 and COM3, but the one on COM1 is
preferred, and is Hayes-compatible, so the OS issues
an ATDTexternal-september.org:119 which establishes
a connection one way or another, and finally the app
is given an NNTP data stream.

What do you think?

BFN. Paul.

> What do you think?

Sorry, i cant answer by reasons:

1. This is architectual question. So, at first, need understand "what you want receive in the end?" (what kind of OS design)
2. (partly) english is not my native (and may be i am not catch your mind)

In original MS-DOS has been broken principle "Everything is a file". Imho, this is good idea (Everything is a file), but can broke compatibility. Most often, drivers were used as a type of TSR (instead in driver sense). And need to remember, com/lpt used not just for networking - there are many industrial equipment (machine tools) that still work with DOS.

PS: Personaly for me, most interesting will be text-mode multitasking with networking (like deskview) in 32-bit DOS. But this is another story (need to do huge investigation).

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > What do you think?
>
> Sorry, i cant answer by reasons:
>
> 1. This is architectual question. So, at first, need understand "what you
> want receive in the end?" (what kind of OS design)

I don't really understand this. I'm basically trying
to connect to something that looks like a BBS. That's
the paradigm I like. I don't like doing TCP/IP calls.
I like the simplicity of a serial port.

There is flexibility in the OS design. The main thing
is that it should look like MSDOS, and run a compiler
and other command-line tools, plus micro-emacs using
ANSI control characters, and everything should be
written in C90, or MSDOS-like calls, not Posix which
requires silly things like fork() and lacks essential
things like a simple syscall to obtain memory.

> In original MS-DOS has been broken principle
> "Everything is a
> file". Imho, this is good idea (Everything is a file), but can broke
> compatibility.

I'm happy to break compatibility, and I do indeed
want everything to be a file, but not a Unix file
descriptor - I want all my applications to operate
by doing C90 calls. There are some applications that
require scanning a directory - for those applications
I want to use an MSDOS-like call, not Posix.

I don't mind breaking compatibility to achieve this
goal, and I don't mind sacrificing things like a lack
of timeout facilities because that doesn't exist in
C90. I want protocols that aren't dependent on that,
like the NNTP protocol.

> Most often, drivers were used as a type of TSR (instead in
> driver sense). And need to remember, com/lpt used not just for networking -
> there are many industrial equipment (machine tools) that still work with
> DOS.

And I would like those applications to be rewritten
in standard C90. Any reason why a machine tool can't
be operated by doing fopen("com1", "r+b"); ?

> PS: Personaly for me, most interesting will be text-mode multitasking with
> networking (like deskview) in 32-bit DOS. But this is another story (need
> to do huge investigation).

My focus is on getting single-tasking working to my
satisfaction. A 32-bit version of MSDOS that I am
happy with. Currently I provide 3 different visions
of that.

BFN. Paul.

> In fact, even "com1"
> should be abstracted and changed to perhaps
> "external:eternal-september.org:119"

> I don't really understand this. I'm basically trying
> to connect to something that looks like a BBS. That's
> the paradigm I like. I don't like doing TCP/IP calls.
> I like the simplicity of a serial port.

IMHO you are remarkably clueless in what you are 'designing'.

even skipping the hard hardware level (RS232, RS422, RS485),
soft hardware level (baud rate, parity, etc.)

COM as a blocking call is hugely useless.

just imaging calling your "external:eternal-september.org:119" as a blocking call.

forgot to plugin modem line? wait a minute and reboot.
forgot to power up the modem ? wait a minute and reboot.

DNS resolver (eternal-september.org) not online? reboot.

eternal-september.org on maintenance or power failure? reboot.

your C90 everything design is simply not suited to real-world communication.

the socket interface was invented/designed for exactly this purpose.

of course, you may develop a TSR that does all this TCP/IP stuff and looks on top like
fd = fopen("external:eternal-september.org:119", "r+b"),

but 32-bit MSDOS won't help in implementing it.

> > In fact, even "com1"
> > should be abstracted and changed to perhaps
> > "external:eternal-september.org:119"
>
> > I don't really understand this. I'm basically trying
> > to connect to something that looks like a BBS. That's
> > the paradigm I like. I don't like doing TCP/IP calls.
> > I like the simplicity of a serial port.
>
> IMHO you are remarkably clueless in what you are 'designing'.

Note that it is already implemented. I'm now
looking to see whether the design should be
modified, or maybe the C standard modified.

> even skipping the hard hardware level (RS232, RS422, RS485),
> soft hardware level (baud rate, parity, etc.)

I am doing that via an effective MODE command
in autoexec.bat. Is that a problem? It's working
fine.

> COM as a blocking call is hugely useless.

It's working fine.

> just imaging calling your "external:eternal-september.org:119" as a
> blocking call.

No need to imagine it, I've used it.

> forgot to plugin modem line? wait a minute and reboot.
> forgot to power up the modem ? wait a minute and reboot.
>
> DNS resolver (eternal-september.org) not online? reboot.
>
> eternal-september.org on maintenance or power failure? reboot.

So far I've never had to reboot for any of those
reasons, but you are correct, I will reboot if I
encounter a problem. This is single-tasking
MSDOS equivalent. It's not a big deal.

And when it works, which 99% of the time it does,
you will be able to download source code, using
zmodem, to get a non-blocking comms program to
replace it. That is my actual goal. To provide,
using C90, the tools required to make non-C90
software if you desire non-C90 features.

> your C90 everything design is simply not suited to real-world
> communication.

Sure. And the lack of a GUI is going to put some
people off too, but you have the tools to write
or download a GUI too.

> the socket interface was invented/designed for exactly this purpose.

It wasn't possible to extend C90 slightly? There
couldn't have been a "don't block" setvbuf call
for example?

> of course, you may develop a TSR that does all this TCP/IP stuff and looks
> on top like
> fd = fopen("external:eternal-september.org:119", "r+b"),

Can you please elaborate on your TSR idea?

> but 32-bit MSDOS won't help in implementing it.

32-bit MSDOS should be equally capable of
implementing it as 16-bit MSDOS, shouldn't it?

Thanks. Paul.