Hi all,

Does anyone know whether T1 reloads from the latches when it times out in one shot mode, or whether it continues to count FFFF, FFFE, FFFD, etc?

There are two conflicting opinions in the 6522 data sheets:





I think it ought to be the latter (which is more or less corroborated by the text of the datasheet), but a picture speaks a thousand words, so...

If anyone knows the behaviour for sure, it'd be most appreciated. I don't have any real hardware to test this myself, unfortunately.

I tried it on a Rockwell 65c22 and it reloaded the counter with what I put in the latch, rather than rolling over to FFFF and continuing with FFFE, FFFD, FFFC, etc..

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Rich, please could you add links to those two datasheets?
Thanks
Ed

Rich gave me some short test code to run on a Beeb, which I believe uses Rockwell 6522s, and it seems to run according to the first diagram - it visits ffff and then reloads, even in single-shot mode. TBC by Rich.

Thanks very much for taking the time to test it!

For reference, the first image was from a Rockwell R6522 datasheet (here), and the second was from the MOS MCS6522 datasheet from archive.6502.org (here). I don't know if the behaviour changed between these two revisions, or whether it was a documentation error which was corrected.

Either way, it seems the Rockwell behaviour (the version I'm interested in) is to reload from the latch, as confirmed by Ed and Garth.

Many thanks again

I am interested in determining the exact behavior of the one shot mode for timer 1. It seems that from the datasheet (first one, which is correct from a functionality standpoint) that the latch value is loaded into the counter. Does the timer actually count to 0x0000, then to 0xFFFF, and then load the latch value as datasheet seems to show? This would delay the counter by 2 cycles. I walked through VICE's 1541 emulator (which uses a two 6522s) and it counts down to 0x0000, goes back up to 0x0001, and then inserts the latch value and counts down normally. It's like the counter goes up for 2 cycles and then back down, simulating what the datasheet is showing - but in an odd way since a 2nd interrupt is not generated when it goes up and then back past zero again. The VICE 1541 emulation is sub-cycle accurate, and it passes every known test possible for the 6522's (about 15 different specific tests). My 1541 emulation fails the one-shot test, being off by a few cycles in a couple of tests and I think it has something to do with the how one-shot is handled. Is there any definitive info out there on this?

In the test program I sent to BigEd, which he ran on real hardware, the results were that the timer behaved identically in both one-shot and free-run mode (i.e. passing through 0001, 0000, FFFF and then reloading from the latch). The only difference was that the IRQ is only generated once in one-shot mode, but every time in free-run mode.

What we didn't check was whether the behaviour was the same in one-shot mode the second (and subsequent) times it crosses zero. I guess there's a possibility that, if IRQ generation were somehow intrinsically linked to crossing from 0000 to FFFF, one-shot mode might have it go from 0000 to 0001 subsequent times, to avoid that. No idea - we'd have to check - but T2 doesn't seem to require any similar trick. Having looked at viacore.c in VICE, I can't see anywhere that seems to be explicitly emulating this behaviour (though I don't really understand much what it's doing - a comment would be lonely in this code...). My tentative opinion would be that VICE's behaviour is buggy.

I wrote some test code for real hardware and I can confirm your findings, and I can confirm that in one-shot mode the counter has the same results on the 1st and subsequent passes through after the initial interrupt is generated.

So, for those that stumble across this thread, the behavior for Timer 1's one-shot and free running mode are the same for the counter, which decrements as follows:

0x0001, 0x0000, 0xFFFF, LATCH VALUE, LATCH VALUE-1, etc.

There is an extra cycle (0xFFFF) inserted after 0x0000 and *before* the latch value is reloaded into the counter.

Here is an example. Let's say that the latch value is $3A00. The sequence through the wrap would be:

0x0001, 0x0000, 0xFFFF, 0x3A00, 0x39FF, 0x39FE, etc. repeating over and over.

Looking back, now it makes sense why you need to subtract 1 from the initial latch value if you expect to be generating an interrupt precisely.


Timer 2

Timer 2 is a one-shot only timer (only), and it behaves differently. There is a latch, but it is internal and only for the low byte of the counter. When you write the low byte of the counter it stores the value into an internal latch and does not affect the counter until the high byte of the counter is written, at which point that low byte is fetched from the internal latch along with the high byte just written, and both are loaded into the counter. The counter decrements to 0x0000 and then wraps. The counter is never reloaded with a value until you re-write the high byte of the counter again. So, Timer 2's decrement sequence is:

0x0001, 0x0000, 0xFFFF, 0xFFFE, 0xFFFD, etc.

By the way, VICE's timers are correct. I was setting the latch to be $0001 and I was seeing sub-cycle accuracy when using different LDA's that have different cycle times. So, I was catching 0x0001 sometimes after the 0xFFFF depending on the length of the instruction.