Re: For those with 6809 experience
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
Re: For those with 6809 experience
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
Re: For those with 6809 experience
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 $, 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
Re: For those with 6809 experience
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
For those with 6809 experience
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 br...@jbrain.com www.jbrain.com
