2022-12-10: Racing, Shooting, CP/M!

I’m Linards Ticmanis, the guy who put out the CPMFAST package in 1999 that has been mentioned several times in the other answers (although I go by the nickname TeaRex on here). While creating that, I had to take a deep look into the innards of C128 CP/M, so that I think I can say that I have a rather detailed understanding of the way it works internally (or did have it over 20 years ago… I’m not excluding some failures of human memory here). I’m afraid there is some myth and half-truths in some of the other answers to this question.

Firstly, in C128 CP/M, writing to the 80-column screen does NOT go through the 8502 CPU as several other answers assert; the Z80 talks directly to the 8563 VDC (the 8502 is used by CP/M for several other things, such as disk I/O and printer output, but not for screen output and not for keyboard input either).

The reason why screen output in C128 CP/M is so slow is rather

1. The Digital Research provided BDOS of CP/M 3.0 is much slower in doing basic character I/O than the BDOS of the more common CP/M 2.2; CP/M 3.0 does support much more complex I/O device reassignments where standard output can go to any possible set of up to 16 devices at the same time; this also means that for every character being written, it has to loop in a complicated, bit-shifting way over a 16-bit mask to determine which of 16 output device drivers to actually send the character to, and of course it does all this in pure Intel 8080 code without making use of the Z80 specific instructions and registers.
2. The code in the C128’s Commodore supplied CP/M BIOS (which for this purpose includes the 4KB of Z80 ROM code) is written in such a way that outputting normal printable characters such as letters or numbers (as opposed to control characters) follows the LONGEST path through the code (each character is compared to every possible control character before it is decided that it isn’t one), even though it is the most common case by far.
3. C128 CP/M supports the bit-banging RS232 on the userport. Unlike in native or C64 mode, the RS232 is always enabled and set to 300 baud by default, which means that the interrupt (IRQ) rate is also much higher than in native mode; and the interrupt code for the Z80 does quite a bit of things, including scanning the full keyboard at the same rate. This wastes a lot of CPU time when RS232 is not used (i.e. practically always).
4. Bank switching between the user program (TPA in CP/M parlance) in bank 1 and the BIOS/BDOS/ROM/buffers in bank 0 happens VERY often in the C128 CP/M. Several times per character. Although the impact of this is lower than the other three points above.
5. Access to the 80-column screen RAM is doubly indirect as indicated in other answers (you have to access the RAM indirectly through some registers of the VDC chip, which in turn are only indirectly accessible to the CPUs through a rather bottleneck-y approach – you write a register number to $D600, do a little check-for-the-readiness-flag-bit-to-be-set loop and then write a register value to $D601).
6. The biggie is of course the fact that the VIC-IIe is not put into fast mode when the Z80 is running, so that the Z80 runs at 4MHz for two cycles (one 8502 half-cycle) and then stops for two cycles (the other 8502 half-cycle), giving it an effective speed of just 2 MHz, which is just too low for CP/M 3.0 in practice, although it would be sort of enough for CP/M 2.2. The C128 CP/M source code (which was available from Commodore back in the day when you bought the complete set of CP/M 3 manuals from them) contains multiple instances of code that switches the VIC-IIe between slow mode (for hardware access, e.g. access to the REU, and for switching between the two CPUs) and fast mode (for everything else); but it’s all commented out, so it seems they aimed for that but couldn’t get it working. I tried to mail the main developer, Von Ertwine, with a question about this back in the 90s, but unfortunately never got an answer.

In practice, you CAN switch the VIC-IIe into fast mode while the Z80 is running; this causes a simple timing loop with interrupts disabled to in fact run somewhat faster (though not twice as fast), but crashes the system when you do much of anything beyond this. It would be really interesting if someone could check with a logic analayzer (which I don’t have access to) what exactly happens signal-wise, especially to the Z80 clock signal, when you enable fast mode while the Z80 is running.

CPMFAST adresses the first three points above by establishing several short-cuts through the code for the common case (output of a printable character, to the 80 column screen only, without RS232 use) and also increases the disk buffer area so that fewer disk accesses are needed. It cannot do anything about the points numbered 4 through 6, though.

Linards Ticmanis, author of CPMFAST