Did CP/M provide compatibility for screen-based programs?
I refer here to 'screen-based programs' that are not actually graphical, but take full advantage of the screen as a two-dimensional array of 80x25 characters, as opposed to typical 'command-line programs' whose output is essentially one dimensional.
MS-DOS provided compatibility for command-line programs. A single binary could run on many different and incompatible computers, provided they all ran MS-DOS.
MS-DOS did not provide compatibility for screen-based programs. In theory it did but in practice it didn't; the screen display routines provided by the operating system were so slow that we all wrote directly to video RAM instead, which meant our programs would only run on an IBM PC or clone.
CP/M was in a sense the precursor of MS-DOS. Did it provide practical compatibility for screen-based programs? Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?
cp-m
add a comment |
I refer here to 'screen-based programs' that are not actually graphical, but take full advantage of the screen as a two-dimensional array of 80x25 characters, as opposed to typical 'command-line programs' whose output is essentially one dimensional.
MS-DOS provided compatibility for command-line programs. A single binary could run on many different and incompatible computers, provided they all ran MS-DOS.
MS-DOS did not provide compatibility for screen-based programs. In theory it did but in practice it didn't; the screen display routines provided by the operating system were so slow that we all wrote directly to video RAM instead, which meant our programs would only run on an IBM PC or clone.
CP/M was in a sense the precursor of MS-DOS. Did it provide practical compatibility for screen-based programs? Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?
cp-m
add a comment |
I refer here to 'screen-based programs' that are not actually graphical, but take full advantage of the screen as a two-dimensional array of 80x25 characters, as opposed to typical 'command-line programs' whose output is essentially one dimensional.
MS-DOS provided compatibility for command-line programs. A single binary could run on many different and incompatible computers, provided they all ran MS-DOS.
MS-DOS did not provide compatibility for screen-based programs. In theory it did but in practice it didn't; the screen display routines provided by the operating system were so slow that we all wrote directly to video RAM instead, which meant our programs would only run on an IBM PC or clone.
CP/M was in a sense the precursor of MS-DOS. Did it provide practical compatibility for screen-based programs? Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?
cp-m
I refer here to 'screen-based programs' that are not actually graphical, but take full advantage of the screen as a two-dimensional array of 80x25 characters, as opposed to typical 'command-line programs' whose output is essentially one dimensional.
MS-DOS provided compatibility for command-line programs. A single binary could run on many different and incompatible computers, provided they all ran MS-DOS.
MS-DOS did not provide compatibility for screen-based programs. In theory it did but in practice it didn't; the screen display routines provided by the operating system were so slow that we all wrote directly to video RAM instead, which meant our programs would only run on an IBM PC or clone.
CP/M was in a sense the precursor of MS-DOS. Did it provide practical compatibility for screen-based programs? Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?
cp-m
cp-m
asked 2 hours ago
rwallacerwallace
7,776336110
7,776336110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.
In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.
The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.
A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.
Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):
Output support is pretty wide:
All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).
Input selection is no more complicated than asking the user to press the keys they want:
It goes on a while — that's just the first screen.
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
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%2f8702%2fdid-cp-m-provide-compatibility-for-screen-based-programs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.
In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.
The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.
A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.
Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):
Output support is pretty wide:
All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).
Input selection is no more complicated than asking the user to press the keys they want:
It goes on a while — that's just the first screen.
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
add a comment |
Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.
In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.
The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.
A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.
Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):
Output support is pretty wide:
All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).
Input selection is no more complicated than asking the user to press the keys they want:
It goes on a while — that's just the first screen.
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
add a comment |
Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.
In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.
The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.
A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.
Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):
Output support is pretty wide:
All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).
Input selection is no more complicated than asking the user to press the keys they want:
It goes on a while — that's just the first screen.
Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.
In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.
The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.
A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.
Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):
Output support is pretty wide:
All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).
Input selection is no more complicated than asking the user to press the keys they want:
It goes on a while — that's just the first screen.
edited 2 hours ago
answered 2 hours ago
TommyTommy
13.8k13767
13.8k13767
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
add a comment |
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
Terminals? I thought CP/M was mostly used on classic microcomputers with video memory in the CPU address space. Are you saying most CP/M computers used a serial terminal for their display?
– rwallace
2 hours ago
1
1
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Yes, it originated on computers of the Altair 8800 form where one would actually have to locate and attach a real terminal, and most microcomputer implementations then just emulated one of the classic terminals. Some with the video memory in CPU address space, some without.
– Tommy
2 hours ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
Now that is interesting. Thanks!
– rwallace
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
MSDOS provided a similar functionality through the ANSI.SYS driver, where you could output terminal (VT100 subset) escape sequences to the console and control the screen display.
– mannaggia
1 hour ago
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f8702%2fdid-cp-m-provide-compatibility-for-screen-based-programs%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