Re: DMA successes with Verilog

From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>
Date: Wed, 20 Jun 2018 20:51:17 +0200
Message-ID: <97eee5bf-4aa9-c6d4-48b2-e49ee9d02e4b@laosinh.s.bawue.de>
On 06/20/2018 06:53 PM, Jim Brain wrote:
> On 6/20/2018 10:03 AM, Gerrit Heitsch wrote:
>> On 06/20/2018 02:16 AM, Jim Brain wrote:
>>> On 6/19/2018 6:56 PM, Mia Magnusson wrote:
>>>> Den Tue, 19 Jun 2018 09:35:02 +0100 skrev smf<smf@null.net>:
>>>>> On 16/06/2018 20:34, Spiro Trikaliotis wrote:
>>>>>
>>>>>> What about JSR (two consecutive pushes), or an IRQ, NMI or BRK
>>>>>> (three consecutive pushes)?
>>>>> Isn't that safe because the first write to the stack is followed by a
>>>>> further write to the stack?
>>> I read Spiro's point as if you halt immediately after the first 
>>> write, the CPU doesn't ack your !RDY request for a few more cycles 
>>> but will happy try to store the data in the stack and such, which 
>>> won't go anywhere, because you pulled AEC low and thus the address 
>>> and data lines went HiZ.
>>
>> The 65xx will not ACK the !RDY in any way
> My comment was not intended to convey that there is an ACK line that 
> will be asserted, but I disagree that the CPU does not provide any 
> indication.  I believe the address lines will remain constant (assuming 
> AEC is not asserted) when the CPU has acknowledged the RDY line.
>> so you have to do what VIC is doing, deassert RDY 3 cycles before you 
>> need the bus. Only then can you be sure that you can take over.
> While this is correct info, I'm not sure how it helps in this context. 
> The thread is discussing the idea of initiating a DMA activity from the 
> cart port without the CPU specifically requesting it.  One cannot 
> perform the same actions as the VIC-II, as we don't have access to the 
> raw RDY and AEC lines.  Just BA and DMA.  So, we have to be in a 
> position to know we can disable the bus at the same time we are 
> requesting the CPU to cede control.  One of the ideas is to wait for a 
> write and then init the DMA, but Spiro is noting that some writes are 
> followed by more writes that will get lost if we try to start the DMA 
> after the first write.

After looking at the schematics, I think the only surefire way would be 
to wait for the end of a badline or sprite access and then take over the 
bus. That way VIC has done the heavy lifting for you, the CPU has been 
halted properly.

You can detect that state with the BA line.

  Gerrit
Received on 2018-06-20 21:00:05

Archive generated by hypermail 2.2.0.