Dec 122017
D/L’d from Quarterdeck BBS. Complete text of all Tech Bulletins (DV/QEMM/QRAM). | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
43LINE.TEC | 2834 | 1175 | deflated |
512AT.TEC | 3793 | 1614 | deflated |
AB_PLUS.TEC | 5560 | 2312 | deflated |
AMIBIOS.PAT | 1936 | 956 | deflated |
API.TEC | 3974 | 1834 | deflated |
APIBBS.TEC | 3848 | 1834 | deflated |
APISTART.TEC | 3458 | 1453 | deflated |
AS400.TEC | 3139 | 1511 | deflated |
AS400Q.TEC | 1765 | 943 | deflated |
AST286.TEC | 2479 | 1158 | deflated |
ASTUTIL.TEC | 2221 | 1047 | deflated |
ATTPAT.TEC | 4047 | 1726 | deflated |
AUTOSCRI.TEC | 6305 | 2573 | deflated |
BANYAN.TEC | 2159 | 1005 | deflated |
BBS.TEC | 873 | 489 | deflated |
BIGSMART.TEC | 16386 | 3583 | deflated |
BIX.TEC | 7523 | 3443 | deflated |
BOOKS.TEC | 3190 | 1438 | deflated |
CIS.TEC | 3395 | 1647 | deflated |
COM3N4.TEC | 4809 | 2001 | deflated |
COMM.DOC | 19062 | 6710 | deflated |
COMPANIO.TEC | 2615 | 1267 | deflated |
CONTACT.TEC | 4670 | 1614 | deflated |
DBASE3P.TEC | 2666 | 1267 | deflated |
DESQMEM.TEC | 1694 | 775 | deflated |
DIRECTLY.TEC | 1562 | 741 | deflated |
DOS4.TEC | 4226 | 1787 | deflated |
DOS40BUG.TEC | 2388 | 1113 | deflated |
DUAL_MON.PAT | 4263 | 1678 | deflated |
DV-OK.TEC | 1197 | 614 | deflated |
DVANSI.TEC | 1650 | 785 | deflated |
DVOFMAT.TEC | 4123 | 1239 | deflated |
DVPALET.DOC | 6529 | 2257 | deflated |
ENVIRON.TEC | 4228 | 1773 | deflated |
EXCEL21.TEC | 1754 | 775 | deflated |
EXCEPT13.TEC | 3829 | 1631 | deflated |
EXPAND.TEC | 5198 | 2269 | deflated |
EXTEND.TEC | 1064 | 570 | deflated |
EXTEND2.TEC | 5537 | 2137 | deflated |
FAST.DOC | 1249 | 663 | deflated |
FIXINT1.PAT | 5086 | 1793 | deflated |
FORMFEED.PAT | 3520 | 1510 | deflated |
GENIUS.DOC | 6803 | 2176 | deflated |
GNS.TEC | 5251 | 2203 | deflated |
HRAMFONT.TEC | 3614 | 1519 | deflated |
IDE.TEC | 4440 | 1841 | deflated |
INDEX.TXT | 9133 | 3917 | deflated |
INST226.PAT | 1794 | 923 | deflated |
INTERNET.TEC | 11393 | 2179 | deflated |
KB8.PAT | 682 | 390 | deflated |
KBMOUSE.TEC | 2207 | 1009 | deflated |
LANTAST2.DOC | 2894 | 1412 | deflated |
LANTASTI.TEC | 2900 | 1404 | deflated |
LIM4-2.TEC | 3515 | 1296 | deflated |
LIM4.TEC | 3542 | 1546 | deflated |
LOADHI.TEC | 3784 | 1586 | deflated |
LONGPATH.TEC | 1339 | 642 | deflated |
LOTUS2.TEC | 2724 | 1254 | deflated |
LOTUS3.TEC | 8649 | 3202 | deflated |
MCA.ADL | 32112 | 6300 | deflated |
MEMSIZE.TEC | 2933 | 1224 | deflated |
MEMSTAT.TEC | 3148 | 1405 | deflated |
MOUSE.TEC | 3804 | 1505 | deflated |
MULTI-T.TEC | 5804 | 2276 | deflated |
NEC_SX.TEC | 648 | 393 | deflated |
NETWORK.TEC | 813 | 445 | deflated |
NINSTALL.TEC | 6947 | 2604 | deflated |
NOFF.DOC | 3224 | 1385 | deflated |
NUMBERS.TEC | 1160 | 394 | deflated |
NWORK.TEC | 6321 | 2488 | deflated |
OUTMEM.TEC | 2013 | 925 | deflated |
PARMS.TEC | 1906 | 861 | deflated |
PCTOOLS.TEC | 6360 | 1642 | deflated |
PROSPEED.PAT | 4852 | 1653 | deflated |
PROTECT.TEC | 2362 | 1037 | deflated |
PRTSC.PAT | 1511 | 798 | deflated |
PRTSCR.PAT | 1313 | 676 | deflated |
PS2.TEC | 2345 | 1089 | deflated |
QEMM5060.PAT | 3035 | 1300 | deflated |
QEXT.TEC | 3809 | 1669 | deflated |
QRAMC&T.TEC | 4828 | 1881 | deflated |
QRAMNOTH.TEC | 4995 | 2168 | deflated |
RAMDRIVE.TEC | 2611 | 1167 | deflated |
RBASE21.TEC | 2910 | 1359 | deflated |
REBOOT.PAT | 151 | 110 | deflated |
REMM.TEC | 425 | 264 | deflated |
SCSIVDS.TEC | 2470 | 1114 | deflated |
SERNUM.TEC | 2152 | 570 | deflated |
SER_PRN.TEC | 1184 | 577 | deflated |
SETENVIR.TEC | 1658 | 817 | deflated |
SK-PLUS.TEC | 5657 | 2305 | deflated |
SNET.TEC | 7456 | 3243 | deflated |
TERMXDI.PAT | 2015 | 970 | deflated |
TOKEN.TEC | 6644 | 2453 | deflated |
TOPS.TEC | 10038 | 4071 | deflated |
TOSH5100.TEC | 1520 | 698 | deflated |
TPCREAD.ME | 199 | 165 | deflated |
UNISYS.PAT | 8463 | 2965 | deflated |
VCPI.TEC | 767 | 488 | deflated |
VGA.TEC | 5084 | 1887 | deflated |
WINDOWS.TEC | 6657 | 2611 | deflated |
WINSIZE.TEC | 7921 | 3246 | deflated |
WP50.TEC | 2861 | 1252 | deflated |
XDV.TEC | 2651 | 1313 | deflated |
XDV2.TEC | 3260 | 1387 | deflated |
XT-286.TEC | 1346 | 734 | deflated |
Download File QOSTNOTE.ZIP Here
Contents of the COMM.DOC file
Communications programs such as terminal emulators, electronic mail programs,
and Bulletin Board Systems (BBS) are one of the most popular reasons for using
a multitasking environment. It is well known that several computers can
"talk" to each other. It might be getting information from a mainframe
database. Perhaps sending electronic letters is more cost effective than
using a messenger service. Or maybe you would like to download the latest
"freeware" program and yet get some other, more important work, done at the
same time. Sometimes you have to redial a BBS dozens of times before it's
available. With a multitasking program you can keep dialing while you do
something else. Having instant access to communications programs and allowing
them to operate in the background while performing other tasks is one instance
of where multitasking programs prove very worthwhile.
This chapter will describe the important features of communications programs
as they regard multitasking, special considerations for multitasking, and
how to find and avoid problems with background communication.
While there are several popular multitasking environments available for IBM
PC and compatible computers, one of the most popular is DESQview. DESQview
is designed to allow multiple off-the-shelf programs to be able to run at
the same time. These programs can be of any type. Depending on the amount
of memory and the type of program you have, it is possible to run programs
in either 640K or beyond with DESQview. While the information in this
chapter will concentrate on suggestions for DESQview, most of the data is
appropriate to other multitasking environments as well.
The Basics of Communications
The two most important concepts to understand for communications are ports
and interrupt request lines or IRQ.
Communication Ports
The communication port is the place where the actual data is read or written.
When a value is to be sent to the serial line, whether it is to a modem or a
direct connection, the data is placed into a communication port. The device
attached to the port, usually an Universal Asynchronous Receiver Transmitter
or UART (pronunced "YOU"-"ART"), converts the data from its current form of 8
bits, into a serial stream; each bit "follows" the others as though they were
going through a pipe. The data in the computer is usually stored in groups
called bytes, which consist of 8 individual bits. A communications line, also
called a serial line, only has one wire over which the data can be sent. A
second line is used to receive. The UART takes the byte of data to send and
"flattens" it, sending one bit at a time. Another UART on the other side
"collects" the individual bits and then presents them as a byte to the
receiver. This kind of operation can only really service one program at a
time, so in a multitasking environment you must have one communication port
(UART location) for each program which needs to communicate.
The standard UARTs can only send and receive one byte at a time. If the
receiving UART has a byte ready and the computer does not read it before
another byte of data arrives, then the data has "overrun" and is lost. It is
very important in a multitasking environment to make sure that the
communications lines are handled as quickly as possible to avoid overrun.
There do exist UARTs which can "buffer" more than one byte, and thus "hold on"
to some data until the computer is ready to receive it. One of these is the
16550A, which can buffer up to eight bytes before overrun occurs. Converting
to a 16550A and software which understands it can be very useful when using
high speed communications while multitasking.
There are several ways to decide which port to use, but most communications
programs allow you to configure the one you want. The most frequently used
ones are COM1 and COM2. The usual port values for these are 3F8 and 2F8. The
location for determining the exact port value is at 40:0 and 40:2, in memory
locations known as the BIOS data area. A communication program normally looks
into this area to find out if a communication port exists, and if so, what the
port value to use is. It is possible to have more ports, but IBM hasn't set a
standard way for finding more ports so each hardware vendor has made up a
method for extending the number of ports. Only COM1 and COM2 can be sure to
work under all circumstances.
The method of looking at 40:0 and 40:2 to find the ports is not universal
though. Some programmers assume that the port values are going to exist with
the particular numbers 3F8 and 2F8. They are probably right 98% of the time,
but it is very confusing if you happen to have your computer set up
differently and a program doesn't work right. I once saw a program which not
only assumed the port values, it also assumed that you wouldn't know how to
set them up, so it always took any data from either port. You couldn't use a
mouse with it because the mouse driver program would have its data stolen! It
also wouldn't allow a second communications program to be multitasked with it
either. Most of the popular programs are quite well behaved, and this is
important for multitasking environments, since several programs and/or devices
will need to coexist in the same computer at one time.
Interrupt Request Lines
An interrupt request line, or IRQ, is a way for a device, such as the
communications port (using an UART), to interrupt whatever the computer is
doing for a moment in order to handle something important; such as a character
which just came in on the serial line. These interrupts are prioritized so
that the most important ones are handled first and can interrupt less
important ones. Thus, if a disk drive has just interrupted the computer and
then a serial line has some data ready, the serial line can "interrupt the
interrupt". The disk, after all, can wait. The serial line has to avoid
overrun. A list of the standard IRQ values and their function is listed in
table 1. DESQview modifies this list (when "Optimize communications" is "Y")
so that communications ports can interrupt everything else and be handled as
quickly as possible; you probably can't type as fast as another computer can
send you data.
The normal IRQs used for communications are IRQ4 (COM1) and IRQ3 (COM2). Yes
this seems backwards. My guess is that, when the IBM PC was being designed,
only one communication line was envisioned. Some time later, after having too
many programs already written using COM1 to change it, they decided to add
another. But the only unused IRQs were numbers 2 & 3. IBM then chose IRQ3
for COM2. Normally most of us wouldn't care about this except that the lower
the IRQ number, the higher its priority. Thus while it seems anti-intuitive,
COM2 actually has a higher priority than COM1. Thus, if you have two
communications programs running, the higher speed one should be on COM2. Or,
if you have a serial mouse in addition to your modem, the modem should be on
COM2 since you can tolerate having the mouse a little "jumpy" in order to not
lose any incoming data.
For IBM's COM3 and COM4 they re-used IRQ 4 and IRQ 3. How? By using a
different port address and having a special indicator value which tells the
interrupt service routine whether the data is for COM1 or COM3 for instance.
But only specially configured programs know how to do this, and there is no
way for a multitasker such as DESQview to know which program is supposed to
get the data for a particular IRQ. If each communications line uses a
different IRQ (say IRQ5 or IRQ2), then there is no ambiguity about which
program gets which data. In addition, there are special drivers written, the
most popular is FOSSIL, which can perform the proper arbritration needed to
handle multiple serial requests. These usually require special communications
hardware adapters.
All of the better communications programs use interrupt processing to handle
receiving of data; it's the most efficient method. It's also best for
multitasking. A program may be busy doing some calculation when a character
has been received by the UART. The UART asserts the proper IRQ and the
current program is interrupted (that's why they're called interrupts) and the
program is put "on hold" for the moment. The communication program has set up
a special routine to handle the interrupt, which usually reads the data from
the port and then stores it someplace to be handled later. The interrupted
program is then resumed. At some later time, the communication program gets
control and takes charge of the stored data. Perhaps it is displayed on the
screen or stored in a file. Often several characters have been received and
"buffered" before the "main" program can handle them. This usually happens so
fast that you don't see anything unusual.
There are some programs which don't use interrupts. They will "loop" or
"poll" the port waiting for the UART to signal that the data is ready and then
process it. This is very wasteful of computer time, since the computer could
be doing many other things while waiting for the next piece of data. These
programs are also especially bad for multitasking programs. First, it wastes
time which could be used by other programs. Second, since a mulitasker must
give a little bit of time to each program, the communications program is not
always in control, and if some data arrives and the communications program is
not active, the data will be lost.
In summary, the important aspects for multitasking are:
a) a serial port can be used by only one program at a time
b) received data must be read as quickly as possible to avoid overrun
c) the number of serial ports is limited
d) the BIOS data area should be used to determine port numbers
e) communications interrupts are prioritized
f) most programs receive their serial input using interrupts
Special Considerations for Multitasking
Most programs, while unaware that multitasking may take place, are
reasonably well behaved. This allows a program like DESQview to run
programs unmodified. There are several things which you must take into
account:
Writing to the Video Display
In order to work as fast as possible, many programs write directly to the
video display memory. This provides the fastest possible video response.
It is also very bad for a multitasking environment. If a program is going
to write directly to the video display while in the background, it will
"bleed through" on top of another program or programs. This is probably
undesirable for most people. What needs to be done is to either have a
program "behave" and use the DOS or BIOS calls provided to write to the
display, or to use a special interface which allows programs to continue to
think that they are writing directly to the video display, while actually
accessing another location which is then updated without interfering with
the other programs. This can be done either by configuring the program to
"behave" or by the program detecting that it is in an environment and
converting itself to behave.
DESQview has a very efficient method for allowing programs to "think" that
they are writing to the video display while actually using an alternate (or
"shadow") area. This method can automatically be invoked by a program in
DESQview, and many of the most popular programs use it, including Crosstalk
XVI and Mark IV, Procomm, ProYAM, PIBTerm, BitCOM, and PC-Talk. On an 80386,
DESQview 386 can even make "misbehaved" programs stay away from the video
screen using special features available on the 80386.
Keeping the Program in Memory
Most multitasking environments allow the programs running in them to be
"swapped" out of memory. This allows you to suspend a program and then resume
it where you were at a later time. Usually programs are swapped to the disk,
but it could also be to a RAM disk, network drive, or expanded memory. Since
the serial ports can interrupt whatever is happening at any time, it is
essential that the program NEVER leave memory while communications are in
progress. Thus a communications program must NOT be allowed to "swap". Most
multitasking programs, including DESQview, allow these programs to be set up
so that swapping will not happen.
The problem is that forcing a program to be "non-swappable" can fragment
memory. If you want to start a new program, and a non-swappable
communications program is in the way of the memory you need, then you won't be
able to run the new program until you close the communications program. This
defeats the purpose of multitasking. DESQview allows communications programs
which are not currently active (perhaps running but not connected to another
computer at the moment), to be swapped. When this happens, DESQview will
"disconnect" the interrupt value from the program. Then, if a character
happens to come in (maybe the phone rings), it will be ignored since the
special interrupt routine is no longer in memory. DESQview will "reconnect"
the interrupt location when the program is swapped back in later. You can
usually avoid memory fragmentation by running the communications programs
first which then leaves the rest of memory contiguous. If you have expanded
memory, or an 80386, then it's possible to have the program run in expanded
memory and not have to worry about memory fragmentation.
Multiple communications programs
There is no real reason NOT to have more than one communication program
available at a time (if your wallet can afford it). There are several
technical considerations though.
For instance, no two programs can use the same port at the same time. The
communications ports are like your water faucet; you can make it go as fast
as you want but only one glass at a time can fit under it. There are programs
which know how to put special information in the data stream to tell the
receiving end which program the data is for, but these programs normally
handle special purpose applications. This allows a single serial line to
appear to be handling multiple sessions. It works by embedding some special
information into the data to say "this is for program A", and then only that
program takes the data. Very few services use this feature.
In most cases, you can use a maximum of 2 communications programs at one time,
since IBM only officially recognizes COM1 and COM2 each on its own IRQ. As
mentioned before, COM3 and COM4 don't usually have their own IRQ values so
they can't be used. If an add-in board DOES have separate IRQ for each
communications port, then it is possible to have more than two programs
communicating at one time.
Communication Speed
The computer itself can only perform one function at a time. A multitasking
program such as DESQview divides the computers attention between several
different programs for short periods of time. Since the computer is so fast,
each of these programs appear to be running at the same time, but obviously
they are not. Thus, when multitasking, each program is running slower than it
normally would. This is usually not a major problem, since most programs
spend most of their time waiting for input and then process for some time and
go back to waiting. But a communications program must be ready to take its
data when it arrives. As mentioned before, interrupts are used to get the
computer's attention when the data is ready. But if the data is coming in too
fast, then the interrupt routine cannot process the information before the
next byte arrives.
For various reasons, there are some standard rates at which computers
communicate. Usually 110, 300, 600, 1200, 2400, 4800, and 9600 bits
per second. Since there are a few bits of control information being sent,
these numbers translate into about 10, 30, 60, 120, 240, 480, and 960
characters per second. Even faster speeds are being used in some special
applications. At the slower speeds, the computer has plenty of time to digest
the incoming data and be ready for more. In the time not used to process
serial data, there's time to do other work such as word processing,
spreadsheets or compiling.
When communicating at 240 characters per second, the characters arrive about
once every 4 milliseconds (every 4 thousandths of a second). Even slow 8088
computers can usually read in these characters using about 500 instructions or
so, which usually takes less than 1 millisecond. This would seem to leave
some time for other programs to get some processing done, and it does. But
remember that each program gets to process itself for some time, and then
control is passed to another program. Thus quite a few characters (maybe 20
or so) will have been "buffered" or stored before the communications program
gets its turn to do something other than just read the data. At higher
communications speeds (such as 4800 or 9600), the amount of time to process
the characters remains the same, but the rate at which they arrive is faster.
Thus the "bufffer" needs to be 2 or 4 times larger in order to accomodate the
larger number of arriving characters. Most communication programs have pretty
good size buffers, and many allow you to increase the size to prevent buffer
overflow.
From these calculations, it would seem that even an 8088 could handle 9600
bits per second communications with characters arriving about every 1
millisecond and about a half millisecond to process it. But that only leaves
about a half millisecond to do something else (such as display the information
on the screen). The solution to to use a faster computer when using faster
communications speeds. You should figure that you want to split the time for
communications programs and other programs evenly, and you should take less
than half the available time processing characters. So, assuming it takes
about 500 instructions to handle each character, you need to find out how long
it takes to process that many instructions for your computer. A 4.77 MHZ 8088
takes about 1 millisecond. An 8MHz 80286 takes about a half millisecond, and
a 16MHz 80386 takes about one fourth millisecond. Leaving time for other
fucntions essentially means that you can multitask 2400 on an 8088, 9600 on an
80286, and higher on an 803836 and still leave time for other programs to get
some usefull work done.
If you run more than one communications program, then you should allow even
more time, since there has to be some extra processing to move between
and Bulletin Board Systems (BBS) are one of the most popular reasons for using
a multitasking environment. It is well known that several computers can
"talk" to each other. It might be getting information from a mainframe
database. Perhaps sending electronic letters is more cost effective than
using a messenger service. Or maybe you would like to download the latest
"freeware" program and yet get some other, more important work, done at the
same time. Sometimes you have to redial a BBS dozens of times before it's
available. With a multitasking program you can keep dialing while you do
something else. Having instant access to communications programs and allowing
them to operate in the background while performing other tasks is one instance
of where multitasking programs prove very worthwhile.
This chapter will describe the important features of communications programs
as they regard multitasking, special considerations for multitasking, and
how to find and avoid problems with background communication.
While there are several popular multitasking environments available for IBM
PC and compatible computers, one of the most popular is DESQview. DESQview
is designed to allow multiple off-the-shelf programs to be able to run at
the same time. These programs can be of any type. Depending on the amount
of memory and the type of program you have, it is possible to run programs
in either 640K or beyond with DESQview. While the information in this
chapter will concentrate on suggestions for DESQview, most of the data is
appropriate to other multitasking environments as well.
The Basics of Communications
The two most important concepts to understand for communications are ports
and interrupt request lines or IRQ.
Communication Ports
The communication port is the place where the actual data is read or written.
When a value is to be sent to the serial line, whether it is to a modem or a
direct connection, the data is placed into a communication port. The device
attached to the port, usually an Universal Asynchronous Receiver Transmitter
or UART (pronunced "YOU"-"ART"), converts the data from its current form of 8
bits, into a serial stream; each bit "follows" the others as though they were
going through a pipe. The data in the computer is usually stored in groups
called bytes, which consist of 8 individual bits. A communications line, also
called a serial line, only has one wire over which the data can be sent. A
second line is used to receive. The UART takes the byte of data to send and
"flattens" it, sending one bit at a time. Another UART on the other side
"collects" the individual bits and then presents them as a byte to the
receiver. This kind of operation can only really service one program at a
time, so in a multitasking environment you must have one communication port
(UART location) for each program which needs to communicate.
The standard UARTs can only send and receive one byte at a time. If the
receiving UART has a byte ready and the computer does not read it before
another byte of data arrives, then the data has "overrun" and is lost. It is
very important in a multitasking environment to make sure that the
communications lines are handled as quickly as possible to avoid overrun.
There do exist UARTs which can "buffer" more than one byte, and thus "hold on"
to some data until the computer is ready to receive it. One of these is the
16550A, which can buffer up to eight bytes before overrun occurs. Converting
to a 16550A and software which understands it can be very useful when using
high speed communications while multitasking.
There are several ways to decide which port to use, but most communications
programs allow you to configure the one you want. The most frequently used
ones are COM1 and COM2. The usual port values for these are 3F8 and 2F8. The
location for determining the exact port value is at 40:0 and 40:2, in memory
locations known as the BIOS data area. A communication program normally looks
into this area to find out if a communication port exists, and if so, what the
port value to use is. It is possible to have more ports, but IBM hasn't set a
standard way for finding more ports so each hardware vendor has made up a
method for extending the number of ports. Only COM1 and COM2 can be sure to
work under all circumstances.
The method of looking at 40:0 and 40:2 to find the ports is not universal
though. Some programmers assume that the port values are going to exist with
the particular numbers 3F8 and 2F8. They are probably right 98% of the time,
but it is very confusing if you happen to have your computer set up
differently and a program doesn't work right. I once saw a program which not
only assumed the port values, it also assumed that you wouldn't know how to
set them up, so it always took any data from either port. You couldn't use a
mouse with it because the mouse driver program would have its data stolen! It
also wouldn't allow a second communications program to be multitasked with it
either. Most of the popular programs are quite well behaved, and this is
important for multitasking environments, since several programs and/or devices
will need to coexist in the same computer at one time.
Interrupt Request Lines
An interrupt request line, or IRQ, is a way for a device, such as the
communications port (using an UART), to interrupt whatever the computer is
doing for a moment in order to handle something important; such as a character
which just came in on the serial line. These interrupts are prioritized so
that the most important ones are handled first and can interrupt less
important ones. Thus, if a disk drive has just interrupted the computer and
then a serial line has some data ready, the serial line can "interrupt the
interrupt". The disk, after all, can wait. The serial line has to avoid
overrun. A list of the standard IRQ values and their function is listed in
table 1. DESQview modifies this list (when "Optimize communications" is "Y")
so that communications ports can interrupt everything else and be handled as
quickly as possible; you probably can't type as fast as another computer can
send you data.
The normal IRQs used for communications are IRQ4 (COM1) and IRQ3 (COM2). Yes
this seems backwards. My guess is that, when the IBM PC was being designed,
only one communication line was envisioned. Some time later, after having too
many programs already written using COM1 to change it, they decided to add
another. But the only unused IRQs were numbers 2 & 3. IBM then chose IRQ3
for COM2. Normally most of us wouldn't care about this except that the lower
the IRQ number, the higher its priority. Thus while it seems anti-intuitive,
COM2 actually has a higher priority than COM1. Thus, if you have two
communications programs running, the higher speed one should be on COM2. Or,
if you have a serial mouse in addition to your modem, the modem should be on
COM2 since you can tolerate having the mouse a little "jumpy" in order to not
lose any incoming data.
For IBM's COM3 and COM4 they re-used IRQ 4 and IRQ 3. How? By using a
different port address and having a special indicator value which tells the
interrupt service routine whether the data is for COM1 or COM3 for instance.
But only specially configured programs know how to do this, and there is no
way for a multitasker such as DESQview to know which program is supposed to
get the data for a particular IRQ. If each communications line uses a
different IRQ (say IRQ5 or IRQ2), then there is no ambiguity about which
program gets which data. In addition, there are special drivers written, the
most popular is FOSSIL, which can perform the proper arbritration needed to
handle multiple serial requests. These usually require special communications
hardware adapters.
All of the better communications programs use interrupt processing to handle
receiving of data; it's the most efficient method. It's also best for
multitasking. A program may be busy doing some calculation when a character
has been received by the UART. The UART asserts the proper IRQ and the
current program is interrupted (that's why they're called interrupts) and the
program is put "on hold" for the moment. The communication program has set up
a special routine to handle the interrupt, which usually reads the data from
the port and then stores it someplace to be handled later. The interrupted
program is then resumed. At some later time, the communication program gets
control and takes charge of the stored data. Perhaps it is displayed on the
screen or stored in a file. Often several characters have been received and
"buffered" before the "main" program can handle them. This usually happens so
fast that you don't see anything unusual.
There are some programs which don't use interrupts. They will "loop" or
"poll" the port waiting for the UART to signal that the data is ready and then
process it. This is very wasteful of computer time, since the computer could
be doing many other things while waiting for the next piece of data. These
programs are also especially bad for multitasking programs. First, it wastes
time which could be used by other programs. Second, since a mulitasker must
give a little bit of time to each program, the communications program is not
always in control, and if some data arrives and the communications program is
not active, the data will be lost.
In summary, the important aspects for multitasking are:
a) a serial port can be used by only one program at a time
b) received data must be read as quickly as possible to avoid overrun
c) the number of serial ports is limited
d) the BIOS data area should be used to determine port numbers
e) communications interrupts are prioritized
f) most programs receive their serial input using interrupts
Special Considerations for Multitasking
Most programs, while unaware that multitasking may take place, are
reasonably well behaved. This allows a program like DESQview to run
programs unmodified. There are several things which you must take into
account:
Writing to the Video Display
In order to work as fast as possible, many programs write directly to the
video display memory. This provides the fastest possible video response.
It is also very bad for a multitasking environment. If a program is going
to write directly to the video display while in the background, it will
"bleed through" on top of another program or programs. This is probably
undesirable for most people. What needs to be done is to either have a
program "behave" and use the DOS or BIOS calls provided to write to the
display, or to use a special interface which allows programs to continue to
think that they are writing directly to the video display, while actually
accessing another location which is then updated without interfering with
the other programs. This can be done either by configuring the program to
"behave" or by the program detecting that it is in an environment and
converting itself to behave.
DESQview has a very efficient method for allowing programs to "think" that
they are writing to the video display while actually using an alternate (or
"shadow") area. This method can automatically be invoked by a program in
DESQview, and many of the most popular programs use it, including Crosstalk
XVI and Mark IV, Procomm, ProYAM, PIBTerm, BitCOM, and PC-Talk. On an 80386,
DESQview 386 can even make "misbehaved" programs stay away from the video
screen using special features available on the 80386.
Keeping the Program in Memory
Most multitasking environments allow the programs running in them to be
"swapped" out of memory. This allows you to suspend a program and then resume
it where you were at a later time. Usually programs are swapped to the disk,
but it could also be to a RAM disk, network drive, or expanded memory. Since
the serial ports can interrupt whatever is happening at any time, it is
essential that the program NEVER leave memory while communications are in
progress. Thus a communications program must NOT be allowed to "swap". Most
multitasking programs, including DESQview, allow these programs to be set up
so that swapping will not happen.
The problem is that forcing a program to be "non-swappable" can fragment
memory. If you want to start a new program, and a non-swappable
communications program is in the way of the memory you need, then you won't be
able to run the new program until you close the communications program. This
defeats the purpose of multitasking. DESQview allows communications programs
which are not currently active (perhaps running but not connected to another
computer at the moment), to be swapped. When this happens, DESQview will
"disconnect" the interrupt value from the program. Then, if a character
happens to come in (maybe the phone rings), it will be ignored since the
special interrupt routine is no longer in memory. DESQview will "reconnect"
the interrupt location when the program is swapped back in later. You can
usually avoid memory fragmentation by running the communications programs
first which then leaves the rest of memory contiguous. If you have expanded
memory, or an 80386, then it's possible to have the program run in expanded
memory and not have to worry about memory fragmentation.
Multiple communications programs
There is no real reason NOT to have more than one communication program
available at a time (if your wallet can afford it). There are several
technical considerations though.
For instance, no two programs can use the same port at the same time. The
communications ports are like your water faucet; you can make it go as fast
as you want but only one glass at a time can fit under it. There are programs
which know how to put special information in the data stream to tell the
receiving end which program the data is for, but these programs normally
handle special purpose applications. This allows a single serial line to
appear to be handling multiple sessions. It works by embedding some special
information into the data to say "this is for program A", and then only that
program takes the data. Very few services use this feature.
In most cases, you can use a maximum of 2 communications programs at one time,
since IBM only officially recognizes COM1 and COM2 each on its own IRQ. As
mentioned before, COM3 and COM4 don't usually have their own IRQ values so
they can't be used. If an add-in board DOES have separate IRQ for each
communications port, then it is possible to have more than two programs
communicating at one time.
Communication Speed
The computer itself can only perform one function at a time. A multitasking
program such as DESQview divides the computers attention between several
different programs for short periods of time. Since the computer is so fast,
each of these programs appear to be running at the same time, but obviously
they are not. Thus, when multitasking, each program is running slower than it
normally would. This is usually not a major problem, since most programs
spend most of their time waiting for input and then process for some time and
go back to waiting. But a communications program must be ready to take its
data when it arrives. As mentioned before, interrupts are used to get the
computer's attention when the data is ready. But if the data is coming in too
fast, then the interrupt routine cannot process the information before the
next byte arrives.
For various reasons, there are some standard rates at which computers
communicate. Usually 110, 300, 600, 1200, 2400, 4800, and 9600 bits
per second. Since there are a few bits of control information being sent,
these numbers translate into about 10, 30, 60, 120, 240, 480, and 960
characters per second. Even faster speeds are being used in some special
applications. At the slower speeds, the computer has plenty of time to digest
the incoming data and be ready for more. In the time not used to process
serial data, there's time to do other work such as word processing,
spreadsheets or compiling.
When communicating at 240 characters per second, the characters arrive about
once every 4 milliseconds (every 4 thousandths of a second). Even slow 8088
computers can usually read in these characters using about 500 instructions or
so, which usually takes less than 1 millisecond. This would seem to leave
some time for other programs to get some processing done, and it does. But
remember that each program gets to process itself for some time, and then
control is passed to another program. Thus quite a few characters (maybe 20
or so) will have been "buffered" or stored before the communications program
gets its turn to do something other than just read the data. At higher
communications speeds (such as 4800 or 9600), the amount of time to process
the characters remains the same, but the rate at which they arrive is faster.
Thus the "bufffer" needs to be 2 or 4 times larger in order to accomodate the
larger number of arriving characters. Most communication programs have pretty
good size buffers, and many allow you to increase the size to prevent buffer
overflow.
From these calculations, it would seem that even an 8088 could handle 9600
bits per second communications with characters arriving about every 1
millisecond and about a half millisecond to process it. But that only leaves
about a half millisecond to do something else (such as display the information
on the screen). The solution to to use a faster computer when using faster
communications speeds. You should figure that you want to split the time for
communications programs and other programs evenly, and you should take less
than half the available time processing characters. So, assuming it takes
about 500 instructions to handle each character, you need to find out how long
it takes to process that many instructions for your computer. A 4.77 MHZ 8088
takes about 1 millisecond. An 8MHz 80286 takes about a half millisecond, and
a 16MHz 80386 takes about one fourth millisecond. Leaving time for other
fucntions essentially means that you can multitask 2400 on an 8088, 9600 on an
80286, and higher on an 803836 and still leave time for other programs to get
some usefull work done.
If you run more than one communications program, then you should allow even
more time, since there has to be some extra processing to move between
December 12, 2017
Add comments