3 Mar
2020
3 Mar
'20
6:39 a.m.
My assumption is, that the LDA address access is too late at the end of
the instruction cycle, and the CPU already started the next instruction
cycle internally. HALT will be acknowledged only during the instruction
cycle following the LDA.
It would be interesting to measure, when the LDA pulls down the HALT
compared to the last instruction cycle signal (LIC). Maybe using LDD
will work better, because the HALT signal will be asserted one clock
before the instruction cycle ends.
Thomas
Am 29.02.2020 um 23: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.
Jim