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