Surely there are faster ways to transfer files between PCs. Why not use an ethernet card? That would be quite a bit faster. If you don't have that, the parallel port is much faster as well, IIRC something like 4Mbit/s.

I've transferred files at 19.2K over null modem but I haven't done it for a while and not on PC. LapLink is supposed to be parallel not serial. Are you sure you're using a LapLink cable and not another null modem?

Hmm I've always used laplink 5 and a null modem cable however the baud rate is usually a lot higher and its reasonably quick.

I didn't want to have to install a network card.

sliderider wrote:

I've transferred files at 19.2K over null modem but I haven't done it for a while and not on PC. LapLink is supposed to be parallel not serial. Are you sure you're using a LapLink cable and not another null modem?

I also used to transfer files with 19,2k over a serial cable. But the last time I did so was about 15 years ago. I remember setting baud rate within windows though.

The baud rate should be set by whatever software you're using.

If not, try this at the DOS prompt:

mode com1:115200,n,8,1

you know your dos SquallStrife.

Maximum dos is allowing is 19200. Every other settings is saying Invalid Parameter. That's much faster than 1200 or 2400 for laplink. So Im happy with that.

But when I load ctmouse 1.8 it drops the baud rate to 1200 on com1 where the mouse is. Is this normal?

Serial mice work at 1200 bps so it is correct.

MSD reports what the current setting on the chip is, not the maximum.

I am pretty confident that LapLink has some configuration setting what baud rate it should try to use, or to autodetect. You should be able to get 115200 bps. However if run MSD, it detects the serial port type as you can see. It is 16550A. I recall MSD accidentally leaves the 16550A FIFO enabled with largish timeout, so running MSD after mouse driver has loaded leads into laggy mouse cursor. If LapLink does not understand about 16550A UART and its FIFO, it is possible that LapLink also slows down because of enabled FIFO and timeout, even if LapLink uses 115200 baud rate. After cold booting the PC, do not run MSD before LapLink.

There should be no requirement for setting baud rate manually with dos MODE command.

But otherwise the parallel port allows for faster transfers. Not 4Mbit/sec though. I think I have maxed out at about 40-50 kbytes/sec with FastLynx and 4-bit parallel cable. There are also different cables that can transfer more bits at a time.

The baud rate you can achieve depends on the quality and length of the null modem cable and its configuration. FastLynx can work with 3-pin cable that only connects RXD, TXD and ground, but it can work faster when the four handshake pins are connected as well. I do not know if LapLink implements such thing.

If you transfer between a modern PC that has no real serial ports and you have to use an USB serial port, it can also be the source of sluggish transfer.

You can also use modem terminal software like Telix or Telemate or whatever to transfer files with protocols such as ZMODEM. I use this to transfer files from a Linux PC to DOS PC.

As Jepal said, MSD reports the "default" parameters, not the parameters used by programs.

Also, keep in mind that type of serial cable can slow down the transfer: 3 wire cable needs "software" handshake (XON/XOFF) and that requires sending an XON character before data and an XOFF character after that... so you'll need to transfer more data.

To solve it, you'll need a 3-wire "enhaced" cable (usually works OK, but may be unreliable in some cases) or a 7-wire cable. Those cables will support "hardware" handshake and may perform better. The quick fix (3-wire "enhaced") would be making a short between DTR-DSR-DCD and another short between RTS-CTS on both sides of the cable. That would allow you to use "hardware" handshake and the computer would think that signals are always OK (but it won't know if any side can't receive data for any reason).

In any case, serial connections are slooooooooow. A parallel data would be a better choice, but I'd use serial or parallel only if I couldn't use a network connection.

Yeah I don't use the old null modem cable often just when I need to copy over a small amount of data..

Ah ..so It might be my cable that's slowing me down? I don't recall it being as slow as it is now so maybe my configuration was different prior.

Parallel cable for xfer was common? I looked in my box of cables and couldn't find one. Does Laplink support parallel cable transfers?

I know this is a 12-year-old post, but I think it's a good place to ask my question.
I built a null modem (parallel) cable that allowed me to copy files to my Dell Latitude LM, whose floppy drive isn't working, but I was only able to do so at a transfer rate of 46 kilobytes/second. The literature I found says that the transfer rate in ECP and EPP modes, depending on the version, should allow transfer rates of up to 2 megabytes/second.
Could someone please clarify this for me?

vico wrote on Today, 01:52:

I know this is a 12-year-old post, but I think it's a good place to ask my question.
I built a null modem (parallel) cable that allowed me to copy files to my Dell Latitude LM, whose floppy drive isn't working, but I was only able to do so at a transfer rate of 46 kilobytes/second. The literature I found says that the transfer rate in ECP and EPP modes, depending on the version, should allow transfer rates of up to 2 megabytes/second.
Could someone please clarify this for me?

That's about the right transfer speed. It's still much faster than any standard PC serial port can go.

Just as you can't connect the USB ports of two computers together with a passive cable, parallel ports were not designed for it either. Your "null-printer" cable gets around it by wiring five outputs on one end to five status lines on the other end. Then, each computer uses "bit banging" rapidly send nibbles (4 bits) to the other end as fast as the CPU can go. The fifth bit is used as a clock.

The suppliers of the Direct Cable Connection cable in Win9x did manufacture and supply a "smart" cable with a chip in the middle to do ECP/EPP speed transfers between two PCs. However, I've never seen one or even one for sale.
I don't have the electronics background to design one, but a newly made circuit board to do that (as well as other things like parallel ethernet or parallel disk) could be interesting projects for a designer.

jakethompson1 wrote on Today, 02:06:

That's about the right transfer speed. It's still much faster than any standard PC serial port can go. […]
Show full quote

vico wrote on Today, 01:52:

I know this is a 12-year-old post, but I think it's a good place to ask my question.
I built a null modem (parallel) cable that allowed me to copy files to my Dell Latitude LM, whose floppy drive isn't working, but I was only able to do so at a transfer rate of 46 kilobytes/second. The literature I found says that the transfer rate in ECP and EPP modes, depending on the version, should allow transfer rates of up to 2 megabytes/second.
Could someone please clarify this for me?

That's about the right transfer speed. It's still much faster than any standard PC serial port can go.

Just as you can't connect the USB ports of two computers together with a passive cable, parallel ports were not designed for it either. Your "null-printer" cable gets around it by wiring five outputs on one end to five status lines on the other end. Then, each computer uses "bit banging" rapidly send nibbles (4 bits) to the other end as fast as the CPU can go. The fifth bit is used as a clock.

The suppliers of the Direct Cable Connection cable in Win9x did manufacture and supply a "smart" cable with a chip in the middle to do ECP/EPP speed transfers between two PCs. However, I've never seen one or even one for sale.
I don't have the electronics background to design one, but a newly made circuit board to do that (as well as other things like parallel ethernet or parallel disk) could be interesting projects for a designer.

I may actually have such a cable? I remember being in the same kind of situation vico was about a decade ago. I went to a local shop on a whim and purchased such a cable (side note: dude at the counter seeing a 15 year old rolling in asking for that cable probably had a neat little water cooler story later)

Used DCC between an XP machine and a Thinkpad with a Pentium 166. Was getting about 120 kb/s up to nearly 1.1 MB/s, it was kind of inconsistent, possibly due to the hard drive on the laptop. It’s a very thick cable though. I know I still have it.

It was called a DirectParallel FAST cable.

One of my earliest computing memories was when my dad bought his first PC and we took it over to his friends house to pirate some software. We were plodding along with a null modem cable and then another buddy of theirs showed up with a laplink cable (parallel nibble) and it blew the serial transfer speeds away

The term "Null Modem" is really only applicible to a serial connection.
Traditionall serial devices are called "DTE" (Date Terminal Equipment) -
Terminals, computers, printers etc. or "DCE" (Data Communication Equipment)
- Modems.

A DTE only talkes to a DCE - a "Null Modem" transitions the lines to be in
the right place for a DTE to talk to another DTE.

Max standard serial speed of a PC is 115,200 bits/second. With 1 start
bit, 8 data bits (byte) and 1 stop bit, /10 = max transfer speed of
11520 bytes/second (11.5k bytes) any transfer protocol will have some
overhead, so actual rate will be slightly less.

Parallel can transfer up to 8 bits at a time, and with specialized features
like ECP, EPP supporting interrupts and DMA may are theoretically able to
transfer much faster, but that's only to a device designed to receive the data
that way, and only in one direction. There are some kludges which can make
it mostly work two ways - usually requiring some "smarts" in the cable, and
limits the types of ports you can use.

Most vendors use a much simpler bidirectional cable that only transfers
4 bits at a time, requires no "smarts"and doesn't take advantage of
interrupts and DMA...

My own DDLINK transfer software can use: Serial, Parallel or Network
I did some tests a while back, transferring a 1mb (binary = 1048576 byte)
file:

Serial 115,200: 93 seconds = about 11.3k bytes/sec
Parallel LPT: 24 seconds = about 43.6k bytes/sec
10mbLAN: <2 seconds = >525k bytes/second

Your number sounds about right. LPT is still almost 4x faster than you
could do serial - If your machine has a network port and you can find a
"packet driver" for it (there are LOTs available) - you could go much
faster with that!

The 16550AFN UART can do DMA and up to 250000 Bit/s, according to a book mentioned at Wikipedia.

https://archive.org/details/interfacingibmpc0 … age/26/mode/1up
https://en.wikipedia.org/wiki/16550_UART#The_FIFO_buffer

Certain USB RS-232 dongles and RS-232 PCI cards can do speeds near the Mbit/s (16650 UART FiFo; 921,6 KBit/s or 115,2KByte/s).
Maybe not in plain DOS and 16550 emulation mode, but natively in Windows 98/XP.

The KeySpan USB dongles are programmable, for example and can do 230 KBit/s.
They have Windows and Mac drivers.
They're especially useful as an alternative to the internal Mac serial ports of Power PC Macs (on Mac OS 9.x),
to get some software to work which want to see a serial printer/modem port.

Edit: This PCIe RS-232 card can do 2 MBit/s, apparently:
https://gembird.nl/item.aspx?id=9916
The chipset is said to be a WCH382, which can do 50 Bits up to 16 MBit/s.

Edit: Found specs of the manufacturer.

Introduction Can be configured as dual-channel UARTs, single printer/ parallel port or dual-channel UARTs with a printer […]
Show full quote

Introduction
Can be configured as dual-channel UARTs, single printer/ parallel port or dual-channel UARTs with a printer/ parallel port.
Provide two-wire serial master interface, can hang serial EEPROM similar with 24C0X to store data which is not easily missing.
Supports that can be set for Vendor ID, Device ID, Class Code or other inforrmations of PCIe board in EEPROM
Driver supports Windows 98/Me/2000/XP/Vista/7/8/8.1/10/SERVER 2003/2008/2012/2016 and Linux.
3.3V voltage, mainly I/O interfaces support 5V. Supports low power sleep mode for serial port.
Chip function is equal to CH367 adds CH438, providing Quad UARTs, Octal UARTs or more UARTs application project.
Supports ExpressCard of PCMCIA notebook card.
Serial Port Interface
Two independent UARTs, compatible with 16C550, 16C552, 16C554 and 16C750 with enhanced.
Supports 5, 6, 7 or 8-bit Serial format and 1 or 2 stop bits.
Supports Odd, Even, None, space 0 and mark 1 parity, etc.
Programmable Baud Rate, supports 115200bps and up to 8Mbps baud rate.
Supports 256-bytes FIFO buffer, supports 4 FIFO trigger layers.
Supports MODEM signal CTS, DSR, RI, DCD, DTR, RTS, can be converted to RS232 level.
Supports CTS, RTS to realize auto handshake and auto transmit speed control, compatible with TL16C550C.
Supports serial frame error check, and Break circuit interval check.
Supports Full-duplex and Half-duplex communication.
Parallel port
Supports IEEE1284 parallel/ printer port modes such as SPP, Nibble, Byte, PS/2, EPP and ECP etc.
Supports bi-directional data transmission, the transfer speed can up to 1M Byte/S.

Source: https://www.wch-ic.com/products/CH382.html

Modern serial chips usually have 16550 compatibility but can also go beyond it.

Edited.

Jo22 wrote on Today, 08:45:

The 16550AFN UART can do DMA and up to 250000 Bit/s, according to a book mentioned at Wikipedia.
...

Absolutely, but you can't count on it being there, and modern "enhanced" chips can differ
enough that you get into an almost "Winblows world" of special cases and "drivers".
DOS is supposed to be simple, and original 8250 compatibility is almost always there
- so I tend to be fairly conservative it what my code "talks to".
(and 115,200 is plenty fast for most of my serial use cases, even the odd
time where I had to move a file - If you've ever experienced downloading a file
over a 300BPS modem you might better understand!)

And also be aware that unlike network etc. serial cables tend not to be designed
for super-high speed over long lengths. I can remember when long serial cable runs
through a factory had trouble maintaining data integrity at 9600.
(This has be even worse today as serial is less a thing, and cheap interfaces
don't follow EIA RS-232 specs)

The same is true BTW for parallel cables - in the early days of <5mhz non-cached
8-bit CPUs, you could pretty much check ready, write data and toggle strobe as fast
as you wanted - but as systems got faster, this became more problematic.

To keep "existing stuff" working, parallel access was actually "slowed down" in
hardware - still lots fast for a printer "of the day", but transferring megs of
bitmap to modern graphic printers got slow enough that the "enhanced" LPT
ports became a thing (and to maintain backward compatibility the code has to
know about it, enable it etc.)

(This is the main reason that traditional 4-bit double transfers over LPT caps out
at about 45k bytes/second effective transfer speed - and that speed can vary a fair
bit depending on the hardware in a system).

It's a bit disappointing that the parallel cable has such poor transfer capacity, but I appreciate all your clarifications. Unfortunately, my DELL Latitude LM doesn't have a network port, only a PCMCIA modem card.

vico wrote on Today, 17:20:

It's a bit disappointing that the parallel cable has such poor transfer capacity, but I appreciate all your clarifications. Unfortunately, my DELL Latitude LM doesn't have a network port, only a PCMCIA modem card.

Depends on what you need to transfer... I never try to use parallel transfer to directly access
drives/directories/files .. but it works well for moving files. I often ZIP up a whole directory and
then DDLINK it to/from another system over LPT - so you're not waiting on each file access,
just take a couple mins to move/backup your work! (way faster than serial transfer)

And .. there are PCMCIA network cards... Just make sure when you find one that you can get a
"packet driver" for it - I think I still have one that's NE2000 compatible, and it works well!