Beiträge von thierer im Thema „MOS6526 CIA detailed test vectors and models“

    After that work I found I can now reproduce anything the CIA reports back on the Timer A output when in CNT count mode, using this input circuit: CNT is an input to a normal D-type Flip-Flop with an Asynchronous reset input. This feeds another flipflop that synchronizes the detected posedge to the PHi2 clock domain, and its output also resets the edge detector. So during the actual internal count pulse (when cnt_rr=1), you can do whatever you want on the CNT input - it is ignored.

    The Verilog you posted suggests that the second flip flop is clocked from the negative PHI2 edge, which matches exactly what I observed, doesn't it? The time between the positive CNT edge and the times that I marked "1" is the period between the two events. The difference between the Timer A logic you describe and the SR logic would be that the latter takes one PHI2 cycle longer.

    The funny thing is, the duty cycle issue you mention doesn't seem to come up in my tests for timer A. The rising edge is detected regardless if it is just a very short 1->0->1 pulse (like in your graph) or if it is a very short 0->1->0 pulse, or of it already goes 1->0 in the cycle before the posedge. Maybe it is a Serial Register exclusive issue, to do with that trasparent path I found. I will research that.

    I think that's a misunderstanding. You're probably referring to what I wrote in Bitte melde dich an, um diesen Link zu sehen.? Maybe "duty cycle" was bad wording. I was talking about the behaviour of the 6526 when sending. It sets CNT low at the beginning of a bit cycle and then does one low -> high transition at 50% of the bit cycle and keeps CNT high for the rest of the bit cycle. What I meant is that this transition has to be earlier than the 50% mark of the bit cycle because in the worst case it can take ~2,5 PHI2 cycles from the positive edge of CNT until SP is sampled (as outlined in Bitte melde dich an, um diesen Link zu sehen.) while 50% of the bit cycle is only 2,0x PHI2 at the highest data rate.

    That does *not* mean, that something like this, with only a short positive CNT pulse, would not work:

    Code
                    |<-  >2 phi2 cycles    ->|
    PHI2 |____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾
    CNT  ‾‾‾‾‾‾‾‾|__|‾‾|_____________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
    SP   ‾‾‾‾‾‾‾‾|___________________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
                             ^              ^ 
                             1              2

    Is that what you meant? I never checked anything like that, I only experimented with having the CNT low -> high transition at different points in the bit cycle.

    What I don't understand is the "... or of it already goes 1->0 in the cycle before the posedge" part. I guess "1->0" refers to CNT (?), but "posedge" of what? PHI2? Shouldn't this be "negedge" then? In that case I would agree (it's what my "diagram" above shows, right?).

    So, I conclude from your FPGA experiments, you've seen max transfer rates close to 2 phi2 clocks per bit using a 6526R4 in a C64 as input, when you first phase-align the external FPGA with the chip. You then also make CNT only high for half of a PHI2 cycle, followed by 1.5 cycles low. Is that correct?

    No, a short CNT low phase followed by a 1,5 PHI2 cycle high phase.

    This is what the "best case" would look like for a transmission of a "0" bit followed by a "1" bit:

    Code
                 |<- 2 phi2 cycles ->|
    
    PHI2 ‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾
    
    CNT  ‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|_
    SP   ‾‾‾‾‾‾‾‾|___________________|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|_
    
                     ^              ^ 
                     1              2

    From what I (think to...) understand, the 6526 would register the positive CNT edge at the negative PHI2 edge at "1" and sample SP 1,5 cycles later at the second positive PHI2 edge at "2". The whole CNT/SP transfer cycle is 2 PHI2 cycles. You could even go slightly faster for one bit by making the CNT "low" phase shorter, but that doesn't gain you anything, because if the time for 1 bit isn't a multiple of a PHI2 cycle, you lose the optimal phase offset for the next bit(s).

    And this is the "worst case":

    Code
                 |<-    ~3 phi2 cycles     ->|
    
    PHI2 |____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾
    
    CNT  ‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾
    SP   ‾‾‾‾‾‾‾‾|___________________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
    
                             ^              ^ 
                             1              2

    As the negative PHI2 edge just misses the positive CNT edge, SP is sampled ~1 PHI2 cycle later than in the "best case". So in order to work with all possible phase offsets, you have to make SP valid for one more PHI2 cycle.

    I actually don't know much about chip design, that's why I can't really follow all your explanations. I merely took a black box approach and checked what signals lead to which bits being sampled in the SR. I can't really comment on what the actual design would have to look like to lead to this behaviour.

    Regarding the IRQ issue: I only brought it up because I thought that you said you found that the SR IRQ has a similar issue as the "timer b bug". As that apparently was a misunderstanding, I wouldn't read too much into that. I didn't do enough research to be confident that the IRQ really wasn't set for the SR. In the end it could well be something as simple as a bad connection on the IRQ probe.

    I have'nt seen if you're looking at sending or receiving bits from the 1571, or both? Do the issues also occur at say lower speeds?

    I actually haven't experienced the problems myself, as I don't even own a 1571. So strik would need to comment if the errors also happen at slower speed (and maybe also when the 1571 is sending).

    I only did some low level tests to learn about the timing requirements of the CIA when receiving at maximum data rate (because that's what the xum1541 firmware is communicating at).

    I mean phi2 clocks (not CNT clocks).

    I understand that. The reason why I was asking was your statement "SP is really still sampled after 3 clocks", while my understanding is that it's sampled after 3 half-cycles of PHI2 (see my reasoning in Bitte melde dich an, um diesen Link zu sehen.).

    Leaving the 6526 at DC 0Hz for a very long time like a few seconds or more, I have seen some weird stuff happen though. Like it resetting itself. Not sure if that is an artifact.

    I think that's true for all the NMOS chips. (In contrast to the WDC versions, where I think you can halt and resume the clock at will).

    In the test above there is a sequence somewhere halfway showing what I mean: (I hope pasting this works): This is the same information as above, but just run through verilog to create a waveform. At the bottom are 2 registers from my own verilog model, where you can observe the shifter shifting and that the IC sends out CF as value of SDR, which is one cycle too late. The proper value SDR should have been was 67.

    If I understand that correctly, the Verilog isn't supposed to model the workings of a real CIA but the equivalent of what you're doing with your Arduino code, right? Otherwise I don't understand it because the original chip takes 4 PHI2 cycles per bit when sending, while the waveform you posted seems to have only two cycles per bit.

    Yes, there may be a bug like the Timer B bug - I would then also only expect those bugs in the so-called "old" 6526R4. But who knows. So far I have not seen this bug in my tests - but if it exists I will be able to find it. But if it is a bug similar to the timer B bug, it would present itself at any speed of operation of the serial port.

    FWIW, my C64 has a 6526R4, so that's what I used. It then probably wouldn't apply to the CIAs in a 1571, though.

    At phi2/2 speeds, SP is really still sampled after 3 clocks, so in the same cycle the next CNT edge is created you can set the SP value for the *previous* bit.

    So here with "clocks" you mean clock changes (not clock cycles), right?

    I'm fairly sure the IC was not intended to go this fast - the datasheet mentions SP is captured on posedge. That is true only if CNT is lower than PHI2/4. And that aligns with the max speed another 6526 on the same clock frequency is able to produce.

    I'm not sure that's what you mean, but in my experience it is *not* possible for the CIA (at least the 6526R4 that I used) to reliably receive from a CIA running at the same clock speed at the highest data rate (ie timer a == 1) . In the worst case it takes 2,5 clock cycles (of the 4 clock cycles for one bit at maximum speed) from the rising edge of CNT until SP is sampled (I just realised in Bitte melde dich an, um diesen Link zu sehen. I wrote that the worst case is 3,5 clock cycles, that is not correct).

    As when sending from the SR the CIA uses a CNT duty cycle of 50% (2 clock cycles), the remaining 2 clock cycles are not enough for the receiving CIA to correctly sample the bit for all possible phase offsets between CNT and PHI2. (To correctly receive a bit, the CIA is happy with a much shorter low CNT phase than 2 clock cycles. The xum1541 firmware for interfacing with the 1571 uses a ~75% duty cycle for CNT, that's why the transfer generally works, even at the highest speed).

    I have to admit that I don't fully understand the implications of the debug output you provided.

    As I understand it, you are suggesting that a similar behaviour to the "timer b bug" might exist for the SR IRQ? How I understand the "timer b bug" (I had to look it up, please pardon my ignorance...) it means that the IRQ flag is not set if the ICR is read right before the flag would be set?

    That would make a lot of sense: What I did in my tests is that I had some code running on the C64 which checked the ICR in a loop and then put the content of the SR in PB, so the FPGA could read it check if this matched the value it sent.

    And checking the ICR in a tight loop is exactly what the Bitte melde dich an, um diesen Link zu sehen. (that exhibits the bug, that strik is currently investigating) is doing.

    WHen I clock SDR in any faster than CNT three cycles low, three cycles high, then I get unreliable state. Something is still working but not reliably. This must mean the exact internal state is meant to go no faster than 3 cycles (which is 4 cycles of an external part which then could be 3 cycles occasionaly due to clock drift between systems)

    Motivated by @strik's recent work on the SRQ-transfer for opencbm that he mentions, I recently did some tests by hooking up a FPGA board to my C64's CIA and using different timings to check which of them are relevant when receiving into the shift register.

    My impression was that after the positive edge of CNT the CIA samples SP on the second rising edge of PHI2 following the next falling edge of PHI2. That's true even if CNT goes low again before this time (but a second rising edge of CNT before the data is sampled seems to kill the cycle). This would suggest that it takes 1,5 (best case) to 3,5 (worst case) PHI2 cycles to sample the data, depending on the phase difference between PHI2 and CNT. And I could in fact "reliably" transfer data into the SR with about double the nominal rate (that it, 2 x PHI2 instead of 4 x) when I aligned CNT to just before the negative PHI2 edges. (I didn't transfer MBs but only KBs, but I found the results to be pretty reproducible in either way).

    I also had cases where the SR would receive the correct value, but the IRQ bit wouldn't be set. I haven't found what could cause that, though, and I suspect it might well be a bug in my test setup.