• Please review our updated Terms and Rules here

Help with DOS Serial Pipe Transfers

nullvalue

nullvalue

Veteran Member
Joined
Oct 8, 2019
Messages
988
Location
Indiana
So I have a hardware device I've built which has a MAX3232 chip on it for sending data over serial. The device works perfect as I can send/receive data in a terminal program no problem. I am running MS-DOS 6.22 on a 486 machine. What my device will do is send some data out onto the serial port (when a user triggers it).

I've issued the MODE command on the DOS machine "MODE COM2:96,N,8,1" (I've also tried "MODE COM2:96,N,8,1,P" and "MODE COM2:96,N,8,1,E")

Then I've tried a few different commands and none seem to work..

COPY COM2: FILE.DAT
TYPE COM2 >> FILE.DAT
TYPE COM2 /B >> FILE.DAT /B

After issuing these commands, the system waits and I trigger the transfer. None of these combinations work - it just continues to sit there as if nothing was transferred. I'm assuming there's some kind of control command I have to send to mark the transfer was complete (EOF?). If can hit CTRL+BREAK to end the command, and I usually just end up with a "^C" in the file as a result from the TYPE commands. the COPY commands will just say "0 file copied" and doesn't create the file.

Am I missing something or does the computer expect flow control? I'm pretty certain the MAX3232 chip doesn't implement any kind of flow control.
 
If you do a copy con to create a text file without an editor, you end the file with a ctrl-z or F6, which I think is used as the end of file character. Not sure if that will help here or not.
 
If you are just transferring text files, sending the EOF char (26/0x1A) should work. For binary files I think you will need to do something more elaborate, like CTTY COM2 and then run DEBUG remotely.
 
Ok thanks guys...

I just tested that with "COPY CON FILE.TXT", typed a bunch of stuff, pressed F6 and I get ^Z on the screen but doesn't end the copy, I have to hit Enter then before it completes, then I get "1 file(s) copied" then my file does indeed contain the text I typed..

So I modified my code to send a (char)26 at the end of my transfer and still nothing happens. It's as if the computer never is seeing the transfer at all because the same happens when I use the TYPE variant of the command. Also tried sending a CRLF after the EOF and that also doesn't help.

I understand that this won't work for binary files and for now I'm fine with that.
 
I’m not sure if it’s possible to copy files across the serial port, directly.

The two programs I can think of that copy files to another computer, over the serial port, without a client at the remote end, are laplink and fastlynx. And they both require you to transfer control of the remote console to the serial port using ctty.

Perhaps you could sniff what either of those are actually doing to see how they do it. I recall loading fastlynx in a VM and then using a windows program to capture the serial port, but I don’t remember how it worked. Probably because it was over my head. :)
 
jafir said:
I’m not sure if it’s possible to copy files across the serial port, directly.

The two programs I can think of that copy files to another computer, over the serial port, without a client at the remote end, are laplink and fastlynx. And they both require you to transfer control of the remote console to the serial port using ctty.

Perhaps you could sniff what either of those are actually doing to see how they do it. I recall loading fastlynx in a VM and then using a windows program to capture the serial port, but I don’t remember how it worked. Probably because it was over my head. :)
Click to expand...

Thank you, guess its time to put that logic analyzer I got to the test..
 
Chuck(G) said:
Um, here's a thought--how are you handshaking signals configured (RTS/CTS/DTR/DSR)?
Click to expand...

Well that's what I mentioned in my first post - the MAX3232 chip I'm using (TTL to RS232 level shifter, basically) doesn't do anything with the handshaking signals as far as I'm aware. Are they required when communicating with the PC in this manner?
 
Use the usual null-modem setup on the PC end. RTS->CTS tied ; DSR->DTR->DCD tied.

On a DB25 connector, that would be pin 4 tied to 5; then pins 6, 8 and 20 tied. Then all you need in a cable is Ground pin 7 and RxD pin 2, and TxD pin 3 (or vice-versa).
 
Your baud, parity & stop bits should be set the same as your terminal program is. Is your terminal program set to use handshaking? Probably not. You can try writing to the serial port using Qbasic, setting the parameters the same as the terminal program. You might need Carriage Returns in your command file to trigger your device to process the commands sent to it.
 
Nullvalue, from your original post, you appear to send a command to the device, but how are you reading the response? A terminal program (procomm, etc.) continuously reads the serial port, except when it's transmitting data. Scratch that, relooking at the commands, it looks like you're trying to read data from the port, but you never send a command in the first place. Is it possible to do a screenshot of the terminal interacting with the device? It would help to understand exactly what you're trying to do.
 
Recall that most PC comms programs drive the UART directly and don't bother with the lame BIOS interface.
The better ones use interrupt-driven communications.
 
Success! So I was a little confused about how I was going to make those connections without hacking up a cable.. then I realized since I am not using the handshake signals at all on my end, I figured it wouldn't matter at which end of the cable I connect those signals. I'm using a DB9 connection, so I combined pins 1,4,6 and 7,8 at my end on my PCB. Now the TYPE and COPY commands work as expected over the COM port. It does seem the ^Z ends the transfer as expected. Obviously this would be a problem transferring binary files.. I kind of doubt it, but is there an escape sequence that might work? Otherwise I'll see if I can document how that fastlynx CTTY/DEBUG approach works.
 
How about COPY with the /B option? But really, if you're going to transfer files over the thing, you really need some sort of protocol on both ends (e.g. XMODEM).
 
Last edited:
nullvalue said:
It does seem the ^Z ends the transfer as expected.
Click to expand...
^Z works because the specific code at the receiving end is expecting a text file AND has been programmed to know that ^Z signals end-of-file for a text file.

nullvalue said:
Obviously this would be a problem transferring binary files.. I kind of doubt it, but is there an escape sequence that might work?
Click to expand...
To transfer binary files appended by an escape sequence, both the sending and receiving code have to be aware of the particular escape sequence (whatever is decided on).

Chuck(G) said:
How about COPY with the /B option?
Click to expand...
The problem I see is that COPY at the receiving end (because of /B, no longer looking for ^Z) will not know when end-of-file has occurred. It will just sit there waiting for more data, unless perhaps it decides end-of-file because no bytes have been received after XX seconds.

Chuck(G) said:
But really, if you're going to transfer files over the thing, you really need some sort of protocol on both ends (e.g. XMODEM).
Click to expand...
Yes, some will perhaps, during the negotiation/setup phase (before actual data is transferred), have the sender pass the byte count to the receiver. The receiving code therefore knows exactly when the file ends. Binary and text files are treated the same.

Perhaps a file transfer protocol that encodes all files (binary and text) to a particular text format. 7-bit operation possible. The receiving code decodes. A specific byte, or byte sequence, as dictated by the particular file transfer protocol, signals end-of-file. A disadvantage is that no 'xx% received' progress indication can be displayed at the receiving end.

Things like:
- software handshaking;
- passing of the file name during the negotiation/setup phase;
- functionality at receiver to detect 'bad' data (corrupted bytes, missing bytes, additional bytes);
- if 'bad' data detected, functionality to request a resend;
- timeout functionality to allow for things 'falling over'.
- etc.
 
That was the other thing--simply transfer the file as ASCII hex and decode at the receiving end. It doubles the size of the payload however.
BINHEX and UUENCODE/UUDECODE are available for DOS.
 
Thanks for the suggestions everyone. I knew transferring without a protocol could only be taken so far. So, COPY /B does in fact work, but transfer is ended the moment it sees a ^Z in the stream. File saves and everything, it's just chopped off at that point. Oh I should also mention, 9600bps was too fast and I was getting errors during a transfer with somewhat larger files. 2400 seems to work perfect - that's on a 486 writing to hard disk. I'd imagine I would really have to slow it down for something like an 8088 writing to a floppy..

Oh yeah, I forgot about UUENCODE. Wonder if I could write a QBASIC implementation. However at that point I may as well do a QBASIC implementation of XMODEM.. that was kind of the thought with this... bootstrap over a BASIC file in text mode, then the BASIC app could handle binary transfers.
 
Last edited:
nullvalue said:
So, COPY /B does in fact work, but transfer is ended the moment it sees a ^Z in the stream.
Click to expand...
You must be writing of what is happening at the receive side, because the /B (i.e. binary mode) on the sending side is not meant to stop at a ^Z byte.

( E.g. /B is used to concatenate binary files: COPY SOURCE_1.BIN /B + SOURCE_2.BIN /B JOINED.BIN /B )

nullvalue said:
Oh I should also mention, 9600bps was too fast and I was getting errors during a transfer with somewhat larger files. 2400 seems to work perfect - that's on a 486 writing to hard disk. I'd imagine I would really have to slow it down for something like an 8088 writing to a floppy..
Click to expand...
Or use 'real' handshaking (flow control), hardware or software, between the two ends.
 
Modem7 has it right. On DOS, when the disk writes, the COM port is "blind" because reading and writing under DOS are what is known as a "blocking" service. Handshaking and buffering will make things work right.
 
You must log in or register to reply here.
Back
Top