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:rbaltiss@worldaccess.nl">rbaltiss@worldaccess.nl</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.