For those with 6809 experience

Jim Brain brain at
Tue Mar 3 09:30:31 CST 2020

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 Brain
brain at

More information about the cctalk mailing list