Pokey Timer calculation using 1.79mhz clock

[AtariGeezer]

I am making an app that uses the Pokey Countdown Timers at 1.79mhz and linking channel 1 & 2 together for a finer resolution.

What is the formula to determine AUDF Delay values for 1ms, 22ms and 33ms?

 

In Steve Stuntz's Packet Terminal, he's using $07C0 (1984) for 300 BAUD (3.33 ms), but I'm stumped on that...

 

Thanks,

Jay

 

Edited August 24, 2021 by AtariGeezer

[VinsCool]

Is this in direct relation for frequencies used for audio output?

 

Because I do have a bunch of formulae but I have no idea how these coul apply to timers

[AtariGeezer]

2 minutes ago, VinsCool said:

Is this in direct relation for frequencies used for audio output?

 

Because I do have a bunch of formulae but I have no idea how these coul apply to timers

Nope, already know about tone generation.  I'm looking for the duration in ms for the countdown timers...

[VinsCool]

1 minute ago, AtariGeezer said:

Nope, already know about tone generation.  I'm looking for the duration in ms for the countdown timers...

Sorry, I have no idea unfortunately.

I can precisely calculate what 16-bit values do in hertz but that's definitely not useful there.

 

I was hoping to find some sort of conversion that could be done but a bit of search around the forum didn't really give me any useful information.

 

I will leave the experts handle this, there are so many helpful people around here

[Rybags]

The formula should be much the same - for timers you omit the /2 part since with audio frequency you're counting both the up and down part of the waveform.

 

Refer the hardware manual re calculating audio frequencies - the notable thing is counting the extra cycle overhead depending if you're in 8 or 16 bit mode.

Generally you'll be in 16 bit mode when doing serial IO.

Note that once you're into the 10,000+ KHz range the steps between each higher frequency get bigger each time.

Also probably not relevant to you but you can use the 16 KHz audio mode to give scanline exact resolution to timers.

[phaeron]

A 16-bit timer fires every N+7 cycles, where N is the 16-bit value of the two AUDFx registers. For instance, AUDF3=$C0 and AUDF4=$07 on an NTSC system gives a period of $07C0+7 = 1991 cycles. Dividing this by the system clock of 1.77/1.79MHz gives the time in seconds. For instance, for an NTSC computer, 1991 / 1789772.5 = 0.001112 seconds, or 1.112 ms.

 

For tone generation and for POKEY's serial port, the effective rate is halved because the audio output or serial clock toggles polarity on each tick and two such transitions are needed for a full cycle. Thus, $07C0 on NTSC would give a 1789772.5 / 1991 / 2 = 449.5Hz, or a serial bit rate of 449.5 baud. Thus, this looks more like a setting for 450 baud rather than 300 baud.

 

For one-shot delays, the effective delay will be slightly longer than this due to delays in starting the timer and responding to the IRQ, but that's on the order of dozens of cycles.

[Rybags]

And note the default system IRQ handler has a fairly large overhead for timers, for anything under an interval of a few hundred cycles it's probably better to resort to alternatives:

- steal the VIMIRQ vector and handle IRQs yourself, preferably disabling everything else and  testing for the timer IRQ earlier.

- have a RAM based OS and handle via the hardware IRQ vector.

- just use polling mode, SEI to disable IRQs then loop checking IRQST on Pokey.  For very short periods it's about the only reliable way.

 

In any case, we can't usually do cycle exact delays due to jitter from screen DMA and memory refresh losses.

Edited August 25, 2021 by Rybags