Hi Dan,
Thanks for the reply, lets continue: You wrote,
DB>First off, I started out with a 2,400bps no-name modem without
DB>compression and error correction.  A modem with a DTE rate of 2,400bps
DB>is commonly referred to as a "2400 baud" modem but it is actually
DB>running at 600 baud since, with modern modems, each symbol encodes
DB>multiple bits - in this case 4 bits/baud).
You lost me here.  I thought 2400 baud was the same as 2400 bits per
sec.?  I also thought that we were dealing with characters that were
defined by an 8 bit byte?  I can see the 600 baud X 4 bits/baud = 2400
bps.  I guess you lost me on the definition of what a symbol is and that
it encodes multiple bits?
 The best transfer speed I
DB>could get out of this was about 232cps under Zmodem. This certainly
DB>whetted my appetite but by today's standards it's a piece of junk.
Sounds about right! Thats what I have and I get the 232cps too!
DB>Next I bought a Maestro v32bis modem. This is an Australian-made
modem, DB>but since the Australian market is relatively small, it's a
DB>straightforward Rockwell v32bis chipset clone. Most of these clones
have DB>the same basic command set, sometimes with a few of the
manufacturer's DB>command extensions.
Is the Rockwell chipset that you refer to here, a ROM or EPROM that is
used to configure the modem or contains a program that runs a CPU  the
modem to accomplish the compression and error correction of the data
stream? Explain a little more about what it is used for and can they be
up graded like BIOS?
The important thing here is that high-speed modems
DB>have v42bis data-compression and v42 error-correction. (Successful
DB>transmission of modem-compressed (on-the-fly) data requires that EC
be DB>operational.) The max transfer rate of an already compressed (e.g.
 zip) DB>file is about 1640-1660cps using Zmodem.  BBS listing and menu
 screens DB>will compress on-the-fly somewhat so the screen display will
 be more DB>snappy with compression turned on than with it turned off
 i.e. the DB>effective cps rate for this type of data will be higher
 than DB>1640-1660cps. To achieve this good performance you need to:
DB>1) Lock the comms program's com port access speed (DTE) at 2-4 times
DB>higher than the DCE speed (v32 DCE is 14,400bps). "Locking" means that
DB>the DTE speed is fixed i.e. not "Autobauding" (free to match the DCE
DB>rate). When did they first start doing this? How is it designated so
you know what model of modem it will work on?  For example can i do this
on my current 2400 baud modem?
Dan the communication program you are referring to here is a program
like "Pro Comm or Telix" right?  I was not aware that you could do that.
What are you doing here?  Does the setting that you make in the setup of
the com program then control the speed of the I/O data stream being sent
or received from the CPU/memory to the input/output register of the
modem for internal or parallel port I/O for an External?
Is it true that all machines 286AT, 386, 486 and Pentiums all have I/Os
operating at 8 to 10 MH even thought the processors can operate at
100mherz or above internal and with memory?  This is to keep a common
exchange rate for all the external hardware on the market right?
Since I am currently operating a 286AT @ 8 MH and a 386DX @ 33 MH I
should be able to operate any of the new or old modems with both
machines right?  I ask this because I oftem see ads for something like a
Internal 28.8 KPS Data/Fax Modem that has V.34 including fax/data
software and requireing a minimum system of : 486dx/33 processor, open
8-hint ISA slot, Windows 3.1 (MS DOS 6.2) and 4 MB of ram, 5 MB H Dsk
space. Am I correct in saying that the reason they specify the 486/33
and 4MB of ram plus 33 MHZ speed is to be able to run the software
that they provide?   In other words they need these requirements to
run under Windows with out slowing the system down so much that it can't
handle the modem traffic and the program overhead?  If I were to just
run the modem with dos 6.2 and the com program Telix on the 286 it would
still work fine right?
DB>2) Tell the comms program to use hardware flow control. Most
highspeed DB>modems default to using hardware flow control (aka RTS/CTS
flow DB>control). This does not put extra control characters in the DTE
link DB>(comms program-modem) to stop modem datastream overflows.
Instead it DB>makes use of the extra wires in the modem's connecting
cable (hence DB>the term "hardware"). This is available in the majority
of situations. DB>Using hardware FC means that no space in the DTE
datastream is DB>wasted on flow control so potentially you get a better
throughput.
Can you use Hardware FC with any modem and does it usually improve the
BPS/CPS?
DB>3) If you are running straight DOS then you can probably use up
to a DB>57,600bps or higher DTE rate. If you are multitasking (e.g. OS/2
or DB>Windows) then the OS overhead means that the comms prog may not be
able DB>to get each byte from the UART (the chip in the computer that
converts DB>between the serial data stream use by the modem and the
parallel data DB>stream used by the computer's data bus) in time before
the next byte arrives DB>from the remote modem. This will cause a data
overrun as well. To DB>prevent this, the comms port your modem is
attached to needs to be DB>equipped with a 16550A (or better) UART.
Modern Pentium-class machines DB>come with this as standard; on my
486DX-50 clone I had to buy this chip. DB>Again this may not be
necessary if you run straight DOS (i.e. not using DB>DESQview).
I've seen the term DESQVIEW before.  Please define what kind of program
it is?
DB>An internal high-speed modem will probably either have a 16550A UART
DB>built-in or emulate the behaviour of it. However I much prefer external
DB>modems. With an external modem if you get a bad connect you can reset
DB>a stuck modem by turning the modem off and then on again. With a stuck
DB>internal modem you usually have to restart the computer, and if you
DB>have lots of programs open at once, this is a major hassle.
Good point I have experienced this and even though i don't usually have
more than one program running, it really makes you mad to have to go
back and reboot back to where you were and reestablish you link with a
BBS etc.
 DB>The presence of v.42 error-correction means that the transfer of
DB>screen data as well as file data will be error-corrected (through the
DB>retransmission of faulty data). With an non-error-correcting modem
DB>link you can still transfer files but you have to rely on the file
DB>transfer protocol (e.g. Zmodem) to detect and resend affected data
DB>packets. There are two operational differences between the old non-EC
DB>modems and modern-EC modems: The DCE link (modem-modem) operates
DB>synchronously (no precious bandwidth is wasted on the transmission of
DB>start and stop bits around every character - this means a 14,400bps
DCE DB>rate can transfer date at a rate of 1,600cps+ rather than at a
little DB>less than 1,440cps with an async DCE link; While the modems
are still DB>operating in synchronous EC mode you should never see any
phone-line DB>noise junk on the screen.
When you are speaking of Synchronous above, you mean that in relation to
the hardware flow control right?  It has been a long time since i
studied Synchronous vs Asynchronous.  But I seem to remember that No one
used sysnchronous because it was to slow because you had to sync clocks
between the transmitting and receiving systems? Is that right?  Need a
little more info here please.
DB>Cheers, Dan Bridges, Brisbug PCUG.
Where are you at Dan?  Where is Brisbug PCUG?
>>> Continued to next message
 * OLX 2.1 TD * I'M DOING BETTER, I'VE ONLY MALFUNCTIONED ONCE TODAY!
--- Maximus/2 3.01
---------------