How do I use the pokey timers?

[bugbiter]

Hi Guys,

 

this might be the last mystery the Atari has been holding for me.

 

I've seen you mention them several times and I've decided to have a go on it..

 

the magical pokey timers!

 

Neither De Re Atari nor my trusted 'Atari Profibuch' explain the topic in a way that I could understand it easily.

 

OK. I have to set the vector of the timer, VTIMR1 ($210) to my interrupt routine.

 

I write the timing value into AUDF1 ($D200), say #100

 

I set off the timer by writing nonzero into STIMER ($D209)

 

Base frequency of pokey is something about 64kHz, so the interrupt should fire after 100/64000 = 1.5625 milliseconds, right?

 

I did this short test code, but it doesn't do anything. What am I not getting?

 

 

 

; my first trial for pokey timer interrupt usage
;
.include AT_SYSEQ.ASM
;
*=$A000
;
; blank screen
lda #0
sta SDMCTL

; set vector for pokey timer 1
lda #<routine
sta vtimr1
lda #>routine
sta Vtimr1+1

lda ch ; put keyboard code as timer value
sta audf1

lda #1
sta stimer ; activate timer
;
loop jmp loop ; idle loop
;--------------------------------------------------------------
;
; pokey timer interrupt routine
routine
pha

lda #15 ; show that timer has fired
sta colbak
lda #0
sta colbak

lda ch ; put keyboard code as timer value
sta audf1

lda #1
sta stimer ; activate timer again

pla
rti

[flashjazzcat]

Did you set bit 0 of POKMSK and IRQEN to enable the IRQ?

Edited September 28, 2016 by flashjazzcat

[bugbiter]

thanks Flashjazzcat for the hint.

 

I now have set bits 0 of both enable registers.

 

Now right after setting Stimer the code jumps to $c02c.. but it doesn't crash and the screen actually shows white spots depending of what key I press like I intended,

but the jmp loop idle segment is never reached. Did I put some wrong vector?

 

Did I understand the timing logic right at all anyway?

[Rybags]

You don't need to store to STIMER continuously, just the initial one is all and even then it's just to align the interval.

 

They operate in continuous mode, the only requirement is to disable the IRQ then enable it again.

Generally you'd do that by masking bits in POKMSK ($10) in the IRQ routine itself and store back to IRQEN.

 

Using the Timer vectors as provided by the OS involves a lot of overhead. Generally it's better to use the Immediate IRQ vector and process all IRQs yourself - in doing so it's just easiest to disable all IRQs except the Timer that you want to use.

Edited September 28, 2016 by Rybags

[phaeron]

Your IRQ routine isn't matching the calling convention used by the OS for timer IRQ routines. Unlike a raw interrupt vector, the OS IRQ dispatcher calls your routine with the A register already saved and you should exit with PLA+RTI without the PHA at the beginning. The immediate IRQ vector is called with no registers saved, most broken out vectors like VKEYBD and VTIMR1 are called with A saved, and Parallel Bus Interface IRQ handlers are called with A+X saved.

 

Make sure you wrap accesses to both IRQEN and POKMSK with SEI+CLI, i.e.:

sei
lda pokmsk
ora #$01
sta pokmsk
sta irqen
cli

This avoids race conditions with any IRQs that may fire around that time, as well as a nasty rare race condition in the hardware when trying to disable IRQs (essentially, you can still get an IRQ right after turning it off in IRQEN). You'll also want to write to AUDCTL to make sure you don't have some unwanted condition like timer #1 running at 1.79MHz instead of 64KHz. Keep in mind that the timer is hot as soon as you turn on the IRQ, regardless of whether you write STIMER at all. Remember that POKEY's timers are periodic timers, not one-shot timers; every time the timer fires, it automatically restarts counting from the set period again regardless of how long it takes or if you even handle the IRQ.

[bugbiter]

No pha indeed. Thank you Avery.

[Heaven/TQA]

don't see the benefits yet for it except for playing samples... loosing sound channels is something I don't like in general. Unfortunatly you can not compare them with the c64 ones...

[emkay]

don't see the benefits yet for it except for playing samples... loosing sound channels is something I don't like in general. Unfortunatly you can not compare them with the c64 ones...

Having a sneak peak at Atari Blast, you see the difference with blind eyes

Atari games tend to have the "sprites" moving like stuck on the screen and with a broom in the back. In Atari Blast the "sprites" move like real Arcade sprites.

[Heaven/TQA]

Yes... but same can be achieved with DLIs leaving all 4 channels free...

[emkay]

Yes... but same can be achieved with DLIs leaving all 4 channels free...

But , it's the flexibility of the POKEY timers that allows that huge amount of moving sprites on the screen also.

And, from another point of view, the 4th channel isn't really lost, if you use the timers for playing digitized bass & drums .... it would cost less than RMT uses for something similar in 4 x VBI programming.

With 15kHz programming, a coder could do both side a side...

[Heaven/TQA]

I don't see any flexibility... esp for Sprite multiplexing? It's not like raster irqs on c64 where I setup at special rasterline... as I said.... for me it's easier to do with DLI...

 

Nrv used timers in the raycaster because he don't wanted to have the WSYNC penalty halting the CPU for too long... when unnesessary...

 

I use pokey timers to play samples in (unreleased) Gridrunner for sound fx. But for gfx?

[emkay]

Nrv used timers in the raycaster because he don't wanted to have the WSYNC penalty halting the CPU for too long...

Isn't that "cause" enough? Also, when you do vertical scrolling and need a "real positions on the screen", you don't need extra CPU cycles/calculations for positioning any "Sprite".

[emkay]

Or to say it in other words: The A8 would benefit 2 times, if people use POKEY timers. More moving objects (less cpu cycles for a multiplexer) and better music in games (direct control over the sampling rate).

Edited September 30, 2016 by emkay

[Heaven/TQA]

Yes... it depends on the use case... but that was special in nrv case as he needs to switch gfx modes each Scanline...

 

But what I wanted to say... sacrificing sound channels... well...

 

And in Boinxx I dealt with that for the score panel...

 

Ldx softscroll

Sta wsync

Dex

Bpl wait

 

But yeah you loose 8 scanlines in worth case

[emkay]

But what I wanted to say... sacrificing sound channels... well...

One soundchannel isn't able to play generated waves. But you can use it for sample playback. The "4th" channel generator is useless in most cases, anyways. 4 channels mean to play around with the max volume. No Tracker is build to handle 2 filtervoices correctly, so you don't have that in games. And what you don't have used regulary, you can easily sacrifice. As Digi-Samples also can play at their own volume, without the max volume issue of the generators.... and so on...

Seeing the flexibility of the sprites in Atari Blast, some Shooter - like Turrican - is very imaginable.

Edited September 30, 2016 by emkay

[Rybags]

There's not much point doing samples with the voice as used in Atari Blast. The IRQs are arbitrary dependant on when the PM graphics changes are required.

But if the voice was really needed... something like low/medium frequency square wave would be fine. Many sounds in general use are in the range of 100-250 HZ which equates to 10 transitions per frame which could in part be handled by DLIs... strange irony there in that the roles of Timers and IRQs reversed.

[emkay]

There's not much point doing samples with the voice as used in Atari Blast. The IRQs are arbitrary dependant on when the PM graphics changes are required.

But if the voice was really needed... something like low/medium frequency square wave would be fine. Many sounds in general use are in the range of 100-250 HZ which equates to 10 transitions per frame which could in part be handled by DLIs... strange irony there in that the roles of Timers and IRQs reversed.

You also could restrict the sampling to every 2nd scanline and the PM positioning to every other scanline. Resulting in less moving objects on the screen, but the benefit is clear.

It's a weird thing that you get clean colour changes on the (8 way scrolling ) screen with DLIs but better moving objects... or better CPU usage... when using POKEY timers.

[Mclaneinc]

The poor old Atari with you lot pounding it like this only makes me think of this:-

 

[emkay]

The poor old Atari with you lot pounding it like this only makes me think of this:-

The CPU is doing stuff anyways. Either NOPs, waitstates or changing some register at that time, costs the same.

Edited October 30, 2016 by emkay