Discussion:
Basic-Plus vt100 cursor control
(too old to reply)
Nootrac90
2016-08-22 01:14:26 UTC
Permalink
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
Dennis Boone
2016-08-22 02:07:12 UTC
Permalink
Post by Nootrac90
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
l***@gmail.com
2016-09-15 07:53:18 UTC
Permalink
Hardcoding escape codes is usually the wrong solution...
You have no choice, when RSTS/E doesn’t provide any curses-type functionality.
Johnny Billquist
2016-09-15 12:14:34 UTC
Permalink
Post by l***@gmail.com
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
Johnny Billquist
2016-08-22 17:03:48 UTC
Permalink
Post by Nootrac90
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
Nootrac90
2016-09-18 19:44:00 UTC
Permalink
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.
Dennis Boone
2016-09-18 21:54:57 UTC
Permalink
Post by Nootrac90
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
Johnny Billquist
2016-09-19 09:57:37 UTC
Permalink
Post by Dennis Boone
Post by Nootrac90
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
John Santos
2016-09-19 21:57:16 UTC
Permalink
Post by Johnny Billquist
Post by Dennis Boone
Post by Nootrac90
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.
Loading...