Hallo allemaal, This email contains a lot of technical stuff about hardware so if you're not interested you may stop reading at this point. At the moment I'm working at two projects. The first one is PC-IEEE, a project to devellop a IEEE interface card for the PC. This can be an internal card or a interface you can attach to your printerport. I'm building the first one, Andre Fachat is building the other one. I want to tell you about the difficulties I experienced so those who are interested in IEEE can learn from it. The first problem I encounterd was that the card I built could be seen by my XT, 286 and my Pentium but not by my 386. I first test every design in a XT, then a 286, then a 386 and at last in my own Pentium. If something goes wrong due to an design error, I prefer blowing up a XT above blowing up my Pentium. But my 386 refused to see the card. With the help of a scoop I found out that only about 500 ns. where available to access the I/O. The accesstime of a 8255 is 500 ns. as well. I tried some other 8255s but with the same result. So those measured ~500 ns. were less then the needed 500 ns. So I had to add some extra hardware to my card to slow down the PC. The ironic thing is that this was my first design ever without this delay device due to the fact I never encounterd any problems with my designs when I disabled it :-( After installing the delay device the 386 recognized my card as well. The second problem I encountered during scanning the IEEE-bus when I had commanded my 8032SK to load a BASIC PRG. I wasn't able to recognise one single byte. So I had to devellop a PRG in BASIC which enabled me to scan and manipulate every single line of the IEEE bus on the 8032 and a simular PRG for the PC. In this way I found out that I had mixed up the datalines on the PC-card. The BASIC PRG will be made available for public use as it can be used for every 40xx and 80xx PET/CBM AFAIK. The third problem was that after replacing the lines I still didn't recognise the data on the bus. After some puzzling I found out that all bytes were inverted. This puzzled me because this simply meant that the byte was inverted on purpose because writing a byte directly to the PIA appears as so on the bus. This also means that an attached device has to invert it again to get the original byte. Has anybody an idea why this is done? At the moment I'm expanding my PRG at the PC so it will show the behaviour of all lines during a transfer. Here I encounterd an other problem. Even using my Pentium neither Pascal nor C are fast enough to scan all lines quick enough to see all changes. So I have to program in assembler. The second project, X-DMA, is a project to devellop an interface which connects the expansion slot of the C64/128 directly with an ISA-slot of an PC. I finnished the theoretical part and I want to let you read it and to give comment on it. This project was also the reason why I asked those questions about the VIC and the SID. As it is meant to be published on my site as well, it is in HTML. --------------------------------------------------------------------------- <HTML><head><TITLE> Ruuds Commodore Site / X-DMA </TITLE> </HEAD> <BODY> <center> <body background bgcolor="#66FFCC" text="#000000" link="#3300FF" alink="#00DEAB" vlink="#FF9900"> <p><br> <font size=7> <FONT COLOR="#3300FF"> <B> X-DMA </B><br><br></FONT></font size></center><hr><p><font size=3> <FONT COLOR="#FF0000">DISCLAIMER <br></FONT><UL> <LI>All names with a copyright are acknowledged. <LI>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 responcible for blowing up your computer, mother-in-law or whatever; it will always be your own fault. <LI>I'm not a sexist, with 'he' and 'him' I also mean 'she' and 'her'. </UL><p><br><FONT COLOR="#FF9900">Copyrights </FONT><UL> 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" :-) </UL><p><hr><br> <FONT COLOR="#FF9900">What is X-DMA?<p></FONT> X-DMA is an idea to connect a complete system like a PC, to the C64/128 in such a way that the exchange of data between that system and the C64 is done by means of DMA. A part of the design can be used to connect only a single CPU to the C64/128.<br> Products: A card for connecting your C64 with that system. NO soldering on the C64 itself needed! <p><br> <FONT COLOR="#FF9900">The story<p></FONT> <A HREF="PC-DISK.HTM">PC-DISK</A>, the first ancestor of X-DMA, is not very fast. I could live with it but because of some questions I decided to develop a faster version: PC-XFER. This interface uses a block of RAM which is accessible from the C64/128 as well as the external system. But I never found the time to actually build one. Either Marko Makela or Frank Kontros launched the question if it was possible to use DMA. I designed a SCH but due to the its complexity I never released it. But it kept wandering through my mind and one day I found out that I could simplify the original PC-DMA design by simply drop the I/O part at the side of the external system. <br> Remark: From now on if I say 'C64' I mean the C128 as well. <p><br> <FONT COLOR="#FF9900">The base<p></FONT> DMA stands for Direct Memory Access. This means that data is transfered from memory or I/O to memory or I/O by other means then by the CPU of that particular system. When DMA is performed, another device or CPU takes complete command of the bus. The REU (RAM Expansion Unit) of Commodore uses DMA to transfer data between this cartridge and the C64/C128. In this case a special <B>C=</B> IC does the job. For the PC users amongst you, DMA is used when loading or saving files from/to your floppydrive or harddisk. In case of the PC the processor is stopped and disconnected from the busses and the 8237 DMA-controller takes control of the bus. <br> A kind of DMA also happens with the C64 all the time; if the VIC (videochip) does not have enough time to read all the data during its normal ratio of time, it simply steals this time by shutting down the 6510 for a few cycles. <p> The basic idea of X-DMA is to let another system (or single CPU) make use of the I/O and memory of the C64. (system: any computersystem which can run stand alone, even when attached to the C64.) This could be a PC, to be used as an alternative drive. The design can also be modified to be used with a single processor so, when using a 65816, we can run a real UNIX- alike/compatible OS, like <A HREF="http://www.tu-chemnitz.de/~fachat/csa/index.html"> OS/A65 </A> from <A HREF="http://www.tu-chemnitz.de/~fachat/personal/personal.htm">Andre Fachat</A>, on a C64. <p><br> <FONT COLOR="#FF9900">The design<p></FONT> What ever system we use, this system must forfill the needs in timing of the C64 when writing data as well as its own needs when reading it. This means we have to synchronize all the actions. When a systems is attached, I presume there is a possebility to slowdown this system in one or another way. The CBM 3032 does have this possebility in the form of an external RDY-line. A standard C64 does <B>NOT</B> have this possebility. Therefore it is not possible to connect a C64 to another C64 in this way. <p><br> <FONT COLOR="#FF9900">Putting the C64 in DMA mode<p></FONT> Befor we can DMA, we have to disconnect the 6510 completely from any bus. This has to be done by the C64 itself. The most simple way is to take a flipflop, a 74LS74 (#1), and use one of its output to activate the DMA- input of the expansionbus. This input stops the 6510 and disables all data- , address- and controllines. <br> How is this flipflop addressed? The most simple way would be to use the IO1 line to activate the flipflop and IO2 to de-activate it again. Disadvantage: you cannot connect another cartridge at the expansionbus parallel to X-DMA. So using an extra decoder within IO1 or IO2 is a more friendly solution but will need more parts. <br> IMHO there are two better solutions but they mean hacking the C64. Unfortunally it will cost us using more parts because we won't use IO1 or IO2 anymore. But the advantage of not using IO1 or IO2 asures us to be able to use any cartridge using these lines. <p> As you all know, the VIC-chip is mirrored all over the range $D000/$D3FF. This means that reading from address $D020 has the same effect as reading from $D120, $D220 or $D320. (And with these I haven't mentioned all addresses!) As far as I know, all programs use the address $D020. So if you develop an decoder specific for the area $D000/$D0FF and connect its output to the VIC, the range $D100/$D3FF will be free for your own use. <br> The second solution is to use a decoder for the not used registers of the VIC ie. $31-$3F ($2F and $30 are used by the VIC in the C128). AFAIK writing a value to these 'non-existing' registers does not influence the VIC or C64 in any way. By using just the address as trigger we can save a lot of hardware. By example we can use $D031 to activate the DMA and $D032 to de-activate it again. <br> The problem we face with both solutions is that the address range $D000/$D3FF is not dedicated to the VIC alone; in other circumstances you can address the CHARROM or RAM with it. But we don't have no means to our disposal at the expansion slot to see what area actualy is addressed. So with both solutions the decoder has to be placed between the VIC chip and its chipselect-line, meaning we have to change the hardware of the C64 itself. <p> Undependent of the choosen solution we connect the 'Activate_DMA' output of the decoder with the 'RESET'-input of the 74LS74, the 'De-activate_DMA' output with the 'PRESET'-input and the Q-output of the 74 with the DMA- input of the expansionbus. To ensure that DMA is NOT active after a reset, we connect the RESET with the CLOCK-input and the DATA-input with +5 Volt. The rising edge of RESET sets the flipflop this way. FYI, the outputs of the decoder must be active (L)! <br> Once our own system or CPU has gained control over the C64, we have to connect the three busses, the address-, data- and controlbus, with the C64 and to synchronize the two systems when necessary. <p><br> <FONT COLOR="#FF9900">The synchronisation of the busses<p></FONT> As we don't have the means to influence the behaviour of the C64 on this area, we have to influence the behaviour of the external system or CPU. I myself am interested in connecting a PC (complete system) or a 65816 (only the processor) to the C64. Both can be manipulated for the needed synchronisation: the 65816 has the well known RDY-line and the PC has a line named IORDY which has the same function as the RDY-input of the 6510 or 65816. <br> There is a difference in connecting live systems, like a PC, or just a CPU to the C64. It would be nice if we could connect a 12 MHz 65816 to the C64. The 6502, and thus the 65816, has been designed in such a good way that it does not waist one single clockcycle; it uses as much cycles as needed to perform the necessary read- or write-operations. The command "INX" for example, uses only one clockcycle; the one to read the command. The command "STA $D020" uses four, one for reading the command, two for reading the address and one for storing the data at $D020. A 12 MHz 65SC816 will do exactly the same. But for this reason it is impossible to operate this 65816 at his native speed due to the simple reason it has to wait every clockcycle for the C64. The overall effect would be that it would run on 1 MHz and in that case you could save yourself a lot of trouble and additional hardware by letting it run on the 1 Mhz of the C64 anyway. <br> But there are CPUs who need more then one clockcycle to perform the same task. Two of them are the well known Z80 and the 8088 (used in the PC-XT). In those cases it makes sence to let them run on an higher frequency because there are cycles which can be performed independent of CLK2, even during the negative half of CLK2 when the VIC is in command. The <A HREF="c64-cpm.htm">CP/M-cartridge</A> for the C64, produced in the early '80s, is equiped with the Z80. It derives its clock from the DOT-clock and the resulting signal is manipulated to synchronize it with the C64 when necessary. But this cannot be done with every CPU in this way. A 8 Mhz 8088 needs 24 Mhz to start with and this means we have to generate it ourself or loosing valuable processortime. And synchronizing it with CLK2 would cost much more effort then using the RDY-input of this CPU. <br> Systems can run on their native speed as long as they don't address the C64. The moment they do, they have to be slowed down to 1 MHz as well. There is no objection against running a program in the memory of the C64 by the CPU of this system but then you must consider the fact that this program only will run at 1 MHz (or even slower). (A Pentium-166 MHz running at 1 MHz. Just the thought :-) ) <p><br> <B>The synchronisation</B> <br> To explain this subject, I'll use a guestsystem with a 65816 running on 4 MHz as an example for the moment. <br> The first thing to realize is to ensure that the data- and addressbus towards the C64 is stable during a complete positive half of CLK2. So at the moment the external system addresses the C64, it should be stopped and won't be allowed to continue until one complete positive half has been detected. One way to do it is to clock a 74LS74 flipflop (#2) with CLK2 of the C64. First we need a decoder to detect the fact that the guestsystem is addressing the C64. The active (L) output from the decoder is connected with the DATA-input of that 74. As long as the output is (H), the Q-output of 74 #2 remains (H) as well. (To simplify things I will write Q2 meaning output Q of flipflop #2) If it becomes (L), the 74 won't detect it until the first positive edge of CLK2 (B). A NAND-gate combines BA and CLK2. The output reflects (NOT CLK2) as long as the VIC isn't in command. An AND- gates combines the ^Q2-output (^Q means the negative Q output of the 74) and the output of the previous NAND-gate. The result is a positive edge at the moment CLK2 finnishes the positive halve which triggered 74 #2 in the first place (C). This edge triggers a third 74 whose DATA-input is connected with the output of the decoder as well. Its ^Q3-output and the output of the decoder we tie to an OR-gate. The output of this OR-gate can be used to activate the RDY-line of a 65816 or the IORDY-line of a PC. <PRE> +--------+ +--------+ +--------+ +---- CLK2 | | | | | | | +----+ +--------+ +--------+ +----//----+ +--------+ +--------+ +--------+ +---- BA | | | | | | | +----+ +--------+ +--------+ +----//----+ _______ +----+ +--------+ +--------+ +----//----+ BA*CLK2 | | | | | | | +--------+ +--------+ +--------+ +---- +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +-- CLK | | | | | | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +//+ +--+ ----------+ +--------------//--------- Decoder | | +-----------------------------+ +------------+ ^Q2 | | -----------------------+ +------------------//--------- +---+ ^Q3 | | --------------------------------+ +------------------//--------- ----------+ +----+ +--------------//--------- RDY | | | | +---------------------+ +--+ Point in time A B C DE F </PRE> At point D the 65816 detects that RDY is (H) and finnishes the cycle. If this cycle involved reading the data, it will be read at the same time. But as you can see, CLK2 is (L) and, certainly at this point, we can presume the data on the databus is as invalid as can be. But, as you will remember, the valid data was latched by the 573 at point (C) and this is the data the system will read. <p> The next operation is to set the 74s again for the next read/write operation. If we presume that the next command has to be fetched from the guest system its own system memory at the beginning of its next CLK, then the output of the decoder becomes inactive at point (F). To set both flipflops again, we could invert the output of the decoder and feed it to the set-input of both flipflops. But if the 65816 is running a program in the memory of the C64, then the decoder won't become inactive again. So the flipflops won't be set and the 65816 will read the next command at normal speed which certainly will result in disaster. This means we have to set the flipflops in another way. <p> The problem is that the needed extra hardware depends on the hardware of the guest system. In the above example using a 65816 means that we can set the flipflops at the first negative flank of CLK after RDY has become (H). We AND ^Q3 and CLK and feed the output to the clock input of a 74 (#4). The data input is tied to Vcc. The moment CLK goes (L), the output of the AND- gate does this as well clocking (L) in the ^Q4-output. This output is tied to the set inputs of the the previous two 74s. To reset the 74 #4 we tie its reset input with ^Q3. This configuration also prevents 74 #4 to do anything except during the interval ^Q3 is (H). <br> This results in the following diagram: <PRE> +--------+ +--------+ +--------+ +------ CLK2 | | | | | | | +----+ +--------+ +--------+ +----//--+ +--------+ +--------+ +--------+ +------ BA | | | | | | | +----+ +--------+ +--------+ +----//--+ _______ +----+ +--------+ +--------+ +----//--+ BA*CLK2 | | | | | | | +--------+ +--------+ +--------+ +------ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +-- CLK | | | | | | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +//+ +--+ ----------+ Decoder | +--------------------------------------------//--------- +------------+ +------------+ +------ ^Q2 | | | | | -----------------------+ +----+ +//--+ +---+ +---+ ^Q3 | | | | --------------------------------+ +-------------+ +//--------- ----------+ +----+ +----// RDY | | | | +---------------------+ +------------+ --------- Point in time A B C DE FB C D B </PRE> One interval, E-F, has still to be explained. The moment ^Q3 becomes (L) again, RDY will become (L) as well. But the 65816 won't notice this until at the end of the positive half of CLK2. If during the first moments of the positive half of CLK2 the 65816 decides to read/write in an other area then where the C64 is situated, the decoder will become inactive long befor the 65816 will scan the RDY line and no harm is done to its normal operation. <br> In the situation of running a program in the memory of the C64, the address on the addressbus will change but the decoder will remain active. So at the end the positive half of CLK2 the 65816 will start waiting again. But in this case it is suposed to do so. <p> If you look at the output of ^Q3, you will notice that the actual speed of the 65816 is only 1 MHz. Let us presume the 65816 runs at a lower speed: <PRE> +--------+ +--------+ +--------+ +--------+ CLK2 | | | | | | | | +----+ +--------+ +--------+ +--------+ + +--------+ +--------+ +--------+ +--------+ BA | | | | | | | | +----+ +--------+ +--------+ +--------+ + _______ +----+ +--------+ +--------+ +--------+ + BA*CLK2 | | | | | | | | +--------+ +--------+ +--------+ +--------+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ CLK | | | | | | | | | | | | | | -+ +----+ +----+ +----+ +----+ +----+ +----+ +- --+ Decoder | +------------------------------------------------------------------ +----------+ +------------+ +--------+ ^Q2 | | | | | | -----+ +------+ +----------------------+ + +-+ +---+ +-+ ^Q3 | | | | | | --------------+ +---------------+ +-----------------------------+ + --+ +--+ +----+ +-- RDY | | | | | | +-----------+ +--------------+ +----------------------------+ Point in time A B C </PRE> The gap between A and B is equal to a speed of about 1 MHz. But the gap between B and C is equal to a speed of about 0.5 MHz. This means the average is about 0.75 Mhz. Seeing the two above diagrams my rough conclusion is that fast guest systems won't go faster then 1 MHz when running in the memory of the C64. Slow systems will become even slower then 1 MHz. The classification of 'slow' and 'fast' depends on the used processor and the used clockspeed. My guess is that the line between slow and fast for the 65816 is 4 MHz. <p><br> <b>Involving the VIC </b> <br> What happens if the VIC starts to steal cycles ie. BA becomes (L)? <PRE> +--------+ +--------+ +--------+ +---- CLK2 | | | | | | | +----+ +--------+ +-//-----+ +----------+ +--------+ +--------+ +---- BA | | | | | +----+ +-------------------//-----+ +----------+ _______ +----+ +-------------------//-----+ +----------+ BA*CLK2 | | | | | +--------+ +--------+ +---- +--+ +--+ +--+ +--+ +--+ +//+ +--+ +--+ +--+ +--+ +-- CLK | | | | | | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ ----------+ +------- Decoder | | +-----------------------//----------------------+ +----------//------------------+ ^Q2 | | -----------------------+ +----------- ----------------------------------//--------------+ +----------- ^Q3 | | +---+ ----------+ +----+ +------- RDY | | | | +-----------------------//--------------+ +--+ Point in time A B C DE F </PRE> As you can see, as long as BA is (L), the third flipflop won't get a positive edge causing ^Q3 to remain (H) and RDY (L). In other words, the period between (B) and (C) is extended as long as BA is (L). <p><br> <B>Connecting a PC </B> <p> Until now we only looked at the 65816 used in a system. As I already mentioned I'm interested in connecting a PC to my C64 as well. But in most PCs there is a INTEL (clone) fitted and they behave different from the 65816. We can detect when a 80x86 actually addresses its memory by looking at MEMW and MEMR: one of them becomes (L). If we involve these signals in the decoder, then the output always becomes inactive after every action. Even when running a program in the memory of the C64. In this case we do not need 74 #4 anymore and only need an inverter to set 74 #2 and #3. <p><br> <FONT COLOR="#FF9900">The technical realisation (system) <p></FONT> <B>The addressbus</B> <br> Connecting the two addressbusses with eachother is simple; you only have to place two 74LS541s between them with the outputs towards the C64. They only may be enabled when ((BA*CLK2) OR Q2) is (L). We have to involve Q2 to make sure that, certainly during a write operation, all devices, including the PLA, only are accessed during a full positive halve of CLK2 so they won't do unexpected things due to an unstable bus. A resistor-arrays is used to define the level of each addressline to (H) when the buss is not used. <p><br> <B>The databus</B> <br> We need some mechanisms to ensure that both systems receive valid data at any time. By slowing down the guest to the level of the C64 we asure this for the C64. A big problem is that if the guest processor or system thinks it is in command of the C64, it is only half of the time: the positive half of CLK2 to be exact. By saving the data in a temporary store during the time the data isn't valid anymore, we asure the availability for the guest system. <br> This is achieved by using a 74LS541 and a 74LS573. The outputs of the 573 and the inputs of the 541 are towards the guest system. 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 a Z80/80x86, the actual reading is done at the positive edge of the RD/MEMR output and as both signals are not synchronised, we have a problem to solve. This means that the data has to be stored in the mean time and that is where the 573 comes in place. This automatically explains the function of the 541 because we also need an counter buffer to write data towards the C64. Dis/enabling these two ICs will be done by MEMR and MEMW in combination with the same signal used to enable addressbus buffers. <p><br> <B>The controlbus</B> <br> To the controlbus belong all signals which whom the CPU controls its enviroment. In case of the C64 only three signals are important: R/W (Read/Write-line) and both the interruptlines, IRQ and NMI. It is obvious that R/W only has to be controlled during the full positive half of the clock mentioned above. The signal itself is derived from MEMW. The interrupts may only be forwarded to the guest system during the period it is in command of the C64. Otherwise the guest system may receive, for that moment, untraceble/unexplainable interrupts. <p><br> <FONT COLOR="#FF9900">Connecting a PC to the C64<p></FONT> The idea of X-DMA is that the external system considers the C64 as 'just another 64 KB of memory or I/O'. This means that there must be a gap of 64 KB unused addressspace available. Unfortunally I cannot tell where you can find that gap because it completely depends on the configuration of the PC. My personal advise is to use an 'old' 386 with only a MGP or CGA card. This means that the range $A0000/$BFFFF is free for X-DMA. <br> To decode the area, you only need a 74LS138 and two NAND-gates. One gate is used to combine MEMR and MEMW, the Read- and Write-signal of the PC. The output of the NAND goes to the G-input (6) of the 138. The negative G2-input (5) you connect with AEN. This signal, active (L), tells the peripheral if the address is valid. The output of the other gate is connected with the negative G1-input (3) and combines adressline A19 and the ^Q1-output. The three inputs A, B and C (1, 2 and 3) are used to decode A16 to A18 for the range you need. One of the outputs of the 138 now reflects the choosen area and is the active (L) decodersignal mentioned above. <br> As we all know, the C64 is an 8-bitter. If we don't use a PC-XT, we are dealing with a 16-bitter or even more. This looks like a possible source of hardware trouble but fortunally it isn't. By NOT telling the PC the attached card is a 16-bitter (or more), it asumes it deals with an 8-bitter and performs internally the needed conversions from 16 to 8 bits and vica versa. This means that if you instruct the PC to write a word to address $0400, it splits up this word in two bytes and then seperatly writes them to the addresses $0400 and $0401. <p> My previous design contained some I/O for the PC as well as for the C64 to determine if the PC was in command of the C64. That I/O was the part I scratched to simplify the design. So how does the PC know it is in command or not? The PC is either busy for the C64 or not, just like a drive. We'll use the 'not busy'-period to let the PC scan the dedicated address range if it is in command. The general idea is that if it is in command of the C64, it should be able to write a value to a random address and, when reading this address again, the read value should be the same as the one written before. If it is not in command, it will read $FF because of the resistor-arrays. But which address to use? As we all (should) know, there are two bytes in the 64 KB-range of RAM the 6510 cannot access: address 0 and 1. The reason is obvious: the internal port of the 6510. But an extrenal system does not have this problem; these addresses are just two addresses of RAM it should be able to write to and read from. <br> Of course you are free to use an other address in the RAM-area but then you have to read this address first so you can restore its original value after the test. And this simply costs more time. <p><br> <FONT COLOR="#FF9900">Connecting another system to the C64<p></FONT> Beside my beloved Commodores and some other old 8-bitters, I'm only used to work with PC's. So if you own a computers like Apple, Atari or even the C= Amiga, I'm very sorry but I'm afraid I cannot help you :-( <br> On the other hand feel free to do some research yourself and tell of the results. <p><br> <FONT COLOR="#FF9900">Connecting a 65xxx processor to the C64<p></FONT> The advantage of using a 65xxx CPU is the fact you don't need the synchronisation mechanism. Because of that you can replace the combination 541/573 by a single 74LS245. The enabling of the buffers only depends on DMA- active and BA. These two signals also control the RDY-input of the CPU. <br> After powering up the C64, the guest-CPU expects a RESET-vector at address $FFFC/D so the 6510 has to provide one before releasing control to it. This can be archieved by using the RAM-area under the System-ROM. <br> Remark: only using a CPU is sometimes waisting a lot of resources. In case of the 65816 I personally would supply this CPU with its own ROM and RAM as well. Nowadays you can get 65816S running at 12 MHZ but using a higher speed enforces you to use the synchronisation mechanism again. <br> Remark: the older versions, including the 65C02, cannot be stopped when writing data. The 65SC02, 65SC802 and 65SC816 can. I know the VIC-chip waits 3 cycle before actually taking over the bus, so theoretically it should be safe. But I wouldn't bet my money on it. <p><br> <FONT COLOR="#FF9900">Connecting another CPU then a 65xxx to the C64<p></FONT> Have a look at my article about the <A HREF="C64-CPM.HTM">CP/M-cartridge</A> to see how to connect a Z80 to the C64. You will see that this cartridge doesn't use my described synchronisation mechanism but on the other hand the used technique cannot be used for every CPU and limits the clockspeed to maximal 8 MHz. Connecting other CPUs, like the 6809, could be realised as connecting it like a 65xxx (but don't rely on this info, just my own theory!), others must use the synchronisation mechanism. One point to pay attention to: The Z80 starts at address $0000 and as that is impossible, its addresS range was shifted with 4096 bytes. This has to be done with every CPU starting at address $0000. No special care is needed for other CPUS I know not starting at this particular address. <p><br> <FONT COLOR="#FF9900">Using X-DMA<p></FONT> Using X-DMA is a different story. This involves software for both machines. Due to the fact that the above is only theoretical, I haven't give it a good thought yet. At the moment I have two ideas. The first one involves changing the KERNEL. The second one is more complicated and involves another project: <A HREF="PC-FLOP.HTM">PC-FLOP</A>. The idea is that the altered 1541 stops the C64 and tells the PC where to load/save a program, block of data or whatever. <p><hr><p><center> You can reach me at: <Address> <A HREF="mailto:email@example.com">firstname.lastname@example.org</A> </Address></center><p><br> <A HREF="CBM.HTM">[Homepage]</A><br> </BODY></HTML> -------------------------------------------------------------------------- I you came this far, I admire your patience and I hope you enjoyed it. Groetjes, Ruud
Archive generated by hypermail 2.1.1.