Does the 6532 (RIOT) timer run stable?

[gdement]

It's generally understood that the RIOT timer is difficult to use because the clock speed is constantly changing between 1.2MHz and 1.79MHz. This is presumed to be the reason why Atari advised that the timer couldn't be used. Thus it's tempting to try to compensate for the effect and use it anyway.

 

However, I'm wondering if there's a bigger problem. I noticed that the 6532 in my console is only a 1MHz part, so at 1.79MHz it's being drastically overclocked. The clock speed automatically slows to 1.2MHz when the RIOT chip is accessed, but that only helps with reading the joysticks. The rest of the time, while the system is doing other things, the RIOT is receiving the clock at 1.79MHz. Rather than just running fast, I wonder if the timer will get drunk at that speed and become functionally unstable. If so, then it wouldn't matter how carefully the programmer tries to use it, it just wouldn't work reliably on every console.

 

Has anyone determined whether the RIOT timers will operate consistently on every console? It could be a nice resource to have for some purposes, but only if it can be trusted from one console to the next.

[supercat]

However, I'm wondering if there's a bigger problem. I noticed that the 6532 in my console is only a 1MHz part, so at 1.79MHz it's being drastically overclocked.

 

I think the RIOT would get even worse overclocked during DMA fetches. DMA data fetches occur at 2.39MHz, and display-list and display-list-list fetches take place at 3.58Mhz.

[Bruce Tomlin]

The timing is for the entire chain of logic gates, taking propagation delays into account. That means the address decoder AND the timer AND the output drivers, etc.

 

The timer by itself has a lot less logic delays to deal with and probably would have no problem running at any of those speeds.

[EricBall]

I think the RIOT would get even worse overclocked during DMA fetches. DMA data fetches occur at 2.39MHz, and display-list and display-list-list fetches take place at 3.58Mhz.

The RIOT/TIA/CPU clock is generated by MARIA and is decoupled from the 7.16MHz clock. RAM/ROM don't have clock lines, MARIA just waits a fixed number of 7.16MHz (140ns) clock cycles after putting the address on the bus before latching the data.

[supercat]

RAM/ROM don't have clock lines, MARIA just waits a fixed number of 7.16MHz (140ns) clock cycles after putting the address on the bus before latching the data.

 

So is phi2 idle during DMA? On most 6502 systems, I thought phi2 was filtered into RAM chip-select operation, though the 7800 seems to use phi1 to gate R/W instead. Seems a little dangerous to me, since the RAM chips would get a negative setup time. So what does phi2 do during DMA?

Edited May 8, 2007 by supercat

[EricBall]

So is phi2 idle during DMA? On most 6502 systems, I thought phi2 was filtered into RAM chip-select operation, though the 7800 seems to use phi1 to gate R/W instead. Seems a little dangerous to me, since the RAM chips would get a negative setup time. So what does phi2 do during DMA?

Hmm.. tough questions, especially since I don't have any way to scope an actual system.

 

As per the 7800 Schematics it looks like the RAM CS is directly connected to MARIA. OE is tied low, while WE is the R/W and CLK1 outputs from the 6502 OR'd together. Since during DMA, MARIA asserts the 6502's RDY line, then I don't see any reason that CLK2 couldn't be free running during DMA.

 

Of course, it should be possible to determine it from a software perspective. Simply set up a test wrapper around my ball demo which sets the timer for a value which will expire during a normal frame. Then see if the timer doesn't expire when DMA gets heavy.