Title screen of Muddy Racers for C64

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

Did the C128 display text in CP/M slowly and why?

Linards Ticmanis gave a fantastic answer to this question.

It turns out that actually despite the fact that the C128 has a Z80 clocked at 4MHz, which is similar to the Amstrad CPC6128, but in the case of the C128 several factors, such as the lack of direct memory access to the 80-column image, support for RS232 (at any time the system is running!) or control characters (comparing each displayed character first with each of them) and absurdly frequent switching of memory banks (even several times per displayed character). On top of that, the Z80 processor’s time-stealing synchronization with the cycles of the “main” 8502….

Backup of the original answer:

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

Published games:

  • #c64: Muddy Racers. We have seen a preview of the upcoming game before, but now you can officially buy it in the store of the publisher – Protovision. This Commodore 64 game has a bit of Micro Machines (that I’ve always loved) vibe, and you can play it by up to 4 people at once! Eighteen different racetracks on three stages, sounds a lot of fun. With the boxed edition you get a physical toy car!
  • #cpc: HyperDrive! Vertical scroller space shooter. Beautiful smooth animation (25fps scroll), good soundtrack, and it seems to promise to be incredibly addictive. Next year we can get a physical release! We shoot seventeen different types of enemies, dealing with five bosses at the end of the level along the way.

Akka Arrh… (I’m not choking)

Atari decided to resume working a game that in 1982 was considered too difficult and… abandoned! Now, after forty years, they are making a second approach to the subject and the game will be released in a modern (PC, PS4/5, XBox, etc.), very neon and still strongly geometric version…

Announcing Akka Arrh

More on this in Engadget.

Notify of

Inline Feedbacks
View all comments