Help w/ hw memory access through expansion port
Stefan Burstroem
through the expansion port without interfering with the VIC chip
memory refresh.
I know that there is som hardware that allows you to connect fast
modems to the c-64 through the expansion port (not the user port)
Any help appreciated!
/Stefan 'Yabba' Burstroem
Andreas Boose
> Is there anyone who knows how to access the memory in a c64
> through the expansion port without interfering with the VIC chip
> memory refresh.
Do you really want an external device to act like a busmaster on the C64's
bus accessing the C64's memory by itself? For that a DMA-controller is
required to generate a complete 6510 bus cycle in phi2 while the real 6510
sleeps. I've only seen this usage of busmaster-DMA on CBM REUs and
accelerator carts with 65C816 write-through/write-buffered cache
subsystem. Very hard to rebuild with standard TTL logic...
BTW: It's not enough not interfering the VIC's memory refresh which
happens in phi1. Any phi1 cycle requires free data and address lines!
Except the 6510's A12-A15 address lines which aren't connected to the
VIC's address space and except under some conditions in Ultimax mode.
Using these lines while phi1 is useful for external Kernal expansions
carts to get the processor's $01 register status for the next phi2 cycle
to be 100%!!! compatible. An external Kernal expansion cart that uses this
amazing trick was published in the 64'er magazine a few years ago. It
plays with A12-A15, EXROM and GAME while phi1 and checks what happens to
ROML and ROMH.
> I know that there is som hardware that allows you to connect fast
> modems to the c-64 through the expansion port (not the user port)
That's a different story. There you don't access the C64's memory through
the exansion port, it's vice versa. You just access the additional
registers/memory with the internal 6510.
Mostly this 'hardware that allows you to connect fast modems' is a lousy
6551 UART banked into the IO address space.
You can add any 65xx bus compatible devices, (static) RAM or latches to
the expansion port, if you trigger them with phi2 and if you use the right
address decoding with -IO1/-IO2.
But you can't add all 65xx devices to the 6510 bus without anything else,
because the old ones like 6522 or 6551 are designed for the 6502 bus. The
6510 has a different timing to work with a 2nd busmaster (the VIC-II).
Both processors expect the data lines to be stable at the falling edge of
phi2, but unlike the 6502 the 6510's address lines aren't stable at the
raising edge of phi2 (due to the AEC switching), in worst case it takes
additional 80..100ns for the address lines to be valid.
The solution is to delay the raising edge of phi2 on the expansion board.
Mostly the carts using a 6522 or 6551 use a 74LS74 flip-flop triggered by
dot-clock to delay phi2. The same goes for external RAM, but there you
have to delay -CS and/or R/-W to aviod fast SRAM writing something into
its memory while the addresses aren't valid.
MfG Andreas
Jim Brain
> Is there anyone who knows how to access the memory in a c64
> through the expansion port without interfering with the VIC chip
> memory refresh.
> I know that there is som hardware that allows you to connect fast
> modems to the c-64 through the expansion port (not the user port)
Well, the modem cartridge (Swiftlink and/or Hart Cart) is just acting like
I/O is the c64 mem map. No tricks there.
If you REALLY want to read RAM from the internal C64 DRAM, you must disable
the 6502 inside the 64 and use its cycles for your activities. Hmmmm,
although I am nowhere near my schematic, you need to look at BE line, and
as I recall AEC.
I will go home and check my schematic, but you should be able to discern
it from the schem. The VIC-II can disable the 6502 when it needs to "steal"
cycles, so you need to behave as the 6502 does when reading/writing RAM.
However, your circuit must make sure the 6502 never executes another
instruction while your circuit is active, because the RAM in the 64 is never
idle. Someone is always got it.
Jim
--
Jim Brain, Embedded Systems Designer, Brain Innovations.
br...@msen.com
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain
bs...@freenet.edmonton.ab.ca
: If you REALLY want to read RAM from the internal C64 DRAM, you must disable
: the 6502 inside the 64 and use its cycles for your activities. Hmmmm,
: although I am nowhere near my schematic, you need to look at BE line, and
: as I recall AEC.
: I will go home and check my schematic, but you should be able to discern
: it from the schem. The VIC-II can disable the 6502 when it needs to
: "steal"
: cycles, so you need to behave as the 6502 does when reading/writing RAM.
: However, your circuit must make sure the 6502 never executes another
: instruction while your circuit is active, because the RAM in the 64 is
: never
: idle. Someone is always got it.
--
Pull the DMA line low (pin 13 on the expansion port), then the 6510
puts it's bus lines into a high impedance state, no need to worry about
the 6510 executing anything! The VIC II will still access memory when the
clock is low (the 6510 only accesses memory when the clock is high, as
should the DMAimg device). The AEC output from the VIC II is ANDed with
the DMA line from the expansion port and sent to the 6510, it is not
brought to an external connector. When the VIC II needs to access character
pointers from the video matrix, or MOB (sprite) data it brings BA (bus
available signal, pin 12 on the expansion port) low, this is done to
signal the 6510 (or an external device) that the VIC II needs more bus
time. What this amounts to is that your external processor must finish
useing the buses within 3-cycles of BA going low (the VIC II will start
using them during the high portion of the clock on the 4th cycle.).
Are you confused yet?
Refer to the Commodore 64 Programmers Reference Guide, appendix N
(pp448-451) for a more complete description of how the VIC II controls the
system.
later...
Bruce (bs...@freenet.edmonton.ab.ca)
Stefan Burstroem
For those who wonder, I wanted to access the c64 memory directly from
an amiga.
That problem is solved now. Thanks! (At least the c64 part)
The remaining problem is to control the Amiga bus. We have fried one
amiga so far, but we are close....
/Stefan Burstroem
Andreas Boose
> Pull the DMA line low (pin 13 on the expansion port), then the 6510
> puts it's bus lines into a high impedance state, no need to worry about
> the 6510 executing anything!
But think twice before pulling down DMA. The C64's memory management
system is well designed for non-external-DMA operation, but if using
external DMA it isn't 100% bug free!
The problem is the handling of the three phi2 cycles after the 6510's
READY input is pulled down. In read mode the NMOS6510/8500 will stop
immediately, in write mode it will stop after the last write cycle, but
not without setting its address lines to the next address!
No problem if the next address is a RAM/ROM location, but big problem if
this address refers to an IO chip, especially an interrupt flag register.
In worst case this register is read 3 times by the frozen 6510 and 1 time
after the DMA when the 6510 fetches the data.
To avoid any problems with this IO insecurity the C64 developers used a
brilliant but ugly hack: They advised the PLA to redirect any IO read
accesses to the internal RAM regardless of $01 in these 3 cycles!
But the PLA hasn't the ability to count 3 cycles (it's a dump logic
array), so they implemented this protection for the VIC's DMA only.
There's a simple way to detect these 3 cycles - just when R/-W is high, BA
is low and AEC is high. That's the only reason why BA is connected to the
PLA.
So external DMA hasn't such protection and if you pull down DMA just
before the 6510 wants to read something from an IFR the IFR is read before
and after DMA. For 'normal' applications this may never be a problem, but
if you want the C64 to do highly sophisticated interrupt stuff combined
with external DMA you will risk a systematic failure.
This is a brain dead design failure of the C64. Almost so brain dead like
the 6502/10's failure to forget the BRK opcode jump when IRQ/NMI goes down
executing the first few cycles of BRK.
MfG Andreas
Andreas Boose
>I started with building a Z80 card for use with CP/M.
>Besides the Z80 I needed:
>Four buffers for addresses, data and control lines,
>One 74LS74 FF for synchronizing Z80 with C64
>And two 74LS00 for several decoding tasks.
>That's all.
OK, that's the right way connecting a second CPU to the bus. Imagine doing
this without any CPU, generating the read/write cycles with TTL as an
interface to another computer's parallel interface...
>BTW: The Z80 runs therein asynchroneously to the 6510, i.e: with
>continuous clock (not like in other (commercial) Z80 cards for 500ns
>with 4 MHz and then 500ns silence), and I can use any clock for the
>Z80 that I want (and the Z80 can cope with..)
That's great! Not such a crap C128 design where the Z80 is clocked
synchronously as well.
>Then, some times later I stepped upon a game Cauldron II (btw: this is
>still the only game in French language that I have), where there is a
>large castle with many rooms. Each room fills a complete screen and I
>wanted to make a hardcopy of the whole castle.
Year, I love Cauldron II (Hexenküche II). Controlling the bounce of the
little pumpkin to move it around and collecting the 6 items in the huge
witch's castle makes fun.
>Each room fills a complete screen and I
>wanted to make a hardcopy of the whole castle.
>First I simply entered a room, did a reset and printed out the screen
>content that was still in the ram.
>Of course this was much too slow and boring with at least one hundred rooms.
Hehe, I had exactly the same problem. But luckily the 64'er magazine (or
was it Happy Computer?) published a complete map of this castle. Although
it wasn't that large in size all details were on it. The map was printed
in very high quality and even in color.
>Then I remembered this Z80 card: I removed the Z80 and hooked the card with
>some flat cables to a experimental 8085 system that I had floating around.
>I had just to add a 70LS74 because in a Z80 card the 6510 switches itself
>down and gives control to the Z80 but I wanted to get control over the
>C64 ram without getting permission from the 6510.
What have you done to wait the first 3 cycles after your cart pulled down
-DMA? Not waiting will corrupt some bytes in the C64's memory if you catch
the NMOS6510 on write access(es).
>Witch this hardware I was able to enter a desired room, stop the C64, transfer
>the screen memory from it to the 8085 system, and continue with the next room.
>After having filled up the 8085 ram with pictures I resetted the c64,
>loaded the hardcopy program and printed out all the pictures by resending
>them to c64 ram.
How long did it took?
>I must admit, that there was a tiny flaw in the interface: sometimes
>there were changed some bytes in the c64 memory randomly but only
>in the 8 KB frame that I selected. Most probably this resulted from the
>multiplexed 8085 bus that is a bit weird to handle.
>But this flaw isn't important for screen capturing purposes and so
>I didn't bother to fix it...
Designing a system: one day - debugging it: one month. :-)
>By printing out dozends and dozends of pictures and assembling this
>puzzle I became the the proud - and at this time probably the only :-)
>owner of a Cauldron II poster (about 1.5m x 1m) !
Are you the person that gave the map to the magazine?
MfG Andreas
Marko Mäkelä
Andreas> This is a brain dead design failure of the C64. Almost so
Andreas> brain dead like the 6502/10's failure to forget the BRK
Andreas> opcode jump when IRQ/NMI goes down executing the first few
Andreas> cycles of BRK.
Well, the IRQ/NMI thing is not so brain dead, since you can detect the
BRK also in the NMI routine by checking the pushed status register on
the stack. If the NMI has interrupted a BRK, the B flag is set, just
like with IRQ.
An NMI can also interrupt an IRQ sequence, but this is pretty
transparent to the application software, as long as the IRQ source
will not be cleared in the NMI routine. Right after returning from
the NMI (or after executing a CLI in the NMI routine), the processor
will see that the -IRQ line is low, and will execute another IRQ
sequence. The NMI interrupted IRQ sequence will also last seven clock
cycles, so it doesn't eat up any extra cycles.
Marko