Herbert Kleebauer wrote:
On 21.05.2021 13:56, R.Wieser wrote:
Herbert,

But in real DOS, the "copy com1 file" should work.

You got me there I'm afraid, I used the DOS w98 ran on. And although
"copy
com1 file" /looks/ to be working there, it , just as "type com1", does
not
know when to stop. Ctrl-C-ing outof it causes the file to be empty.
:-\

How many characters did you send? Maybe it is written to the file only if
an internal buffer is full. But in DOS you can use .com programs. Just a
few bytes of code is necessary to copy bytes from com1 to stdout (terminate
if a special character is received or after maybe 1k byte is received).
Use debug or directly enter an ascii binary using the keyboard.

I did this at work, between an Apple computer and a PC
that had no NIC card in it. My boss got a PC from the
"warehouse", and I gather this is like "picking plums
from a plum tree", you don't get to specify anything
about the machine. They just take the one on the front
of the pile and ship it. The PC arrived, with no NIC card,
and I couldn't afford to wait for that to be corrected.

And at the time, I had both directions working. I was sending
files Apple to PC and PC to Apple. Complete with the little
ceremony to send some character like ETX, to close the file
on the receiving end. I may have brought in an adapter cable
from home (because Apple to PC wouldn't have been a cable
sitting in the lab at work).

While many would consider what Rudy is doing, to be some
kind of joke, this is a survival skill. If you're in the
jungle and two PCs won't talk to one another, this is
what you do. I saw it on McGyver.

It's possible my config here, would work better if
using COM1 or COM2 (SuperIO), than one of the many USB
serial ports I've got. One machine has a COM1, but the
other one only has COM3, and it's remotely possible
the USB driver for the COM3 is screwing this up.

Paul