29 Feb
2020
29 Feb
'20
3:42 p.m.
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
--
Jim Brain
brain at jbrain.com
www.jbrain.com
3 Mar
3 Mar
12:26 a.m.
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.
Jim
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.
--
Holger
7:30 a.m.
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
brain at jbrain.com
www.jbrain.com
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
5 Mar
5 Mar
6:11 p.m.
On 3/3/2020 8:39 AM, osi.superboard via cctalk wrote:
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.
Which is exactly what I ended up doing:
http://www.go4retro.com/2020/03/05/coco-dma-fighting-on-the-bus/
Jim
1752
days inactive
1758
days old
4 comments
3 participants
participants (3)
-
brain＠jbrain.com -
holger.veit＠iais.fraunhofer.de -
osi.superboard＠gmail.com