8

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?

  • 1
    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-Reinstate Monica Jan 10 at 5:29
  • 2
    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 at 9:32
  • 1
    Check also this Answer to a mostly related question of yours half a year ago :)) – Raffzahn Jan 10 at 13:16
  • It is interesting to see CP/M enthusiast in 2018 :) – i486 Jan 10 at 14:27
15

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.

  • 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 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 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-Reinstate Monica Jan 10 at 5:26
  • 1
    @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-Reinstate Monica Jan 10 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 at 12:03
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.

  • 3
    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? – Wilson Apr 5 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-Reinstate Monica Apr 5 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-Reinstate Monica Apr 5 at 14:07
  • Typo (too small for me to fix directly): s/life/live/ – Toby Speight Apr 5 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.