CP/M-cartridge for the C64



DISCLAIMER

  • All names with a copyright are acknowledged.
  • If the reader uses information from this document to write software or build hardware, then it is on his own account. I cannot be held responsible for blowing up your computer, mother-in-law or whatever; it will always be your own fault.
  • I'm not a sexist, with 'he' and 'him' I also mean 'she' and 'her'.


Copyrights

  • You may copy every bit on this page, including the source code, for NON-commercial use. I hope you enjoy it. If you use it, just give me at least some credit like "Stolen from Ruud" :-)



Some backgrounds
CP/M is an operating system developed by Digital Research and was meant for systems using Intels 8080. Some employees of Intel grounded a firm of their own and called it Zilog. One of their first products was a processor: the Z80. This processor wasn't only downwards compatible with the 8080 but had a lot of extra instructions and registers. The Z80 also had some technical advantages above the 8080 and soon computer manufactures discarded the 8080 and turned towards the Z80. Due to this fact CP/M-programmers started to use the extra features of the Z80 as well. Nowadays you could call CP/M the MS-DOS of the '70s and at that time Commodore hoped to benefit from this by developing a CP/M-cartridge for the C64. As the very intelligent reader you are, you know that the processor of the C64,the 6510, is not a Z80 and not even related with it so this cartridge must at least contain a Z80. And yes, you're right!.
This document will describe the technical ins and outs of the CP/M-cartridge. As there are enough databooks about the Z80 available, I won't describe the Z80 in detail but only those things needed to describe the cartridge.


Another processor, how is that possible?
As you all know, the VIC-II chips takes care of the video. It does this by sharing the bus with the 6510. At the positive half of the clockcycle the 6510 is in command, at the negative half the VIC-II. As the 6510 doesn't do anything with the bus at all during the negative half, no harm is done. Unfortunately the VIC sometimes needs more time to perform his tasks then the foreseen negative half of the clock. In that case it simply steels the time from the 6510 by stopping it down by activating the RDY-input. RDY stands for 'ReaDY' and is meant to signal the processor that the data is not available yet and that it has to wait a little longer. But a normal 6502, even stopped, still drives all the lines and that is not acceptable for the VIC so the developers of the 6510 built a feature inside this chip which made it possible for the VIC chip to tell the 6510 to disconnect itself from the bus. The name of the input for the 6510, which performs this function: AEC.
I think you all already guessed what must be done to connect another processor to the C64: activate AEC and RDY and you're ready to fire up your own processor.

Theoretically you could disable the 6510 right after the power-up of your C64 and let an external uP do all the work. But that means you only can run C64-programs after unplugging this uP again. So the same mechanism used for the 6510 we have to apply to this external uP as well. So let's start with telling you something about the bus of the Z80, which is formed by the addressbus, databus and the controlbus.

The Z80 has 16 addresslines, just like the 6510. Just like 6510, you also can tristate the Z80 so you could connect the Z80 straight to the bus. Unfortunately there is a nasty problem. After a RESET the Z80 expects a program at address $0000 and as we all know, the 6510 isn't able to write to this address in RAM due to its internal port. So the developers decided to shift the addressbus for the Z80 with $1000 = 4096 bytes. This is done with the help of U10, a 74LS283. So address $0000 for the Z80 is $1000 for the 6510. So the I/O-area starts at $C000 for the Z80. Unfortunately the 74LS283 cannot be tristated so an extra 74LS245, U14, does this job. An extra 74LS245, U11, does also tristate the addresslines A0..A7. Dis/enabling the addressbus will be discussed later.
Personal comment: IMHO there is no reason to buffer/tristate A0..A11.

As you can see, U7, a 74LS245 and U4, a 74LS373, are used to buffer/store the databus. Why two ICs?. As you probably know, CLK2 is used to tell all ICs inside the C64 when the data on the bus should be read. The actual reading is done at the negative flank of CLK2. However in case of the Z80, the actual reading is done at the positive edge of the RD (= ReaD) output and this edge appears about 85 ns. after CLK (at 4 MHz.). This means that the data has to be stored in the mean time and that is were the 74LS373 comes in place. This automatically explains the function of U7 because we also need an counter buffer to write data towards the C64. Dis/enabling these two ICs will be discussed later.

Regarding the controlbus only one signal is used: R/W. This signal is derived from WR through U5A, a 74LS74 (data-flip-flop). The moment WR becomes active (L), R/W becomes (L) as well. R/W becomes (H) at the positive edge of CLK when WR is (H) again, or when the Z80 has to WAIT (= Z80 equivalent of RDY).
Personally I don't understand the involvement of this flip-flop at all. WAIT is only activated when the z80 is told to return control to the 6510 again and at that moment the complete R/W-signal will be disabled so I question this function. The flip-flop only delays the (L)-level of R/W about 250 ns after the negative edge of CLK. So R/W remains (L) for these 250 ns during the first part of the negative halve of CLK2. But it has no function there at all, so why???

What about the other signals of the controlbus? With the Z80 a designer has the possibility to separate memory and I/O by means of two lines: MREQ and IORQ (memory / I/O request). As you can see, both have not been used. This means that memory- and I/O-operations can have affect on the same area within the 64K-range of the C64.
The Z80 does have the equivalents of the 6510 IRQ- and NMI-inputs as well: INT and NMI. But both are NOT used! I don't have any idea why this, IMHO enormous, limitation has been put upon the cartridge. I was told that this cartridge was a flop. As I never have worked with CP/M on a C64 (my interest in this cartridge is purely technical at the moment) I cannot give you hard facts why. But as programmer I think the cause of this flop is this not connecting NMI and INT with the C64; it puts a lot of stress on the programmers handling things like keyboard, RS232 and Video. As far as I know the idea was to let only the 6510 deal with the interrupts but then I still wonder how the communication between the Z80 and 6510 has been set up.


The clock
A Z80 normally runs at a higher frequency then the 65xx family but on the other hand it uses 3 or 4 cycles for every cycle the 65xx uses. CLK is derived from the DOT-clock (= ~8 MHz.). The DOT-clock is divided by 2 (U1B, 74LS74) so CLK is about 4 MHz. At the moment CLK2 becomes (H), CLK is frozen. The total effect is that the Z80 runs at about 3 MHz. As you can see the output of the flip-flop drives U2D, a 74LS04, and a PNP-transistor. Personally I have no idea why this has been done. IMHO connecting the CLK-input of the Z80 directly to the Q-output should work as well.


Dis/enabling the card
Enabling the card is done through a flip-flop by writing a byte to an address in the range $DE00/$DEFF with bit0 is 0. Writing with bit0 = 1 disables the card again. Disabling the card is done by activating the BUSRQ-input (=BUS ReQuest) of the Z80. The moment the request is validated, the Z80 activates (H) the BUSAK (=BUS AcKnowledge). This signal is used to disable the buffers of the address- and databus as well. Enabling the card automatically disables the 6510 by activating the DMA-input of the expansion connector.
Whenever the card has been enabled, the VIC must be able to disable it. So the signal BA is involved in the disabling process as well. In this case BA activates the BUSRQ-input (U2C, U9B).


Testing the card
The following program is an edited version of the one in the Reference Guide, page 370. (Actually I copied it from FUNET, saved me some typing :-) )

10 rem this program is to be used with the z80 card
20 rem it first stores z80 data at $1000 (Z80=$0000)
30 rem then it turns off the 6510 irq's and enables
40 rem the z80 card. The z80 displays a message and
45 rem then the z80 card must be turned off
50 rem to re-enable the 6510 system.
100 rem store z80 data
110 read b: rem get size of z80 code to be moved
120 for i=4096 to 4096+b-1:rem move code
130 read a:poke i,a
140 next i
200 rem run z80 code
205 print"" 
206 print"6510 in command" : print
210 poke 56333,127: rem turn of 6510 irq's
220 poke 56832,00 : rem turn on z80 card
230 poke 56333,129: rem turn on 6510 irq's when z80 done 
235 print"6510 again in command" : print
240 end
1000 rem z80 machine language code data section
1010 data 102 : rem size of data to be passed
1100 rem z80 turn on code
1110 data 00,00,00 : rem our z80 card requires turn on time at $0000
1200 rem z80 task data here
1210 data 62,18,50,40,244,62,21,50,41,244,62,21,50,42,244
1211 data 62, 4,50,43,244,62,32,50,44,244,62, 9,50,45,244
1212 data 62,19,50,46,244,62,32,50,47,244,62,20,50,48,244
1213 data 62, 8,50,49,244,62, 5,50,50,244,62,32,50,51,244
1214 data 62, 2,50,52,244,62, 5,50,53,244,62,19,50,54,244
1215 data 62,20,50,55,244,62,32,50,57,244
1300 rem z80 self-turn off data here
1310 data 62,01 : rem ld a,n
1320 data 50,00,206 : rem ld (nn),a :i/o location
1330 data 00,00,00  : rem nop, nop, nop
1340 data 195,00,00 : rem jmp $0000
1350 data 00,00,00  : rem nop, nop, nop
1360 data 00,00,00  : rem nop, nop, nop
I changed the program from line 1210 on because of the fact I didn't notice any change in the behaviour of the computer with the original program.


Differences with the Z80 in the C128
I had a look at the SCH of the C128 and I immediately saw two important differences: INT and IORQ were used. So the Z80 of the C128 can at least recognise interrupts. The MMU translates the use of the IORQ-line to an address in the I/O area of the C128 ($D000-$DFFF). But I have no idea at this moment what the conversion algorithm is.


Software
I put some requests on VICUG for some CP/M software for the C64 but until I haven't had any response :-( Theoretically you can use all CP/M software but I have my doubts. FUNET can at least provide you with a boot floppy. Remark: the floppy doesn't boot correctly the second time if you reset the C64 using a reset-button, you MUST turn your computer off and on.


Schematics
Available here.




You can email me here.


[Homepage]