Image Map Image Map
Page 3 of 14 FirstFirst 123456713 ... LastLast
Results 21 to 30 of 135

Thread: REMEX Paper Tape reader

  1. #21
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    I found a method that works for EDIT, I still can not make PIP work. Here is what does work in EDIT.

    .R EDIT
    *RIMTRY.RA<
    #A

    This creates a new file and the input is APPENDED.

    C:/>copy B:RIMTRY.RA COM1:/B

    The front panel lights blinked then stopped and restarted. I was not hopeful of success, but it worked. Maybe tomorrow I'll try to make PIP work. Mike

  2. #22
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    Well.... I can not get PIP to do what I want. That is copy a serial input to a file. This seems logical

    .R PIP
    *RIMTST.RA<TTY:/B

    But it doesn't do any thing. The PTR device is not active as a device handler on my system, so I can not try that. So, I'm giving up on it for now. I can get EDIT to do this, at least Something works. I can get a program that I worked on in SIMH onto a floppy disk transfer it to me XT and with the COM1: port input it to EDIT and save it as a file.

    You know I fell like a kid who just got back in school after summer vacation. I have to re learn a bunch of stuff, including how to use PAL8. A bunch of reading and horsing around and I seem to be proficient again, but I'm having trouble with the /L option. I thought that I could assemble a file and load it into core like this,

    .R PAL8
    *RIMTST.BN<RIMTST.PA/L=1000

    but the machine just seems to stop and do nothing. The /G option works

    .R PAL8
    *RIMTST.BN<RIMTST.PA/G=1000

    So maybe I'm remembering what /L does incorrectly or something else is wrong, probably with my thinking. I also had a brief brain fart, thinking that something was wrong with PAL8, but it was me. I had entered the binary file extension as .PA rather than .BN. This didn't work at all and caused me with an hour or so of confusion. Had to walk the dog and during the pleasure autumn walk it occurred to me what I did. Anyway I'm getting closer to attempting a read on the REMEX. Mike

  3. #23
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    Well..... I suffered another hardware failure this time on my 12 channel I/O board. After I found the problem and repaired it, and weeding out one program error, I loaded LBAA the BINARY LOADER from the REMEX to the PDP8E, with no errors. This proves that the REMEX, the M863 and connections work.

    Now what I want to do is replace the original DEC PTR device handler with software that will communicate with the REMEX. Currently the PTR device handler is loaded, but is inactive. I have been looking for a way to inspect the PTR device handler software, so that I could get and idea how to write a replacement, but so far have not found anything or a way to see the software. I found some documents on the device handlers that should help. But I would really like to see the DEC PTR handler code. Mike

  4. #24
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,150

    Default

    Just got back from a business trip and caught up with your progress - but about to go on another one...

    Something in my water seems to be telling me XON/XOFF is not being supported correctly. DEC tended to use XON/XOFF characters to handle data flow - but I don't think the DOS COPY command handles this at all. So, if your 8 sends an XOFF (please don't send me any more characters until I tell you to do) but the DOS COPY command does - they will (most liekly) disappear.

    If you use a terminal emulator (or something similar) and can set it to support XON/XOFF flow control - if you chose the right product you should be able to open a text file and send it to the 8 from within the terminal emulator. The terminal emulator should (then) suppor the XON/XOFF flow control and all should be well with the world.

    Dave

  5. #25
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    I was also thinking along these lines. I was looking for an external handshake, like CTS/RTS, which I am familiar. Never had any experience with XON/XOFF, which is handshaking in the data stream? I wonder why EDIT works without the XON/XOFF? I'll look a little closer at KERMIT, which I use as the terminal. I'm sure that I can send a file from there also, maybe also include the XON/XOFF. In the mean time I'm searching for information regarding the device handlers. The DEC software support manual has a lot of information, and a high level example. But I need something more specific in order to penetrate my thick skull. There must be a way to open up existing device handler code. BUILD has some interesting commands, like LOAD and EXAMINE, but so far I don't have the necessary understanding to use them. Then maybe they are not what I want. Thanks for the help, temperatures have dropped here, 30's, and I was working outside on house repairs, trying to get them done prior to the real cold that is coming.

    Dave I never liked traveling for business. Then when the airlines started all the security stuff, I avoided the airlines as much as possible, but that meant lots of train and car travel. That is all behind me now. A long trip now is done via the Model T, which is much more enjoyable, Thanks for all the help, Mike.
    Last edited by Mike_Z; October 11th, 2018 at 08:00 AM. Reason: clearity

  6. #26
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    Today on one of the RK05 disk images I have, I found PT8E.PA, which is the high speed paper tape reader/punch device handler. Now I have to figure out what is what. Mike

  7. #27

    Default

    XON/XOFF can be tricky to set up to work correctly. If you think about it, the receiving software has to sense that it needs to tell the other end to stop sending and then send the XOF. Then the XOFF goes through the data stream to the other end where the receiving software has to do whatever it takes to stop the data flow temporarily. At higher speeds if the buffer sizes are not set up correctly you can mysteriously drop bytes in not always repeatable ways. If that starts to happen you can either increase the buffer sizes or decrease the data rates or both. If you have access to what's going on with the actual data buffers and the pointers in to same, you could also opt to have the XOFF sent earlier when using higher data speeds but this often isn't possible with canned terminal emulation software.
    Last edited by DDS; October 12th, 2018 at 03:27 PM.
    "It's all bits on the bus, Cowboy! It's all bits on the bus!" -- Tom Beck, #1ESS Instructor, Southern Bell Opa Locka Training Center

  8. #28
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    Still no luck with the XON/OFF, no matter. I've been studying the PT8E device handler. Looks like it only does two things. Either it punches a 128 word block or reads a 128 word block. Seems to use a buffer, which the calling program must know about. If when reading a block that is less than 128 words, the remainder is packed with zero's. The handler initially waits for the user to press a key. This allows the user to get the tape ready and it also looks for CTRL C, which stops everything. The read packs 3 bytes into 2 12 bit words. Kinda odd, Word 1 is character 3 0-3 bits and character 1, Word 2 is character 3 4-7 bits and character 2. There is also some error checking. The fatal error is mixing up read and punch. I have the original device handler written into PAL8 code and it assembles. I need to study it some more to better understand the code. Then separate the needed stuff from the punch routine. The guy that wrote this has a sense of humor in his comments. He used statements like "do some common crap", "look at the glorious lack of overlap". I think I can make this work. I have to think about ways of testing this, prior to attempting to install it with build. Mike

  9. #29
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    2,150

    Default

    If you are using Kermit, I have seen the command "set flow xon/xoff" and "set flow ?" To query the setting.

    See http://kermitproject.org/onlinebooks...oskermit2e.pdf

    Dave

  10. #30
    Join Date
    Dec 2013
    Location
    Near Milwaukee Wisconsin
    Posts
    1,064

    Default

    I've been reading as much as I can find on Device Handlers. It tells me that the handler has to have a specific format, that is a Header Block and the Handler Body. I've been looking for how the header block is used. Does the body code need any of the header information? Does the calling program need it. I'm a little confused. Seems that some how the calling program finds the handler it needs then loads it at *0 and *200, finds the offset address it needs for the function wanted and JMS to it. Does this sound correct? Would the handler body code need anything recorded in the header?

    Other than that I think all I need to change in the PT8E code is write routines for RFC, RSF and RRB that will address the REMEX rather than the Hi Speed Reader Punch. Then if space is needed I could eliminate some of the punch code. Still reading, thinking and planning what to do. Thanks Mike

    Dave, thanks for the reference. I believe I have a paper copy of this. Just have not taken any time to look into it some more. Supposed to be colder today, so I'll stay in and maybe look at it. Mike

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
  •