Re: DEC VT100/220 line wrapping semantics sought

[Mattias Engdegård via cctalk]

1 mars 2017 kl. 07.14 skrev Lars Brinkhoff via cctalk :

> 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.

Re: DEC VT100/220 line wrapping semantics sought

[Lars Brinkhoff via cctalk]

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.

Re: DEC VT100/220 line wrapping semantics sought

[Mattias Engdegård via cctalk]

28 feb. 2017 kl. 20.10 skrev Lars Brinkhoff via cctalk :

> I have a VT420 set up for my kid to play with.  I'll borrow it and
> submit a pull request with the results.

That is what I call being a responsible parent.
Many thanks for the VT420 results!

Re: DEC VT100/220 line wrapping semantics sought

[Lars Brinkhoff via cctalk]

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.

Re: DEC VT100/220 line wrapping semantics sought

[Mattias Engdegård via cctalk]

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.

Re: DEC VT100/220 line wrapping semantics sought

[Antonio Carlini]

On 02/01/17 15:45, Noel Chiappa wrote:

Even at 1K pages, it shouldn't be anything like that big, if scanned using
the most space-efficient encoding.

For _manuals_, scan at 300 dpi with Black+White encoding (i.e. 1 bit per
pixel), then store as TIFFs with CCITT Group 4 (fax) compression. That does a
typical page of text in ~45KB or so. So you're about an order of magnitude
high



This manual (which is Rev C 14-APR-1989, and so 2 years older than the 
one Al has made available) was scanned in 2002.


Back then I had access to a Lexmark something or other. The only thing 
I'm certain of is that it was scanned at
600x600 dpi, B  I can't see the point in dropping to 300 dpi for B 
... 400MB will be the average size of a
two page CV written in Word 20 years from now :-) For those who care, 
it's easier to convert from 600dpi to

300dpi than the reverse.

Back then I would use Adobe to convert to CCITT G4 encoded TIFF and 
repackage as PDF. (The current scanner

does that for me, or so it seemingly claims).

Maybe I forgot that step for this one. I do know that this one (and the 
VAXBI STD) both had pages that were
sticking together by the time they came to me, so I had to separate them 
all manually before scanning.

They are probably nowhere near as clean as a typical manual.

Picking on a few random samples and comparing to what I'm getting out of 
the current scanner I can use,
I see a range from 240KB/page to 390KB/page. So I don't think I missed 
out a step after all: I think it's in line

with what I generally see coming out of the scanner(s).

Antonio


--
Antonio Carlini
arcarl...@iee.org

Re: DEC VT100/220 line wrapping semantics sought

[Mattias Engdegård]

1 jan. 2017 kl. 23.38 skrev Al Kossow :
> 
> 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.

Re: DEC VT100/220 line wrapping semantics sought

[Paul Koning]

> On Jan 1, 2017, at 6:25 PM, allison  wrote:
> 
> 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:
>> 
>>> I did see a bunch of DEC STDs sitting on bitsavers but 070 doesn't seem to 
>>> be one of them.
>>> 
>> 
> Other standards that apply is DEC-STD-062 internationalization, STD-110
> Escape code actions, STD-111 terminal synchronization (Xon-Xoff).

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

Re: DEC VT100/220 line wrapping semantics sought

[Noel Chiappa]

> From: Antonio Carlini

> My scan is ~400MB (and 1090 pages long!)

Even at 1K pages, it shouldn't be anything like that big, if scanned using
the most space-efficient encoding.

For _manuals_, scan at 300 dpi with Black+White encoding (i.e. 1 bit per
pixel), then store as TIFFs with CCITT Group 4 (fax) compression. That does a
typical page of text in ~45KB or so. So you're about an order of magnitude
high

(For engineering drawings, basically the same, except scan at 600 dpi, to
capture all the small characters such as pinouts.)

Noel

Re: DEC VT100/220 line wrapping semantics sought

[allison]

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:
>
>> I did see a bunch of DEC STDs sitting on bitsavers but 070 doesn't seem to 
>> be one of them.
>>
>
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

Re: DEC VT100/220 line wrapping semantics sought

[allison]

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

Re: DEC VT100/220 line wrapping semantics sought

[Al Kossow]

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:

> I did see a bunch of DEC STDs sitting on bitsavers but 070 doesn't seem to be 
> one of them.
> 

Re: DEC VT100/220 line wrapping semantics sought

[Antonio Carlini]

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
arcarl...@iee.org

Re: DEC VT100/220 line wrapping semantics sought

[Paul Koning]

> On Jan 1, 2017, at 2: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.

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