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)

[systemprog]

Hello all,

I am new to this forum but have been working w/ CP/M and Z80 assembly language for some time. Some years ago, I wrote a BBS in Z80/6502 assembly language for the Apple II with Microsoft's Softcard. I also have experience designing and building embedded hardware using the 80188 cpu, with a custom BIOS for I/O (LCD, keyboard, serial and parallel ports) supporting an embedded application written in C.

As mgkaiser wrote, having a Z80 with its own memory allows for a clean memory map for CP/M. At least two boards have been previously designed for the Apple II with that architecture: Microsoft's Softcard II and PCPI's Applicard. Both feature a Z80 (with dedicated memory) running at 6 MHz or higher. Newer versions of these cards use modern components (for example, https://gglabs.us/node/2098 and https://gglabs.us/node/2321); schematics are available for both implementations. GGLabs's Applicard implementation runs at 20 MHz. Maybe those boards can be used as a starting point for the development of a similar board for the X16.

Regardless of the route you all want to pursue, I would gladly volunteer for this project.

[mgkaiser]

In fairness this design really means you are plugging an entire Z80 computer into a card and hijacking the X16's IO for it's use. It would work and would even be economically feasible by todays standards. But it would have been complexly silly back in the day. Given that the Z80 has been discontinued, how about a FPGA and RAM on a card? Load a Z80 core into it if you like. Load a 6809 core into it if you like. Design your own processor if you like!

[kelli217]

Just a point of information: The topic of a Z80 card has come up before. One of the major contributors was BruceMcF.

[TomXP411]

In fairness this design really means you are plugging an entire Z80 computer into a card and hijacking the X16's IO for it's use. It would work and would even be economically feasible by todays standards. But it would have been complexly silly back in the day. Given that the Z80 has been discontinued, how about a FPGA and RAM on a card? Load a Z80 core into it if you like. Load a 6809 core into it if you like. Design your own processor if you like!

Complex or not, there were several implementations that worked this way: The Apple II CP/M card, Commodore 64 CP/M cartridge, the Commodore 128's built-in Z80, and I think the BBC Micro had a Z80 option. And let's not forget the 8088 and 80286 "pc on a card" implementations for the Macintosh and Amiga.

The difference is how these different systems went about implementing things. CP/M on the Commodore 128 completely took over the system; the 8502 and Z80 shared the same RAM and peripherals. The same goes for the C64 CP/M cartridge.

However, I believe the Apple II's card was more self-contained, and it may have been possible to run tasks on the Z80 separately from the 6502. (I'd have to research that more.)

This was definitely the case for Amiga's Bridge Board: the PC screen was just a window on the Amiga's multitasking interface, or the user could install a VGA card and run their PC apps on its own display.

I think Bruce's solution is more like the latter; using the microcontroller variant, it's possible to run a mostly self-contained computer, with the X16 just acting as a terminal. Conceptually, this is not much different than just connecting the X16 to a CP/M computer via a serial port, something a few of us have already done (and which works fairly well.)

[tim1724]

However, I believe the Apple II's card was more self-contained, and it may have been possible to run tasks on the Z80 separately from the 6502. (I'd have to research that more.)

There were a number of different CP/M cards for the Apple II. Some (such as the Softcard, which was Microsoft's very first hardware product) suspended the 6502 and used the Apple II's onboard RAM. (They also mapped the Apple II's I/O space into the Z80 memory map, for direct access.) The Softcard was hugely popular and was widely cloned, both for compatibility with Microsoft's card and because it was cheap to manufacture (having no expensive RAM onboard). The problem with this approach was that the Z80 couldn't run faster than 2 MHz, because it was using the Apple II's built-in RAM.

Later cards such as the PCPI Appli-Card had their own RAM so they could run the Z80 at higher speeds. These are known as Single-Board Computer cards, or SBCs. (Note that Microsoft's Softcard II and Premium Softcard //e fall into this category; they're not Softcard-compatible!) These cards would leave the 6502 running and would not map the Apple II's RAM or I/O space into the Z80 address space. The 6502 would be left running code that handled I/O. The CP/M drivers would perform all I/O by communicating through I/O registers to talk to the 6502 code running on the Apple II. So the text output driver would send a string to the 6502 to have it print it to the test screen, for example. Theoretically you could replace the usual 6502 code with your own, to have it be doing other processing as long as it checked for I/O activity from the Z80 on a regular basis. Or you could replace CP/M with your own code on the Z80 side to use it as a coprocessor for a program running on the Apple II, to perform fast background computation or whatever.

[TomXP411]

In fairness this design really means you are plugging an entire Z80 computer into a card and hijacking the X16's IO for it's use. It would work and would even be economically feasible by todays standards. But it would have been complexly silly back in the day. Given that the Z80 has been discontinued, how about a FPGA and RAM on a card? Load a Z80 core into it if you like. Load a 6809 core into it if you like. Design your own processor if you like!

We have had several people working on ideas for a soft card, which would use a microcontroller to talk to the X16 bus. The microcontroller could either directly run a Z80 emulation or pass data to a dedicated processor.

Considering the lower cost of entry, both in terms of money and programming skill, I'm very interested in seeing what could be done with something like that.

And don't forget that it's a trivial exercise to add an RS-232 converter to Teensy 3.5, 3.6, or 4.1 and connect it to the serial port. I currently have my X16 in a standard Micro-ATX case, so I'm thinking of mounting the microcontroller in a drive bay and pulling a reset and power switch out to the front of the case.

For that matter, a Raspberry Pi Zero could easily be wired up to the serial/network board, and that would open up a world of possibilities.