1 Jan
2017
1 Jan
'17
2:39 p.m.
Would someone with a real DEC VT terminal be so kind and help settle, once and for all,
the question about how they behave with respect to line-wrapping, exactly? It is something
that isn't covered by any standard, nor by any of DEC's manuals, and there is a
scarcity of information online that is not vague repetition of folklore.
There are emulators, of course, but these do not agree with one another to the point that
they can be trusted, and are probably just copying each other in any case. It seems that
some ground truth would be welcome, for the benefit of both application and emulator
writers.
First, the problem: A VT100, when in "auto-wrap" mode, will wrap text from one
line to the next in a peculiar way, sometimes called "soft-wrap" or "the
VT100 glitch". When the terminal receives a printable character with the cursor in
the last column, the character is put at that location but the cursor remains in place.
Instead, the terminal enters a pending wrap state, which causes the cursor to wrap before
next printable character is displayed. This behaviour is widely known.
What isn't widely known are the finer points:
* What control codes will cancel the wrap state?
* What cursor position is reported in the wrap state?
* Do any operations behave differently in the wrap state?
* Is the wrap state saved/restored by the save/restore cursor codes?
and so on. Every emulator programmer seems to have a different answer to these questions.
If you have a VT100, VT220 or later model (compatibles like Wyse are also of interest) and
have a spare moment, I'd be most grateful if you would download and run
https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c
in that terminal, and send me the resulting output. (Redirect stdout to save the report.)
The test program is not comprehensive but would give us a good idea of the rules.
Current results, right now only from various emulators, are found in
https://raw.githubusercontent.com/mattiase/wraptest/master/results.txt
1 Jan
1 Jan
3:20 p.m.
On 01/01/2017 02:39 PM, Mattias Engdeg?rd wrote:
Would someone with a real DEC VT terminal be so kind
and help settle, once and for all, the question about how they behave with respect to
line-wrapping, exactly? It is something that isn't covered by any standard, nor by any
of DEC's manuals, and there is a scarcity of information online that is not vague
repetition of folklore.
The terminals SRM did cover this from the VT220 on. The transition from
VT100 and related add on versions to the
monolythic VT220 required setting standards for all terminals as up to
that point it was NOT consistent within VT100
models or prior to VT100 (VT05 and VT52).
There are emulators, of course, but these do not agree
with one another to the point that they can be trusted, and are probably just copying each
other in any case. It seems that some ground truth would be welcome, for the benefit of
both application and emulator writers.
First, the problem: A VT100, when in "auto-wrap" mode, will wrap text from one
line to the next in a peculiar way, sometimes called "soft-wrap" or "the
VT100 glitch". When the terminal receives a printable character with the cursor in
the last column, the character is put at that location but the cursor remains in place.
Instead, the terminal enters a pending wrap state, which causes the cursor to wrap before
next printable character is displayed. This behaviour is widely known.
What isn't widely known are the finer points:
* What control codes will cancel the wrap state?
* What cursor position is reported in the wrap state?
* Do any operations behave differently in the wrap state?
* Is the wrap state saved/restored by the save/restore cursor codes?
and so on. Every emulator programmer seems to have a different answer to these questions.
All of that is due to either not understanding weather the terminal
setup for vt100 is set to wrap or
the ansi controls were setting it to wrap. Further the various flavors
of VT10X did not always agree.
plus over time there were several firmware changes to correct errors
that may or may not have
had odd effects.
General form for wrap was the characters would pole at the end with the
cursor set there.
If line-wrap were enabled the excess characters for that line would wrap
to the next line
as they exceed the line length. This was generally true for 80 char
lines but not always for
132 char lines and double width (40 char) lines where those were
implementation (model)
dependent.
If you have a VT100, VT220 or later model (compatibles
like Wyse are also of interest) and have a spare moment, I'd be most grateful if you
would download and run
Be very wary as the setup to the test must be specific. Also the exact
model must be known.
Much of the behaviors depend on:
preset line length (characters per line) (setups screen and control codes.)
Preset screen (lines) (or status line enabled) (setup screen)
Line wrap enabled (setup screen)
Newline/no newline (setup screen)
Soft scroll or jump scroll (setup screen)
prior ANSI (DEC control codes)
VT52, VT100, or VT220 mode
So to validate the action that results one must know what the user setup
screen has preset
and if any other ansi/dec/vt2 control codes have been previously sent.
Also if the cursor was first line
or last tine of in the mid screen area. IF cursor addressing is in use
the cursor position for each case.
https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c
in that terminal, and send me the resulting output. (Redirect stdout to save the
report.)
The test program is not comprehensive but would give us a good idea of the rules.
Current results, right now only from various emulators, are found in
https://raw.githubusercontent.com/mattiase/wraptest/master/results.txt
Most PC based emulators get it wrong. Most really get it wrong on
keyboard to terminal key
alignment. They rarely have the setup screen actions for the keyboard
mapping.
Even the terminals group at DEC and the terminals and printers test
group would tend to argue
what was the intended action vs what it really did, especially during
development. After the
Terminals SRM was developed there would be exceptions galore (for
example DECMate
terminal behavior and the various PCs (Pro, Rainbow, Vaxmate) in
terminal emulation mode.
FYI when using terminal emulation I defer to VT52 as that is both the
simplest to get right
and emulate however most keyboard on PCs still have it seriously wrong.
Plan B is use a real
terminal such as VT100, VT125, VT220, VT320 or Vt340, or the VT1200 as I
have those.
The most reachable is the VT320 (on my CP/M system) and VT340
(PDP-11/73). They get
used as they are smaller than the VT100s I have.
Allison
4:54 p.m.
On Jan 1, 2017, at 2:39 PM, Mattias Engdeg?rd
<mattiase at acm.org> wrote:
Would someone with a real DEC VT terminal be so kind and help settle, once and for all,
the question about how they behave with respect to line-wrapping, exactly? It is something
that isn't covered by any standard, nor by any of DEC's manuals, and there is a
scarcity of information online that is not vague repetition of folklore.
I'll have to see if I can reverse engineer this from the RSTS PRO display code. The
reason is that this was written based on the standard (DEC Std 070). If you can find
that document, that would be great, because it is the authority on how things are supposed
to be done. The VT200 series were supposedly implemented from that spec. The VT100
series predates it.
paul
5:26 p.m.
On 01/01/17 21:54, Paul Koning wrote:
I'll have to see if I can reverse engineer this
from the RSTS PRO
display code. The reason is that this was written based on the
standard (DEC Std 070). If you can find that document, that would be
great, because it is the authority on how things are supposed to be
done. The VT200 series were supposedly implemented from that spec. The
VT100 series predates it. paul
I did see a bunch of DEC STDs sitting on bitsavers but 070 doesn't seem
to be one of them.
My scan is ~400MB (and 1090 pages long!) but if it will help I can see
about making it available.
Antonio
--
Antonio Carlini
arcarlini at iee.org
6:25 p.m.
On 01/01/2017 05:38 PM, Al Kossow wrote:
I'll put my copy on line. It's 70mb, the
mirrors should have it sometime tomorrow.
On 1/1/17 2:26 PM, Antonio Carlini wrote:
Other standards that apply is DEC-STD-062 internationalization, STD-110
Escape code actions, STD-111 terminal synchronization (Xon-Xoff).
Those are available on bitsavers.org.
Allison
I did see a bunch of DEC STDs sitting on
bitsavers but 070 doesn't seem to be one of them.
2 Jan
2 Jan
11:15 a.m.
On Jan 1, 2017, at 6:25 PM, allison <ajp166 at
verizon.net> wrote:
On 01/01/2017 05:38 PM, Al Kossow wrote:
Note that DEC Std 110 (in spite of the higher number) is much older. It describes, very
briefly, the "VT50" escape sequences, and it also mentions the VT05 control
codes (which are not escape sequences).
paul
I'll put my copy on line. It's 70mb, the
mirrors should have it sometime tomorrow.
On 1/1/17 2:26 PM, Antonio Carlini wrote:
Other standards that apply is DEC-STD-062 internationalization, STD-110
Escape code actions, STD-111 terminal synchronization (Xon-Xoff). I did see a bunch of DEC STDs sitting on
bitsavers but 070 doesn't seem to be one of them.
11:32 a.m.
1 jan. 2017 kl. 23.38 skrev Al Kossow <aek at bitsavers.org>:
I'll put my copy on line. It's 70mb, the mirrors should have it sometime
tomorrow.
Many thanks! Very interesting reading; the information I was looking for is on page D-13.
While the document makes the architectural intent reasonably clear, it also says:
It should be noted that existing products vary widely in their
handling of the end-of-line condition in regards to resetting the
Last Column Flag.
For that reason, I would still be very grateful if someone with an actual VT100 or later
would run the previously mentioned test program at
https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c. It should build on
any Posix system and should be easy to adapt in any case. I'll summarise any
contributions.
28 Feb
28 Feb
10:21 a.m.
Some time ago I solicited help investigating how DEC VT terminals handle line wrapping,
mainly for the purpose of accurate emulation. Having received assistance from very kind
people -- many thanks! -- some of the findings have now been summarised at
https://github.com/mattiase/wraptest, in case it would be of help to anyone else.
Data for VT100, VT220 and VT510 have been collected, as well as several emulators
(https://github.com/mattiase/wraptest/blob/master/results.txt). If anyone has access to
other working terminals, VT3xx/VT4xx in particular, I'd be most grateful if you would
take a few minutes to run the test program.
2:10 p.m.
Mattias Engdeg?rd wrote:
Data for VT100, VT220 and VT510 have been collected,
as well as
several emulators
(https://github.com/mattiase/wraptest/blob/master/results.txt). If
anyone has access to other working terminals, VT3xx/VT4xx in
particular, I'd be most grateful if you would take a few minutes to
run the test program.
I have a VT420 set up for my kid to play with. I'll borrow it and
submit a pull request with the results.
1 Mar
1 Mar
1:14 a.m.
Mattias Engdeg?rd wrote:
Many thanks for the VT420 results!
I have a VT220 too, but it's in storage. I can dig it out if necessary,
but I'm hoping someone else can contribute those results.
Note that the setup probably can alter the results. I had "Auto Wrap"
enabled, which is probably what you want.
5:12 a.m.
1 mars 2017 kl. 07.14 skrev Lars Brinkhoff via cctalk <cctalk at classiccmp.org>:
I have a VT220 too, but it's in storage. I can
dig it out if necessary,
but I'm hoping someone else can contribute those results.
Thank you, I already got results for a VT220 from another contributor.
Note that the setup probably can alter the results. I
had "Auto Wrap"
enabled, which is probably what you want.
Quite right. The test actually turns on auto-wrap itself.
I even ran the test on a VT100 emulator in Javascript
(http://www.pcjs.org/devices/pc8080/machine/vt100/), which emulates the VT100 hardware
with the original ROMs. There is a configuration with a VT100 connected to an IBM PC AT,
so after installing Microsoft C on it and porting the test to MS-DOS, I got the same
result as a genuine VT100.
2705
days inactive
2764
days old
12 comments
6 participants
participants (6)
-
a.carlini＠ntlworld.com -
aek＠bitsavers.org -
ajp166＠verizon.net -
lars＠nocrew.org -
mattiase＠acm.org -
paulkoning＠comcast.net