CP/M for the 6502

[granzeier]

...No commercial software written in 6502 "CP/M" exist, plus no ability to transfer data back and forth for use with running a common program written for both DOS's. So you've created a DOS that will never be used outside of a few experimenters hacking an ancient OS for the proposes of seeing if it is possible. ...

See, when Gary Kildall first wrote CP/M (or any other programmer wrote any other OS, or language) there was no commercial (or otherwise) software written for it either. the fact that CP/M-65(?) exists allows for other programmers to write commercial (or other) software for it. Perhaps that port of CP/M will never be used, but the possibility exists just like it did when Gary wrote the original. (Although in today's world, you are probably correct that there will not be much.)

 

[Bruce Tomlin]

There never was one common 5.25" CP/M-80 floppy format and therefore what are you going to do with it.

I guess that makes it even more like real CP/M!

 

[alank2]

Chuck, I'll miss keyboards if they go someday.

CP/M was a bit before my time as I started with MS-DOS 2.11, but I can appreciate what it did for computing!

It provided an interface to keep someone from having to deal with floppy disks as block devices and additionally it provided a compatibility layer between systems with different hardware, but the same (or a compatible CPU).

The lack of compatibility for terminals and disk formats was a disaster for it along with its price. PC-DOS and the "PC compatible" platform added those things and did so at a lower price.

I think the Turbo Pascal 3 installation program shows the terminal issue quite nicely. For CP/M, it was a whole page of terminals and a big list of customizations for terminal codes. Get all that right and you still have to get all the keyboard codes right for your keyboard. For PC, it was 5 choices which really could have been 3 choices (did anyone ever pick 40 column mode?).

 

[whartung]

CALL 5 was already a problem with MP/M-80 RSXs requiring the value of the jump address to be adjusted so all calls pass through the RSXs before reaching the API.

How was that an issue since the only thing sitting at "5" was a JP to an entry point, and since this was RAM, it could be adjusted to anything.

 

[whartung]

But even if this 6502 OS mirrors CP/M calls in many ways, what good is it.

One thing I've learned over the years in the vintage computing world is to never ask "what good is it".

However, outside of the personal aims of the original author, CP/M-65 has a bit to offer the community.

The 6502 is famous for having a slew of "spectacularly incompatible" machines. This system is novel is that it does two things. One, it tackles the problem of the wide diversity of memory maps on the various machines head on with its relocatable binaries. 6502s are quite popular in the homebrew community. Z80 moreso, because of CP/M, but the 6502 because of its simplicity. This offers that community a foundation (for those that actually take it to the level of having a disk at all) on which to potentially build, well, anything they like.

Finally, it gets to leverage the 50 years of documentation within the CP/M community. In theory, any book on the operation and coding for the CP/M OS, should have pretty good relevance if the project is indeed as compatible as the name suggests. Sure, all of the examples are in the wrong assembly language, but that's a minor nit compared to understanding how the filesystem is laid out, how the TPA works, how the CCP works. That knowledge is all "portable".

It would be fun to see an Atari port, moreso as a proof of concept (no doubt it'll perform as poorly as the C-64 port, as the disk drives are pretty awful). But it would be interesting.

It can also lead more to a base architecture for a modern board, running a 8 or 14MHz 6502, with some kind of solid state file system. The Z80 community base goal is "get CP/M to run", because once they get there, they get the rest "for free". 6502 doesn't have that. Come up with a board and you have...a board. And maybe a monitor. Now, for example, someone could take the Fig-Forth CP/M listing and the Fig-Forth 6502 listing, toss them in a blender, and get "Fig-Forth for CP/M-65". They could do that port in an evening. Boom, native development on a CP/M-65 machine -- WITH an assembler.

Perhaps this will get no traction, who knows. Sure, there's no software for the CP/M-65, but, honestly, "so what". CP/M-80 has software, but little of it is used. "Great I can run Wordstar. Why in the world would I do that beyond 'Yay. Wordstar'?". The core lament of the vintage computing community.

It could fizzle, or it could act as a catalyst. Time will tell.

 

[rfka01]

I think it's a great idea to keep concepts like CP/M alive - the number of people having worked on machines of that era first hand is in decline.
I thought I remembered a similar effort from a while back, but it's modeled after MS-DOS: https://www.applefritter.com/content/us-dos-or-other-ms-dos-emulator

Robert

 

[skate323k137]

I think it's a great idea to keep concepts like CP/M alive - the number of people having worked on machines of that era first hand is in decline.
I thought I remembered a similar effort from a while back, but it's modeled after MS-DOS: https://www.applefritter.com/content/us-dos-or-other-ms-dos-emulator

Robert

I use CP/M in two ways, though not often on the 1st. I have a couple of Z80 soft cards for my Apple II series computers.

Apples aside though, I built a RC2014 Pro which is a homebrew Z80 computer, currently mine is using CP/M and MBASIC to control digital I/O boards.

 

[Chuck(G)]

One aspect of the original CP/M that's often glossed over is that it was designed as a floppy-based OS for limited-memory implementations. Hence, keeping the allocation information in the directory entries to keep seeking down and blocking up sectors into conveniently sized allocation units.
CP/M started to stumble a bit when hard drives were introduced. The idea of a flat directory structure on large volumes became problematical. The idea behind MS-DOS to separate the allocation information from the directory wasn't new--it had been around for at least 20 years before that. In fact, from the viewpoint of the execs at IBM, it's hard to make a meaningful distinction between PCDOS 1.x and CP/M-86. MP/M-86 had just come onto the scene and offered multi-user/tasking capabilities, but that wasn't enough to cinch a decision. I suspect that the PCDOS/CP/M question was resolved by pricing and licensing and not by anything technical.

 

[acgs]

One thing I've learned over the years in the vintage computing world is to never ask "what good is it".

Especially when you think about how DOSbox, etc. were first looked at by the average user and they asked the same thing. Heck, the entire vintage computer world has had that same reaction. Just ask Jim Brain how many emails he received back in the late '90s/early 2000's asking why he was bothering with a C64 when the Pentium could run rings around it.

The 6502 is famous for having a slew of "spectacularly incompatible" machines. This system is novel is that it does two things. One, it tackles the problem of the wide diversity of memory maps on the various machines head on with its relocatable binaries. 6502s are quite popular in the homebrew community.

Exactly what I was thinking when I made my last post. A set of Z80 to 6502 migration tools for CP/M would help a lot also.

Perhaps this will get no traction, who knows. Sure, there's no software for the CP/M-65, but, honestly, "so what". CP/M-80 has software, but little of it is used. "Great I can run Wordstar. Why in the world would I do that beyond 'Yay. Wordstar'?". The core lament of the vintage computing community.

It could fizzle, or it could act as a catalyst. Time will tell.

We seem to be on the same page. And thanks for making a post long enough that I don't look like I just run at the mouth.

 

[whartung]

The idea of a flat directory structure on large volumes became problematical.

Boy is that an understatement. The USER system on CP/M doesn't really help matters (as it's similarly awful).

The floppy really was a key aspect to the CP/M experience. Playing with CP/M on a simulator that doesn't allow "floppy swaps" is, well, not as good as if it did.

There are extension, naturally, that mitigate a lot of this, but out of the box, yea, CP/M with large volumes is kind of extra horrible.

 

[Chuck(G)]

On the other hand, if you use a floppy-only CP/M version, you get to deal with that "BDOS err on A: R/O" business.

 

[hjalfi]

Well there's also the tiny little problem that the 6502 stack can only exist at 0100-01FF, which on an x80 or x86 is the standard location for the start of a loaded .COM file. It was significant enough that MSDOS did that too. And it's why I never had delusions of running CP/M on my TRS-80 Model I, because even with a compatible CPU, there's no point when everything would have to be re-assembled to 0x4100 or so. At that point you might as well just patch all the OS calls in Wordstar to work with TRSDOS.

 

[hjalfi]

Well there's also the tiny little problem that the 6502 stack can only exist at 0100-01FF, which on an x80 or x86 is the standard location for the start of a loaded .COM file. It was significant enough that MSDOS did that too. And it's why I never had delusions of running CP/M on my TRS-80 Model I, because even with a compatible CPU, there's no point when everything would have to be re-assembled to 0x4100 or so.

Yeah, I think I can count on the fingers of one foot the number of production CP/M systems which had a TBASE which wasn't 0x0100. It's why I was so focused on using relocatable binaries.

(Entertainingly enough, while working on this, it became apparent that it would be very easy to add relocatable binaries to CP/M-80 using the same scheme, allowing useful stuff like running one program from another, and also that adding proper subdirectory support would be almost trivial --- simply extend the user number field to be eight bits and use it as the identifier of the containing subdirectory for each file. 0 would be the root directory. The existing user numbers map to the directories with IDs 0..15 for backwards compatibility. The trickiest part would be parsing paths, as you'd need to resolve each path element to get the ID of the containing directory for the next element, and I think I'd prefer to put that in the BDOS, but that's about it.)

(I could make a mint if I were in 1980... and if I had the patience to write 8-bit software without sub-second compilation and test cycles, which I probably wouldn't!)

C really wants to be a 16-bit language. Using C on an x80 is a bit tight, but on the register-poor, stack-poor 6502, it's not a very good fit at all.

You might want to look up llvm-mos --- it's a port of the LLVM compiler to the 6502, and it frequently generates startlingly good code. Most of the time.

For an upcoming project I actually want to do a modern PL/M compiler targeting LLVM, allowing me to compile the original Digital Research tools for the 6502.

 

[Chuck(G)]

A 256 byte stack is not much for a CP/M-80 program, particularly if the stack is used for local variable storage. The TPA starting at 0100h with the FCBs at 005c and 006c created problems if the CPU was a Z80 and used the NMI/Trap interrupt (interrupts to 0066h). Absolute addresses are a problem in any architecture. I believe that the DDT single-step interrupt uses RST 7 (0ffh instruction), but that can be worked around, as some Z80 systems used the single IRQ 7 to service peripherals.

It's a little surprising to me that there wasn't a code relocation register in the 8080 architecture. I guess the cycles taken for an additional address addition might have been too much. However, bankswitching schemes in hardware can get around that.

 

[Eudimorphodon]

For all the crud the 8086/88 get for their segmented architecture it has to be admitted that it's really useful for solving the relocation problem. At the cost of making them do all that address arithmetic...

 

[lowen]

The Z280 solved the relocation problem with PC-relative and SP-relative addressing modes (beyond the Z80's JR relative jumps (or branches, same thing)) which allow for true position-independent code.

Segmentation is just a highly integrated MMU; a good MMU makes the need for position-independent code moot. Even a simple MMU, like the HD64180/Z180's, is sufficient.

The 6502 has the skeleton for position independence already, if I remember correctly.

In my opinion, and as a 'nice to see happen' thing, the next CP/M (ish) could be on the 6809, and target the TRS-80 CoCo 3.

 

[DDS]

I find it interesting that someone took the time to create a 6502 DOS that acts like CP/M-80. My hat is off for all the effort. But even if this 6502 OS mirrors CP/M calls in many ways, what good is it. There never was one common 5.25" CP/M-80 floppy format and therefore what are you going to do with it. There almost was a common one with the 8" IBM format, useful for loading software from commercial developers, but even there not all systems had 8" soft sector drives. So if you can't load data or programs from all the various Osborne, Kaypro, Northstar, and so many other format floppies, then what's the point. No commercial software written in 6502 "CP/M" exist, plus no ability to transfer data back and forth for use with running a common program written for both DOS's. So you've created a DOS that will never be used outside of a few experimenters hacking an ancient OS for the proposes of seeing if it is possible. Very good work, but will anyone make use of it?

Very little of what we do and/or discuss on this site will be of any practical use to anyone outside of our rather peculiar hobby.

When someone sees one of my antique computers and asks me "What does it do?", my response tends to be "It makes me happy."

"And that's all I have to say about that." -- Forrest Gump

 

[ClassicHasClass]

You might want to look up llvm-mos --- it's a port of the LLVM compiler to the 6502, and it frequently generates startlingly good code. Most of the time.

Still doesn't mean that C is a good fit for the 6502, particularly code that passes a lot of stuff on the stack. While llvm-mos gets around the register problem by basically using zero page as a sea of virtual registers, which is even appropriate, that doesn't play so nice with other code. It's not to say it's not clever or well thought out, but it's still doing a lot of work to make the hippo dance on an architecture the hippo can barely fit on.

I certainly don't dispute it's nice having a compiler option so you don't go insane writing a project like this (and congrats), but myself on the 6502 I still find I get better performance out of a macro assembler despite improvements in cross-compilers, and I feel a lot more in control of what's being generated.