14

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?

Improve this question
4
  • 4
    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-Moving 2 Codidact
    Jan 10, 2019 at 5:29
  • 3
    Simply: No. CP/M is based arount the idea of a terminal and as usual, control codes are terminal specific. Similar MS-DOS.
    – Raffzahn
    Jan 10, 2019 at 9:32
  • 1
    Check also this Answer to a mostly related question of yours half a year ago :))
    – Raffzahn
    Jan 10, 2019 at 13:16
  • It is interesting to see CP/M enthusiast in 2018 :)
    – i486
    Jan 10, 2019 at 14:27

4 Answers 4

Reset to default
23

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 launching TINST the user may configure either the screen or commands (i.e. keyboard control codes):

enter image description here

Output support is pretty wide:

enter image description here

All of which are 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:

enter image description here

It goes on a while — that's just the first screen.

Improve this answer
11
  • 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
    Jan 10, 2019 at 2:50
  • 3
    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
    Jan 10, 2019 at 3:55
  • 1
    @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-Moving 2 Codidact
    Jan 10, 2019 at 5:26
  • 2
    @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-Moving 2 Codidact
    Jan 10, 2019 at 5:26
  • 1
    @rwallace Most had video memory but CP/M did not have an API for it. Only the "print single character" and "print string up to $" functions. Some applications - like WordStar - could be patched to talk to video memory directly, but it wasn't an operating system feature.
    – Thorbjørn Ravn Andersen
    Jan 10, 2019 at 12:03
4

To add to the other answers: While there was no support in the operating system itself, there were a couple of attempts at a terminal abstraction library that could be linked with programs. GSX (mentioned above) contains a set of text-mode output functions for cursor positioning, clearing areas of the screen and so forth, though it would have been a very heavyweight solution to link the entire GSX system just for its text mode functions.

ZCPR (a replacement command processor for CP/M written by a group of hobbyists) eventually gained a terminal capabilities library. The characteristics of a terminal would be stored in a .Z3T file, which would be used by any ZCPR-aware program for screen highlighting, cursor movement etc.

Improve this answer
4

Others have covered the bit that CP/M did not provide any abstraction of the output device so each program needing it, had to be instructed in what characters - usually escape sequences - should be sent to the console to do a specific task ("termcap").

I just want to mention that WordStar not only had the ability to shortcut printing out menus and other information by pressing a key, which was then interpreted, but also the ability to write directly to display memory to get very fast output. To my knowledge no other commercial program supported that. It even saved memory so larger documents could be edited without needing to access the diskette (which was very slow)

It is described in the Wordstar 3.0 Installation Manual in the section "DIRECT STORAGE ON A VIDEO BOARD" on page 6-5.

Improve this answer
1
  • WordStar was not limited to editing files that could fit in memory. Moving around a document does slow down once it doesn't all fit in ram however.
    – Brian
    Oct 14, 2022 at 17:25
0

Actually, MS-DOS doesn't give you any enhanced compatibility. The screen simply was MGA/CGA/EGA/VGA text mode which was 80xSomething by default. Cursor positioning, etc was done by BIOS calls and the programs ran directly on the CPU and the programmer could do whatever he pleased. It was just a nice-to-have to return to a functional DOS after the program was done.

So MS-DOS had to run on IBM-PC or compatible which meant MDA/CGA compatible hardware screens.

CP/M on the other hand was for any hardware, mostly mechanical teletypes at first. Terminals had really evolved after CP/M had created a market for more complex terminals. In early computing, you mailed in your punchcards or tapes and got them back with a printout of the results. "Hacking" - typing in stuff life on a computer - wasn't common before the late 1970s.

Improve this answer
6
  • 5
    I am not sure that MS-DOS "had to run on IBM-PC or compatible". Some computers not compatible with the IBM ran MS-DOS quite happily. Also, did CP/M really create a market for more advanced terminals?
    – Omar and Lorraine
    Apr 5, 2019 at 13:54
  • 1
    1 - As @Wilson stated, MS-DOS did not require an IBM-PC or compatible and did not require a memory-mapped screen; 2 - the market for more complex terminals evolved rapidly in the 1970s but due to a wide variety of factors - microcomputers including far more than CP/M, plus minicomputers - e.g., DEC, Data General, etc. CP/M was flexible enough to work with pretty much anything character based (as opposed to a 3270), 3 - "mail in your punchcards or tapes" - no, the norm was hand them in at the mainframe batch processing desk for punchards and get back your printout later - punched tape was far..
    – manassehkatz-Moving 2 Codidact
    Apr 5, 2019 at 14:05
  • interactive with many minicomputers and even micros (Altair Microsoft Basic) as it allowed punching offline but still interactive once you loaded the tape.
    – manassehkatz-Moving 2 Codidact
    Apr 5, 2019 at 14:07
  • 2
    A CP/M BIOS could emulate a terminal on its own if it wanted to - CP/M itself didn't care. The Z80-machine I started with did exactly this. it turned out that the display controller could be configured to show the last 48 bytes too as half of a 26'th line where I ended up putting a clock and other information after having reverse engineered the bios.
    – Thorbjørn Ravn Andersen
    Oct 3, 2020 at 13:16
  • 1
    @ThorbjørnRavnAndersen it didn't even have to be in the BIOS. My Z80 machine had a 2K ROM that I programmed myself, and it had a full terminal emulator in it. I think it used the VT-52 escape sequences.
    – Mark Ransom
    Oct 18, 2022 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .