Are there any OS's for the 6502 (better yet, the 65C02) that are on par with CP/M?

And as a side question, why was CP/M never ported to 65C02 systems?

Thanks

_________________
Cat; the other white meat.

I'm not absolutely sure what facilities CP/M offers - it's mean to be a platform-agnostic insulating layer, I think, and allows the loading of programs from a file system, and redirection of input and output.

Acorn's OS for the BBC micro is at least comparable, and probably much more sophisticated (it's much bigger after all) - it separates machine facilities from filing systems from the VDU subsystem, and all of those are independent of the language or application. So Basic is a language, and has none of the above because it uses the ABI to get the OS to do it. Any machine code program can do the same. Indeed, Basic is optional. Filing systems are pluggable - you can have several and switch between them. I wrote a bit about the Beeb here:
viewtopic.php?f=3&t=3482

I know next to nothing about it, but I gather the Atari 8-bit machines also have a substantial OS.

As Ed noted, CP/M is really not much of an operating system, at least not in terms of what we would consider an operating system these days. CP/M was little more than a program loader and a BIOS, and lacked a sophisticated filesystem, along with other services we'd expect from a modern computer. I worked with CP/M in the early 1980s, and was by and large unimpressed, especially since I had, by then, some exposure to UNIX.

Canadian computer whiz Craig Bruce had developed a UNIX-like operating environment back in the latter 1980s, written entirely in 6502 assembly language, that ran on the Commodore 128. He had it up on his website at one time, available for download. I don't have a current link, so I don't know if it's still available.


Probably because by the time the 65C02 entered mainstream computing (c. 1984, in the Apple IIc and IIe units) CP/M was nearly moribund. A native CP/M system would have had to be nearly scratch-written to run on the 'C02, as it is a fundamentally different MPU than the Intel 8080 and Zilog Z80. There was no economic justification do engage in such a task.

You have to understand that the CP/M BIOS and BDOS were not at all portable. Each had to not only be written in the assembly language of the target MPU, each had to be tailored to the specific hardware on which it ran. For example, CP/M for a Kaypro was not directly runnable on an Osborne, due to architectural differences in the two machines. Also, CP/M was never written in any kind of a portable language, such as C (indeed, C was largely unknown outside of AT&T at the time CP/M was developed), so it wasn't just a case of changing a few equates in a source file and then compiling.

When Commodore decided to bundle CP/M Plus with the C-128 they went the route of including a Z80 in the hardware, along with a complicated logic system to make either the Z80 or the 8502 the active MPU. It was not a good setup and relatively few C-128s were run on CP/M. The Xetec Lt. Kernal could support CP/M on the C-128 but that was something that was never fully exploited.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

GeckOS comes to mind. It's more Unix oriented than CP/M, and seems to have a lot of fundamental features.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Oops! Forgot about GeckOS. Sorry, André!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

From my links page:

• André Fachat's context Switching and thread synchronization on a 6502
• André Fachat's GeckOS/A65 V2.0, a full-featured Multitasking/Multithreading OS for the 6502. It is preemptive and implements some Unix-like features, like signals, semaphores, relocatable file format, standard library, internet support via simplified sockets, and virtual consoles.
• Jon's preemptive multitasking GUI OS for Atari 6502 computers
• operating-system wiki (OSDev.org)

Is the question about OSs in general implemented on the '02 (as the title suggests) with CP/M being only an example, or is it specifically about CP/M?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Another factor is that CP/M and its programs were much more terminal centric than most of the 6502 machines. For example, the Apple II was the first color graphics computer, the Atari eight bit had significant hardware dedicated to sound and graphics, as did the C64. CP/M was kinda ho hum by comparison.

During that era I was an avid Atari user and devoured "De Re Atari". It was a great machine to use, and fun to program.

Also DOS/65 ( http://www.z80.eu/dos65.html )
a 6502 port of CP/M, warts and all.

Also Fuzix by Alan Cox which I'm considering porting to the L-Star.

===Jac

I am exceptionally far from being a CP/M expert, but a brief search revealed this:

http://www.computerhistory.org/atchm/ea ... urce-code/



Mike B.

Unfortunately, that claim of "portability" is significantly exaggerated. Outside of the Intel 80xx lineage, there was not significant support for PL/M. PL/M worked with the Z80 only because the Z80 was binary-compatible with the 8080.

The most significant part of CP/M, the BIOS, had to be customized to match the particular system on which CP/M was to run. There were no hardware standards for CP/M machines, other than the requirement that the MPU be a Z80, 8080 or 8085 (even the formats for 5-1/4 inch disks weren't standardize). Adding to the fun, a BIOS customized to take advantage of the Z80's more expansive instruction set could not run on an 8080 or 8085 nachine. More often than not, the BIOS was done in assembly language, as the PL/M cross-compiler tended to produce bulky code, which was a key consideration on the hardware of that era and its tiny memory space. Usually, what was written in PL/M and compiled were the transient functions.

So I stand by my earlier statement that CP/M was never written in a portable language. A truly portable language is processor- and system-agnostic, C being one example. PL/M was neither, as it was only usable with a system that had an 8008, 8080 or compatible processor, such as the Z80 and Intel 80xx microcontrollers. Later on, compilers were developed for the 16 and 32 bit members of the x86 family, but that was about it. There was no support for the 68K environment, 65xx, 6800, PA-RISC, Sun SPARC, etc. That's not portability in this computer dinosaur's book.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

> PL/M
Good find Mike!

> Fuzix
But of course - how could I forget - I'm hoping we can see our way to getting that on the Beeb's second processors, which now have suitable banked memory.

The thing about CP/M, and what made it a stroke of genius by Gary Kildall (and of course completely obvious after the fact) was its three parts: The BDOS, the CCP, and the BIOS. The smart part was that the BDOS and CCP stayed the same, you only had to write a comparatively small BIOS for your particular architeture (your floppy disks, your interfaces etc). The OEM CP/M kit came with a 'generic' BIOS which you could start with and tweak for your system. It had to provide a number of entry points, normally to be called from the BDOS, e.g. char in, char out, disk sector read etc. It was not hard to bring up a new CP/M system - I still have a couple of books detailing the process. It was not uncommon to bring up a new system completely from scratch, you bootstrapped bits by bits until you finally saw the A> prompt.

The BDOS and CCP was 8080 code (originally via the already mentioned PL/M compiler), and stayed 8080 even though the Z80 was the most popular CPU for CP/M systems. Some used the 8085 though, and 8085 is also a superset of 8080.

With that setup you could use all kinds of generic CP/M software. This was very different from any other micro setup out there at the time. Its filesystem was very simple (but on the other hand, it was a real filesystem), PC DOS version 1 had something very similar (it was based on a re-implementation of CP/M, from specs, after all)

DOS/65 was not by DRI of course, and I have never had a chance to play with it. Today it would be Fuzix for me.

CP/M itself was eventually ported to the Intel 8086, the Motorola 68k, and the Zilog Z8000. But that's all. It needed at least 48K of RAM, preferably 64K (and could use more, for the CP/M-3 and MP variants), which wasn't common in home micros until the mid-eighties or later, when the IBM PC and PC-DOS/MS-DOS had already taken over the business market.

Another point, perhaps, CP/M is very much a disk operating system. Many 6502 machines didn't have disks although of course some did. They needed a ROM-based OS which could handle tape. I'm not sure how other OSes manage this, but Acorn's had the merit of supporting multiple filesystems from the start: the tape filesystem was built-in and was the default, but there were two disk filesystems from Acorn, more from third parties, and there was also a network filesystem which really helped in education - one fileserver serves many stations.

Yea, shouldn't poo poo CP/M. CP/M sold a boat load of Apple ]['s.

CP/M application binaries were portable across machines. All of the machine shared, essentially, the same architecture, which made that easier. But even when most machines were Z80s, a lot of the software compiled developed against the 8080, as that was the portability layer of CP/M.

The IBM PC and MS-DOS owe a lot to the legacy of CP/M.

Internally, the CP/M calling sequence was quite simple. You would set up registers with function numbers, pass in some pointers to File Control Blocks, and then JSR (CALL in 8080) to a common entry point.

At that entry point was a JMP to the machine specific address within the BDOS. As mentioned, the BDOS was portable at the source level, the BIOS was specific to the machine. The BDOS would then dispatch the call to the proper functionality.

CP/M had a custom boot track, which loaded a common CP/M loader, which knew enough about the directory and file layout on disk to be able to load the BDOS and BIOS binaries. Once loaded, a cold start would be called in the BDOS, which would, likely, load the CCP, which is the CP/M shell. CCP was portable software.

So, in order to stand up a new CP/M machine, you would port the BIOS, port the original boot sector loader for the machine, assemble a new BDOS against the BIOS and RAM configuration, and get all that on to an appropriately formatted floppy disk. Everything after that was portable binaries.

At that point you had things like Wordstar having to jump through hoops to work with different terminals, and printers, and whatever -- that was all on Wordstar, CP/M offered none of those facilities.