What was the largest resolution supported by terminal escape codes?












10















Terminal escape codes can be used for various functions such as positioning the cursor or querying the size of the screen. What was the largest resolution (in columns and rows of characters) supported by the encoding of escape codes?



The question may be answered in the context of a standard (such as ANSI), or for a particular terminal model; either is acceptable.










share|improve this question

























  • But terminal escape codes aren't retrocomputing? They are used even today.

    – Wilson
    Feb 4 at 16:41











  • @Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

    – manassehkatz
    Feb 4 at 16:43






  • 1





    @Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

    – Dr Sheldon
    Feb 4 at 16:46













  • @DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

    – Wilson
    Feb 4 at 16:48






  • 2





    Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

    – tofro
    Feb 4 at 20:07
















10















Terminal escape codes can be used for various functions such as positioning the cursor or querying the size of the screen. What was the largest resolution (in columns and rows of characters) supported by the encoding of escape codes?



The question may be answered in the context of a standard (such as ANSI), or for a particular terminal model; either is acceptable.










share|improve this question

























  • But terminal escape codes aren't retrocomputing? They are used even today.

    – Wilson
    Feb 4 at 16:41











  • @Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

    – manassehkatz
    Feb 4 at 16:43






  • 1





    @Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

    – Dr Sheldon
    Feb 4 at 16:46













  • @DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

    – Wilson
    Feb 4 at 16:48






  • 2





    Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

    – tofro
    Feb 4 at 20:07














10












10








10








Terminal escape codes can be used for various functions such as positioning the cursor or querying the size of the screen. What was the largest resolution (in columns and rows of characters) supported by the encoding of escape codes?



The question may be answered in the context of a standard (such as ANSI), or for a particular terminal model; either is acceptable.










share|improve this question
















Terminal escape codes can be used for various functions such as positioning the cursor or querying the size of the screen. What was the largest resolution (in columns and rows of characters) supported by the encoding of escape codes?



The question may be answered in the context of a standard (such as ANSI), or for a particular terminal model; either is acceptable.







terminal escape-codes






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 4 at 16:44







Dr Sheldon

















asked Feb 4 at 16:39









Dr SheldonDr Sheldon

1,8612832




1,8612832













  • But terminal escape codes aren't retrocomputing? They are used even today.

    – Wilson
    Feb 4 at 16:41











  • @Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

    – manassehkatz
    Feb 4 at 16:43






  • 1





    @Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

    – Dr Sheldon
    Feb 4 at 16:46













  • @DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

    – Wilson
    Feb 4 at 16:48






  • 2





    Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

    – tofro
    Feb 4 at 20:07



















  • But terminal escape codes aren't retrocomputing? They are used even today.

    – Wilson
    Feb 4 at 16:41











  • @Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

    – manassehkatz
    Feb 4 at 16:43






  • 1





    @Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

    – Dr Sheldon
    Feb 4 at 16:46













  • @DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

    – Wilson
    Feb 4 at 16:48






  • 2





    Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

    – tofro
    Feb 4 at 20:07

















But terminal escape codes aren't retrocomputing? They are used even today.

– Wilson
Feb 4 at 16:41





But terminal escape codes aren't retrocomputing? They are used even today.

– Wilson
Feb 4 at 16:41













@Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

– manassehkatz
Feb 4 at 16:43





@Wilson One could argue that terminal escape codes are Retrocomputing if limited to ASCII text-mode terminals as those are, by and large, extinct. Plenty of terminal escape codes used in ANSI (or other) emulation running on a PC, but that is different from an actual real terminal.

– manassehkatz
Feb 4 at 16:43




1




1





@Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

– Dr Sheldon
Feb 4 at 16:46







@Wilson: In that case, the 27 other questions tagged terminal or the other questions tagged escape-codes would also be off-topic.

– Dr Sheldon
Feb 4 at 16:46















@DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

– Wilson
Feb 4 at 16:48





@DrSheldon not all. For example "Does ancient UNIX create a new shell process for each terminal?"

– Wilson
Feb 4 at 16:48




2




2





Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

– tofro
Feb 4 at 20:07





Even in times you would consider retro, there were already X-terminals, whose xterms could be nearly arbitrarily (within limits, but not within cost limits) large.

– tofro
Feb 4 at 20:07










3 Answers
3






active

oldest

votes


















19














There is no limit, at least not by definition. And more so, not something across all terminals ever made.



Most prominent nowadays (*1) is the so-called ANSI sequences standard - understood by next to all terminals built after ~1978. Trying to be as device agnostic as possible, it implies no upper limits by itself. The structure is built (*2) around an initiating sequence (ESC+[; *3), one (or more, separated by ;) value(s) expressed in ASCII numerals, and a command letter.



For example:





  • <ESC>[<Value>A moves the cursor <Value> lines up.


or





  • <ESC>[<Value1>;<Value2>H moves the cursor to line <Value1> and column <Value2>, counted from the top left position (as 0;0).


There is no definition how many valid digits a value may have, or what's their upper limit. While the standard defines a default value of Zero for a left out parameter, it doesn't always apply, as these examples conveniently display. Where Cursor-Up assumes 1 as default, if no value is given, Cursor-Positioning assumes 0;0 as default (*4). Similarly, upper limits are defined by each command and terminal depending on their capabilities (and how intelligent or lazy the programming was done).





*1 - Well, since the late 70s at least that is.



*2 - And based around the command sequences defined for the popular DEC VT-52 of 1975.



*3 - Or CSI (Control Sequence Indicator), X'9B' - that's ESC set with high bit set. A trick to reduce overhead after 8 bit lines became standard. Not that it meant a lot with the verbose encoding anyway.



*4 - It is simply a left over from ANSI-encoding being an extension of the VT52 command set - here ESC+ A moved the cursor up one line, so for compatibility it had to do the same in the later standard.






share|improve this answer


























  • @manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

    – Raffzahn
    Feb 4 at 16:59











  • @manassehkatz Ok. sounds good to me. gimme a sec.

    – Raffzahn
    Feb 4 at 17:03






  • 1





    I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

    – manassehkatz
    Feb 4 at 17:30













  • @manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

    – Raffzahn
    Feb 4 at 17:36











  • Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

    – manassehkatz
    Feb 4 at 17:53



















6














Tektronix (and emulated Tektronix) graphics mode



Not exactly what you are looking for (because not "characters"), but Tektronix 4010/4014 mode as supported by Wyse 99GT and Wyse 370 (and I assume by actual Tektronix terminals, though I haven't used those since ~ 1986), supported Escape Codes for positioning on a 4,096 x 4,096 virtual display. According to the Wyse 370 manual, the actual display is a (simulated, of course, not actually that high resolution) 4,096 x 3,128.



The Wyse 370 could actually display up to 161 columns of text, though I never used it in that mode.






share|improve this answer



















  • 1





    The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

    – alephzero
    Feb 4 at 19:22








  • 1





    @alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

    – manassehkatz
    Feb 4 at 19:33



















2














In the early 1980s practically every terminal had its own particular set of escape codes, to the point where the software we were selling then had a separate module which we could quickly reprogram as each customer sent us a copy of their terminal's manual. This continues at least as far as 1984.



Some "grown-up" terminals did indeed use escape sequences that gave X and Y coordinates as straightforward decimal numbers, sequences of characters between '0' and '9'. But this demanded exceptionally high computing capacity in the terminal itself, and of course also higher bandwidth in the connection from computer to terminal. Thus our "terminal adaptor" layer maintained two memory maps, one of the screen as it ought to be and one of the screen as it currently was, and its main job was to work out the "optimum" way of turning "current" into "ought to be". For instance, if characters 1 and 5 on a line have changed, is it better to send "character 1, escape sequence, character 5", or "character 1, character 2, character 3, character 4, character 5"? Life was made more interesting by the fact that some terminals had short ways of moving from one position to another, other than a full X-Y positioning (think of the LF character, for an example).



So the answer to the question is that in the minority of terminals that thought of themselves as cut-down supercomputers and actually did all the multiplications and additions required to convert "1,0,0" into the number 100, there was no intrinsic limit to the addressable positions on the screen. But most terminals would try to encode each coordinate in one character, which meant a maximum of 95 or so if you confined yourself to printable characters or a maximum of 128 if you allowed any character at all. What encoding was used, and whether X came before Y or Y came before X, was down to the manufacturer's whim.






share|improve this answer



















  • 1





    Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

    – cup
    Feb 5 at 12:04











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9074%2fwhat-was-the-largest-resolution-supported-by-terminal-escape-codes%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









19














There is no limit, at least not by definition. And more so, not something across all terminals ever made.



Most prominent nowadays (*1) is the so-called ANSI sequences standard - understood by next to all terminals built after ~1978. Trying to be as device agnostic as possible, it implies no upper limits by itself. The structure is built (*2) around an initiating sequence (ESC+[; *3), one (or more, separated by ;) value(s) expressed in ASCII numerals, and a command letter.



For example:





  • <ESC>[<Value>A moves the cursor <Value> lines up.


or





  • <ESC>[<Value1>;<Value2>H moves the cursor to line <Value1> and column <Value2>, counted from the top left position (as 0;0).


There is no definition how many valid digits a value may have, or what's their upper limit. While the standard defines a default value of Zero for a left out parameter, it doesn't always apply, as these examples conveniently display. Where Cursor-Up assumes 1 as default, if no value is given, Cursor-Positioning assumes 0;0 as default (*4). Similarly, upper limits are defined by each command and terminal depending on their capabilities (and how intelligent or lazy the programming was done).





*1 - Well, since the late 70s at least that is.



*2 - And based around the command sequences defined for the popular DEC VT-52 of 1975.



*3 - Or CSI (Control Sequence Indicator), X'9B' - that's ESC set with high bit set. A trick to reduce overhead after 8 bit lines became standard. Not that it meant a lot with the verbose encoding anyway.



*4 - It is simply a left over from ANSI-encoding being an extension of the VT52 command set - here ESC+ A moved the cursor up one line, so for compatibility it had to do the same in the later standard.






share|improve this answer


























  • @manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

    – Raffzahn
    Feb 4 at 16:59











  • @manassehkatz Ok. sounds good to me. gimme a sec.

    – Raffzahn
    Feb 4 at 17:03






  • 1





    I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

    – manassehkatz
    Feb 4 at 17:30













  • @manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

    – Raffzahn
    Feb 4 at 17:36











  • Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

    – manassehkatz
    Feb 4 at 17:53
















19














There is no limit, at least not by definition. And more so, not something across all terminals ever made.



Most prominent nowadays (*1) is the so-called ANSI sequences standard - understood by next to all terminals built after ~1978. Trying to be as device agnostic as possible, it implies no upper limits by itself. The structure is built (*2) around an initiating sequence (ESC+[; *3), one (or more, separated by ;) value(s) expressed in ASCII numerals, and a command letter.



For example:





  • <ESC>[<Value>A moves the cursor <Value> lines up.


or





  • <ESC>[<Value1>;<Value2>H moves the cursor to line <Value1> and column <Value2>, counted from the top left position (as 0;0).


There is no definition how many valid digits a value may have, or what's their upper limit. While the standard defines a default value of Zero for a left out parameter, it doesn't always apply, as these examples conveniently display. Where Cursor-Up assumes 1 as default, if no value is given, Cursor-Positioning assumes 0;0 as default (*4). Similarly, upper limits are defined by each command and terminal depending on their capabilities (and how intelligent or lazy the programming was done).





*1 - Well, since the late 70s at least that is.



*2 - And based around the command sequences defined for the popular DEC VT-52 of 1975.



*3 - Or CSI (Control Sequence Indicator), X'9B' - that's ESC set with high bit set. A trick to reduce overhead after 8 bit lines became standard. Not that it meant a lot with the verbose encoding anyway.



*4 - It is simply a left over from ANSI-encoding being an extension of the VT52 command set - here ESC+ A moved the cursor up one line, so for compatibility it had to do the same in the later standard.






share|improve this answer


























  • @manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

    – Raffzahn
    Feb 4 at 16:59











  • @manassehkatz Ok. sounds good to me. gimme a sec.

    – Raffzahn
    Feb 4 at 17:03






  • 1





    I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

    – manassehkatz
    Feb 4 at 17:30













  • @manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

    – Raffzahn
    Feb 4 at 17:36











  • Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

    – manassehkatz
    Feb 4 at 17:53














19












19








19







There is no limit, at least not by definition. And more so, not something across all terminals ever made.



Most prominent nowadays (*1) is the so-called ANSI sequences standard - understood by next to all terminals built after ~1978. Trying to be as device agnostic as possible, it implies no upper limits by itself. The structure is built (*2) around an initiating sequence (ESC+[; *3), one (or more, separated by ;) value(s) expressed in ASCII numerals, and a command letter.



For example:





  • <ESC>[<Value>A moves the cursor <Value> lines up.


or





  • <ESC>[<Value1>;<Value2>H moves the cursor to line <Value1> and column <Value2>, counted from the top left position (as 0;0).


There is no definition how many valid digits a value may have, or what's their upper limit. While the standard defines a default value of Zero for a left out parameter, it doesn't always apply, as these examples conveniently display. Where Cursor-Up assumes 1 as default, if no value is given, Cursor-Positioning assumes 0;0 as default (*4). Similarly, upper limits are defined by each command and terminal depending on their capabilities (and how intelligent or lazy the programming was done).





*1 - Well, since the late 70s at least that is.



*2 - And based around the command sequences defined for the popular DEC VT-52 of 1975.



*3 - Or CSI (Control Sequence Indicator), X'9B' - that's ESC set with high bit set. A trick to reduce overhead after 8 bit lines became standard. Not that it meant a lot with the verbose encoding anyway.



*4 - It is simply a left over from ANSI-encoding being an extension of the VT52 command set - here ESC+ A moved the cursor up one line, so for compatibility it had to do the same in the later standard.






share|improve this answer















There is no limit, at least not by definition. And more so, not something across all terminals ever made.



Most prominent nowadays (*1) is the so-called ANSI sequences standard - understood by next to all terminals built after ~1978. Trying to be as device agnostic as possible, it implies no upper limits by itself. The structure is built (*2) around an initiating sequence (ESC+[; *3), one (or more, separated by ;) value(s) expressed in ASCII numerals, and a command letter.



For example:





  • <ESC>[<Value>A moves the cursor <Value> lines up.


or





  • <ESC>[<Value1>;<Value2>H moves the cursor to line <Value1> and column <Value2>, counted from the top left position (as 0;0).


There is no definition how many valid digits a value may have, or what's their upper limit. While the standard defines a default value of Zero for a left out parameter, it doesn't always apply, as these examples conveniently display. Where Cursor-Up assumes 1 as default, if no value is given, Cursor-Positioning assumes 0;0 as default (*4). Similarly, upper limits are defined by each command and terminal depending on their capabilities (and how intelligent or lazy the programming was done).





*1 - Well, since the late 70s at least that is.



*2 - And based around the command sequences defined for the popular DEC VT-52 of 1975.



*3 - Or CSI (Control Sequence Indicator), X'9B' - that's ESC set with high bit set. A trick to reduce overhead after 8 bit lines became standard. Not that it meant a lot with the verbose encoding anyway.



*4 - It is simply a left over from ANSI-encoding being an extension of the VT52 command set - here ESC+ A moved the cursor up one line, so for compatibility it had to do the same in the later standard.







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 4 at 21:45

























answered Feb 4 at 16:48









RaffzahnRaffzahn

53.7k6132218




53.7k6132218













  • @manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

    – Raffzahn
    Feb 4 at 16:59











  • @manassehkatz Ok. sounds good to me. gimme a sec.

    – Raffzahn
    Feb 4 at 17:03






  • 1





    I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

    – manassehkatz
    Feb 4 at 17:30













  • @manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

    – Raffzahn
    Feb 4 at 17:36











  • Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

    – manassehkatz
    Feb 4 at 17:53



















  • @manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

    – Raffzahn
    Feb 4 at 16:59











  • @manassehkatz Ok. sounds good to me. gimme a sec.

    – Raffzahn
    Feb 4 at 17:03






  • 1





    I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

    – manassehkatz
    Feb 4 at 17:30













  • @manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

    – Raffzahn
    Feb 4 at 17:36











  • Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

    – manassehkatz
    Feb 4 at 17:53

















@manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

– Raffzahn
Feb 4 at 16:59





@manassehkatz Right. The question does not only include/refer to ANSI, but also asks for maximum. Isn't it? And due that nature, providing a single answer showing one example without limits will fulfil the request, doesn't it? Beside, you're of course right, that certain terminals had their individual limits, no matter if ANSI of custom

– Raffzahn
Feb 4 at 16:59













@manassehkatz Ok. sounds good to me. gimme a sec.

– Raffzahn
Feb 4 at 17:03





@manassehkatz Ok. sounds good to me. gimme a sec.

– Raffzahn
Feb 4 at 17:03




1




1





I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

– manassehkatz
Feb 4 at 17:30







I don't know what the crossover date was, but understood by next to all terminals build after ~1978 doesn't sound right to me. I would consider 1986 (intro. of Wyse 60) a plausible crossover date as the WY-60 included ANSI emulation (along with many others). But the Wyse 50, which was extremely popular for several years, and was introduced in 1983, did not include ANSI emulation (it had a handful of emulations, most, like Televideo) very similar to ADM3A, etc. and not at all like ANSI).

– manassehkatz
Feb 4 at 17:30















@manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

– Raffzahn
Feb 4 at 17:36





@manassehkatz Well, I guess that's the 'next to all' part as different manufacturers, especially such with a wide customer base of their own, tried for some time to continue on their lock-in strategy. Other large manufacturer switched already as early as 1979/80. Wise may be a good example to mark 1986 as the point where even the last gave in to use standard sequences.

– Raffzahn
Feb 4 at 17:36













Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

– manassehkatz
Feb 4 at 17:53





Actually, Wyse was the opposite of lock-in strategy. From relatively early on, they supported multiple emulations of other brands of terminals (and there own "original" codes with the Wyse 100 was very close to ADM3A, TVI, etc. and not a really new type) - they were great as the alternative to having to buy a specific vendor terminal to match a particular computer. It was only natural that they supported ANSI, it just took some time.

– manassehkatz
Feb 4 at 17:53











6














Tektronix (and emulated Tektronix) graphics mode



Not exactly what you are looking for (because not "characters"), but Tektronix 4010/4014 mode as supported by Wyse 99GT and Wyse 370 (and I assume by actual Tektronix terminals, though I haven't used those since ~ 1986), supported Escape Codes for positioning on a 4,096 x 4,096 virtual display. According to the Wyse 370 manual, the actual display is a (simulated, of course, not actually that high resolution) 4,096 x 3,128.



The Wyse 370 could actually display up to 161 columns of text, though I never used it in that mode.






share|improve this answer



















  • 1





    The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

    – alephzero
    Feb 4 at 19:22








  • 1





    @alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

    – manassehkatz
    Feb 4 at 19:33
















6














Tektronix (and emulated Tektronix) graphics mode



Not exactly what you are looking for (because not "characters"), but Tektronix 4010/4014 mode as supported by Wyse 99GT and Wyse 370 (and I assume by actual Tektronix terminals, though I haven't used those since ~ 1986), supported Escape Codes for positioning on a 4,096 x 4,096 virtual display. According to the Wyse 370 manual, the actual display is a (simulated, of course, not actually that high resolution) 4,096 x 3,128.



The Wyse 370 could actually display up to 161 columns of text, though I never used it in that mode.






share|improve this answer



















  • 1





    The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

    – alephzero
    Feb 4 at 19:22








  • 1





    @alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

    – manassehkatz
    Feb 4 at 19:33














6












6








6







Tektronix (and emulated Tektronix) graphics mode



Not exactly what you are looking for (because not "characters"), but Tektronix 4010/4014 mode as supported by Wyse 99GT and Wyse 370 (and I assume by actual Tektronix terminals, though I haven't used those since ~ 1986), supported Escape Codes for positioning on a 4,096 x 4,096 virtual display. According to the Wyse 370 manual, the actual display is a (simulated, of course, not actually that high resolution) 4,096 x 3,128.



The Wyse 370 could actually display up to 161 columns of text, though I never used it in that mode.






share|improve this answer













Tektronix (and emulated Tektronix) graphics mode



Not exactly what you are looking for (because not "characters"), but Tektronix 4010/4014 mode as supported by Wyse 99GT and Wyse 370 (and I assume by actual Tektronix terminals, though I haven't used those since ~ 1986), supported Escape Codes for positioning on a 4,096 x 4,096 virtual display. According to the Wyse 370 manual, the actual display is a (simulated, of course, not actually that high resolution) 4,096 x 3,128.



The Wyse 370 could actually display up to 161 columns of text, though I never used it in that mode.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 4 at 16:52









manassehkatzmanassehkatz

3,032623




3,032623








  • 1





    The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

    – alephzero
    Feb 4 at 19:22








  • 1





    @alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

    – manassehkatz
    Feb 4 at 19:33














  • 1





    The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

    – alephzero
    Feb 4 at 19:22








  • 1





    @alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

    – manassehkatz
    Feb 4 at 19:33








1




1





The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

– alephzero
Feb 4 at 19:22







The Tektronix address space was indeed 4096 x 4096 pixels, though anything above 3128 was vertically off the top of the screen on a real 4014 (as compared with a high-resolution plotter emulation of the terminal). It's not really fair to talk about pixels on the 4014, because the electron beam deflection to write on the screen was analog not digital. But that had the advantage that smooth straight lines could be drawn in any direction, with no rasterization artifacts.

– alephzero
Feb 4 at 19:22






1




1





@alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

– manassehkatz
Feb 4 at 19:33





@alephzero Except (a) On a Wyse 370 (or Wyse 99GT) it really was pixels since they were bitmapped terminals not storage tubes and (b) these truly were Terminal escape codes can be used for various functions such as positioning the cursor, just at a "virtual pixel" level rather than characters.

– manassehkatz
Feb 4 at 19:33











2














In the early 1980s practically every terminal had its own particular set of escape codes, to the point where the software we were selling then had a separate module which we could quickly reprogram as each customer sent us a copy of their terminal's manual. This continues at least as far as 1984.



Some "grown-up" terminals did indeed use escape sequences that gave X and Y coordinates as straightforward decimal numbers, sequences of characters between '0' and '9'. But this demanded exceptionally high computing capacity in the terminal itself, and of course also higher bandwidth in the connection from computer to terminal. Thus our "terminal adaptor" layer maintained two memory maps, one of the screen as it ought to be and one of the screen as it currently was, and its main job was to work out the "optimum" way of turning "current" into "ought to be". For instance, if characters 1 and 5 on a line have changed, is it better to send "character 1, escape sequence, character 5", or "character 1, character 2, character 3, character 4, character 5"? Life was made more interesting by the fact that some terminals had short ways of moving from one position to another, other than a full X-Y positioning (think of the LF character, for an example).



So the answer to the question is that in the minority of terminals that thought of themselves as cut-down supercomputers and actually did all the multiplications and additions required to convert "1,0,0" into the number 100, there was no intrinsic limit to the addressable positions on the screen. But most terminals would try to encode each coordinate in one character, which meant a maximum of 95 or so if you confined yourself to printable characters or a maximum of 128 if you allowed any character at all. What encoding was used, and whether X came before Y or Y came before X, was down to the manufacturer's whim.






share|improve this answer



















  • 1





    Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

    – cup
    Feb 5 at 12:04
















2














In the early 1980s practically every terminal had its own particular set of escape codes, to the point where the software we were selling then had a separate module which we could quickly reprogram as each customer sent us a copy of their terminal's manual. This continues at least as far as 1984.



Some "grown-up" terminals did indeed use escape sequences that gave X and Y coordinates as straightforward decimal numbers, sequences of characters between '0' and '9'. But this demanded exceptionally high computing capacity in the terminal itself, and of course also higher bandwidth in the connection from computer to terminal. Thus our "terminal adaptor" layer maintained two memory maps, one of the screen as it ought to be and one of the screen as it currently was, and its main job was to work out the "optimum" way of turning "current" into "ought to be". For instance, if characters 1 and 5 on a line have changed, is it better to send "character 1, escape sequence, character 5", or "character 1, character 2, character 3, character 4, character 5"? Life was made more interesting by the fact that some terminals had short ways of moving from one position to another, other than a full X-Y positioning (think of the LF character, for an example).



So the answer to the question is that in the minority of terminals that thought of themselves as cut-down supercomputers and actually did all the multiplications and additions required to convert "1,0,0" into the number 100, there was no intrinsic limit to the addressable positions on the screen. But most terminals would try to encode each coordinate in one character, which meant a maximum of 95 or so if you confined yourself to printable characters or a maximum of 128 if you allowed any character at all. What encoding was used, and whether X came before Y or Y came before X, was down to the manufacturer's whim.






share|improve this answer



















  • 1





    Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

    – cup
    Feb 5 at 12:04














2












2








2







In the early 1980s practically every terminal had its own particular set of escape codes, to the point where the software we were selling then had a separate module which we could quickly reprogram as each customer sent us a copy of their terminal's manual. This continues at least as far as 1984.



Some "grown-up" terminals did indeed use escape sequences that gave X and Y coordinates as straightforward decimal numbers, sequences of characters between '0' and '9'. But this demanded exceptionally high computing capacity in the terminal itself, and of course also higher bandwidth in the connection from computer to terminal. Thus our "terminal adaptor" layer maintained two memory maps, one of the screen as it ought to be and one of the screen as it currently was, and its main job was to work out the "optimum" way of turning "current" into "ought to be". For instance, if characters 1 and 5 on a line have changed, is it better to send "character 1, escape sequence, character 5", or "character 1, character 2, character 3, character 4, character 5"? Life was made more interesting by the fact that some terminals had short ways of moving from one position to another, other than a full X-Y positioning (think of the LF character, for an example).



So the answer to the question is that in the minority of terminals that thought of themselves as cut-down supercomputers and actually did all the multiplications and additions required to convert "1,0,0" into the number 100, there was no intrinsic limit to the addressable positions on the screen. But most terminals would try to encode each coordinate in one character, which meant a maximum of 95 or so if you confined yourself to printable characters or a maximum of 128 if you allowed any character at all. What encoding was used, and whether X came before Y or Y came before X, was down to the manufacturer's whim.






share|improve this answer













In the early 1980s practically every terminal had its own particular set of escape codes, to the point where the software we were selling then had a separate module which we could quickly reprogram as each customer sent us a copy of their terminal's manual. This continues at least as far as 1984.



Some "grown-up" terminals did indeed use escape sequences that gave X and Y coordinates as straightforward decimal numbers, sequences of characters between '0' and '9'. But this demanded exceptionally high computing capacity in the terminal itself, and of course also higher bandwidth in the connection from computer to terminal. Thus our "terminal adaptor" layer maintained two memory maps, one of the screen as it ought to be and one of the screen as it currently was, and its main job was to work out the "optimum" way of turning "current" into "ought to be". For instance, if characters 1 and 5 on a line have changed, is it better to send "character 1, escape sequence, character 5", or "character 1, character 2, character 3, character 4, character 5"? Life was made more interesting by the fact that some terminals had short ways of moving from one position to another, other than a full X-Y positioning (think of the LF character, for an example).



So the answer to the question is that in the minority of terminals that thought of themselves as cut-down supercomputers and actually did all the multiplications and additions required to convert "1,0,0" into the number 100, there was no intrinsic limit to the addressable positions on the screen. But most terminals would try to encode each coordinate in one character, which meant a maximum of 95 or so if you confined yourself to printable characters or a maximum of 128 if you allowed any character at all. What encoding was used, and whether X came before Y or Y came before X, was down to the manufacturer's whim.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 5 at 10:41









Martin KochanskiMartin Kochanski

1211




1211








  • 1





    Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

    – cup
    Feb 5 at 12:04














  • 1





    Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

    – cup
    Feb 5 at 12:04








1




1





Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

– cup
Feb 5 at 12:04





Re y before x: It depends on whether they are thinking x,y or row column. Anyone who thinks row, column will end up with y,x.

– cup
Feb 5 at 12:04


















draft saved

draft discarded




















































Thanks for contributing an answer to Retrocomputing Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9074%2fwhat-was-the-largest-resolution-supported-by-terminal-escape-codes%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Human spaceflight

Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

File:DeusFollowingSea.jpg