Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 29

Thread: Curious about CP/M; how compatible were CP/M systems with each other, generally?

  1. #1
    Join Date
    Mar 2016
    Location
    Georgia, USA
    Posts
    650

    Default Curious about CP/M; how compatible were CP/M systems with each other, generally?

    Never used CP/M before in my life, but there's a pretty astonishing variety of CP/M machines out there going back to the early, early days of personal and business computing.

    Is CP/M software generally compatible across a broad range of these machines? Or was each system essentially provided with it's own CP/M implementation and software library?

  2. #2

    Default

    CP/M came in roughly 4 parts: the BIOS, the BDOS, the CCP, and then programs.

    The BIOS is the lowest level and was machine specific and had to be ported to each different pieces of hardware.

    The BDOS was the interface layer between the programs and the BIOS. This was much more portable as it was supposed to rely directly on the BIOS for it's access to peripherals.

    The CCP is the "shell", the command prompt, of CP/M. It stands out as a little different than generic application programs because it was typically loaded in to high memory (unlike normal programs), and programs had the option of simply returning to the CCP (which called them), or warm starting CP/M forcing a complete reload of the CCP.

    At the application level, the programs were generally portable. Where this broke down was dealing with the variety of terminals, printers, disk configurations, etc. across the machines. Also there were applications the bypassed the BDOS and BIOS that became machine dependent (Kermit is notorious for this, for example).

    So, even though you have a portable binary, there were likely several steps necessary to actually get it to run on your hardware.

  3. #3

    Default

    Quote Originally Posted by whartung View Post
    ...

    So, even though you have a portable binary, there were likely several steps necessary to actually get it to run on your hardware.
    I'll just add that a wide variety of applications were portable. Some, like Magic Wand word-processor, provided overlay modules for terminal and printer and one could often find existing modules to match their peripherals. The core CP/M utilities and assemblers did not require any porting (things like SYSGEN and FORMAT were custom for the platform, though). Some software providers would ship special versions of their software targeting specific platforms (like a "cheap" version for Heathkit users), even though the software itself was platform independent. This often involved some "platform detection" routine during program start that would refuse to run if the correct platform was not detected. So, one usually had to test whether or not they could run, if it came from some "outside" source. But, I believe most things would run - again depending on details like terminal screen control codes or printer formatting codes (if the software depended on those).
    - Doug

  4. #4

    Default

    I guess the other angle on your question was "how compatible was the hardware". In stark contrast to the PC world, the hardware was quite diverse and not very compatible at all. This speaks to the "genius" of Gary Kildahl, Digital Research, and CP/M, as they successfully created an ecosystem that functioned quite well, all things considered.
    - Doug

  5. #5
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,967

    Default

    If you are using CP/M in an office-type application, then it should be fairly portable. The issues are going to be more customisation to terminal type.

    A lot of CP/M programs were used for industrial applications, and this requires potentially bespoke hardware. Combining CP/M with the S-100 bus potentially opened the market for this type of application.

    CP/M ‘hides’ the details of the underlying hardware, providing a unified interface to the disk filing system.

    Combined with CP/NET permitted interoperability at the network level.

    Stock, inventory and warehouse control was certainly something I know about. Our local car showroom / garage dealership used Cromemco equipment to run their operation across the UK.

    Of course, it’s all gone now!

    Dave

  6. #6

    Default

    Quote Originally Posted by durgadas311 View Post
    In stark contrast to the PC world, the hardware was quite diverse and not very compatible at all.
    Can you explain that? The CPU of a CP/M system was almost always Z80. While there were ports to e.g. x86, these broke compatibility. PC hardware was way more different between the IBM ones, clones, Tandy 1000 etc. and still MS-DOS and its applications did run on all.

    It's also worth noting that CP/M was text-only by default.
    Last edited by Timo W.; August 10th, 2020 at 07:37 AM.

  7. #7

    Default

    Quote Originally Posted by Timo W. View Post
    Can you explain that? The CPU of a CP/M system was almost always Z80. While there were ports to e.g. x86, these broke compatibility. PC hardware was way more different between the IBM ones, clones, Tandy 1000 etc. and still MS-DOS and its applications did run on all.
    It's difficult to defend something that seems obvious to me. There were early 8086 machines that were considerably different from the IBM PC, but in general that was considered inferior in a lot of circles, and hence the "clones" - which in the beginning were risking the wrath of big blue by being too faithful of copies. It is true that MS-DOS/PC-DOS defines a BIOS API (now in ROM) and that was hardware independent, in the end the market seemed to heavily favor hardware that was similar/identical to the IBM PC. There was an awful lot of early software that directly accessed the video console hardware, for example (the BIOS interfaces were just too slow/clumsy).

    While both the PC world and CP/M-80 world restricted themselves to a particular CPU family, I saw a great deal more diversity in CP/M systems designs compared to the MS-DOS/PC designs.
    - Doug

  8. #8

    Default

    For 5.25" Floppy Formats- it seemed every manufacturer had incompatible formats. 8"- much more compatibility.
    Order software for a 5.25" system, you had to specify what computer you were using.

    Keyboards- lots of differences. I used ZSID to change the keyboard mapping for Wordstar 3.3 to use the arrow keys, page-up, page-down, and other special keys on my Xerox 820-II keyboard.

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,917
    Blog Entries
    18

    Default

    Ignore the nonsequiturs about BIOS and hardware interfaces; consider that a lot of CP/M programs were written for the Z80 ISA, even though CP/M systems using 8080 and 8085 CPUs were quite common.

    IOW, CP/M itself was pretty hardware-independent; the applications written for it, less so.

  10. #10

    Default

    I wouldn't say they're exactly non sequiturs, although the points could stand a lot more elaboration in order to be clearer and less misleading. Essentially, CP/M had the same problem that MS-DOS did, in that it provided reliable, standarized interfaces...for about half of the functionality people actually needed. So if all an application needed to do was read some stuff from a file and then fire off plain ol' ASCII to a TTY or a thing pretending to be a TTY, no problem. If, on the other hand, it needed to set a timer, or configure a serial port to a specific speed/format, or do screen-oriented terminal control codes in a terminal-independent way...no such luck. So people had to roll their own solutions for things that the BDOS/BIOS didn't provide, and that's where compatibility ran into trouble.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •