For those with 6809 experience
holger.veit at iais.fraunhofer.de
Tue Mar 3 02:26:50 CST 2020
Am 01.03.2020 um 00:42 schrieb Jim Brain via cctalk:
> Looking at the datasheet for the 6809 (specifically, the 6809E that
> needs incoming quadrature clock), I read that !HALT can be asserted
> 200nS (for 1MHz part) before falling Q and the CPU will finish the
> existing instruction and then go into a HALT state as long as the HALT
> line is low during the falling edge of Q.
> That's the store from the datasheet, but when I am testing it, I see
> that, even if I pull HALT low at the very beginning of the last cycle
> of an instruction, the 6809 will not acknowledge the HALT until
> executing the next instruction.
> My logic is watching for IO address $ff61. When found, it drops Q
> so, to start the HALT condition, I need only:
> lda $ff61
> Not that the trigger is being performed by the code, so the current
> instruction (the lda) should complete and then the CPU should go into
> HiZ. What I see is:
> lda $ff61
> lda $ff60 <- the next instruction
> executed, and THEN the CPU goes into HiZ.
> I can deal with this (Yes, I should just look at BS=BA=1, which tell
> when to safely use the bus, but I don't have access to those signals
> for this project), but I thought I'd see if this was known by all, or
> if there is something I am missing.
What are you trying to accomplish? 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.
More information about the cctalk