I missed the big picture of what the goal is, but a couple of observations: 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 Bil -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Gábor Lénárt Sent: Thursday, April 11, 2013 2:53 AM To: email@example.com 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 listReceived on 2013-04-11 17:00:04
Archive generated by hypermail 2.2.0.