RE: C64 buses when RESET is asserted

From: Bil Herd <>
Date: Thu, 11 Apr 2013 12:22:43 -0400
Message-ID: <>
I missed the big picture of what the goal is, but a couple of

The pausing and  tristate of the processor won't work the first couple of
cycles after a /reset goes high when it does the reset vector fetches.
After that it will tristate but may have fetched bad data if something
else was on the bus.  This is why a reset circuit should look at BA so it
doesn’t let the processor start in the middle of a VIC DMA pointer fetch.

After that an external device can have the bus  by asserting /DMA on the
expansion connector  as long as it listens to BA.  If the VIC chip is
active the external device has to get off the bus every PHI Low and when
the VIC does DMA's, the BA hence the tristating is much quieter without
VIC being active.

CPM cartridges failed for a couple  of reasons mostly due to how they
interfaced to the DRAM.  The critical path for  external devices that
write to DRAM need to make sure that have good stable data propagated to
the DRAM before the falling edge of /RAS


-----Original Message-----
[] On Behalf Of Gábor Lénárt
Sent: Thursday, April 11, 2013 2:53 AM
Subject: Re: C64 buses when RESET is asserted

On Mon, Apr 08, 2013 at 04:31:02PM +0200, Gerrit Heitsch wrote:
> Even with RESET asserted, the VIC still displays a picture on the
> screen. It can only do that if it is activly reading from RAM (and
> ROM) to fetch the data to be displayed.
> If you want to be sure, you can tristate the CPU from the expansion
> port using the _DMA signal.

Isn't that similar to the scheme how CP/M cartridge works? The situation
is somewhat familiar: an external device (a Z80 CPU in our case) wants to
control the C64 bus, so it needs to disable the 6510. However it's
interesting to note that CP/M cartridges have problem (?) with certain C64
models, otherwise maybe it's worth to learn from the schematics of the
CP/M cartridge to control the bus externally maybe?

       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list
Received on 2013-04-11 17:00:04

Archive generated by hypermail 2.2.0.