Jo22 wrote on 2025-02-23, 18:25:

Actually, there is. But not with standard EIA-232.
....
Fossil drivers maybe can provide compatibility with non-standard serial ports.

Sure, I was trying to stick with regular RS-232 that many 70's and 80's era systems, to avoid appending specialized hardware onto those systems (and that at least KERMIT or XMODEM is relatively easy to implement on those systems).

Like the NEC PC-8001 has an onboard 8251 USART, then the parts to level shift to RS-232 -/+ 12V (video about it https://www.youtube.com/watch?v=YWsarGG6Xns).

NOTE: I tried the X00 FOSSIL driver to see if it would help accelerate things on a '286, and in short - it did not.

It's interesting how the "Mac-world" always seemed to be a step ahead in fast data exchanges (for example, FireWire first and Thunerbold first before "PCs" caught up). I tend to think it's because Macs (in general) were more involved with large-media (large images and video media), hence more demand for slinging/streaming data from here to there, so more motivated to get higher throughput equipment. On the other hand, modems were never that fast, and the 1.8432MHz clocked 8250 were plenty sufficient for those (except that the original PC had that BIOS bug capping it artificially to 9600). The other thought is: most homes barely had 1 PC (throughout the 1980s), so there wasn't too much motivation to worry about system to system data streaming speed (not until laptops became more affordable and obtainable in mid-1990s; yes, they existed earlier, but poor battery and displays made their use limited).

So I just tested INTERLNK and LAPLINK5. Using the TYREND.ANM file (an animation data included with Tyrian) at 3,315,848 bytes (a good size file to test with, not massive but not tiny), between two 386DX's and using CF (compact flash) "hard drives":

INTERLINK (INTERSVR/INTERLNK) and LAPLINK5 (using the same cable) managed this copy in 1min 56sec --> ~29KBps
NOTE in LAPLINK it said it was using "8-bit turbo" and compression, it has a 4-bit normal mode. I used whatever defaults these all had (in terms of buffer sizes). Throughput is sensitive to that kind of stuff (you see that also in UART FIFOs - to get past 115.2K you'll probably need more than 16-byte FIFO; which on this USB/serial adapters, you'll see they generally have 64-bit FIFO at a minimum, often 128 bytes or some are up to 4K).

For comparison, the SDLPT device (local SD-card adapter over LPT), it copied this file in 2min 50sec --> 19.5KBps (little surprised this was noticeably slower, but I've no idea what code they are using to interface with the SD-card; I'd assume even the slowest SD-card would be far faster?)

I gotta get outside for awhile, but DDLINK so far didn't work. I ran /S server mode and that seemed to startup ok (said Server Ready). On the other system it has two LPT ports, and I tried L=1 and L=2, and it reported "LPT handshake failure". I'll read more about it when I get back (I was just trying it with the same cable I used for InterLink and LapLink, but perhaps the wiring is a little different for DDLINK?)

voidstar wrote on 2025-02-23, 16:40:

I'd still like something that goes MS-DOS to modern-Win64 more natively (via a USB-dongle of some sort, without DOSBox).

There are certainly ways of transferring files directly between DOS and modern 64bit Windows (I'm the maintainer of the Windows half of one of them), but enumerating those options is probably best done in its own thread.

Sure, like the mTCP tools and ethernet (which depend on a bunch of hardware and the 3COM drivers). I like the approach Dave has here with "minimalistic software" (and widely available standard hardware, just since so many 80's systems happened to have printers). But I never had solid numbers on the parallel-port throughput, at least now I have a number for 386's systems, and can see how it scales/changes with slower/faster systems (maybe it won't change?) But now I'm curious if/how parallel can scale to higher speeds (as the classic RS-232 port has, except that >7MHz clocked UARTs were never quite widespread -- those are a good option to just interoperate with existing kermit/x/ymodem capable terminals, but otherwise there are some faster specialized SPI options).

Report, just got DDLINK working with the same cable and systems are mentioned above. I had to reverse which system I used /S on. Not sure why it would matter - but it "just worked" (so otherwise using all default settings).

With the same 3MB file, it took 4min 18sec. That's not as efficient - this is a 386DX-20 (using original IBM 8-bit ISA parallel card) and 386DX-33 (using a parallel port hanging off a MDA video card). 3315848 bytes / (240+18) seconds = 12.8KBps. Still beats a serial 115.2Kbps connection. Seems to me DDLINK might be status'ing the transfer to much? (was updating status every block? not sure if that impacts things)

Neat to confirm that the same cable works with all 3 options.

voidstar wrote on 2025-02-23, 20:05:

Report, just got DDLINK working with the same cable and systems are mentioned above. I had to reverse which system I used /S on. Not sure why it would matter - but it "just worked" (so otherwise using all default settings).

With the same 3MB file, it took 4min 18sec...

I think something in your connection might be "not quite right"
If you're using an "off the shelf" LAPLINK cable - check that it matches
the cable pinout that DDLINK uses (I just "invented" a cable - the way I
wired it makes most sense to me and I would think that others would have
come to the same design ... but you never know.
.. Perhaps DDLINK is doing retries?

But you are right - parallel transfers are slower than network:

Using DDLINK with a parallel connection between two DOS system with a true
3meg (3x1024x1024)=3,145,728 random bytes - I get:

L= (parallel) 54sec
P= (network) 4.5sec (10mbit cards & hub)

To be fair I've not looked at this in a long time - I have old 10m NE2000
cards in all my DOS systems, and they are connected to a hub ... much easier
to just load the packet driver than to dig around the back and plug in 25-
pin cables, they don't have to be close to each other, and I can just as
easily DDLINK to/from a "modern system" running DosBox.

I put in LPT because I had a laptop without network, but it did have an
LPT port - and L= is much faster than serial!

I had thought it would be quicker than network because it's sitting in a
tight loop waiting for the control pin to change ... should be less code
per transfer than calling the packet driver... (athough one LPT tranfer is
only 4 bits - a packet transfer is 1024 bytes -- so it would really
depend on the code within the packet driver! - someday I must look into this!)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

It may be that these 20MHz/33MHz 386 systems just can't push the data fast enough (cross reading from CF emulate hard drive and their 30pin SIMM RAM) ? (I mean fast enough to fully utilize whatever buffers DDLINK is using to shove data across the LPT connection) // But yes, I'm using a "regular" Laplink cable (but no I didn't make it myself, so I'm not sure of the exact pinout, but interesting that INTERLNK and LAPLINK5 s/w got about the same performance across it)

Is there a way to turn on any logging in DDLINK to see if re-tries or flow control throttling is happening? LPT support is great for laptops and don't want to deal with PCMCIA or a NIC.

EDIT: In other news, I just finally tried the ~7MHz 16550 in a 386 - using QModem Pro's YModem implementation, it just did 19,754,258 bytes in 1296 seconds (that means ~15.2 KBps). QModem normally only supports up to 115200, but jumpers on this board lets you proxy in a different divider - so 115200 becomes a proxy for 230400 or 460800 (depending on the jumper setting). It's an impressive speed for RS-232 and the equipment involved, but it is a "special hardware mod" dependent (the high speed 16550 serial card by SIIG).

A slightly related note...

A few months back I was given a "Poqet PC" a very tiny 80C88
laptop that runs from 2AA cells...

But it doesn't have any sort of normal drives - just an internal ROMdisk
and a couple of battery-backup up CMOS-RAM drives that plug in the sides
on "their own" connectors - so no easy way to just copy stuff in...

It does have an IOadapter connector on the back, which is unusual (I have no
idea where to get one) - but does have the same spacing as a PCI card.

I just got around to making to short connector that plugs into one and and
gives me a serial port. I know it works because I can CTTY COM1 on the Poqet
and access a command line via serial with a TTY program.
- I *think* it has an LPT on there as well... I just have to find a connector
and make a cable 🙁

I had hoped to bootstrap DDLINK to it ... but that fails... DDLINK /B "types"
a small binary bootloader into a COPY COMn - not a common thing to do, but
mostly works... Perhaps the Poqet COM port isn't 100% 8250 compatible
or MS-DOS 3.3 on the ROMdisk is not as transparent (FreeDos certainly wasn't)

Fortunately the ROMdisk does have most of DOS on it including DEBUG and
I'm able to use my DBBS (DeBug BootStrap) tool to put small things on it.
I wanted to move DDLINK itself but entering a 17k program through DEBUG 'E'
would take hours (even when done by a program - lots of chars transferred
/echoed etc. for each byte), and no error checking makes the chances of
failure uncomfortable high.

So... I've just made/tested a tiny tool to transfer a file over serial
using a 3->2 method - 3-printable chars moves 2 binary bytes
(and since it's 6 bits/char, 3 actually give you 18 bits - so lots of
room for out-of-band control codes) - with checksum/retry recovery.

I just got it working, at 288 bytes it's not to bad to transfer with DBBS,
and moving the 17k DDLINK.COM at the default rate of 2400 takes just under
2 mins. I've still got to clean it up a bit, add some options etc., but
when it's ready I'll post in on my site in case anyone else could use
something like this.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

voidstar wrote on 2025-02-23, 23:22:

It may be that these 20MHz/33MHz 386 systems just can't push the data fast enough (cross reading from CF emulate hard drive and their 30pin SIMM RAM) ? ...

I kinda doubt it - unfortunately I don't have old/slow systems any more, the two DOS systems I
was testing were a P3 and a P4... but given the difference between LPT and LAN (almost a min .vs.
<5s) - I don't think its so much CPU holding it back ... probably more that it's over a cable setup
not designed for high-speed transitions.
-- And when I leave my desktop running DDLINK so I can access files from the DOS
-- machines downstairs, I often set DosBox CYCLES quite low to "idle" the system

I also use it in my ImageDisk system - this is a P200MMX - transferring over the network
and it's not slow. A 1.5M disk image is just a couple secs.

I do still have a couple Acer AsoireOne netbooks, these use one of the original Atom processors,
quite slow - and I DDLINK to them over network quite nicely).

Is there a way to turn on any logging in DDLINK to see if re-tries or flow control throttling is happening? LPT support is great for laptops and don't want to deal with PCMCIA or a NIC.

Sadly no - there's not much debug features in DDLINK - It's a fairly complex program, has some
very large internal buffers - all the while being a single .COM (max 64k code+data)
- and yes, I could have made it bigger .. but at the time I wrote it I really liked being able
to fit it, a large collections of packet drivers and my ImageDisk package all on a single
boot floppy ... was really useful for people who didn't keep DOS systems when they wanted to
read or write a classic system diskette.

Have you got a NIC you can stuff in - would be interesting to see how it does over network with the
same drive config...

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Curious Marc recently demo'd a teletype punching 4K original MS BASIC - he had to do it twice because of (probably) a transfer (or punch error), you do have to go slow on those bootloaders for sure. It was a nice re-enactment of events in 1975.

I use RS-232 to key in programs into the IBM 5100, it took a while to dial in the appropriate speed. Here's a later demo of the same approach on an IBM 5110 when it was still slow ( https://www.youtube.com/watch?v=NOMCa3f1s5w )

Keying in through debug.com is pretty neat idea 😀

DaveDDS wrote on 2025-02-23, 23:38:

Have you got a NIC you can stuff in - would be interesting to see how it does over network with the
same drive config...

I only have one NIC here, the other is 2 hours away at another location. NIC aren't as interesting to me - it's faster, but "anyone can do that" 😉 [ although, doing it a <64K .COM is impressive ]

I do have a couple ThinkPad Pentiums, and do plan to see how all this scales to the faster systems. I'll have to boot them from floppy since they have OS/2.

Do you think MS-DOS 5 vs 6.22 could be a factor? I use 5.0 on the older 386 just since I keep it "period correct" (to software that was available around 1991/1992). Not sure if you're using any DOS interrupts that might be less efficient in their older version? (but then again, both interlink/laplink got pretty impressive speed on that equipment - but they didn't report as much status during the actual transfers)

voidstar wrote on 2025-02-23, 23:42:

Curious Marc recently demo'd a teletype punching 4K original MS BASIC - he had to do it twice because of (probably) a transfer (or punch error), you do have to go slow on those bootloaders for sure. It was a nice re-enactment of events in 1975.

My first computer (a homebuilt 8080) had a Model-28 teletype as a printer.
75bps 5-bit baudot coding - I didn't use interrupts for any reason on that early system,
so I wrote code to output to the printer by "flashing" the 8080 interrupt enabled signal.

You can see that early setup on "Daves Old Computers"

I use RS-232 to key in programs into the IBM 5100, it took a while to dial in the appropriate speed...

I had a 5100 at one point. Very cool for the day - What? A computer you could actually lift and not always
get a hernia?

Keying in through debug.com is pretty neat idea 😀

Thanks - it does work quite well.... but I discovered that standard IBM/MS DOS 3.3-through-7.x
is remarkably transparent for: COPY COMn: BOOTSTRAP.COM
It basically passes all BYTE values (assuming you have 8-bit serial configured) except for 0x1A
(ASCII End-Of-File) - so for DDLINK /B I send a little bootloader which does proper serial I/O
with retries etc. to transfer the actual program code...

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

voidstar wrote on 2025-02-23, 23:52:

Do you think MS-DOS 5 vs 6.22 could be a factor? I use 5.0 on the older 386 just since I keep it "period correct" (to software that was available around 1991/1992). Not sure if you're using any DOS interrupts that might be less efficient in their older version? (but then again, both interlink/laplink got pretty impressive speed on that equipment - but they didn't report as much status during the actual transfers)

I still run MS-DOS 5 on most of my DOS systems... but I've made up boot disks with IBMDOS 3.3, MSDOS 4.0,
MSDOS 5, and IBM PCDOS 7.1 and they all work well with DDLINK (serial and network - I've not tried them all
with LPT)

For serial, I used the standard interrupts associated with those ports. I don't use any interrupts for LPT,
and for LAN it's whatever interrupts the packet driver uses.

And for the communications, the code is all my own ... I don't call DOS for any of the remote IO
(obviously I do call the packet driver - and the code that runs within it isn't mine)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Well, I've run out time to play for this weekend... But couple interesting things:

I booted the ThinkPad Pentium with OS/2, and it was able to run LapLink5 with no issue (the MS-DOS version, same as what I had been using on the 386's) - and got decent performance (about 22KBps across LPT). I couldn't do that with the WinXP Pentium system (for several reasons), so it was neat seeing OS/2 Warp handle it like a champ.

I tried DDUTIL on that same Pentium OS/2 system. And it actually did START to transfer, but eventually it would always fail out with LPT handshake failure error. Highest amount I got transferred was about 300KB. This was with the 386 MS-DOS 6.22 system (33MHz) trying to transfer to that Pentium OS/2 system (150MHz). I'll try a more equal Pentium to Pentium experiment later when I get more time.

I did try transfer (from the 386) to an older 286 system. Mixed results: INTERLINK was actually faster on that setup, LAPLINK was slower, and DDLINK did work but was a lot slower (only ~7KBps). Kind of suggest that attributes of the hardware on the two connected systems can influence the performance (i.e. a relatively fast system streaming data to a much slower system; I see a similar thing in RS-232 serial connections, there is a "breaking point" where flow control can't keep up if the systems are widely different in performance - in those cases, you have to drop down the baud rate a bit, but in this LPT exchange I think we just get the "handshake failure").

But also like you said, maybe I don't have an optimal cable for DDLINK? Can it "partially work" and have one data-pin degraded? Plus also I don't really have much control on the parallel port on these older systems (EPP modes and such?) I checked in the BIOS of these 286 and 386 systems and just didn't see options about it (the ThinkPad's options might be in the Windows ThinkPad Configuration utility, as its BIOS options are fairly sparse).

Ok, I've updated DDLINK.ZIP on my site:

-Now includes DMFT (Daves Minimal File Transfer)
Transfer files over stubborn serial links using only printable
characters (3->2 byte encoding) remote client is SMALL (easily
transferred by included DBBS - DeBugBootStrap)
- DBBS "types" into DEBUG on remote (CTTY)

I've also fixed some bugs in and generally cleaned up DDLINK as
well as some of its tools, recommend you update even if not
interested in DMFT

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

voidstar wrote on 2025-02-23, 23:22:

It may be that these 20MHz/33MHz 386 systems just can't push the data fast enough

Btw, I just happened to be recovering a MS-DOS 2.11 boot floppy today, and decided "what the heck"..
I booted the image in DosBox and it works.

Then, I tried with:
CPUTYPE=386
CYCLES=500

I happened to have on my DOS system, an old program called "speedcom" - I used to use it because
it can tell you what kind of CPU is sees, and give you an idea of "how fast" it is...

It does report a 386, and gives the clock speed as 1.5mhz, saying the system
performs like a 5mhz AT

In contrast my main DosBox(cycles=max) reports a 486, 52mhz clock and 300-400mhz AT (it wobbles)

NE2000 packet driver loads, and DDLINK works and can see another DDLINK
running on my main system.

I can't do LPT as it's booted in DosBox... But LAN works fine!
(Probably not worth testing serial as it would be slower than even
this CPU)

I've not taken the time to set up a HD or RamDisk, so I only have the 360k boot floppy.
Transferring SPEEDCOM.EXE (that's how I put it on) - about 40k - seemed quick
enough (way faster than it would have been via floppy).

386 is the lowest CPUtype I can pick (VMware doesn't mention CPU types).. I may
have to look into other 8086 emulators.

DDLINK itself is written in Micro-C/PC which generates stock 8086
code .. so it shouldn't need more than that - I don't know what the packet
driver needs.

That's about as far as my curiosity wanted go, but if you would like, I can set up
some larger drives and do more testing...

I could also do <500cycles but SPEEDCOM takes longer to "determine cpu speed"
at lower settings (500 took prob. 30ish seconds)

... I also have a DOS system with a P200 MMX - IIRC the MMX can be slowed down
fairly easily ... do you happen to know of any DOS tools that can do that? That would
let me test LPT transfers on slower systems (and also with InterLink)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2025-02-26, 21:13:

... I also have a DOS system with a P200 MMX - IIRC the MMX can be slowed down
fairly easily ... do you happen to know of any DOS tools that can do that? That would
let me test LPT transfers on slower systems (and also with InterLink)

Phil’s Computer Lab covered the topic of adjusting systems for variable performance.

https://www.philscomputerlab.com/136-in-1-pentium-mmx.html

How can I use DDLINK in local mode only as a file manager?

I tried with the TAB key to switch between the blue and red listing (which usually is the assigned key for such purpose in file managers) but it does not work.
The DDLINK manual in its last section (8) mentions "DaveD Command Menu", which is what I am asking for, but the executable is not included in the archive and does not work if used as an argument when executing DDLINK.

"For more information: DDCM -?" says the manual. But it seems an incomplete/future/WIP reference section or am I wrong?

BTW, I am using DDLINK archive version from the 24th february 2025.

igully wrote on 2025-02-28, 14:51:

How can I use DDLINK in local mode only as a file manager?
I tried with the TAB key to switch between the blue and red listing (which usually is the assigned key for such purpose in file managers) but it does not work.

DDLINK uses Left and Right to change sides. I'm pretty sure this is mentioned in it's manual,
and '?' (DDLHLP.EXE) lists: Left/Right Change side (location) where commands operaate

The DDLINK manual in its last section (8) mentions "DaveD Command Menu", which is what I am asking for, but the executable is not included in the archive and does not work if used as an argument when executing DDLINK.
"For more information: DDCM -?" says the manual. But it seems an incomplete/future/WIP reference section or am I wrong?
BTW, I am using DDLINK archive version from the 24th february 2025.

I think I updated DDLINK last before DDCM was ready, but was already in the in the manual.
I'll try to get it in shortly.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

igully wrote on 2025-02-28, 14:51:

... The DDLINK manual in its last section (8) mentions "DaveD Command Menu", which is what I am asking for, but the executable is not included in the archive and does not work if used as an argument when executing DDLINK. ...

Ok, I've updated/uploaded DDLINK.ZIP on my site to include DDCM

**Please note that unlike DDLINK itself, DDCM is something that I just
created, may not be quite as polished/debugged as most of my other stuff.
-- Bug reports/enhancement requests are welcome.

-- Also, I figured out why it wasn't in the published archive although
mention of it was:

Between my personal site, "Daves Old Computers", and formerly the DDS
commercial site - I maintain a LOT of files "on the web".

To simplify trying to keep track of all this ... I've written some tools
which will scan for and let me know if published files have been updated
on my local systems and also auto-build the .ZIPs that are published.

All this uses a simple database (TXT file) which tells it what files are
in what arhives and where they are on my systems.
- I had forgotten to update this database to add DDCM to DDLINK!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Thank you Dave!

I have already downloaded the new archive.