Commander X16

I recently did a port of CP/M to the 6502, and have just made it work on the X16, more or less. See https://github.com/davidgiven/cpm65.

There's currently no actual 6502 CP/M software, so it's of questionable utility, but it does work and it will run the same executables as on the BBC Micro and Commodore 64 ports (I want to add more). I haven't tested this on real hardware for obvious reasons but it runs on x16emu; although, it uses M mode file access and P to seek within them (the CP/M filesystem is stored in a big file), so I also had to patch in support for this in the host filesystem. There's a pull request outstanding at https://github.com/commanderx16/x16-emulator/pull/435. I think this is the easiest way to do it; raw sector access of an SD card partition would be cool but I don't think it'd be worth it. One annoyance is that you can't use 1541 drives from the C64 port on the X16 port. I suppose it'd be possible to detect the drive type and use different code paths, but at 300 bytes per second using a 1541 drive is an exercise for masochists anyway...

The OS is written in portable hand-tooled machine code, but it uses the llvm-mos toolchain so you get C support out of the box. (The STAT command shown in the screenshot is written in C.)

Does anyone know of any actually-open-source (i.e., with a license) command-line C64 software that it might be interesting to port? For example, assemblers and the like? I'm suspecting there's not much as the nature of the C64 is that it tends to encourage combined editor-assemblers, which aren't suitable for CP/M...

Oh, yeah. Is there any way to make the cursor blink?

There's some tools written for the X16 that work with files. You may find them in the Download section.

Written by myself:

• 
  X16 Edit - Text editor similar to GNU Nano
  


• 
  BASLOAD - Tokenizes BASIC programs stored as plain text files; uses labels instead of line numbers
  

Written by others:

• 
  File based assembler by desertfish
  


• 
  Volksforth ported by pzembrod
  


• 
  CC64 by pzembrod - a small C compiler
  


• 
  BASIC Preprocessor by Scott Robison
  


• 
  LED - a line editor by Michael Parson
  

Maybe some of these are interesting for your project

The kernel's SD card file accesses translates between CBM style disk access and FAT32. Why not have this tool do something similar? That would simplify the task of adding files for the CP/M system to the card from a desktop computer.

This seems to be a pet project of a lot of people. There's DOS/65, there's Monarch, there's your project CP/M-65...

Yeah, Monarch isn't quite as close to CP/M as the other two, but it's still also designed around a BIOS/BDOS/CCP model. It doesn't call the layers that, though, and it doesn't try to replicate the CP/M API, nor does it try to provide file system cross-compatibility. DOS/65 doesn't call their layers that, either, but as I understand it the OS functionality is otherwise very similar to CP/M.

CP/M is a bit tricky to implement on a 6502 (or 65C02), because of the memory-mapped I/O on a lot of platforms taking up so much address space, leaving a small TPA. The relatively narrow I/O channels used on the X16 should help with that. However, it has a rather large ROM that can't be switched out for RAM, which is kind of the same problem in a different guise.

On 10/16/2022 at 7:59 PM, kelli217 said:

This seems to be a pet project of a lot of people. There's DOS/65, there's Monarch, there's your project CP/M-65...



Yeah, Monarch isn't quite as close to CP/M as the other two, but it's still also designed around a BIOS/BDOS/CCP model. It doesn't call the layers that, though, and it doesn't try to replicate the CP/M API, nor does it try to provide file system cross-compatibility. DOS/65 doesn't call their layers that, either, but as I understand it the OS functionality is otherwise very similar to CP/M.



CP/M is a bit tricky to implement on a 6502 (or 65C02), because of the memory-mapped I/O on a lot of platforms taking up so much address space, leaving a small TPA. The relatively narrow I/O channels used on the X16 should help with that. However, it has a rather large ROM that can't be switched out for RAM, which is kind of the same problem in a different guise.

It seems like the ideal X16 CPM/65 would have the BIOS in a ROM segment, probably together with the BDOS if it fits.

My one puts the BDOS and CCP in high RAM, leaving the entire low RAM area for the TPA. I wish the I/O area didn't split up the RAM but, well, tradition, I suppose! My original development platform was the BBC Micro; but it puts the I/O up high at 0xfc00. On the Master, which has banked RAM, it's theoretically possible to get everything from 0x0000 to 0xe000 available as RAM.

I did know about DOS/65, but couldn't use it because of the no-commercial-use license; although I recently discovered that it may have been relicensed to GPL-3 --- the documentation is muddled. I haven't head of Monarch. Do you have a link? Google's not helping.

One additional thing I'm planning on doing is a PL/M compiler targeting LLVM. This should allow compilation of the original Digital Research tools for the 6502.

On 10/17/2022 at 5:39 AM, hjalfi said:

My one puts the BDOS and CCP in high RAM, leaving the entire low RAM area for the TPA.

Yeah, I'm considering going the other way and putting the OS in low RAM and pushing applications to use banked RAM. (Maybe providing 16K of unbanked TPA and 512KB/2MB of banked RAM.)

Of course, I'd also want to provide far jump and far read/write routines, with appropriate block functionality. (copying up to 8K between banked and non-banked RAM.)

(edit: I need to stop trying to think at 5:30 in the morning. The OS is going to be in ROM, so the TPA is at $0400. When we get around to building a BASIC interpreter, it will likely use banked RAM to store the tokenized code, but that's not "the operating system.")

On 10/17/2022 at 10:47 AM, TomXP411 said:

Yeah, I'm considering going the other way and putting the OS in low RAM and pushing applications to use banked RAM. (Maybe providing 16K of unbanked TPA and 512KB/2MB of banked RAM. 

I like this idea. Ideally there would be a jump table in page BF so the OS knows where to look for the code. If that's standardized across apps it makes a lot of things easier. Low RAM would have space for data shared across apps.

On 10/17/2022 at 12:47 PM, TomXP411 said:

Yeah, I'm considering going the other way and putting the OS in low RAM and pushing applications to use banked RAM. (Maybe providing 16K of unbanked TPA and 512KB/2MB of banked RAM.)



Of course, I'd also want to provide far jump and far read/write routines, with appropriate block functionality. (copying up to 8K between banked and non-banked RAM.)

But there doesn't have to be a contention between having the BDOS and CCP in High RAM and applications using High RAM. CP/M 2.2 programs that don't use the CCP functions are free to overwrite them, since the CCP is typically reloaded on exit, and those that don't use the BDOS functions are free to overwrite those as well and have the BDOS reloaded when they exit. It's even easier to do either of those if BDOS and CCP are in a HighRAM segment, since the warm start is just bringing those back into the memory map and calling the correct routine there.

If the CP/M function call is at a vectored location, you could even swap between a direct call when the BDOS/CCP is in HighRAM and the X16 Kernal is in ROM, and a long call when the correct window need to be set-up for a call, so that when you are NOT using the freedom to use HIghRAM, you don't have the extra overhead on CP/M function calls. That would make the LowRAM stub the direct function call, the long function call, and optionally the LowRAM support for using all or part of HighRAM as a RAMdisk.

On 10/17/2022 at 7:39 AM, hjalfi said:

I haven't head of Monarch. Do you have a link? Google's not helping.

There isn't much activity currently; there's a board here, and there's a channel on the Discord, but primarily it's on GitHub, at https://github.com/tomxp411/monarch-os