CP/M Porting In A Few Hours

If you’ve ever wanted to watch someone bring CP/M up on a new system and you have a couple of hours to spare, check out the recorded live stream of [Poking Technology]. The system in question is an Agon Light, a modern board with a Z-80-derived CPU. If you want to get right to the porting part, you might want to skip about 31 minutes of the nearly 2.5-hour video.

The first half hour is more about the built-in assembler and the board in general. If you’ve ever ported CP/M before, you know it isn’t as hard as bootstrapping a modern operating system. There are two major things you need: A BIOS, which is specific to your machine, and a BDOS, which is usually taken verbatim from the operating system sources. Your programs typically call one of the 40 or so functions in the BDOS.

The BIOS has about 20 functions you must provide and is mainly called by the BDOS. While BDOS worries about things like directories and file structure, the BIOS simply reports information about disks and devices and lets a caller directly access those things.

Part of the task of creating a BIOS involves building data structures to describe the disk hardware. You also provide a jump table with a few common functions. For the original CP/M there were only 15 functions. CP/M 2 added two more. CP/M 3 added a whopping 16 functions. The functions fall into three broad categories: system management (like BOOT and WBOOT), device I/O (like CONIN and PUNCH), and disk I/O (like HOME, DETTRK, and READ).

As you’ll see in the video, it doesn’t take much to write the handful of functions you need. CP/M is small, software-wise. It can be small physically, too. While it is perhaps more satisfying to run it on period hardware, it is easier to run it on new devices and they don’t even have to be very complex, either.

13 thoughts on “CP/M Porting In A Few Hours

  1. Awesome! I just love CP/M – and MP/M, too!
    For one because it’s DOS like and because it can be completely understood by a single individual.
    My father used it back in the 70s on a Sharp MZ-80K, which he wrote his own floppy code for.
    Afaik, he adapted the screen to have scrolling, so 80 characters could be used (80×24 was terminal standard; 25th line was status line).

    That was in a time when it was still widely known as Control Program/Monitor.
    Thanks to the Z80, Turbo Pascal could be used, even. And MBASIC (BASIC-80), of course.
    The CP/M programs he wrote were used at university, too.
    Some of which were pretty complex (calc. of behavior of fluids).

    You have to understand how important CP/M’s portability was at the time.
    Yes, most Linux freaks would may say “no, it’s not portable because of machine code dependency.. yadda.. yadda.. yadda..”
    Well, that’s partly true. The normal CP/M required an 8080 or compatible CPU, but the BIOS was portable.
    (There also was CP/M 68000 and CPM-86 and some more werid versions, maybe.)
    So except for BIOS and terminal type (serial model or CRT device), there was no (little) difference among the PCs.

    So binary applications could run on a variety of different PCs with different capabilities.
    Which means, it was possible for a poor student to write a program for university at home.
    All he/she/they needed was a simple Z80 “toy computer” (home computer) with 32 to 64KB of RAM and a floppy drive.
    The same application would then run on university at a much more capable, serious PC.

    This is something that mustn’t be forgotten, I think. CP/M provided both a standardized API and ABI first time.
    That’s why there were so many CP/M emulators for about any computer, even the poor C64.
    It built a bridge among different platforms, without dominating them.

    And like with Linux, there were many “distros” out there. CP/M had many compatible spin-offs.
    About every country or larger company had a CP/M look-a-like at hand that could run CP/M 2.2 programs.

    1. I forgot.. The Kermit protocol was also part of the CP/M and DOS era.
      It was so small that it could be typed in manually at a foreign computer.
      Once that was done, programs and data could be transferred vial null-modem connection.
      That way, the issue with the various 5,25″ floppy formats could be bypassed.
      (There was an official CP/M floppy format, but it was from the days of 8″ floppy drives.
      It still worked on 5,25″ drives, but it became highly inefficient, so it was rarely used anymore.)

      1. Ah Kermit, saved my rear several times. I had forgotten that spaghetti mess of floppy formats and TMJ it gave me. It got even weirder with people doing their own home setups as you mentioned and the suped up rigs with their own quirks or extended bioses etc. It was an excellent way to just get the data from a to b without several code bosses to fight lol. Great memories of the floppy light shutting off after an otherwise impossible save. Thanks :)

      2. Cross-platform development in the (relatively) early days?

        ‘From the KERMIT-80 user’s guide: “[An 8080/8085/Z80] cross assembler is provided that runs on the DEC-10 and DEC-20, called MAC80(*), contributed by Bruce Tanner at Cerritos College, that may be used for cross assembling KERMIT-80 as shown in this example (for TOPS-20) …”

        The cross-assembler would generate an ASCII “.HEX” file that could be downloaded (by hook or crook) to CP/M, which had a built-in command to convert the file to a CP/M executable.’

        * In other words, Tanner used the DEC macro assemblers to generate Z80 et al code.

  2. In a time far ago my brother had an apple II an I had the C64.
    The apple had a built in monitor with a disassembler and i wanted that on the Commodore so we had a parallel setup and he read hex codes from the rom listing and i entered them into to the C64.

    Worked first time.

  3. Thank you for the kind words!

    I have, BTW, a complete rewrite of CP/M for the 6502. It runs on pretty much every popular 6502 microcomputer out there (with varying degrees of success — a DOS with 1541 drive speeds is a miserable experience). All it needs now is some software…

        1. I had seen the “someone else’s better CP/M port” and when watching the video didn’t realize that this port wasn’t that one until I got to the final section of the video where you mentioned that someone else had done a port at the same time you were doing this one. The light bulb went off, “Ah, so THAT’S why he never mentioned how he was going to upgrade it to handle multiple disk images!”. But it was still a fascinating look at the use of an 8bit basic with an embedded assembler as a kind of macro assembler.

  4. I hacked cp/m and co-joined a vt100 emulator using a 340×220 lcd on an esp32, absolutely cracking having the CP/M software repository available, it ran as good as or better than I recall on the original hardware in something the size of a pack of cards.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.