| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Facts about CIA and... question.
Obviously, correct me if i'm wrong.
- I know that CIA's counters $DC04..07, $DD04..07 never reach the value $00 during countdown, but $01 is repeated twice (EDIT: not $01, but the reset value is repeated twice).
- After that, i know that CIA's TOD alarm 1/10 seconds register, can't be set at value $00 otherwise the alarm does not work.
- Then i know that, if ICR is readed 1 or 2 cycles just before an IRQ generated by Timer B occur, then IRQ don't occur at all..
But... what are "the differences" between CIA revisions?
Not all of these bugs occur on all revisions or there are other differences? |
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
See http://codebase64.org/doku.php?id=base:detecting_6526_vs_6526a_.. for a bit more info. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote:...sets off a single-shot NMI ... The older 6526 triggers one cycle later
This mean that the IRQ is triggered 1 cycle later, or the timer start to count one cycle later? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Quote:...sets off a single-shot NMI ... The older 6526 triggers one cycle later
This mean that the IRQ is triggered 1 cycle later, or the timer start to count one cycle later?
Trigger only.
IIRC timer B doesn't double count either, only timer A. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote:IIRC timer B doesn't double count either, only timer A.
Strange...
If this is correct, and no value is "doubled", means that a cycle is lost every countdown.
If i understand your sentence ... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Quote:IIRC timer B doesn't double count either, only timer A.
Strange...
If this is correct, and no value is "doubled", means that a cycle is lost every countdown.
If i understand your sentence ...
to be clear: this is for all revisions of the chip. Timer B doesn't feature the counting anomaly of timer A. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Sorry, you will definitely clear for who knows more than me.
But i can't understand what you mean with "counting anomaly".
Are you talking about the fact that is impossible to read value zero from timers (A in this case) but, instead, reset value is used twice?
Or the meaning is different? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Sorry, you will definitely clear for who knows more than me.
But i can't understand what you mean with "counting anomaly".
Are you talking about the fact that is impossible to read value zero from timers (A in this case) but, instead, reset value is used twice?
Or the meaning is different?
That's what I ment, but thinking about it, it may only apply in chained (Timer B counts Timer A) situations.
I fiddled around with it a lot to get make r-load 0.3 working but can't remember the details at the moment.
Anyone has this fresh in memory? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote:it may only apply in chained (Timer B counts Timer A) situations
This make sense now.
I'm pretty sure that both Timer A/B suffer from the "counting anomaly", but making Timer B counts Timer A, CIA could handle "zero" properly... |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
There is a strange thing i noticed.
I tested this only in Vice, not on RH, but seems if CIA has some problems handling "1 cycle" events.
Now i try to explain.
If we set Timer B to count Timer A with this:
LDA #%00010000
STA $DD0E
STA $DD0F
LDA #$01
STA $DD04
LDA #$00
STA $DD05
LDA #$04
STA $DD06
LDA #$00
STA $DD07
LDA #%01100001
STA $DD0F
LDA #%00000001
STA $DD0E
then $DD06 reaches zero.
But if we set
LDA #$00
STA $DD04
LDA #$00
STA $DD05
$DD06 never reaches zero, but the "counting anomaly" appears.
This should be in relation with the time taken by CIA to clear and reset the counter: 1 cycle is probably not enough... |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
It's been a long time since I wrote that detection code, but this is what I remember:
Between the two CIA versions, if you set a timer for N cycles in continuous mode, both revisions will have that same exact number of cycles between IRQs, but at a 1-cycle "phase offset" compared to the other revision. IIRC, one will trigger the interrupt while transitioning to zero, the other will trigger after it has transitioned to zero. Both count through the same sequence of numeric states internally.
I use this for syncing the NMI to the screen for raster splits and DMA delay, while the IRQ is used from the VIC-II for sprite multiplexing. The same timer values are used regardless of the CIA revision, but which cycle the NMI timer is started depends on the revision. |
| |
enthusi
Registered: May 2004
Posts: 677 |
I remember this being a pain for Hawkeye2 at X-Party ;-)
(there still is some bug-fixed-smile pic of yours somewhere) |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
That pain was that the demo machine ended up having 1 cycle of jitter more in its initial interrupt than I supported, or had seen before in VICE. It was a pain to figure out what was going on, but fortunately relatively easy to fix.
Inside my interrupt handler, I used the jitter value as an offset to INC some unused area and was able to build up a histogram of actual jitter observed. Using timer interrupts for cycle-accurate effects is nice because you can directly read the jitter amount from the CIA timer registers.
If I remember correctly, it's not that it had a 1-cycle phase offset to what I was expecting, but had a legitimately larger range of jitter possibilities for whatever reason. |
| |
enthusi
Registered: May 2004
Posts: 677 |
That very moment:
 |
