DaveDDS wrote on 2026-09-26, 12:28:

I've been half-heartedly looking into fixing it ...

Ok... I believe I have made DDLINK much more robust. I did find a protocol error and enhanced a couple things while I was working on it.

It's a slightly bigger now (I can eventually reduce it - right now there extra test/debug code in it) for example when an "IOfailure" abort happens, it now dumps all the processor registers at the time of fail.

It's a bit slower over LPT now - more conditioning (I had removed some of the conditioning thinking it wasn't really needed - but it's more robust with it) I'm not really to concerned about this ... it's better if it's more reliable, and 4 mins to transfer a 10m file is still *way* better than serial at 115,200 (16+ mins) - and I only ever used it in the rare case of a getting images on/off of an ImageDisk (DOS) system without a network card (which all my DOS systems have)

I can't guarantee it - I needed at least a 10mb file to make it happen, and at 5mins or so a shot - I'm not overly keen to keep trying something I never actually use anymore.

I've updated the DDLINK.ZIP archive on my site which is the "official" place to get DDLINK.COM - it will eventually trickle into any other archives that have it as I update them. I've not updated the published source yet but will try and get to that after I have some more experience with this new version.

DaveDDS wrote on 2026-10-01, 23:27:

DaveDDS wrote on 2026-09-26, 12:28:

I've been half-heartedly looking into fixing it ...

Ok... I believe I have made DDLINK much more robust. I did find a protocol error and enhanced a couple things while I was working on it.

Good to hear. Will test it but will take some time as I'm about to go on holiday. Probably somewhere in November at the earliest.

Yoghoo wrote on 2026-10-02, 07:27:

Good to hear. Will test it but will take some time ...

No hurry - LPT transfer seems mostly irrelevant these days ... the only reason I did look at it is that it just "bugs" me to have something I've published with known problems.

I use DDLINK a lot, but almost always via network. All my DOS systems but one have NICS, even though they don't have other networking (For a while I had the DOS components of WFW on a couple, but don't use that at all now, Winblows networking has "improved" to the point where WFWs protocol isn't directly supported (you can apparently do a registry hack to enable the "old insecure" protocol. I also used NEOS for a while - but not being able to transfer to/from modern systems makes that unworkable now.

DDLINK runs well in DosBox over packet(network) or serial links, which makes moving to/from modern systems very eary.

I've never gotten LPT to work with any modern OS or even an emulator... DDLINK runs under DOS (accesses LPT port directly and in non-standard ways) - Winblows likes to "twiddle" inactive LPT bits (presumable to see if printer is attached) often enough that it causes problems with LPT transfer (even with emulators) and if you "disable" the port, emulators won't make it accessible - on top of that, I've not found any emulator that supports a virtual "parallel transfer cable" between sessions (DosBox does provide for a
"virtual serial null-modem between sessions which makes testing serial easy)

The only way I can test LPT is by setting up three actual DOS systems on one bench (two to do the transfer) and one to monitor via the "DB25 breakout board" I showed earlier.

I do have one DOS system without a NIC - A "PoqetPC" - super tiny 8008 Laptop with DOS 3.3 in ROM - I don't have the proprietary connector I/O cable, but was able to make a COM connection via a bit of PCI edge connector (same spacing) - too much work to try to make an LPT cable.

So... I used DDLINK to bootstrap itself onto the Poqet and can use it to get stuff on/off - This is pretty much the only time I use COM.

Back in the day when I did use DDLINK/LPT it was on much slower systems, or some 386 laptops I had which didn't have a NIC. And as I mentioned, I never had the problem you encountered. Even today I really had to go to a 10mb file o cause failure and that kind of limitation was never a problem for me in DOS.

DDLINK uses a VERY simple LPT protocol with no interrupts etc.

There are 5 data bits D4-D0 - Idle is D4=0
Sending PC sends D4=1 and D3-0 to high nibble of byte to transmit
Receiving PC sees D4high, records high nibble, then toggles D0 (which will be of whatever was last transmitted) to let sender know it has done so, then waits for D4low.
Send: D4=0 D3-0=Low nibble
receive: Sees D4low, reads low nibble, adds previous high nibble, buffers, then toggles D0 to acknowledge.

The bug: if sender gets processing an interrupt at just the wrong time, at the last byte of a "packet", receiver may initiate TX of protocol ACK before sender has seen D0 toggle - if protocol ACK has the same D0 value, sender doesn't see D0 toggle and waits for byte ack. Very tight timing for this to occur which is why it needs such a huge file (lots of transfers).

My quick fix: If sender sees D4 go high while waiting for D0 to toggle, it knows receiver has moved on from the receive function (which means it did get the low nibble) and concludes the TX (and will see D4 high at the higher level and initiate a receive.

Seems to work much better - but at 5 mins a test.... not tested much!