CP/M-cartridge for the C64
                                     
                            by Ruud Baltissen
                                     
                                     
DISCLAIMER 

-    All names with a copyright are acknowledged.

-    This document is PURELY based on personal research. I haven't found
     any document or whatever about the INTERNAL working of this cartidge.
     This means that this document tells you how I think how it works. And
     as I am a normal human being, I could be wrong. 

-    If the reader uses information from these documents 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 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 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-cartidge for the C64. As the very inteligent 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-car-
tridge. As there are enough databooks about the Z80 available, I won't
describe the Z80 in detail but only those things needed to desrcibe the
cartidge. 


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.
Unfortunally the VIC sometimes needs more time to perform his tasks then
the forseen 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 acceptible
for the VIC so the developpers of the 6510 built a feature inside this chip
which made it possible for the VIC chip to tell the 6510 to disconnect from
the bus. The name of the input for the 6510 which performs this function:
AEC.  
I think you all already guesed what must be done to connect another
processor to the C64: activate AEC and RDY and you're ready to fire up your
own one. 

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 this extrenal uP as well. So let's start with the
bus 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 as well so you could connect the Z80 straight to the
bus. Unfortunally 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. Unfortunally 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 nsec 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-flipflop). The moment WR
becomes active (L), R/W becomes (L) as well. R/W becomes (H) at the posi-
tive 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 flipflop 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 flipflop only delays the (L)-level of R/W about 250 nsec
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 possebility 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 inte-
rest in this cartridge is purely technical at the moment) I cannot give you
hard facts. As engineer I think the cause of this flop is this not connec-
ting 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
froosen. The total effect is that the Z80 runs at about 3 MHz. As you can
see the output of the flipflop drives U2D, a 74LS04, and a PNP-transistor.
Personally I have no idea wy 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 flipflop 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 expan-
sion connector. 
Whenever the card has been enabled, the VIC must be able to disable it. So
the signal BA is involved in the disablingproces 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 reenable 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 C128
I had a look at the SCH of the C128 and I immediatly saw two important dif-
ferences: INT and IORQ were used. Reading 'C128 Intern' I found out that
the MMU took care of shifting and repositioning of complete addressranges
as well. With other words, completely different with the cartridge.


                                     
                           You can reach me at:
                                     
                         rbaltiss@worldaccess.nl