• questions about implementing a RDR: device

    From Robert Kincaid@21:1/5 to All on Thu Sep 23 16:09:32 2021
    I've been tinkering around with CP/M 2 and an RC2014 system (SC114 + ACIA boards and even the native SC114 bitbang I/O). I've been successful at getting LPT:, LST: and PUN: devices working. Basically anything that outputs. But I'm kind of stumped with
    regards to RDR: and it's associated devices. Is this polled by CP/M? If so when/how? There is a console status call in bios, but no equivalent I can see with regards to non-console reader devices and I'm kind of stumped on how it works. Does anybody have
    experience with this and can provide some clues? I've tried just implementing something assuming the RDR: is polled, but it doesn't seem to work. Thoughts?

    Thanks,
    Robert

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy McLaughlin@21:1/5 to All on Thu Sep 23 16:38:21 2021
    RDR and PUN are leftovers from the early days when paper tape was still common.

    The devices have BIOS entries but it's up to the BIOS developer to decide how to implement them.

    Please not there is no status entry. Normally when called the hang until the operation is complete like CONIN and CONOUT.

    I have used PUN as a second printer.


    Randy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Kincaid@21:1/5 to All on Fri Sep 24 12:56:04 2021
    I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jack Strangio@21:1/5 to Robert Kincaid on Sat Sep 25 00:33:46 2021
    Robert Kincaid <rhkincaid@gmail.com> writes:
    no equivalent I can see with regards to non-console reader devices an=
    d I'm kind of stumped on how it works. Does anybody have experience with th= is and can provide some clues? I've tried just implementing something assum= ing the RDR: is polled, but it doesn't seem to work. Thoughts?

    All of the input devices need to be actively polled by an application to function. An alternative is to have the input device interrupt driven. But
    that will only store characters in a buffer.

    An application of some description (even a TSR) will still need to
    specifically take control of that interrupt or actively poll the buffer
    itself for available characters.

    CP/M as such (except when the CCP is active) does not monitor any input devices.

    Jack
    --
    "My mother says I don't know what good, clean fun is.
    She's right. I don't know what good it is."

    - Laugh-In, 1968

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Fri Sep 24 18:17:41 2021
    CP/M 2 added a LST: status, but nothing for RDR: or PUN: - those were blocking interfaces. An alternative some people used was to implement device redirection ("iobyte"), and then switch the console around to other devices. That can get messy, though.

    CP/M 3 implements full polling for CON:, LST:, and AUX: (formerly RDR:/PUN:), plus extended redirection.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to Robert Kincaid on Sat Sep 25 05:42:33 2021
    Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
    I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.


    Implement the I/O Byte!

    If you ever want to do serial communication, you will need it.
    The READER/PUNCH is mostly unusable without it.


    It works in this way:
    You switch the input to BAT:
    You use CONST for polling the READER
    You use CONIN for reading from the READER
    You switch the input back to TTY:

    This is very fast, just set the relevant bits in the I/O Byte.
    Normally you save the existing state at startup and restore on exit.

    *Kermit* is one of the best examples.

    In its "generic" implementation,
    it does *everyhing* only using the I/O Byte!


    Want an example implementation?

    In my BIOS, I have done it the following way...


    1) Addidional jump verctors:
    ============================

    [...]

    ;*****************************************************
    ; jump vector for indiviual routines
    ;
    JP BOOT
    WBOOTE: JP WBOOT
    JP CONST
    JP CONIN
    JP CONOUT
    JP LIST
    JP PUNCH
    JP READER
    JP HOME
    JP SELDSK
    JP SETTRK
    JP SETSEC
    JP SETDMA
    JP READ
    JP WRITE
    JP LISTST
    JP SECTRAN
    ;
    JP CONOST ; <<< Console output status
    JP AUXIST ; <<< Reader input status
    JP AUXOST ; <<< Punch output status
    ;

    [...]


    2) Implementing the I/O Byte:
    =============================

    [...]

    ;*****************************************************
    ;
    VCONST:
    DW S1RXSE ; TTY:
    DW S1RXSE ; CRT:
    DW AUXIST ; BAT:
    DW NONST ; UC1:
    VCONIN:
    DW S1RXIE ; TTY:
    DW S1RXIE ; CRT:
    DW READER ; BAT:
    DW NONIN ; UC1:
    VCONOST:
    DW S1TXSE ; TTY:
    DW S1TXSE ; CRT:
    DW LISTST ; BAT:
    DW NONST ; UC1:
    VCONOUT:
    DW S1TXOE ; TTY:
    DW S1TXOE ; CRT:
    DW LIST ; BAT:
    DW NONOUT ; UC1:
    ;
    VAUXIST:
    DW S1RXSE ; TTY:
    DW S2RXS ; PTR:
    DW S2RXS ; UR1:
    DW NONST ; UR2:
    VREADER:
    DW S1RXIE ; TTY:
    DW S2RXI ; PTR:
    DW S2RXIN ; UR1:
    DW NONIN ; UR2:
    ;
    VAUXOST:
    DW S1TXSE ; TTY:
    DW S2TXST ; PTP:
    DW NONST ; UP1:
    DW NONST ; UP2:
    VPUNCH:
    DW S1TXOE ; TTY:
    DW S2TXOTE ; PTP:
    DW NONOUT ; UP1:
    DW NONOUT ; UP2:
    ;
    VLISTST:
    DW S1TXSE ; TTY:
    DW S1TXSE ; CRT:
    DW S2TXST ; LPT:
    DW NONST ; UL1:
    VLIST:
    DW S1TXOE ; TTY:
    DW S1TXOE ; CRT:
    DW S2TXOTE ; LPT:
    DW NONOUT ; UL1:
    ;
    ;
    CONST:
    XOR A
    LD HL,VCONST
    JR IODISP
    CONIN:
    XOR A
    LD HL,VCONIN
    JR IODISP
    CONOST:
    XOR A
    LD HL,VCONOST
    JR IODISP
    CONOUT:
    XOR A
    LD HL,VCONOUT
    JR IODISP
    ;
    AUXIST:
    LD A,1
    LD HL,VAUXIST
    JR IODISP
    READER:
    LD A,1
    LD HL,VREADER
    JR IODISP
    ;
    AUXOST:
    LD A,2
    LD HL,VAUXOST
    JR IODISP
    PUNCH:
    LD A,2
    LD HL,VPUNCH
    JR IODISP
    ;
    LISTST:
    LD A,3
    LD HL,VLISTST
    JR IODISP
    LIST:
    LD A,3
    LD HL,VLIST
    JR IODISP
    ;
    IODISP: LD B,A
    OR A
    LD A,(IOBYTE)
    JR Z,IODISC
    IODISL: RRCA
    RRCA
    DJNZ IODISL
    IODISC: AND 3
    RLCA
    LD D,B
    LD E,A
    ADD HL,DE
    LD A,(HL)
    INC HL
    LD H,(HL)
    LD L,A
    JP (HL)
    ;

    [...]

    ;*****************************************************
    ;
    NONIN: LD A,1AH
    RET
    ;
    NONST: XOR A
    NONOUT: RET

    [...]


    The source speaks for itself :-)
    Martin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to All on Sat Sep 25 05:08:39 2021
    Note: if you are going to add non-standard JMPs to the BIOS vectors, you may not need iobyte as your program(s) can just make BIOS calls for RDR:/PUN: (AUX:) status. Of course, those programs become non-standard then (not very portable to other CP/M
    implementations). Even using iobyte, that limits the platforms your programs can run on (many did not implement iobyte).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to Douglas Miller on Sat Sep 25 15:21:58 2021
    Am 09/25/2021 02:08 PM, Douglas Miller schrieb:
    Note: if you are going to add non-standard JMPs to the BIOS vectors, you may not need iobyte as your program(s) can just make BIOS calls for RDR:/PUN: (AUX:) status. Of course, those programs become non-standard then (not very portable to other CP/M
    implementations). Even using iobyte, that limits the platforms your programs can run on (many did not implement iobyte).


    Thanks for your note!

    The part with the 3 extra entries in my BIOS jump table
    was inserted very late without much explanation.

    I just wanted to include this as an optional, but very
    non-standard possibility.

    In my case, these JMPs were already included in the stock BIOS
    and I took them over only for compatibility.


    If one really wants to extend his BIOS with more advanced features,
    I suggest at least reading Section 2 (the BIOS Overview)
    in the "CP/M Plus System Guide".


    Martin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Schultz@21:1/5 to Martin on Sat Sep 25 14:12:54 2021
    On 9/24/21 10:42 PM, Martin wrote:
    Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
    I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.


    Implement the I/O Byte!

    I dug around my floppy disk images and found where I once did this for CP/M-68K. Pretty much the same way.

    --
    http://davesrocketworks.com
    David Schultz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to David Schultz on Sun Sep 26 03:07:33 2021
    Am 09/25/2021 09:12 PM, David Schultz schrieb:
    On 9/24/21 10:42 PM, Martin wrote:
    Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
    I've managed to get it working as intended. But if anyone *wants* to
    add any additional help (possibly for others) feel free.


    Implement the I/O Byte!

    I dug around my floppy disk images and found where I once did this for CP/M-68K. Pretty much the same way.


    Hi, David!

    Just (re)visited your new CP/M-68K site on: <http://davesrocketworks.com/electronics/cpm68/index.html>

    There is something wrong with the simulator zip-file <http://davesrocketworks.com/electronics/cpm68/cpmsim.zip>

    This file is very out of date!

    It is the same as the very first version from 2014:
    -rw-r--r-- 1 martin users 924309 Apr 27 2014 cpmsim.zip

    These are the newer versions I have:
    -rw-r--r-- 1 martin users 924891 Jun 24 2016 cpmsim.zip
    -rw-r--r-- 1 martin users 924894 Feb 6 2018 cpmsim.zip

    Martin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Schultz@21:1/5 to Martin on Sun Sep 26 06:53:50 2021
    On 9/25/21 8:07 PM, Martin wrote:
    This file is very out of date!

    It is the same as the very first version from 2014:
    -rw-r--r-- 1 martin users 924309 Apr 27  2014 cpmsim.zip

    These are the newer versions I have:
    -rw-r--r-- 1 martin users 924891 Jun 24  2016 cpmsim.zip
    -rw-r--r-- 1 martin users 924894 Feb  6  2018 cpmsim.zip

    Martin

    Thanks. I figured out what happened. I have a directory where I keep all
    of the web page files and that is what I copied to the new server. Unfortunately, when I updated cpmsim.zip (in its working directory), I
    didn't copy it over to the space for the web pages when I updated the
    server.

    It should be better now.


    --
    http://davesrocketworks.com
    David Schultz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)