CP/M on the X16

[mortarm]

The C128 had a CP/M mode, along with a Z80, and it never caught on due to lack of interest and technical issues. I'd expect the same to be true here, as well. Too bad, too. WordStar was my favorite word processor at the time.

[mgkaiser]

I'm not sure if this feature is even necessary, but can (in theory, with a expansion card) the Commander X16 run CP/M, in order to run some business software for CP/M, or even write new software for CP/M? This question seems stupid, but I'm just asking.

This is less a "feature" of the CX16 and more of an add on project. It definitely requires an add on board, and all of the signal lines needed to decouple the 65C02 from the bus exist on the expansion port. The hardest part would be that CP/M expects there to be RAM at the top of memory and ROM at the bottom of memory. The RAM part could be accomplished by adding 16k of RAM on the board and mapping it in from $C000-$FFFF, which the CX16's architecture easily supports. I guess you don't really need the ROM at the bottom of memory if you setup the BIOS and BDOS before you give the Z80 control. The most problematic part really is that I/O is locked at $9f00-$9fff, just above the middle of the address range. So either you need to do something about that or tolerate that you only have a 38k TPA.

So what can you do about the IO? It's kind of hard because there is no CX16 supported way to do this. Fortunately the Z80 supports separating IO from Memory access. So memory map from Z80 would look something like this:

$0000 - $9eff: CX16's onboard RAM
$9f00 - $9fff: 256 bytes of RAM on the Z80 card only accessible to the Z80
$a000 - $bfff: 8k of RAM, locked onto one of the CX16's banked RAM pages
$c000 - $ffff: 16k of RAM, provided on the Z80 card and visible to the 65C02 as a page of "ROM"

Add some glue logic so that when the Z80 accesses IO on $00-$ff it really hits $9f00-$9fff and hits the CX16 IO.

The only part I am uncertain about is how the bank ports at $00 and $01 are implemented. Are they ALWAYS visible regardless of who has the bus? If so that is a touch problematic because $0000-$0002 contain "JP START_OF_BIOS" for CPM. So maybe there needs to be some fancy glue logic that presents $00 and $01 as RAM to the Z80 and maybe allows IO to see $00 and $01 at $FE and $FF

*****************************

Given all of this complexity it might just be easier to give the Z80 it's own set of RAM and implement some custom IO that is the only shared thing between the 65C02 and Z80. Then you could run CP/M 3.0 with > 64k of RAM (96k would do) which would allow the BIOS and BDOS to page and you could have a 60k TPA, which is about as big as CP/M ever got. So now $0000-$ffff see's the Z80's private RAM. IO $00-$ff point to $9f00-$9fff of the CX16 IO space. And custom logic implemented in one of the IO expansion pages of the IO Range deals with choosing the active processor and letting the 65C02 load stuff into the Z80 RAM (similar to how accessing VRAM works) to bootstrap the Z80. The card now also contains some ROM to get the bootstrap code over to the Z80's RAM (and the bootstrap code itself).

[mgkaiser]

And while we are at it, the same probably applies to a 6809 card allowing OS9 to run.

[ZeroCool32]

I'm not sure if this feature is even necessary, but can (in theory, with a expansion card) the Commander X16 run CP/M, in order to run some business software for CP/M, or even write new software for CP/M? This question seems stupid, but I'm just asking.

This is less a "feature" of the CX16 and more of an add on project. It definitely requires an add on board, and all of the signal lines needed to decouple the 65C02 from the bus exist on the expansion port. The hardest part would be that CP/M expects there to be RAM at the top of memory and ROM at the bottom of memory. The RAM part could be accomplished by adding 16k of RAM on the board and mapping it in from $C000-$FFFF, which the CX16's architecture easily supports. I guess you don't really need the ROM at the bottom of memory if you setup the BIOS and BDOS before you give the Z80 control. The most problematic part really is that I/O is locked at $9f00-$9fff, just above the middle of the address range. So either you need to do something about that or tolerate that you only have a 38k TPA.

So what can you do about the IO? It's kind of hard because there is no CX16 supported way to do this. Fortunately the Z80 supports separating IO from Memory access. So memory map from Z80 would look something like this:

$0000 - $9eff: CX16's onboard RAM
$9f00 - $9fff: 256 bytes of RAM on the Z80 card only accessible to the Z80
$a000 - $bfff: 8k of RAM, locked onto one of the CX16's banked RAM pages
$c000 - $ffff: 16k of RAM, provided on the Z80 card and visible to the 65C02 as a page of "ROM"

Add some glue logic so that when the Z80 accesses IO on $00-$ff it really hits $9f00-$9fff and hits the CX16 IO.

The only part I am uncertain about is how the bank ports at $00 and $01 are implemented. Are they ALWAYS visible regardless of who has the bus? If so that is a touch problematic because $0000-$0002 contain "JP START_OF_BIOS" for CPM. So maybe there needs to be some fancy glue logic that presents $00 and $01 as RAM to the Z80 and maybe allows IO to see $00 and $01 at $FE and $FF

*****************************

Given all of this complexity it might just be easier to give the Z80 it's own set of RAM and implement some custom IO that is the only shared thing between the 65C02 and Z80. Then you could run CP/M 3.0 with > 64k of RAM (96k would do) which would allow the BIOS and BDOS to page and you could have a 60k TPA, which is about as big as CP/M ever got. So now $0000-$ffff see's the Z80's private RAM. IO $00-$ff point to $9f00-$9fff of the CX16 IO space. And custom logic implemented in one of the IO expansion pages of the IO Range deals with choosing the active processor and letting the 65C02 load stuff into the Z80 RAM (similar to how accessing VRAM works) to bootstrap the Z80. The card now also contains some ROM to get the bootstrap code over to the Z80's RAM (and the bootstrap code itself).

Now that I am thinking more about it, this is most likely the solution. I propose splitting the boot process in two stages:

• BOOT65/BIOS65 (65C02 bootstrap, handles enabling the Z80, loading BOOTZ80 and BIOSZ80 into it's dedicated memory on the card, disabling BASIC/Character ROM, jumping to Z80)

• BOOTZ80/BIOSZ80 (Z80 bootstrap, a modified CP/M BIOS that handles the CX16's hardware, loads CCP and BDOS)