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
asked 23 hours ago
rwallacerwallace
7,835336110
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
asked 23 hours ago
rwallacerwallace
7,835336110
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
1
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago
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
asked 23 hours ago
rwallacerwallace
7,835336110
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 23 hours ago
rwallacerwallace
7,835336110
asked 23 hours ago
rwallacerwallace
7,835336110
asked 23 hours ago
rwallacerwallace
7,835336110
asked 23 hours ago
rwallacerwallace
7,835336110
asked 23 hours ago
rwallacerwallace
7,835336110
7,835336110
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
1
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago
add a comment |
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
1
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
1
1
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago
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.
answered 22 hours ago
TommyTommy
13.9k13868
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
22 hours ago
7
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
22 hours ago
2
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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
|
show 2 more comments
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.
answered 22 hours ago
TommyTommy
13.9k13868
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
22 hours ago
7
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
22 hours ago
2
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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
|
show 2 more comments
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.
answered 22 hours ago
TommyTommy
13.9k13868
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
22 hours ago
7
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
22 hours ago
2
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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
|
show 2 more comments
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.
answered 22 hours ago
TommyTommy
13.9k13868
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.
answered 22 hours ago
TommyTommy
13.9k13868
edited 22 hours ago
answered 22 hours ago
TommyTommy
13.9k13868
answered 22 hours ago
TommyTommy
13.9k13868
answered 22 hours ago
TommyTommy
13.9k13868
13.9k13868
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
22 hours ago
7
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
22 hours ago
2
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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
|
show 2 more comments
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
22 hours ago
7
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
22 hours ago
2
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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 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
22 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
22 hours ago
7
7
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
22 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
22 hours ago
2
2
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
21 hours 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
21 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace I think (but no proof without research that I don't have time for) that the vast majority of CP/M systems used a 24x80 moderately smart terminal (or occasionally smaller, but 24x80 was the de facto standard) and escape/control codes to do the work. Turbo Pascal raised everything to a fine art, but WordStar and plenty of other programs did this too.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
@rwallace There were plenty of "integrated" systems where the built-in terminal was actually a separate device either using an actual serial (RS232) port or an I/O port of some sort to communicate with the main 8080/Z80 CP/M system. That had a big advantage that the 2K (sometimes more) of screen memory plus the character ROMs and terminal logic code did not cut into the very tight 64K CP/M memory map.
– manassehkatz
20 hours ago
|
show 2 more comments
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%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
For the few systems that did use a memory mapped display, it was almost always 80x24 not 25. 80x25 was an IBM PC thing and occasionally used elsewhere (e.g., function key labels on Wyse 100 and other terminals) but the target display for CP/M software was 80x24.
– manassehkatz
20 hours ago
1
Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
– Raffzahn
16 hours ago
Check also this Answer to a mostly related question of yours half a year ago :))
– Raffzahn
12 hours ago
It is interesting to see CP/M enthusiast in 2018 :)
– i486
11 hours ago