1. Forum
  2. Usenet
  3. COMP.OS.RSTS

  • Basic-Plus vt100 cursor control

    From Nootrac90@21:1/5 to All on Sun Aug 21 18:14:26 2016
    Does anybody remember how to do vt100 cursor control using Basic-Plus?

    I've seen lists of the codes, but can't seem to remember how to make it work. I know it involves sending escape codes, but not how.

    Any help would be greatly appreciated, especially example code I could play with.

    Thanks

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dennis Boone@21:1/5 to All on Sun Aug 21 21:07:12 2016
    Does anybody remember how to do vt100 cursor control using Basic-Plus?

    I've seen lists of the codes, but can't seem to remember how to make
    it work. I know it involves sending escape codes, but not how.

    Hardcoding escape codes is usually the wrong solution, but it's
    not hard. In most BASIC dialects, you can make an escape character
    with something like CHR$(27). For a VT100, cursor positioning looks
    like an escape, a left square bracket, the row number, a semicolon,
    the column number, and the letter H.

    De

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johnny Billquist@21:1/5 to All on Mon Aug 22 19:03:48 2016
    On 2016-08-22 03:14, Nootrac90 wrote:
    Does anybody remember how to do vt100 cursor control using Basic-Plus?

    I've seen lists of the codes, but can't seem to remember how to make it work. I know it involves sending escape codes, but not how.

    Any help would be greatly appreciated, especially example code I could play with.

    Cursor positioning for a VT100 is easy. But it will be specific to VT100
    and compatible terminals.

    PRINT CHR$(27+128)+"["+NUM1$(row)+";"+NUM1$(col)+"H";

    should do it. If I remember right, you need to have the high bit set for
    the escape character in RSTS/E, or else the terminal driver will replace
    the escape with a dollar sign.

    Johnny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From lawrencedo99@gmail.com@21:1/5 to Dennis Boone on Thu Sep 15 00:53:18 2016
    On Monday, August 22, 2016 at 2:07:17 PM UTC+12, Dennis Boone wrote:
    Hardcoding escape codes is usually the wrong solution...

    You have no choice, when RSTS/E doesn’t provide any curses-type functionality.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johnny Billquist@21:1/5 to lawrencedo99@gmail.com on Thu Sep 15 14:14:34 2016
    On 2016-09-15 09:53, lawrencedo99@gmail.com wrote:
    On Monday, August 22, 2016 at 2:07:17 PM UTC+12, Dennis Boone wrote:
    Hardcoding escape codes is usually the wrong solution...

    You have no choice, when RSTS/E doesn’t provide any curses-type functionality.

    Uh.... Curses are just a software library. Nothing would prevent you
    from implementing the same thing in RSTS/E. There is nothing magical
    about it that would prevent it to be done in RSTS/E.

    That said, I already provided an (hopefully) correct solution to the OP.
    And if anything is not as assumed, then of course, things will not work
    as expected.

    Johnny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dennis Boone@21:1/5 to All on Sun Sep 18 16:54:57 2016
    Between Dennis and Johnny, I got the idea of how to make it work.
    I ended up using chr$(155) for the escape code (27+128) and had
    to switch terminal emulator software to make the codes do what I
    expected them to do.

    If memory serves, setting the 8th bit on the ESC (155) gives you the
    CSI character referred to by all the references, and is equivalent
    to the ESC plus the [. Doing it this way assumes an 8-bit-clean path
    from the program to the terminal emulator.

    De

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nootrac90@21:1/5 to All on Sun Sep 18 12:44:00 2016
    Between Dennis and Johnny, I got the idea of how to make it work. I ended up using chr$(155) for the escape code (27+128) and had to switch terminal emulator software to make the codes do what I expected them to do.

    Thank you both for the nudge in the right direction with the coding.

    David Moisan in one of his blog entries, mentioned using Tera Term successfully for its VT100 emulation.

    Thanks for your help.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johnny Billquist@21:1/5 to Dennis Boone on Mon Sep 19 11:57:37 2016
    On 2016-09-18 23:54, Dennis Boone wrote:
    Between Dennis and Johnny, I got the idea of how to make it work.
    I ended up using chr$(155) for the escape code (27+128) and had
    to switch terminal emulator software to make the codes do what I
    expected them to do.

    If memory serves, setting the 8th bit on the ESC (155) gives you the
    CSI character referred to by all the references, and is equivalent
    to the ESC plus the [. Doing it this way assumes an 8-bit-clean path
    from the program to the terminal emulator.

    That is true in a general sense, in that CSI is (155) in Latin-1 and DEC
    MCS. However, as I said before, RSTS/E is playing tricks. If you print
    an ESC (33), the RSTS/E terminal driver will print out a '$' instead In
    order to print the actual ESC character, you need to set the high bit.
    RSTS/E will strip it off, but print the ESC literally. So no, in this
    case you are *not* getting a CSI. You actually cannot print a CSI
    character from RSTS/E, unless you set the terminal in some special mode perhaps.

    All from memory, as usual, but I think I remember this right.

    Johnny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Santos@21:1/5 to All on Mon Sep 19 17:57:16 2016
    In article <nrocqi$k1r$1@Iltempo.Update.UU.SE>, bqt@softjar.se says...

    On 2016-09-18 23:54, Dennis Boone wrote:
    Between Dennis and Johnny, I got the idea of how to make it work.
    I ended up using chr$(155) for the escape code (27+128) and had
    to switch terminal emulator software to make the codes do what I expected them to do.

    If memory serves, setting the 8th bit on the ESC (155) gives you the
    CSI character referred to by all the references, and is equivalent
    to the ESC plus the [. Doing it this way assumes an 8-bit-clean path
    from the program to the terminal emulator.

    That is true in a general sense, in that CSI is (155) in Latin-1 and DEC
    MCS. However, as I said before, RSTS/E is playing tricks. If you print
    an ESC (33), the RSTS/E terminal driver will print out a '$' instead In
    order to print the actual ESC character, you need to set the high bit.
    RSTS/E will strip it off, but print the ESC literally. So no, in this
    case you are *not* getting a CSI. You actually cannot print a CSI
    character from RSTS/E, unless you set the terminal in some special mode perhaps.

    All from memory, as usual, but I think I remember this right.

    Johnny

    There is a binary output mode that can be applied to the write, that will
    pass all characters as is (including retaining the sign bit on the CSI
    if the terminal is eight-bit enabled.) This is overloaded on the
    "record" keyword (value = 4096%, IIRC.) The record keyword tells the
    i/o system what disk block to read or write (hence the name), but would otherwise be meaningless on terminal I/O, so used to encode special flags instead. (Remember, it's trying to fit all this in 16 bits!)


    --
    John Santos
    Evans Griffiths & Hart, Inc.

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