Increase the maximum number of pages for VT52x to 20

[davidrg]

Because it turns out the upper limit is not 8. With a memory widget plugged into the back, it will do 20:

Should probably keep the default page count at 8 though. Nothing much out there actually uses paging, so no point defaulting to wasting RAM on an extra extra 12 pages that probably always go unused.

[j4james]

I'm curious whether your device attributes report changes when this cartridge is installed. According to one of the VT1000 manuals, there is a DA extension number 39, which is supposed to represent the "page memory extension". I never saw the details documented anywhere, but I assumed it might be something like this.

If not there, maybe an additional parameter in the DA2 report?

It's also worth noting that the maximum page count on the VT525 is one more than the VT520 by default (i.e. nine pages rather than eight). At least according to the installation manual.

[davidrg]

A little surprising and disappointing, but nothing new in the DA1 or DA2 response:

I'd have thought plugging a cartridge into the slot in the back would at least result in an option being reported via DA2, but I guess not. If there is a way to detect the presence of the memory cartridge I guess it would be to try and use DECSPMA to allocate some large number of pages, then seeing how many you actually got.

I have thought out about trying to contact the guy whos name is all over DEC STD 070 to see if he has any more information - newer versions of the standard, or other documentation not included that might describe what the other extenisons are or what, if anything, implemented them.

The VT520/525 announce seems to have implied that the VT525 could also be upgraded to 20 pages though I guess the shape of the cartridge must be quite different. Right now K95 does differentiate the two, giving a future VT520 emulation option 8 pages while the K95 and future VT525 options 9. I guess both should have a maximum of 20 with a default of 8/9.

Its also interesting that this cartridge even exists. Who was the target audience? I've never heard of anything actually using paging, though I guess it must have had users given the feature was developed and expanded over time. More scrollback lines must have been useful too. But there are barely any mentions of the memory cartidge online, and I've not seen any order/part numbers so perhaps it never actually made it to market, or was only available briefly.

[j4james]

OK, thanks for checking. It's not a huge surprise that it didn't affect the DA reports, since they all seem to be hardcoded in the ROM. I was just hoping we might get some confirmation of what extension 39 actually indicated, because I hate that there so many extension numbers for which we don't have any real definition.

As for determining the actual page count, I just use something like \e7\e[999 P\e[?6n\e8, which can also double as a way to check the page size (assuming you also included a CUP 999;999 control). And even if the cartridge was detectable, you'd still need something like that to detect the different page counts on devices without the cartridge installed.

[davidrg]

Yeah, its a bit frustrating having all those mystery extension numbers with no other details. I assume for them to have been allocated and referenced in published documentation something must have used them, though I can't imagine what. Perhaps some unreleased or very region-specific product(s) that never really made it on to the internet. STD 070 doesn't seem to be comprehensive (eg, doesn't cover the VT340s local editing/block mode stuff), so I guess there must have been more documentation covering other extensions at one point. I guess if anyone knows it would probably be Peter Sichel (now at sustworks.com) as he seems to have been there all the way to the end.

And perhaps some of them were implemented publicly but for whatever reason the extension number was never reported. Eg DECterm doesn't seem to report extension 43 even though the documentation says it should.

[j4james]

DECterm doesn't seem to report extension 43 even though the documentation says it should.

I've never used DECterm, so I'm not sure exactly how you configure it, but I was under the impression that it must be explicitly set up to emulate a VT382-J for the Ruled Lines extension to take effect. And I saw you had that working in DECterm, so I assumed you already chose VT382-J emulation to do that, but maybe the extension works by default, and it's only the DA1 reporting that is affected by the configured terminal type.

[davidrg]

I didn't think the VT382-J supported ruled lines - I couldn't see it anywhere in the manual when I skimmed through it.

The version of DECterm I have here (conveniently, Tru64 works in an emulator now) doesn't seem to have a VT382-J option, so I've always just left it set to DECterm:

[j4james]

Maybe I've misunderstood what they were saying, but the place I saw it mentioned was a document named "Tru64 UNIX, Writing Software for the International Market" (part no AA-RH9YC-TE). And in the section "Determining DECterm Support for Ruled Lines", it had the following:

This extension is valid at a level–2 video display or higher. For example, if a DECterm window is emulating a VT382-J terminal, which is the Japanese version of a VT382, the primary device attributes are generated as follows:

CSI ? 63; 1 ; 2 ; 4 ; 5 ; 6 ; 7 ; 8 ; 10 ; 15 ; 43 c

I took that to mean there must be a way to tell DECterm you wanted to emulate a VT382-J terminal.

And yeah, I also didn't see any mention of it in the VT382-J programmer reference, so I though it was possibly a DECterm specific feature. But it's possible it was omitted from the VT382-J manual by mistake.

[davidrg]

I picked up a copy of WRQ Reflection 8.0 recently, and it turns out it implements ruled lines:

And its VT382 emulation reports extension 43:

So I guess that's one point in favor of it being a poorly documented feature of the VT382 - I assume someone at WRQ must have had access to one of the things if they bothered to provide it as an emulation option.

[j4james]

I can't believe I didn't realise that! At some point in the past I made a list of all the different DA reports generated by Reflection, and checking my notes now, the VT382-J report is definitely included in that list, but I obviously didn't pay much attention to it at the time. I wasn't aware that they supported the Kanji extension either! I'm keen to do some testing now to see how they handle these extensions - I think they're usually very good at matching the original hardware.

ETA: I've done a bit of testing now, and their ruled line support seems good to me, but I couldn't get any Kanji functionality to work (possibly just because I don't know how).

[davidrg]

Yeah, its VT420 emulation actually seems solid - all the other commercial terminal emulators I've found aren't much good as a VT420 if they even offer the option.

Their ruled lines implementation largely matches how I expected it should work and that DECterms implementation is just buggy. I did see that they chose not to scroll ruled lines in vertical scrolling regions though - I wonder why. DECterm and I assume the VT382J doesn't support DECLRMM so DEC never publicly defined how these things should interact.

Where as I chose to scroll ruled line segments normally regardless of what kinds of margins were in effect both because its easier and it seemed like the reasonable thing to do. Perhaps in the absence of any spec WRQ just chose the easiest option too based on how they were storing lines, or maybe their behaviour is a result of some customer request long ago.

The also seem to have chosen to have erase by default just erase the right border, where as DECterm by default does nothing (the X below the double-height D). Need to find someone with a VT382J to break this tie!

I guess ultimately these minor differences are probably irrelevant though - its such an obscure feature only implemented by terminals most have never heard of one of which doesn't even have a price tag. And given how buggy DECterms implementation is I assume its not a feature that ever saw much use.

[j4james]

I did see that they chose not to scroll ruled lines in vertical scrolling regions though

I'm not sure what you mean by vertical scrolling regions, but I'm almost sure I got it to scroll ruled lines between the top and bottom margins (DECSTBM). The ruled lines moved up along with the text when you had a linefeed at the bottom of the margin area, and they moved down when you had a reverse index at the top of the margin area. If scrolled beyond the margin boundaries, they would disappear in the same way the text did.

I didn't test left/right margins (DECSLRM), but I wasn't expecting that to work, because the VT382 didn't support the horizontal scrolling extension as far as I'm aware.

In case it makes any difference, I was testing a Windows version of Reflection Desktop (version 16 I think).

[davidrg]

DECSLRM is what I meant. If the left and right margins are moved from the page edges, then ruled lines don't scroll with text in Reflection.

As DECterm and the VT382J don't support DECSLRM and the version of Reflection I had a the time (R2 5.10) didn't either, when I implemented ruled lines I didn't see much reason to treat them specially when mixed with DECSLRM as it was unlikely any application out there would try to use the two features together. So K95 currently scrolls them with the text regardless of the DECSLRM setting, just like it scrolls ruled lines between top/bottom margins.

If there was a good reason for Reflections behaviour it probably wouldn't be hard to change K95 to match. Perhaps Reflections behaviour even existing is reason enough - more people probably have/had access to Reflection than a VT382J or DECterm.

[j4james]

I realise now that Reflection doesn't enable and disable extensions based on the selected terminal ID, which is what I originally thought. I had assumed it only did ruled lines when configured as a VT382, and then wouldn't also haven't horizontal scrolling.

Anyway, I've done some more testing now, and can confirm that I'm seeing the same results as you. To try and make the test as simple as possible, I just set some left/margins, no top/bottom margins, and then performed DECFI and DECBI on the boundaries (this is the exact equivalent of my top/bottom margin test, just along the horizontal axis). The content within the margin area moved left and right as expected, but the ruled lines did not.

And it occurred to me that there is some justification for that behaviour. Remember that DCH and ICH also do not have any effect on ruled lines. So the rule could be that ruled lines only track vertical movement of text, and not horizontal movement. And if you consider left/right margins as a facet of horizontal movement functionality, it doesn't seem entirely unreasonable to ignore them altogether.

Not saying that you have to do that. But if you're looking for a reason to match the Reflection behaviour, that's at least a possible explanation for it. If you think of the ruled lines as a structure attached to the row rather than the individual cells, it might make more sense.

[davidrg]

Yeah, I think that makes sense. And really Reflection doing it that way ought to be reason enough to do the same - then at least K95 is consistent with everything else out there that implements this feature rather than doing its own thing that may someday cause incompatibility if some other terminal decides to implement it.

I might make that change tomorrow - its a pretty trivial one, just deleting some code. That will leave what DECERLBRP should do by default (DECterm - nothing, Reflection - erase right border) as the only remaining behaviour difference (ignoring all the DECterm bugs).