search

hackerb9 / vt340test

Tests of VT340 compatibility
Creative Commons Zero v1.0 Universal
40 stars 5 forks source link

Question regarding repeat counter handling on VT340 #21

Closed jerch closed 3 years ago

jerch commented 3 years ago

Me again. :smile_cat:

Looking through several resources regarding SIXELs I find somewhat contradictionary remarks regarding the handling of the repeat counter, thus I wonder how it is implemented on the VT340. In particular I am interested in these cases:

In the end I would go here with the behavior of the VT340, as I tend to see it as the last and most prominent real world reference we got from DEC (even if it collides with their own docs).

j4james commented 3 years ago

See the test case here: https://github.com/hackerb9/vt340test/blob/main/j4james/repeat_introducer.sh And the results here: https://github.com/hackerb9/vt340test/blob/main/j4james/repeat_introducer.png

I think that should cover most if not all of your questions.

j4james commented 3 years ago

Does VT340 allow stacking repeat counters as of !255!255...? Would it interpret it as a repeat of 510 (as described for the VT240), or as 255 (discarding the first value, as described in DEC STD 070)?

I didn't have a test for this, but I assume it would just be 255. That's definitely the case on the VT240 (tested in MAME). In which VT240 documentation did you see the repeat counts being stacked?

jerch commented 3 years ago

@j4james Thats just based on hearsay, I think it is stated somewhere in this old usenet resource: https://www.digiater.nl/openvms/decus/vax90b1/krypton-nasa/all-about-sixels.text.

The motivation for this reads like this: due to 8 bit limitations some older devices (incl. VT240?) used stacking to be able to address more than 255.

Edit:

Yepp found it:

Furthermore, the  VT240 never specifies a repeat-count greater than 255: if
it wants to send 600 repetitions of the  "empty" sixel  ("?" character), it
will send

    !255?!255?!90
j4james commented 3 years ago

Yeah, that's not true. The VT240 has no problem with repeat counts greater than 255. Maybe the VT125 or one of the DEC clones?

Edit: Also note in that example you quoted they're not actually relying on multiple repeat counts being added together - they've just got two instance of a 255 repeat of ?.

jerch commented 3 years ago

Edit: Also note in that example you quoted they're not actually relying on multiple repeat counts being added together - they've just got two instance of a 255 repeat of ?.

Oh well, overlooked the ? in the example. So yeah, things are all answered with that. Thx.

j4james commented 3 years ago

I've just been reading the page you linked to again, and I've figured out what they mean now. They're talking about the sixel that is generated by the VT240 when you print a page. I can write something like !600~ to the VT240 and get an image 600 pixels wide, but when I print that out, the sixel that they generate is !255~!255~!90~. It may well have been a limitation of the printers at the time.

hackerb9 commented 3 years ago

The VT340 behaves the same in terms of "stacking". It accepts repeat counts over 255, but will not generate them when printing. This is true regardless of whether I have the printer set to Level 1 or Level 2 Graphics.

@jerch: Did you get answers to the !0 and !x case error handling?

jerch commented 3 years ago

@jerch: Did you get answers to the !0 and !x case error handling?

Yes, thats covered by the test cases @j4james pointed me to.

dankamongmen commented 3 years ago

In the end I would go here with the behavior of the VT340, as I tend to see it as the last and most prominent real world reference we got from DEC (even if it collides with their own docs).

people keep saying this; wouldn't the VT525 qualify?

(also, why did the VT420 step back to monochrome despite coming out three years after the VT340?)

hackerb9 commented 3 years ago

In the end I would go here with the behavior of the VT340, as I tend to see it as the last and most prominent real world reference we got from DEC (even if it collides with their own docs).

people keep saying this; wouldn't the VT525 qualify?

Nope. No sixel support, which is what @jerch was asking about.

I'm not saying the VT525 isn't cool. It has neat features the VT340 is missing, most noticeably ANSI colors. Also, you can be logged in simultaneously on four separate connections (the VT340 can only do two). And the VT525 can (I believe) do hardware handshaking (the VT340 appears to have the hardware to do it, but doesn't actually use it in the firmware).

(also, why did the VT420 step back to monochrome despite coming out three years after the VT340?)

I don't know, but I believe the VT320 (also monochrome and sixel-less) came out a year after the VT330/VT340 and was extremely well received because it was cheap enough to compete against the knock-off brands. Although they did have the VT1000 X Terminal, I think at that point Digital was trying to sell terminals as being able to do all the boring stuff business applications (point of sale, data entry) at a lower price than PCs. From that mindset, fancy features that command line users enjoy, like color and sixels, only made their products too expensive.

But that's just a guess.

dankamongmen commented 3 years ago

oh weird, so the 525 (and others) allow font composition from sixels, but can't display arbitrary ones? i mean, i guess that isn't completely unreasonable, but it seems a weird regression. i guess at the data rates available, big bitmaps just weren't really usable? huh.

sorry for all the basic questions =[. true hardware terminals were just before my time.

hackerb9 commented 3 years ago

oh weird, so the 525 (and others) allow font composition from sixels, but can't display arbitrary ones?

That's my understanding. I don't own a VT525, but @jerch is getting one working.

i mean, i guess that isn't completely unreasonable, but it seems a weird regression. i guess at the data rates available, big bitmaps just weren't really usable? huh.

Yeah, baudrate is my first guess for why sixels died. (Or, perhaps it is better to say they hibernated until communication rates were fast enough that they were usable).

I think I mentioned this before, but in the 90s, it wasn't unreasonable to think that the command line had no future. If you look at the features of the VT525, while there were definitely advances, many of the major ones were backwards looking: compatibility with competitor terminal types, compatibility with PC style ANSI colors, compatibility with PC keyboard and monitor. Even the ability to have four sessions, which I think is pretty nifty, is just offering people more of what they already knew.

In contrast, the VT340 had capabilities that no other terminal at the time was even close to. Sixels are nifty for bitmaps on the command line, but the VT340 also had a way of drawing vector graphics integrated with the text using DEC's ReGIS protocol. Unlike the older Tektronix protocol, ReGIS was clearly designed by people who were trying to make things work well for command line users. On the VT340, it is easy to try out various ideas and manipulate graphics in what we would now call a "REPL" (read-eval-print loop).

I may be wrong, but the VT340 appears to have been the zenith of Digital's command line graphics aspirations. I know of no terminals after the VT340 which had support for fullscreen ReGIS or sixel graphics.

sorry for all the basic questions =[. true hardware terminals were just before my time.

I didn't know any of this a year ago. I'm still just learning and asking basic questions myself.

jerch commented 3 years ago

Yes my statement was meant for sixels, where the vt340 was DEC's top notch product for long (imho they kept selling it for a long time at a high price, even when the 400 and 500 line was already released).

I am also curious, why they stopped the graphics capabilities with the 400/500 line. I always was under the impression, that it just did not happen for market reasons (the higher production costs were not justified anymore at the early 90s given the competition from cheeper full X11 terminals popping up at that time). Whether there were serious VT emulation incompatibilities or hard to bridge issues with the newer emulation lines prolly remains a mystery forever, not sure if there are still former DEC employees around, that could shed some light on the subject with insider knowledge.