Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!usc!samsung!uakari.primate.wisc.edu!sdd.hp.com!apollo!nelson_p
From: nelson_p@apollo.HP.COM (Peter Nelson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why use MS-window ?
Message-ID: <4abdd913.20b6d@apollo.HP.COM>
Date: 1 Jun 90 14:17:00 GMT
Sender: root@apollo.HP.COM
Distribution: usa
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 82


                                                        

 



 I got lots of interesting answers to my question of how DOS
 multitaskers handle communications programs running in the
 background.  



From: shim@zip.eecs.umich.edu (Sam Shim)

>Multitasking programs can download in the background without losing characters
>because the UART chip has a buffer (the size depends on the chip).  Just give
>the comm program enough time and it will be able to fetch the data off the
>buffer before it overflows.

  I'm skeptical because too many UART chips (f'rinstance the venerable
  but popular Intel 8251) don't have very big buffers.  The 8251 holds
  *1* character, many others hold *4* characters.  But at 4800 baud
  in two ticks of the Desqview clock (the minimum they recommend 
  using) you can receive 26 characters.  Yet Desqview claims that they
  can successfully run *multiple* comms programs in the background
  at 9600 baud!

  Of course it's possible the hardware has improved a lot recently
  and the UARTs currently in use have deep buffers.  Does anyone 
  know what some typical UARTS for PC's are and how deep their 
  buffers are?     Also what about chipsets used to implement MNP
  on modern modem boards?  Since they do data-compression they *have*
  to do some considerable buffering.  Anybody know anything about these?


From: altman@sbstaff2.cs.sunysb.edu (Jeff Altman)

>One way to allow communication packages to run in background
>to perform file transfers is to not actually let the applications
>receive the interrupts from the UART.  What you do is capture 
>the interrupts and then when the Comm Package is given its chance
>to use the CPU re-echo the interrupts to the Comm Package, thereby 
>making it think that it is actually receiving the characters when 
>they were received.  

  I didn't get this at all.  What IS handling the characters before
  the Comm package gets it's chance?   They have to get processed and
  buffered *somewhere*.  
                                     


...And from my mailbag (anonymous) simply sez...

> Hardware interrupt.

  Yeah, but if the comms program is not mapped in to the virtual
  8086 machine's address space because someone else is the "current"
  owner of the machine, then how does the multitasker assure that
  the comms program gets to handle the interrupt?   Does it remap 
  memory every tine an interrupt comes in on that port?


-------------------------------------------------------------------------

  This is like the old "how many different ways can you use a 
  barometer to measure the height of a building?"  Sure, there
  are lots of ways you *could* do it.  But I'm not giving points
  for creativity.  Does anyone out there know how it REALLY 
  works?   Is there a better newsgroup for this question?

  This question does have practical significance because if
  indeed there is a hardware approach (UART-buffering) then
  if you are having problems with background comms programs 
  you could consider using a different UART or modem chip
  set that has a deeper FIFO which, given the relatively low
  cost of moidems and serial ports these days, might be a    
  reasonable choice.   On the other hand, if it's done "in
  software", this would be a waste of money.

                                                   ---Peter