CP/M for the 6502!

[hjalfi]

Interested parties may be, er, interested to know that I've just done a basic port of CP/M to the 6502.

https://github.com/davidgiven/cpm65

It currently runs on the BBC Micro (and Master and Tube), and the Commodore 64 (very slowly), but should be almost trivial to port to any system with a reasonable amount of contiguous RAM and zero page. It adds relocatable binaries, necessary to make programs portable between systems, but is otherwise essentially CP/M 2.2, just rewritten for the 6502. Naturally, there is no software whatsoever for it...

Also, if you're interested in watching about 45 hours of Youtube, I recorded myself programming it. Videos will be appearing here:

https://www.youtube.com/playlist?list=P ... RZL8K0zRDA

[BillG]

Thanks for doing this and picking a permissive license.

Not promising anything will ever come of this, but I have been working on an 8080 processor simulator to run on my FLEX for 6502. It is currently stalled due to complexities around the differences between the CP/M and FLEX file system structures. A version for CPM65 would not have this problem.

[Proxy]

oooo, i wonder how difficult it would be to port to the 65816 plus the mentioned 8080 Emulator.... hhmm, does a version of CP/M exist that was written in C? that would make it much easier to port to any given architecture.
also i'm a bit confused why you're using ca65 for the assembly but then llvm-mos for the C. why not just do everything with one of them? so that you don't need to get 2 seperate utlities to build it.
or are the C files not needed to just generate a regular binary?

[plasmo]

Very cool! I’ll try porting it to CRC65 which has 58K RAM, serial port, compact disk interface, and run up to 29.5Mhz.
Bill

[hjalfi]

@Proxy Short answer to the last: I was going to do it all with cc65 but then couldn't figure out how to persuade cc65 to produce CP/M-65 binaries with the relocations. mos-llvm was easy to port (well, as easy as ELF parsing gets).

There isn't a CP/M in C, but I have actually thought about it. It'd make a fantastic stub OS for boot loaders, microcontrollers etc.

[plasmo]

I'm a casual user of CC65 in Windows development environment, so I'm trying to understand the various commands of CC65 embedded in CPM65 assembly and include files. CRC65 has 58K RAM from $0 to $E7FF, so what should be the values of __ZEROPAGE_SIZE__, __CODE_RUN__, __BSS_RUN__, __BSS_SIZE__ ?
Bill

Edit:
I should mention that I do have experiences with porting CP/M to Z80 and 68K machines. Since I'm porting CPM65 to a specific 6502 hardware, CRC65, I don't need relocatable 6502 code. My plan for CPM65 is putting BIOS/BDOS/CCP at top of RAM ending at $E7FF while CPM65 program starts from $300 (assuming $200-$2FF is allocated to BDOS calls).

[hjalfi]

For the BDOS and CCP, those symbols are magic --- the link script sets them (the linker thinks that binaries assemble at $0200 with zero page starting at $00, and then there's a tool that fixes up the result into a relocatable binary). For the BIOS, they're set by the platform linker script in scripts/c64.cfg or scripts/bbcmicro.cfg. The BDOS doesn't have to be relocatable but I haven't done that bit yet so for now I'd load and relocate it via the BIOS. The bottom of memory is easier because when it starts up the BDOS will try to adjust the bottom of the TPA and ZP workspace automatically.

The biggest difference between CP/M-80 and CP/M-65 is that the BDOS is only loaded once, on startup, and isn't reloaded on warm boots. Both the BBC Micro and C64 ports use the native file system to load it.

[nollkolltroll]

Very nice, congrats!
Will have a good look at it.

[Dr Jefyll]

Unsurprisingly, this very cool project is being discussed on Hacker News.

-- Jeff

[floobydust]

Having a direct port of CP/M is very nice, so a big thanks to David on this. I've also started watching the videos... and will dive deeper into those. I've sorta figured out the BIOS interface, which is different to what I'm using now, but that should be pretty easy to change over. Most of the 6502 code I've seen or written has used the A/Y register pair for passing data/addresses/parameters and the X register for passing a command (as does DOS/65), so this CP/M port has the X/Y registers swapped in usage, not a big problem, but leveraging some of the CMOS instructions/addressing modes might be more cumbersome, but time will tell.

Sadly, I'm not a CC65 user but will look at it more closely.... but will likely look to move it over to WDC Tools (hate it or love it... it's what I use).

Chances are I can port it over to a modified version of my C02 Pocket (reconfigured for 56KB and RAM and 8KB of EPROM) and modify the BIOS to boot from the Microdrive. Ah... another project

As the initial port seems to favor older retro machines, using newer storage (which all default to 512-byte blocks), I'll likely use a similar blocking routine to what DOS/65 uses. Unless I'm not up to date... I believe that CP/M 2.2 is limited to an 8MB maximum disk size and a maximum file size of 512KB. Is this correct??

[hjalfi]

I'm actually in the process of moving over to llvm-mos for doing the assembly. However, the only part which needs to be modified for a new port is the BIOS --- everything else, including the BDOS, uses the same binaries. Let me know if you need help. Documentation is, erm, lacking.

Re block size: yeah, everything from the BDOS down assumes traditional 128-byte sectors (I've tried to refer to these as 'records' where possible to avoid confusion). Deblocking ought to be simple; the C64 port does it due to the underlying 256-byte sector size. bios_WRITE takes a parameter to tell it whether a write should be deferred, performed immediately, or whether this is writing to a new allocation block and so the BDOS doesn't care about the state of the rest of the sector. CP/M 2.2 supports 8MB files (0x10000 records) and 1GB disks (0x10000 16k blocks), although you won't enjoy using a disk that size; it'll need an allocation bitmap which is a full 8kB long, which is ridiculous.

Re XA: that's actually what I've seen elsewhere; it frees up Y for doing indirect indexing, making things a lot easier for doing stuff with the value. It's what llvm-mos uses.

[floobydust]

Thanks for the update.

I built up a VM with the latest Ubuntu 22.04.1 running under Fusion (VM Ware on OSX). After installing a lot of stuff and building llvm-mos from your modified version, I was able to complete the build images for the C64 and Beeb. I mounted and autostarted the D64 image using Vice (runs on OSX) and it booted CPM/65, yay!

Now, is there an easy way to get the BDOS and CCP files and preferably the listing files separately?

[plasmo]

Impressive progress, floobydust. I’ve gotten absolutely nowhere trying to understand the inner working of CC65, BDOS, CCP, BIOS. They are too abstract for my simple-minded thought process. I think I’ll have better luck emulating your C02 pocket SBC hardware then following your progress implementing CPM65 on your C02 pocket SBC. Yep, in fact that’s what I’ll do.
Bill

[hjalfi]

Excellent!

What do you mean by getting the BDOS and CCP files separately? The source is in src/bdos.s and src/ccp.s respectively (plus a bunch of macro packages).

[floobydust]

The sources are no issue... but I find having a listing file is really nice, especially when I start moving it to WDC Tools. Some of the calculated values as operands don't always work the same between assemblers and that can cause all kinds of problems.