Resetting the color palette

[j4james]

I know you said a soft terminal reset doesn't reset the palette, and a hard reset isn't ideal because it takes a long time, but I have an idea for another method you could try. According to the documentation, when entering or exiting Tektronix mode, the VT340 "sets the output map to the factory-default state, or the state specified in set-up", which sounds to me like a palette reset.

Essentially something like this:

printf "\e[?38h\e[?38l"

I've tried this on the VT240, and it seems to work there. It does also clear the screen, which isn't ideal, but it's definitely faster than a full RIS reset.

[j4james]

One other issue I noticed is that on the VT240 this sequence also disables DECAWM (auto wrap mode) which seems a bit weird. And it's not like it's resetting it to the state specified in setup - it's always turned off regardless. But maybe this is just a VT240 thing, and it's not that hard to reenable it anyway.

[hackerb9]

printf "\e[?38h\e[?38l"

Clears the screen but does not reset the color palette.

Auto wrap mode is not modified. That definitely sounds like a bug in the VT240 firmware; the Tektronix screens didn't have autowrap, if I recall correctly.

[j4james]

Clears the screen but does not reset the color palette.

Damn. I was convinced that was going to work. But maybe there are some benefits to that, because that suggests you can control the Tektronix colors by setting the palette beforehand (which doesn't work on the VT240).

Anyway thanks for testing. I don't have any other ideas, so feel free to close this.

[j4james]

I was just browsing the new edition of the VT330/340 manual that you got from Paul Flo Williams, and I noticed it documents the DECSTGLT command, which I didn't realise was supported on these devices. And reading those docs I think might answer this question:

https://github.com/hackerb9/vt340test/blob/8c0ceeac4da45967b154cb2dd1ef0c5ba29cc005/colormap/resetpalette.sh#L61-L64

In theory DECSTGLT 1 would select color table 1, and DECSTGLT 2 would select color table 2. And I believe the second table should also have a different affect on text attributes - reverse video in particular.

I put together a little script to test that theory if you want to give it a try. It just outputs a sixel test pattern with all the colors and some text with all the attributes, and reruns that with different DECSTGLT values (I wasn't sure if DECSTGLT might also clear the screen).

Click to view the script

``` #!/bin/bash CSI=$'\e[' # Control Sequence Introducer DCS=$'\eP' # Device Control String ST=$'\e\\' # String Terminator set_cursor_pos() { echo -n ${CSI}${1}';'${2}'H' } output_color_pattern() { echo ${DCS}'2;1q' echo '#0!40~ #1!40~ #2!40~ #3!40~ #4!40~ #5!40~ #6!40~ #7!40~-' echo '#8!40~ #9!40~ #10!40~ #11!40~ #12!40~ #13!40~ #14!40~ #15!40~-' echo ${ST} } output_text_attributes() { echo -n ${CSI}'m' echo -n ' Normal ' echo -n ${CSI}'1m' echo -n ' Bright ' echo -n ${CSI}'0;7m' echo -n ' Reverse ' echo -n ${CSI}'1m' echo -n ' B.Reverse ' echo -n ${CSI}'m' echo } test_lookup_table() { echo -n ${CSI}'2J' echo -n ${CSI}${1}'){' # DECSTGLT set_cursor_pos 3 34 echo -n "${2}" set_cursor_pos 6 25 output_color_pattern set_cursor_pos 11 23 output_text_attributes set_cursor_pos 14 1 read -sn 1 } test_lookup_table 0 ' Monochrome ' test_lookup_table 1 'Color Table #1' test_lookup_table 2 'Color Table #2' ```

And the reason I've brought this up in this issue, is because I'm thinking (assuming this works) that this could potentially be a way to reset the palette. You might need to switch to another table and then switch back to table 1, but maybe just reselecting table 1 would be enough.

That assumes that any palette changes made programmatically don't update the values in the settings. I don't know if that's true or not.

[j4james]

Oh and this is also something for the errata document. The escape sequence for DECSTGLT is given as CSI Ps ) } while I believe it should be CSI Ps ) {. The code point values beneath the text are correct though.

[hackerb9]

Very interesting! I think they may not have documented it before because the behaviour seems kind of glitchy.

So, first switching to monochrome then back to colormap 1 does reset the palette to the factory defaults. It does not recall the user's saved colormap from Color Set-Up, nor does there seem to be a way to tell it to switch to the user's preferred Color Map saved in Global Set-Up.

While it works, there are a couple glitches that make it less ideal.

First, switching to Colormap-2 produces reverse background colors that are much darker than in Colormap-1. Sending an inquiry for the color table report shows no difference in the RGB values. This glitch also occurs when I switch to Colormap-2 from the Global Set-Up menu instead of using the escape sequence. This is most obvious in the status line at the bottom which is always printed in reverse.

Second glitch is that random rectangles of old text gets splatted on the screen when switching colortables. It is not clear what causes text to be saved or how it gets picked to be drawn on the screen other than it appears to happen close to where the cursor is.

I think the safest bet, if attempting to use this sequence, would be to always clear the screen after sending DECSTGLT. Something like,

CSI=$'\e['
echo ${CSI}'0){'${CSI}'1){'${CSI}'2J'

I'm going to have to read up more on these color lookup tables as I'm not seeing any benefit of having a second one. If I change the colors while Colormap-1 is active then switch to Colormap-2, I find its colors have changed, too. Without a way to programmatically Recall a Saved Color Map, there seems little point in being able to select which one is active.

[hackerb9]

Oh and this is also something for the errata document. The escape sequence for DECSTGLT is given as CSI Ps ) } while I believe it should be CSI Ps ) {. The code point values beneath the text are correct though.

Yes, you are correct. } does not seem to do anything.

[j4james]

First, switching to Colormap-2 produces reverse background colors that are much darker than in Colormap-1.

This I think is intended to emulate the VT240. The VT240 had only 4 colors, and no support for the ANSI SGR color sequences. So the best you could do was switch the text color from green to red (color map 3 to 2) using the bold rendition attribute. To get one more color, there was a mode in the settings called "Mono+Color", which made the reverse rendition attribute map to color 1, typically blue (I'm not completely sure of the details, though, because I think the MAME emulator has got the color attributes hooked up incorrectly).

So in order to emulate this behavior on the VT340, I think you are supposed to select color map 2 (which should function the same way as the "Mono+Color" mode on the VT240). Only now the mappings are slightly different: normal rendition maps to 7, the bold rendition maps to 15, and the reverse rendition maps to 8. So if you wanted to get the same default colors as the VT240 you would setup the color map so that color 7 was green, color 15 was red, and color 8 was blue.

[j4james]

If you want to read more docs on the subject, there is some info in the DEC STD-070 manual in section 5.6.3.7, Alternative Text Rendition Mapping. This is listed as page 5-112, which for me is page 367 in the PDF.

There in also some info in the VT330/340 Text Programming reference in Appendix C, Bold and Negative-Image Character Attributes. This is listed as page 288, which for me is page 302 in the PDF (the new second edition you got recently).

[hackerb9]

This is listed as page 288, which for me is page 302 in the PDF

I thought I fixed the page numbering in the PDF. Do you not get roman numerals for the section before page 1?

[j4james]

Oh that's neat. I just checked in Firefox and the pages work correctly there. I was using Edge as my pdf viewer, because it used to be way better than the other browsers, but it's gone downhill since they switched to Chromium.

[hackerb9]

First, switching to Colormap-2 produces reverse background colors that are much darker than in Colormap-1.

So in order to emulate this behavior on the VT340, I think you are supposed to select color map 2 (which should function the same way as the "Mono+Color" mode on the VT240). Only now the mappings are slightly different: normal rendition maps to 7, the bold rendition maps to 15, and the reverse rendition maps to 8. So if you wanted to get the same default colors as the VT240 you would setup the color map so that color 7 was green, color 15 was red, and color 8 was blue.

I'm not following that last part with the colors since I don't know the VT240 at all, but I think that's okay.

Does this sound right?

In the VT340, the second colormap is used to assign a specific colortable entry for the reverse highlight color. In colormap 1, which is the normal case, reverse video displays the text background using the foreground text color (entry number 7 in the color map). Colormap 2 uses color number 8 instead.

	Color Map 1	Color Map 2
Text Foreground	7	7
Text Background	0	0
Reverse Text Foreground	0	0
Reverse Text Background	7	8
Bold Text Foreground	15	15
Bold Text Background	0	0
Bold & Reverse Text Foreground	?0	?0
Bold & Reverse Text Background	?15	?8

(I need to double check the behaviour of text with both the Bold and Reverse attibutes).

[j4james]

In case it helps, these are screen caps showing the color tables on MAME's VT240 implementation. I'm not positive that MAME has got these mappings correct, though. In particular I wasn't expecting the normal text and bright text colors to have switched in color table 2.

But it does at least show that the reverse attribute is getting you access to another one of the color table entries. I was hoping there was a way to access that color without being reversed, though, otherwise I don't really see the point, but maybe I've misunderstood the purpose of this mapping.

[j4james]

Actually, now that I'm looking at all three of them together, I think I understand.

On monochrome devices, when the reverse attribute is applied, the background color is actually dimmer than it would have been when it was foreground. This is because the phosphor bleeds into the unlit portion of the display, so the letters would become unreadable if the background was too bright. If you look at a VT100, you'll see the same thing.

So that's why the monochrome colors have the normal rendition as light gray on black, but it's black on dark gray when reversed. Similarly the bright rendition is white on black, but black on light gray when reversed.

And color table 2 exactly matches the color positions of that monochrome mapping, it's just no longer a monochrome palette. This explains why it's called Mono+Color in the settings. It's a color palette, but it should still look reasonable on a monochrome monitor (whereas color table 1 probably wouldn't).

Following this logic, on the VT340 color table 2, I'd expect the bright reverse rendition to be 0 foreground on a 7 background.

[hackerb9]

That is a good hypothesis. It makes sense to me more than anything else does and it correctly predicts the bright reverse color scheme. Here's the final chart and a Media Copy of the screens.

	Color Map 1	Color Map 2
Text Foreground	7	7
Text Background	0	0
Reverse Text Foreground	0	0
Reverse Text Background	7	8
Bright Text Foreground	15	15
Bright Text Background	0	0
Bright & Reverse Text Foreground	0	0
Bright & Reverse Text Background	15	7

[hackerb9]

Interestingly, the VT340 remembers what text that was drawn in the previous colormap and does not change its color when switching between colormaps 1 and 2. So, you can show text with both colormaps 1 and 2 simultaneously. Sort of.

The VT340 only remembers one previous colormap. All previously drawn text gets assigned that colormap, no matter what colormap it was actually drawn with. So you can switch colormaps once, but any more won't work as expected.

I'm surprised that they implemented this feature as I'm not sure of the value of it. But, given that they did, I'm also surprised they didn't allow switching back and forth between colormaps 1 & 2. Without any increase in memory usage, DEC could have checked if the previous colormap is equal to the new colormap DECSTGLT is requesting. If so, then any previously existing text would have the "use previous colormap" attribute toggled. If not, then all existing text gets the "use previous colormap" attribute set to TRUE.

[j4james]

Interestingly, the VT340 remembers what text that was drawn in the previous colormap and does not change its color when switching between colormaps 1 and 2. So, you can show text with both colormaps 1 and 2 simultaneously. Sort of.

I'm not sure I've correctly understood what you're saying, but my theory is as follows:

1. Each of the SGR attribute combinations has a foreground and background color index assigned to it, exactly as you've listed them in the table above.
2. When you write out some text with a given set of attributes, what is stored in the buffer is not the attributes, but the index values that are currently assigned to those attributes.
3. Changing from one color map to the other will change the attribute-index mapping, but can't affect the index values that have already been written to the buffer.
4. Changing the color palette itself should affect the text that has been written out, though, because now you're changing the actual color associated with a given index.

Example test case:

echo -e '\e[1){'                 # Select color map 1
echo -e '\e[7m COLOR 07 \e[m'    # This should use color 7 for the background
echo -e '\e[1;7m COLOR 15 \e[m'  # This should use color 15 for the background

echo -e '\e[2){'                 # Select color map 2
echo -e '\e[7m COLOR 08 \e[m'    # This should use color 8 for the background
echo -e '\e[1;7m COLOR 07 \e[m'  # This should use color 7 for the background

echo -e '\eP2$p7;2;100;0;0\e\\'  # Set color 7 to red
echo -e '\eP2$p8;2;0;100;0\e\\'  # Set color 8 to green
echo -e '\eP2$p15;2;0;0;100\e\\' # Set color 15 to blue

If my theory is correct, those 4 lines of text should be displayed in red, blue, green, and red again.

If that does work, an interesting follow-up would be to see what happens when you throw the monochrome color map into the mix. The chances are it's also just using index values 7 and 15, but it's possible it could actually be using 13 and 3 instead.

[hackerb9]

Background is red, blue, green, and then (perhaps my eyes are deceiving me) the last one looks reddish-orange.

[UPDATE: It is an optical illusion, but a very persistent one]

So, yes, your hypothesis was correct. What is the "attribute-index mapping"?

[j4james]

What is the "attribute-index mapping"?

I just meant there's a mapping that says something like "reverse background" maps to index 7, and "bright reverse background" maps to index 15, like in the table you did above. This is the same concept as the DECATC mapping on the VT525.

But seeing your screenshot now, my hypothesis can't be completely correct, and I understand now what you meant when you said it only remembers one previous colormap. I was assuming that the pixels written out in the "COLOR 07" text would be stored in the graphics buffer with the value 7. So a palette change could update all index 7 pixels to another color, but you shouldn't have some being blue and others being red.

So I don't know now. I need to think about this some more. It's not that I particularly care about emulating this behavior exactly, but I'm curious to understand how it's actually producing the output you're seeing.