Re: How to resume the 6510 after being stopped the hardware way.

From: tokafondo_at_tokafondo.name
Date: Sun, 10 Jul 2022 09:27:48 +0000
Message-ID: <176eb5df1b686901ada5b07920757a9c_at_tokafondo.name>
>> On 2022-07-09, at 19:51, ruud_at_baltissen.org wrote:
>> 
>> Normally you don't stop the 6510 "just like that". When giving control to the Z80 in the CP/M
>> module it is the 6510 that initiates the whole proces. It (re)sets a flipflop with a specific bit
>> which on its turn negates the DMA line and then executes some NOPs. When the Z80 returns the
>> control, the 6510 resumes with executing those NOPs and then resumes with the rest of the program.
>> 
>> If you negate the DMA line just out of the blue, there is a chance that you disable it in the
>> middle of reading an instruction. If you "stop" the 6510 in the beginning of PHI2, you will disable
>> the buses of the 6510. The 6510 will read $FF as the next instruction and that is a KILL
>> instruction: stop and do nothing at all anymore. Looks familiar?
>> 
>> I can give several other reasons why things can go wrong. But my main message is: negate the DMA
>> line only under controlled circumstances.
> 
> There's a well-known document by Gideon
> 
> https://codebase64.org/lib/exe/fetch.php?media=base:safely_freezing_the_c64.pdf
> 
> which explains a lot of this stuff in detail. There's one error in this doc, which was confirmed
> with Gideon. Namely the part about 850x CPU. BR does exactly the stuff Gideon describes there, and
> it works 100% on HMOS-II CPUs too. The rest is spot-on and an invaluable resource.



Thanks both for your useful and detailed answers.

It seems to me that a sort of combination between NAND'ing the different lines that qualify the DMA could do the trick, with some mechanism that would make the external CPU wait that for it to happen.

Something like

- The external CPU (eCPU) asks for DMA.
- An external circuit acknowledges that petition and pulls eCPU's RDY line low in its own terms to make it wait for the DMA authorization.
- PHI2 goes high: that should mean the internal CPU (iCPU) in in charge.
- BA line goes high: that should mean the VIC-II has released the bus.
- R-/W goes high: that would mean iCPU (when appropiate) finished writing.

When those last three conditions met, I think it can be concluded that it's safe to assume that iCPU is ready to be stopped, isn't it?

- So those three 'highs' could be NAND'ed and they could pull /DMA low with a latch so iCPU is stopped, and that would pull eCPU RDY high as a signal of 'go ahead but in sync with VIC-II', because the BA line and DOT/PHI2 lines would be also linked to eCPU RDY input.

Timing is also crucial, of course...

What do you think?
Received on 2022-07-10 12:00:02

Archive generated by hypermail 2.3.0.