If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

DOS 6.22 Copy Command & device

I have an ASR 33 teletype which I have connected to my IBM XT through the COM1 port. The reason being, I want to make files into paper tapes and convert paper tapes to files.

I have successfully made files into paper tapes. All I did was set the COM1 as
MODE COM1:110,N,8,2
COPY TEST.BIN/B COM1:

I figured that all I had to do was reserve this idea to make paper tapes into files
MODE COM1:110,N,8,2
COPY COM1: TEST.BIN/B

This works a little. What happens is that the XT will accept the first 100 or so bytes and then stop and make the TEST.BIN file, but the paper tape has not finished. I suspect that what is happening is that the COM buffer filled and the process stopped. My question is how can I either make this buffer? larger or do something else that will save this paper tape as a file. Thanks Mike

Do you know how the cable is physically wired between the ASR 33 and the PC?

I think the issue is one of handshaking (i.e. the PC telling the ASR 33 when to stop sending characters - because the buffer is getting full - and when to start again).

There are two types of handshaking - XON/XOFF and hardware.

XON/XOFF is implemented by the PC sending two special characters back to the teletype (would you believe they are called XON and XOFF) and expecting the ASR 33 to obey them (i.e. start and stop sending characters respectively).

Hardware handshake involves the PC setting/clearing a hardware wire from the PC to to the ASR 33. If this is not physically wired in your cable - it won't work.

I remember in very old versions of DOS - I had to write my own program in TURBO BASIC (TBASIC). BASIC's equivalent of the MODE command supported hardware handshake, but the native DOS MODE command didn't (or something like that).

I'll add that there are two types of hardware handshake--RTS/CTS and DTR/DSR. AFAIK, the PC's 8250 UART supports both, but, as Dave says, you have to have your cable set up correctly and the TTY must be able to assert the proper signals. Normally, an ASR33 should be capable of keeping up with a 10 cps (110 whatevers) data stream--the only real delay is in the CR LF sequences. In the old days, we'd run our TTYs with line endings that looked like CR-LF-RO-RO (RO=7Fh, known as "rubout") to allow for the extra time to return the carriage and advance the paper feed one line.

As far as buffer sizes go, I'd advise using a communications program, such as Procomm Plus (available from the SIMTEL20 archive). It has its own buffering and UART drivers, which are hugely better than the default BIOS ones.

The ASR33 has a 20 ma loop. I built a RS232 to 20 ma converter. But for simplicity I use CTS/RTS and the ASR33 just shorts the two wires. I'll have to look into the ASR33 circuits and see if there is a way to stop the reader and wait when the handshaking asks. Right now the reader just blasts the entire file without waiting at all. There was no need for handshaking, because I can not type very fast.

I'm currently looking at Kermit to try and receive a file, but not being that familiar with Kermit, that may take awhile. Thanks for the pointers. Mike

Looks like what I'd have to do to control the paper tape reader would be to control the Distributor Clutch Trip Coil. When this relay is picked up, the reader (and keyboard) can send data. When the relay drops out, the distributor will finish the last byte of data and stop. The coil is 120 VAC and will need some interface to effectively control it. Mike

To be perfectly honest, I'm not sure. What seems to happen is that after a while the IBM XT stops to empty the com buffer to the file, and then stops. I'll try stopping the data flow prior to this happening and see what occurs. Mike

As mentioned I'd be very surprised if the PC couldn't keep up at 110 bd and handshaking is involved. Does it always stop at the same place? I'm with gslick that it might well be a character in the data stream (e.g. CTL-Z) that's terminating the transfer.

Create a paper tape that has all of the characters from 0x00 to 0xFF on it (assuming an 8-bit paper tape) and try and read that back into the PC.

Create another tape 'backwards' (i.e. with the data from 0xFF to 0x00) and try and read that back in. What do you see in the file that the PC has read (if anything); and can you get a 'sense' of where the PC stopped reading the paper tape?