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. > > > Gerrit > > > -- Jim Brain brain@jbrain.com www.jbrain.comReceived on 2018-06-20 19:00:03
Archive generated by hypermail 2.2.0.