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?

rwallace
  • 60,953
  • 17
  • 229
  • 552
  • 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 '19 at 05: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 '19 at 09:32
  • 1
    Check also this Answer to a mostly related question of yours half a year ago :)) – Raffzahn Jan 10 '19 at 13:16
  • It is interesting to see CP/M enthusiast in 2018 :) – i486 Jan 10 '19 at 14:27

4 Answers4

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.

Tommy
  • 36,843
  • 2
  • 124
  • 171
  • 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 Jan 10 '19 at 02:48
  • 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 '19 at 02: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 '19 at 03: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 '19 at 05: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 '19 at 05: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 '19 at 12:03
  • 1
    @manassehkatz: On the Apple I, the screen memory wasn't RAM at all, but instead consisted of seven 1024-bit shift register chips (six to hold character codes, plus one to keep track of which character was active). – supercat Jan 10 '19 at 22:29
  • 1
    @supercat Quite true about the Apple I. But the Apple I couldn't run CP/M (wrong CPU). – manassehkatz-Moving 2 Codidact Apr 05 '19 at 14:00
  • @manassehkatz: The Apple I doesn't run CP/M, but is the only specific machine I know of which definitely held screen contents in shift registers. I would guess many CP/M machines used a similar architecture, though I don't know the specifics. – supercat Apr 05 '19 at 17:01
  • @supercat I wouldn't be that surprised if there were some CP/M machines that did something like what the Apple I did. But I think far more common were either "ordinary RAM memory mapped screen" (e.g., Osborne 1 = 64k, 60k for code/data, 4k for video) or serial I/O, even when everything is in one package - e.g., H/Z-89 which had two processors - one for CP/M (or HDOS) and one for the terminal. – manassehkatz-Moving 2 Codidact Apr 05 '19 at 17:22
  • @Codidact You typically only want a single byte for a screen location so 2k. You still need the BDOS and the BIOS. The system I used had a 56 kB TPA. – Thorbjørn Ravn Andersen Oct 03 '20 at 13:19
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.

Thorbjørn Ravn Andersen
  • 2,262
  • 1
  • 14
  • 25
  • 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 '22 at 17:25
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.

john_e
  • 7,263
  • 20
  • 44
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.

C64
  • 19
  • 1
  • 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 05 '19 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 05 '19 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 05 '19 at 14:07
  • Typo (too small for me to fix directly): s/life/live/ – Toby Speight Apr 05 '19 at 14:33
  • 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 03 '20 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 '22 at 16:28