What was the largest resolution supported by terminal escape codes?
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
add a comment |
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
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
add a comment |
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
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
terminal escape-codes
edited Feb 4 at 16:44
Dr Sheldon
asked Feb 4 at 16:39
Dr SheldonDr Sheldon
1,8212832
1,8212832
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
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.
@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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
@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
add a comment |
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.
@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
add a comment |
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.
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.
edited Feb 4 at 21:45
answered Feb 4 at 16:48
RaffzahnRaffzahn
52.3k6123211
52.3k6123211
@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
add a comment |
@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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
answered Feb 4 at 16:52
manassehkatzmanassehkatz
3,012623
3,012623
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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