Supposedly Interlnk in DOS 6 is just a demo of Fastlynx, written by the same people.

Were the files you transferred compressible? That could account for some of the variation in transfer speeds. At 10 bits/byte (because of start and stop bit) the theoretical maximum of a 115200 serial interface is 11520 bytes per second. So a 1MB file should take 1:31. If it's faster than that, it's either compression, or they are doing some direct bit-banging on the UART rather than using it in the normal way.

edit: Kermit (C-Kermit or MS-Kermt for DOS or the revived Kermit 95 for Windows) would be nice to see, but it takes a lot of configuration since the default is the stop-and-wait 90 bytes per packet protocol which is why it's remembered as slow. It does not do parallel however.

Fastlynx does use stream compression for parallel port transfers.

It also has a "faster" transfer mode when used with its own special cable.
(the pinout is available in the help file. Image taken.)

Ok, I ran some tests ....

(Forgive if math is in error - working with screen displays and a calculator + plus I do have some vision problems)
-at least reported number are correct - captured into a LOG by my TIMEIT tool -

Test systems were PIII-500m and P4-1.4g
running DOS 5.0

Timing was done with my TIMEIT program which records the system 55ms "tick", then executes the command, reads "tick" again and calculate elapsed time.
- so yeah, timing accuracy is limited to 55ms -

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

I called the file to transfer "BIN" (so it would be first on my RamDisk) and used DDLINKs preset Key function to automatically enter 'C', 'Y', <ESC>
This basically transmits the first file that shows up in the directory to the other end.

First tests were done over COM at 115,200 with simple null-modem cable:

107-15-26 09:20p       10,240 R:\BIN
2> ddlink c=1 k=CY~E
3Elapsed 0:00:01.210
4
507-15-26 09:26p      102,400 R:\BIN
6> ddlink c=1 k=CY~E
7Elapsed 0:00:09.405
8
907-15-26 09:28p    1,024,000 R:\BIN
10> ddlink c=1 k=CY~E
11Elapsed 0:01:30.970

I didn't test >1meg as that takes a while to transfer serial.

1024000 bytes x 10 bits (start,8,stop) = 10240000 bits
10240000 / 115200 = 89 sec theoretical max
60sec+30sec = 90sec
DDLINK doesn't do compression - I don't see how it could be a whole lot faster

-

Next tests were done over LPT

107-15-26 09:34p       10,240 R:\BIN
2> ddlink l=1 k=CY~E
3Elapsed 0:00:00.550
4
507-15-26 09:36p      102,400 R:\BIN
6> ddlink l=1 k=CY~E
7Elapsed 0:00:02.090
8
907-15-26 09:38p    1,024,000 R:\BIN
10> ddlink l=1 k=CY~E
11Elapsed 0:00:17.985
12
1307-15-26 09:41p   10,240,000 R:\BIN
14> ddlink l=1 k=CY~E
15Elapsed 0:02:56.550

In this case I added a 10m file (LPT is much faster)
10240000 bytes / 176 seconds = 58182 bytes(x8=465456 bits)/second

-

And just to show it, I transmitted the 10m file over LAN

107-15-26 09:45p   10,240,000 R:\BIN
2> ddlink p= k=CY~E
3Elapsed 0:00:15.125

Obviously a lot faster
10240000 bytes / 15 seconds = 682666 bytes(x8=5461328 bits)/second
- My DOS lab test machines are connected through a (10 mbps hub)

-

I use DDLINK a LOT - and don't have any of the problems you describe.
I would like to figure out what's happening in your setup - perhaps we could run some tests at some point!

-edit- I had modified my TIMEIT tool to show milliseconds and had accidentally showed as xx:xx:xx.xxxx - fixed to .xxx

Btw - DDLINK.COM I was using shows "May 13 2025" in it's startup message.

FWIW - DDLINK.COM is stand alone needing NO other files (it does need a "packet driver" for LAN)
and is <18k (17,630 bytes) in size.

I created it to have an efficient/small way of moving files to/from an ImageDisk system booted from floppy (which uses a RamDrive for working storage)
- not everyone has DOS installed on a system these days!
It fits nicely on boot floppy, still leaving LOTS of space for ImageDisk and other tools!

I hadn't used DDLINK before, tested it out tonight.
Works fine, even though the server side is inside DOSBox and using a USB-serial.
Copying a 2,094,602 byte file, with B=4000, DDLINK does it in 3min9sec.
My properly-tuned Kermit does it it 3min17 sec.
Theoretical max is 3 min 2 sec, so both of these are right in line with expectations.

As DDLINK.TXT says it doesn't need RTS-CTS, it must use a stop-and-wait protocol? but that is fine for a low-latency, local connection like this.

Bootstrap mode worked too--though I have a null modem cable that has DSR properly connected at the DOS end (I had to crack open one end and modify it as such).

jakethompson1 wrote on 2026-07-16, 02:59:

I hadn't used DDLINK before, tested it out tonight. Works fine, even though the server side is inside DOSBox and using a USB-ser […]
Show full quote

I hadn't used DDLINK before, tested it out tonight.
Works fine, even though the server side is inside DOSBox and using a USB-serial.
Copying a 2,094,602 byte file, with B=4000, DDLINK does it in 3min9sec.
My properly-tuned Kermit does it it 3min17 sec.
Theoretical max is 3 min 2 sec, so both of these are right in line with expectations.

Always good to hear.

I use DDLINK under DosBox all the time - most often over LAN with DosBoxs virtual NE2000 network interface.
It is by far the easiest way I've found to move files between my DOS systems that don't have an "official" network configured and my more modern Winblows systems (with DDLINK running in DosBox)

As DDLINK.TXT says it doesn't need RTS-CTS, it must use a stop-and-wait protocol? but that is fine for a low-latency, local connection like this.

DDLINK is written using my own Micro-C/PC compiler which has a set of very efficient buffered, interrupt driven serial I/O functions ... on most systems it can run at 115,200 without losing data* and very low end-to-end turnaround time - the actual protocol is documented in detail within DDLINKs documentation (I even provide a [much simplified] sample program in C source which can communicate with it!)

* I've used it from 286-I7 without needing slower speeds ... the only time I've had to set it slower is when someone gave me a "Poqet PC" - a very slow CMOS 8088 system that runs on AA cells. It has DOS 3.3 in ROM, a small RamDisk, and a battery backed up CMOS RAM "hard drive" in which the battery had failed (and I've still not gotten around to replacing the officially non-removable cell) It has a proprietary expansion cable/connector which I don't have, but found a dead PCI card edge has the right spacing, and was able to make a serial connection that way. I have to bootstrap DDLINK to it, then run it at 19,200 to get reliable (no re-TXs) transfers - but that system is excruciatingly slow!

Bootstrap mode worked too--though I have a null modem cable that has DSR properly connected at the DOS end (I had to crack open one end and modify it as such).

DDLINKs serial I/O code doesn't care what RTS/CTS, DTR/DSR is doing - it needs only the basic serial wires (Rxd, Txd and Gnd)
The need for these signals during BOOTSTRAP is because it has to talk to a DOS CTTY console - and DOS needs these signals to communicate.
- a bog standard null-modem (Txd<>Rxd, Dtr<>Dsr, Rts<>Cts, Gnd) will work find to bootstrap.

jakethompson1 wrote on 2026-07-15, 22:17:

Supposedly Interlnk in DOS 6 is just a demo of Fastlynx, written by the same people.

Were the files you transferred compressible? That could account for some of the variation in transfer speeds. At 10 bits/byte (because of start and stop bit) the theoretical maximum of a 115200 serial interface is 11520 bytes per second. So a 1MB file should take 1:31. If it's faster than that, it's either compression, or they are doing some direct bit-banging on the UART rather than using it in the normal way.

edit: Kermit (C-Kermit or MS-Kermt for DOS or the revived Kermit 95 for Windows) would be nice to see, but it takes a lot of configuration since the default is the stop-and-wait 90 bytes per packet protocol which is why it's remembered as slow. It does not do parallel however.

I forgot to mention that the 2 files were already compressed (1 as zip and 1 as 7z).

Will take a look at Kermit. Needs to have a NC like interface though. One of the reasons I didn't include pcAnywhere was that it didn't have one (and also didn't support parallel).

DaveDDS wrote on 2026-07-16, 02:02:

I use DDLINK a LOT - and don't have any of the problems you describe.
I would like to figure out what's happening in your setup - perhaps we could run some tests at some point!

I don't understand it as well. More than willing to take a closer look. Just PM me or put it here if you need to test something or need more information.

DaveDDS wrote on 2026-07-16, 02:02:

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

Dave, I looked through all your files (even your OLD files) on your site but I couldn't find MTF.

This utility will be very useful to create test files of random data. May you possibly either link to it or provide the MTF.COM file here as an upload?

zyzzle wrote on 2026-07-18, 20:26:

DaveDDS wrote on 2026-07-16, 02:02:

Test file was a series of randomly generated binary bytes of the size shown. I have a MTF (MakeTestFile) tool I use sometimes while testing:
> MTF BIN -B 10
Will generate "BIN" containing 10k (10x1024 = 10240) of random binary data.

Dave, I looked through all your files (even your OLD files) on your site but I couldn't find MTF.

This utility will be very useful to create test files of random data. May you possibly either link to it or provide the MTF.COM file here as an upload?

Yeah, it's a little tool I needed once and just "ripped out" for myself - I've never published it - It's a simple thing to do ... except ...

I didn't clean it up, make it look nice, add proper command help etc. - give me a few days and I'll see what I can make available.
(got a few enhancements I've wanted to add - but never found worth it - might do now (like being able to set random seed - currently it's randomized at startup from clock tick - but sometimes it would be nice to be able to generate the same "random" 😀 file)

Ok, here's a "first pass" at a public version:

Note that this is a DOS (16-bit) program and won't run under Win32
(It runs well in DosBox ... I could compile a .DVM version for those who might
want an "easier" way to run it under Win32/64.

1MakeTestFile
2
3use: MTF file[.ext] -B<size> [-R]*    Make [.BIN] Binary file of <size> k-bytes
4            ""      -T  ""             ""  [.TXT]  Text   ""  ""   ""     ""
5            ""      -L  ""             ""    ""     ""    ""  ""   ""    Lines
6
7*   -R          show random number generation seed
8    -Rvalue      set    ""    ""       ""      ""   to value
9
10Creates a "test" file of random binary data or text lines.
11
12Dave Dunfield   -   https://dunfield.themindfactory.com

Thanks, that's a very useful small DOS program. Been looking for something that can do this for awhile now. We should be able to produce the same "random" data with the same random seed using your -R switch. But randomized from clock tick at program start works also for truly random data, as clock ticks will always be different, assuming we don't change the date.

zyzzle wrote on 2026-07-20, 01:46:

Thanks, that's a very useful small DOS program. Been looking for something that can do this for awhile now. We should be able to produce the same "random" data with the same random seed using your -R switch. But randomized from clock tick at program start works also for truly random data, as clock ticks will always be different, assuming we don't change the date.

Doesn't actually have anything to do with the date.

The PC has a 55ms "tick" in BIOS - 18.2 a seconf x 60 secoonds x 60 mins x 24 hours = 1.5m ticks/day, the chances of running the same application at the sane "tick" - adjusted for differences in PC clocl speed make ot VERY unlikely that the "random sequence" will be the same for two different runs if the same program (and it it were truly randim - this woukd be entirely possible.

Found a new official LANtastic parallel cable. So did some new tests so I could test the cable in combination with my new BOOK386 laptop.

Test setup: Intel Pentium MMX (200MHz / laptop) - 386SX (40MHz / BOOK386 laptop)

Parallel (ECP mode) - 10MB zip file

1FastLynx: 1:42
2File Maven: 2:19
3Norton Commander: 2:21
4Laplink: 3:14
5DDLINK: 5:05

Mostly the same results as earlier (with different cable and systems). FastLynx is the fastest and DDLINK the slowest.

You got me curious because of the vast differences in speed. The FastLynx suggested pinout, where 7-1, 8-14, 9-16 and 17-17 are connected, and section 6 this reference https://www.sfu.ca/phys/430/datasheets/parport.html made me realize it's possible to use pins 1, 14, 16, and 17 {STROBE, LF, RESET, SELECT} as inputs, thereby allowing the transfer of bytes rather than nibbles. It's explained somewhat hacky; the sending side outputs a '1' bit on pins 1, 14, 16, and 17, which causes a pull-up resistor to raise them high; if the opposite end is outputting a '0', that will safely override the pull-up so that the host can read those values in its read-back register. It's also elegant in that the parallel port never needs flipped to bidirectional mode since the data pins are never used as inputs.

Since DDLINK is the only open source one on the list, we can look at it and understand that it does not attempt the above trick with pins 1, 14, 16, and 17, rather, it uses five pins, so that five bits (four data and one handshake) can be sent to the other side at any time. PLIP drivers (both packet driver and open source in Linux and the BSDs) also only use such a 5-bit cable. This reduces speed at the benefit of being universally compatible with any parallel port, while the FastLynx manual warns that some machines might not be able to take advantage of the extra pins. DDLINK also uses polling to synchronize the two sides when using a parallel port. It's also possible to use a nibble mode cable in interrupt driven mode to wake up the opposite end, but this can require introducing deliberate delays to avoid overwhelming the opposite end with IRQs. I suspect the 4-bit slow/normal/fast/turbo options in FastLynx are controlling such intentional delays. Also, it's possible to send a burst of nibbles rather than just two at a time, but that would require more timeout handling and resynchronization code.

I'm not sure EPP and ECP help since this is a low-level bit-banging protocol rather than the opposite end handshaking like a printer. In particular FastLynx is the fastest yet its manual (https://www.minuszerodegrees.net/transfer/fas … 7s%20Manual.pdf) doesn't have a single mention of EPP or ECP (like a suggestion to turn them on in the BIOS since they're off by default) makes me think no EPP or ECP features are used.

jakethompson1 wrote on 2026-08-06, 22:23:

I'm not sure EPP and ECP help since this is a low-level bit-banging protocol rather than the opposite end handshaking like a printer. In particular FastLynx is the fastest yet its manual (https://www.minuszerodegrees.net/transfer/fas … 7s%20Manual.pdf) doesn't have a single mention of EPP or ECP (like a suggestion to turn them on in the BIOS since they're off by default) makes me think no EPP or ECP features are used.

I don't think it has a huge impact but I included just for completeness. In theorie it should be much faster but I didn't see huge differences. It was even mentioned somewhere that EPP could be even faster than ECP in some cases (ZIP drives). But I don't think any DOS transfer programs supported EPP or ECP.

Yoghoo wrote on 2026-08-06, 22:35:

I don't think it has a huge impact but I included just for completeness. In theorie it should be much faster but I didn't see huge differences. It was even mentioned somewhere that EPP could be even faster than ECP in some cases (ZIP drives). But I don't think any DOS transfer programs supported EPP or ECP.

I think the issue is more that it's impractical to implement the IEEE 1284 handshaking with nothing but a passive cable. Parallel Technologies, who made the PARALINK.VXD driver for Direct Cable Connection in Win9x, did sell a "smart" parallel cable with a chip in the middle: https://web.archive.org/web/20050205043039/ht … hefastcable.htm that should allow EPP/ECP but I've never seen one.

As I found a LANtastic parallel cable it would be a good idea to test it with the software it came with: LANtastic Z V5.0.

This is similar to Personal Netware but working with a parallel cable, serial null modem cable or modem instead of a network card. You can mount (CDROM) drives, share printers, mail and send messages. Works very nicely and is quitte small (1 * 720KB floppy).

The memory consumption for the client is about 38KB. For the server it's twice that amount (76KB).

Test setup: Intel Pentium MMX (200MHz / laptop) - 386SX (40MHz / BOOK386 laptop)

Parallel (ECP mode) - 10MB zip file

1LANtastic Z: 2:50