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)

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)

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)

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)

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)

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)

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)

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)

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)