Commodore C64 & CP/M: hands-on! (Part 2/2)

[@christopheoberrauch784]

You have to be a little crazy to run CP/M on a C64 in 2024. Just great what you have tried, unbelievable what hurdles have to be overcome. Thomas Tempelmann, a name that has made C64 history. Unbelievable that you were able to contact him. What brilliant detail work.

[@THEPHINTAGECOLLECTOR]

@@christopheoberrauch784 just a bit crazy… but more curious! ^^

[@mudi2000a]

The 1571 can even read MS-DOS floppies with the appropriate tools on the C128. But when the C128 came out it was already too late for CP/M as DOS was in the rise.

[@jussiala-konni288]

Yes, and C128 recognizes and formats C64 CP/M disks. So C128 CP/M can be used to copy stuff from MFM disks to C64 CP/M disks. This works both with real hardware and in emulation. Z64K emulator supports reading .imd image format, which gives access to archived CP/M stuff.

[@SamK4074]

Brilliant work! Quite the headache creating appropriate disc images for it though; I appreciate you jumping through the hoops to both demonstrate the CP/M cartridge & its shortcomings, as well as explain exactly how you got there so that anyone else crazy enough to try it, be it via emulation or on real hardware, can. Both CP/M and the C64 pre-date myself, so I've never had hands-on experience with either, but I finding it incredibly interesting nonetheless; I'm enjoying this series so far!

[@danielktdoranie]

So I always test stuff out on emulation before trying to make it work on the real retro hardware: it’s a smart move that you do this!

[@THEPHINTAGECOLLECTOR]

@@danielktdoranie Sometimes emulation saves time. Though I also ran into occasions when things didn‘t work but on the real hardware.

[@tlhIngan]

GCR was used a lot on drives that had their own developed controllers - Apple II, Macintosh, Commodore, etc all either used a software defined controller, or an in house developed controller. MFM disks used a standard floppy controller chip like on the IBM PC. Unfortunately, GCR describes many oddball formats so compatibility was basically nil between them. The 1541 had "DOS" built into it, so it handled the disk format independently of the computer. That's why you had to load "*" and list - the drive managed the disk file catalog and transferred back a BASIC program that the computer could handle. The drive could also run programs on its internal processor - this is what many fast loaders used, Likely as well, CP/M for Commodore 64 loaded in a special program for the 1541 to access CP/M disks. You probably would need something like a Pi1541 which emulates the 1541 CPU to be able to access CP/M disk images. SD2IEC fakes a lot of the fastloader implementations, but doesn't emulate them, whilst Pi1541 emulates the actual 1541 hardware.

[@kFY514]

What was the software compatibility situation in general in the CP/M-80 era? I remember that in the IBM PC / MS-DOS era, basically every application that did something useful did talk to the hardware directly in some capacity, because the official BIOS and DOS APIs were not only painfully slow, but also so limited that AFAIR you couldn't even write a text-mode word processor without accessing the video memory directly, let alone anything that used the graphics mode. Were the CP/M APIs more comprehensive? How was the multitude of floppy disk formats handled? Were CP/M applications released in multiple variants for different computers anyway? If so, did they usually differ in floppy disk formatting only, or was the code actually different between them? I'm just trying to grasp how useful CP/M was as a "standard" if the interoperability was so heavily limited.

[@THEPHINTAGECOLLECTOR]

TBH, I can't answer all those questions (yet ...). I'm just starting to get into CP/M myself. The power of CP/M was surely the overall hardware abstraction layer it introduced, as that was not commonly known before, except for the floppies, where a lot was left to the vendors to implement. I explored the floppy formats to some extended already in a previous video. And yes, it was terrible. For certain, vendors published their software on the most common formats at the time. I can't tell, if there weren't cases, where programmer's also took shortcuts via direct hardware access. Propably it was a mix of both, IDK. But for certain, certain programs like Basic, Multiplan, WordStart, and others, were available for most if not all systems. And I think the largely used the CP/M API, which actually is similar to the DOS API (as DOS actually cloned the CP/M API ...). But so far I haven't really tried running lot's of software accross systems. I'll do that one day, in order to see how portable they really were. However, from what I've read, it was quiet possible to take CP/M software that ran on the Apple II Z80 board, and run it elsewhere. I'm inclined to say that for commercial software, they propably went the API-way, to leverage the CP/M API, for portability reasons. But maybe some of the viewers of this channel had actual hands-on back in the day. I'm sure there's someone better qualified to answer this in full extend.

[@phill6859]

CPM software mostly had to be customised with your terminals escape codes. The first cpm machines just had whatever random serial terminal hooked up and there was no standard or API. You would tend to buy a computer for one application and you would usually go to someone who would sell you one that they had patched an application to run on it. WordStar was generic enough that you could configure it for anything, and they documented it rather well. But most people wouldn't know what it meant. Other applications were less configurable. Later on when the computers included built in console, some computer manufacturers licenced the software and sold it pre configured.

[@kFY514]

@@phill6859 Yeah, after writing my original comment I remembered the ANSI escape codes and how they're still there norm for TUIs on Unix-like systems, and even MS-DOS included ANSI.SYS from version 2.0 onwards, even if not much used it (and there wasn't much need to, because there was compatibility on the hardware level). Did CP/M machines typically support ANSI escape codes, or not really?

[@daybyter]

@@kFY514 I bought Turbo Pascal and it came with an installer, where you selected the terminal type. I am not sure which type I had to select on the c64 (vt52 maybe?), but after a successful config, you could move the cursor around etc. I know, that it worked, because I wrote a text editor with Turbo Pascal, that used those terminal commands a lot.

[@8randomprettysecret8]

Impressive features

[@NiceCakeMix]

Really nice and well explained CP/M video. Thank you for sharing it

[@THEPHINTAGECOLLECTOR]

@@NiceCakeMix my pleasure! ^^

[@slincolne]

It looks like the objective of the Z80 card for the C64 was to show the FTC that Commodore did produce it as they promised. It's likely good enough to run some code, with code that fails being an edge case that (like with other CP/M systems) not completely compatable. Good enough for lawyers to argue over, but not good enough for real end users to use.

[@Kw1161]

Thanks for this blast from the past, I remember when I owned a Amiga 500 until the power supply took it out. Before that I was eyeing buying the “Fred Fish CD’s” one of the programs was CP/M but pre internet I couldn’t find enough information to make running CP/M worthwhile for me. What Commodore should have made for the Amiga was a C64 emulator or better C128, then Cp/m if their business clients wanted to run it. Oh well they were run by a marketing team that wanted to charge the “Star Trek 3” production team over $50,000 dollars to use their Amiga…and Apple provided theirs for free…and now is one of the biggest companies on earth…and Commodore….?…sad. Have a great day!

[@ChrisCebelenski]

The product was half-baked and as you point out, a forced release. C= certainly could have improved it, especially the disk access and formatting - the 1541 could do a lot of things because it was programmable, hence things like fastloaders, etc. Most of the improvements however were later tricks for the C64 - 80 columns would have been easy, and I wrote a vt100 emulator for the C64 that did that. Fastloaders I think were later than the C64 carts, but I never had my CP/M cart for long (returned it) so never found out. In the end, CP/M for the C64 wasn't all that interesting, and because of the disk format not even approachable, but I don't think C= even considered it a first-class operating environment. C128 CP/M suffered from it's own limitations, and it's I/O system was absolutely maddeningly slow too.

[@phill6859]

Dolphindos is the best drive accelerator to use with cpm. Jiffydos works as well, but isnt as fast.

[@THEPHINTAGECOLLECTOR]

@@phill6859 good hint, thx 🙏 ! I‘ll have a look.

[@toddalancox]

Seems like I mostly just programmed z80 assembly on the C64 CP/M. The C128 with the 1571 drives was a much better situation.

[@negirno]

I have to ask that who is this product was for? Maybe on paper it made sense because one could save money this way by not buying a separate Z80 computer with its own monitor and accessories, so one could enjoy the best of both worlds, but the seeming lack of commitment and different floppy disk formats made this a folly. Maybe it's just hindsight that blinds me by thinking that the C64 was always a product for kids and teens to play video games and program in basic?

[@THEPHINTAGECOLLECTOR]

That's an absolute valid question. I think one must look at this from a certain perspective. When Commodore brought the C64 along in 1982, it was by no means meant only as a "gaming machine". On the contrary, Commodore tried to position their machines also suitable for business use (some were even sold as "CBM" = "Commodore Business Machines"), and at least the CBM-II even offered an Intel 8088 coprocessor board for CP/M-86 and MS-DOS compatibility. By 1982, it was absolutely not clear yet, that MS-DOS would make the run. And CP/M was a widely established operating systems, that was around for 8 years already and thus had a huge base of business software out there. So actually it was quiet reasonable by Commodore, trying to capitalize on that, as it would give C64 users immediate access to all that software. Plus, one has to consider that competing systems of the time like the BBC Micro and even Apple II also offered Z80 coprocessor options to run CP/M. So it was certainly also a move to not give up market share to competitors. But with the product consumers ultimately got, the idea - however clever it was - backfired, as by all intents and purposes, it was totally unusable.

[@ringtailedfox]

Is that program actually attempting to execute Intel 8080 operation codes on a MOS 6502??? that's never gonna work... they're entirely different CPUs with entirely different instruction sets... perhaps that's why it did nothing? Or am i misunderstanding things?

[@THEPHINTAGECOLLECTOR]

@@ringtailedfox Nah, it‘s trying to run the Z80 code on the coprocessor on the cartridge.

[@ringtailedfox]

@@THEPHINTAGECOLLECTOR got it. thanks for the clarification!

[@mwehrens1]

The original c64 cpm can only access one device at two drives (being, 8:0 and 8:1) The config prog doesn’t change that. The mentioned basic prg patches the 6502bios part Also the cpm load ccp+bdos every warmboot. Very wasteful

[@tlhIngan]

CP/M had terrible disk compatibility. If you had an Osborne machine, you couldn't use its disks in a Kaypro, for example. Every disk drive had a different format, and you pretty much had to buy the specific version of the program. Popular programs like VIsicalc and WordStar had dozens of versions for each machine, but lesser known systems less so. The problem was just disk format, so you could take the binaries from the Kaypro disk, transfer them via serial to an Osbourne, and it would work there. The disk formatting and reading routines were implemented in the BIOS of each machine which is why each had a different format. (This was carried onto the IBM PC as well - which is why Windows 9x stuttered when you formatted a floppy as it was executing BIOS code that formats the disk track by track. Windows NT didn't use the BIOS, which is why formatting disks never caused it to skip a beat).