Jump to content
IGNORED

CP/M compatibility across different formats?


Recommended Posts

This is probably a mind-bendingly dumb question for some of you, but I'm finally ready to admit I need help understanding this.

 

I understand CP/M compatibility was a big deal for a time BITD, as it was probably the closest thing to a "standard" operating system in the late '70s and early '80s until MS-DOS dethroned it. And basically every [Z80-based] system had it: TRS-80, TRS-80 Model II, Apple II w/ Z80 card, KayPro, Cromemco, etc.

 

As I understand it, the idea was that the same software could be run on a variety of systems.

 

What I don't understand, is how this compatibility is possible when every system has its own disk format. Even if the data or code or whatever was software-compatible, CP/M disks for, say TRS-80 and KayPro, couldn't actually be read by one another, right?

 

A good example: I have Pickles & Trout CP/M for my TRS-80 Model II, and a stack of Cromemco 8" CP/M software that can't be read by it.

 

Hit me with some knowledge, plz. :)

  • Like 2
Link to comment
Share on other sites

Naturally, disk formats would need to be converted.. Especially between 5.25 and 8 inchers. Other than that there might be machine-specific formatting for different displays and keyboards.

 

It be like something written generically, like Stella or MAME, and compiled for each platform. In that way it's compatible. You just don't take a binary from Apple and run it on TRS-80 Model II.

Edited by Keatah
  • Like 1
Link to comment
Share on other sites

Naturally, disk formats would need to be converted..

 

But how would you do that without reformatting (and therefore erasing) the disk? Is there a utility within CP/M that does this? I've looked into the various commands and PIP but none of them seem like they would serve this function.

  • Like 1
Link to comment
Share on other sites

The actual disk I/O is hidden behind OS calls, and the hardware can differ from one machine to another.
Some CP/M formats only differed in how the data was arranged on disk, but it doesn't even have to use a disk drive, it could be a tape drive, or some other random access device,
There are several CP/M machines with tape drives.
A few systems that had flexible enough hardware could transfer from one format to another by using a special utility, but I've long forgotten the name of it.
I was never really a CP/M person.

Worst case, all it really takes to get the software running on a different system is transferring files over a serial connection.
There were also issues with a few different screen widths, but you usually had 80, 64, or 40 columns patches, or configurable widths.
If you have 80 columns, it's probably not an issue, but you may have to find the right terminal settings for a given machine since that was controlled by the software itself if I remember right.

  • Like 2
Link to comment
Share on other sites

The only "standard" CP/M format was 8" SSSD. Everything else was basically a custom format, especially on 5 1/4" disks, where they had hard sector, soft sector, 128-byte sectors, 256-byte sectors, 35/40/80 tracks, single-density, double-density*, and I guess different starting tracks too, based on how much was reserved for boot/BIOS/BDOS. And of course Apple II CP/M would use nibble format. And that's assuming there weren't some parameters for high-level disk allocation sizes, I can't remember right now if there were.

 

* I don't remember if CP/M was still relevant by the time of 5 1/4" HD, but IIRC it basically treated the entire drive as 8" double-density.

Edited by Bruce Tomlin
  • Like 3
Link to comment
Share on other sites

Speaking as someone who dealt with this on a daily basis:

 

Yes, CP/M programs were compatible.

 

Yes, the problem was disk formats, usually. The other big difference was mostly with terminal programs that talked to serial ports directly, as most programs that did printer like things just talked to the devices exposed by the BIOS.

 

For 8 inch disks, this wasn't that much of an issue, as most systems with 8-inch disk formats could at the very least read the IBM 3740 format, which could hold approximately 241K of data, and was soft sectored. This wasn't everybody, Altair disk systems for example had a 16 hole hard-sectored format that held about 337K of data, but nothing else could read them.

 

The 5 1/4" disk systems were far more chaotic, because while there WAS an IBM standard (System/34) it wasn't adhered to, and many disk systems tweaked the basic format, but there were some systems you could pin a flag to as a common point. The most common interchange format for 5 1/4" CP/M disks was a variant of the IBM 3740 format for 5 1/4" disks that held roughly 90K of data that was commonly used by the Xerox 820 machines. Many CP/M systems had programs that would reprogram the disk controller to read these disks and you could at least copy stuff off of them, some CP/M systems had disk definition tables in their BIOS, which could be altered at run-time, (The ATR8000 was a good example of this, the Big Boards did this too.). For the ATR8000, this was the DISKDEF utility. so you could quickly set e.g. drive B: to read a disk from an Osborne 1 or a Superbrain, to copy stuff off.

 

Failing this, there was always the MODEM. This was actually one of the reasons that RCP/M systems sprang up, and why XMODEM exists (and why XMODEM had a 128 byte block, it corresponded exactly to a CP/M BDOS sector). You would have two systems hooked up either via MODEM or serial link, and use XMODEM (or even just PIP over a straight serial link) to transfer a program from one system to another. PIP could be used to bootstrap XMODEM to a system that didn't have it.

 

-Thom

Edited by tschak909
  • Like 5
Link to comment
Share on other sites

Commodore's 1571 could handle a variety of disk formats. Back in the day a friend gave me a disk with a CP/M program on it from his TRS-80 and it ran just fine on my C= 128, though I seem to recall it was slower than on his system.

 

Lest we forget that CP/M on the Commodore 64 and the 1541 uses the native GCR format for all sorts of non-interchangeable goodness. The wonderful thing about the 1571 is the 1772 is programmable for virtually any MFM format, but IIRC only MFM as FM is physically disabled in the 1571.

Link to comment
Share on other sites

On a random related note, I was just going through some random Apple cards and parts I have stashed away, and found a Microsoft Premium Softcard IIe that I completely forgot I had! :)

 

Can't remember where it came from. I just hope I didn't accidentally chuck out or reformat any CP/M disks I might have had when they wouldn't boot under Applesoft...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...