RO>You lost me here.  I thought 2400 baud was the same as 2400 bits per
RO>sec.?  I also thought that we were dealing with characters that were
RO>defined by an 8 bit byte?  I can see the 600 baud X 4 bits/baud = 2400
RO>bps.  I guess you lost me on the definition of what a symbol is and that
RO>it encodes multiple bits?
Unless you are heavily into communications engineering (I'm not)
it probably impossible to fully understand the workings of modern
modems. As far as I can understand it, baud rate corresponds
fairly well with bandwidth. On a voice-quality line this will be
around 3,000-3,500 Hz in width. Only by encoding multiple bits
into each symbol (think of a symbol as being a baud wide) can
enough information be carried down a narrow bandwidth channel.
And when you consider that this is a duplex connection (you/the
modem can both talk/send and listen/receive at the same time)
then it becomes an even more amazing technical feat.
RO>Is the Rockwell chipset that you refer to here, a ROM or EPROM that is
RO>used to configure the modem or contains a program that runs a CPU  the
RO>modem to accomplish the compression and error correction of the data
RO>stream? Explain a little more about what it is used for and can they be
RO>up graded like BIOS?
As I understand it the simplified modem consists of a
modulation/demodulation section, a data pump section and a
set of programs to handle all the actions.  In total this 1 or 2 chipset
group is supplied by Rockwell. The programs (or rather routines)
are also supplied by Rockwell and the individual modem
manufacturers either put this unaltered into ROM or add a few
tweaks to differientate themselves from the mob or to match the
command set of earlier models in their line.
You can sometimes get improvements to this set of "programs" by
getting either a new ROM chip off the manufacturer (more likely,
you will have to send the modem back to be updated). However with
Flash RAM on the Courier v.Everything modem it becomes very
simple: you download a DOS program and run it and it clears the
old program out of the Flash RAM and then places the new one
there. Takes about a minute.
RO>When did they first start doing this [locking the port]? How
RO>is it designated so you know what model of modem it will
RO>DB>work on?
Since I've have to work on many different clients' sites with old
modems I've discovered an easy way to test this. This example
uses a 2400bps modem. Set the comms prog's baud rate to 2400 and
confirm that it works and you can see your typing (you may need
to type ATE1 first to see your own typing). Set the comms package
to 4800, save the change and exit. Switch the modem off and then
on. Go back into the comms prog. If the modem is still working
and you can see your typing then the modem probably has EC and
compressing capabilities (although these may currently be
disabled). If the modem appears to lock up and you don't see your
own typing even after ATE1 is issued then the modem is a straight
(no-EC, non-compressing) 2400bps modem. If it supports EC and
compression set the DTE rate to 9600 or 19200 and select the
comms prog option that "locks the port" ie. don't let the UART
change the DTE rate depending on the DCE (modem-modem) connection
rate.
RO>Dan the communication program you are referring to here is a program
RO>like "Pro Comm or Telix" right?  I was not aware that you could do that.
RO>What are you doing here?  Does the setting that you make in the setup of
RO>the com program then control the speed of the I/O data stream being sent
RO>or received from the CPU/memory to the input/output register of the
RO>modem for internal or parallel port I/O for an External?
Yes. As I understand it the comms program sets the rate that the
UART sends and expects data on the computer bus side. By locking
this side of the UART you can maintaining a much higher DTE rate
than the DCE rate and so allow headroom for EC and compression.
RO>Internal 28.8 KPS Data/Fax Modem that has V.34 including fax/data
RO>software and requireing a minimum system of : 486dx/33 processor, open
RO>8-hint ISA slot, Windows 3.1 (MS DOS 6.2) and 4 MB of ram, 5 MB H Dsk
RO>space. Am I correct in saying that the reason they specify the 486/33
RO>and 4MB of ram plus 33 MHZ speed is to be able to run the software
RO>that they provide?   In other words they need these requirements to
RO>run under Windows with out slowing the system down so much that it can't
RO>handle the modem traffic and the program overhead?  If I were to just
RO>run the modem with dos 6.2 and the com program Telix on the 286 it would
RO>still work fine right?
Yep that level of equipment is only required for the software.
Using a comms package like Telix or Telemate on an 8Mz 1MB AT
with a 16550A uart under straight DOS you should be able to run a
v34 modem with a DTE (comms prog-modem) rate of 115,200bps or
115,200 baud (on the DTE link there is no need for more that 1 bit/baud).
RO>Can you use Hardware FC with any modem and does it usually improve the
RO>BPS/CPS?
As I understand it, Hardware FC is best used for a direct
connection between the computer and the modem (ie. not accessing
the modem over a network). With a DTE of 9600 baud or less I don't
think you see much difference but it improves the throughput at
higher rates.
RO>I've seen the term DESQVIEW before.  Please define what kind of program
RO>it is?
DESQview is a program that you can use to mulitask under DOS. You
can have multiple sessions running at the same time and switch
between them with hot keys. The difference between this and
task-switchers, such as the clunky DOSSHELL that used to come
with DOS 5, is that the background task (say receiving a file in
a comms session) can continue operating while you are doing
something else in the foreground. While it was good at the time,
in my opinion, the quality of multitasking you can get of a
operating system like OS/2 leave DESQview with DOS for dead.
(Although for a lark I once ran multiple DOS programs under
DESQview in a DOS session under OS/2 while running other DOS,
WIN-OS2 and OS/2 programs under separate sessions on my OS/2
machine.
RO>When you are speaking of Synchronous above, you mean that in relation to
RO>the hardware flow control right?  It has been a long time since i
RO>studied Synchronous vs Asynchronous.  But I seem to remember that No one
RO>used sysnchronous because it was to slow because you had to sync clocks
RO>between the transmitting and receiving systems? Is that right?  Need a
RO>little more info here please.
As I understand it, the DCE (modem-modem) link is operating
synchronously with the constant data stream (with nulls be sent
when there is nothing else to send) providing a self-clocking
means of keeping the two modems synchronised. Can't see why this
should be slower than async; in fact the lack of start/stop bit
surrounding every char gives sync a theoretical 125% improvement
over an async link runing at the same DCE rate.
RO>Where are you at Dan?  Where is Brisbug PCUG?
Brisbane, capital city of the state of Queensland, Australia.
>>> Continued to next message
___
 X SLMR 2.1a X 
--- Maximus/2 3.01
---------------