Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: DOS 6.22 Copy Command & device

  1. #1
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    979

    Default 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

  2. #2
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,797

    Default

    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.

    Also, you need some software in the PC - this is also configured by the DOS MODE command. Have a look at https://technet.microsoft.com/en-gb/.../bb490932.aspx. Obviously, it depends on which version of the Microsoft OS you are running.

    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).

    Dave

  3. #3
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    27,308
    Blog Entries
    20

    Default

    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.

  4. #4
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    979

    Default

    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

  5. #5
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    979

    Default

    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

  6. #6
    Join Date
    Feb 2011
    Location
    NorthWest England (East Pondia)
    Posts
    1,822
    Blog Entries
    10

    Default

    Sorry, does the PC really struggle to keep up at 110 baud? What happens if you disable flow. Do you loose characters?
    Dave
    G4UGM

    Looking for Analog Computers, Drum Plotters, and Graphics Terminals

  7. #7
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    979

    Default

    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

  8. #8
    Join Date
    Dec 2010
    Location
    Seattle, WA
    Posts
    1,758

    Default

    If you COPY /B COM1: TEST.BIN how does it know when to terminate the copy?

    Does it terminate on a Ctrl-Z in the data stream, or on some change in the port status lines?

  9. #9
    Join Date
    Dec 2005
    Location
    Toronto ON Canada
    Posts
    6,909

    Default

    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.

  10. #10
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    1,797

    Default

    Yes, gslick raises a good point...

    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?

    Dave

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •