On 3/3/2020 2:26 AM, Veit, Holger via cctalk wrote:
Am 01.03.2020 um 00:42 schrieb Jim Brain via cctalk:
What are you trying to accomplish?
Right now, I am just trying to understand how one pulls the 6809 off the
system bus and get some more experience in performing DMA activities. I
have no specific end goal in mind.
I guess you are using $FF61 as a trigger to start a DMA transfer, or
alike. I've seen something like this in code already, so it might have
been be known in developer circles for long. The plain simple fix
apparently was to add one or two NOPs after the initiating address
reference. The hardware price could be an additional flipflop and
another comparator. Detecting $FF61 wil arm the FF and a following NOP
on databus will initiate the operation. If no NOP follows, the FF is
reset.However, the latter situation should not occur when all
instances of LDA $FF61 are properly followed by NOP.
My first attempt was to simply hold off the DMA activity for a few
cycles, which indeed worked. When I hooked up the logic analyzer, I
determined that no matter how early in the last cycle I pulled !HALT
low, the CPU would execute one more instruction before acting on the
HALT condition.
I then put, as you note, a NOP in my code and could see that it was
being executed after the access to $ff61, following which the BA/BS
lines would go high and the Address bus went to $ffff, as expected.
At that point, someone pointed me to a small notation on the 6809E
datasheet on the timing diagram showing the HALT usage. It creates more
questions, but it did answer this one.
Thus, in case it is of any help to others (unlikely, given the age of
the CPU), even though the text in the datasheet does not mention this
constraint (I know, completely unexpected :-), the timing diagram points
out that the HALT condition (and interrupt conditions as well) must
occur tPCS ns before the falling edge of Q in the *second* to last cycle
of the current instruction in order to be acknowledged. I noticed the
text on the datasheet when looking at the timing, but assumed they
presented the HALT condition on the second to last cycle as a way to
illustrating to the designers that the system would not immediately go
into a HALT state, but would indeed (and the text confirms this)
complete the current instruction.
I have no idea why the extra cycle is needed (I assume internal
pipelining), but I can confirm the IC does indeed behave in the above
manner. The person who pointed me to the datasheet also (out of
curiosity) ran a test to see if interrupts or the HALT condition take
precedence if both arrive at the same time, and it appears HALT takes
precedence (more testing is needed there, though)
I appreciate your note. It's been an interesting exploration of the CPU.
Jim
--
Jim Brain
br...@jbrain.com
www.jbrain.com
