How can POKEY IRQ Timers mess up NMI timing?

[atariksi]

Alright, at the risk of beating a dead horse, I'm going to announce what I believe to be the real condition, based on a lot of testing with various delays, mode lines, and interrupting methods:

 

>> The last cycle of the seven-cycle IRQ/BRK sequence must land on exactly cycle 10 to block an NMI. <<

 

The following sequence should accomplish this once, regardless of any DMA (assuming no intervening interrupts and no display list or P/M DMA on the scan line):

 

STA WSYNC   ;clear existing DMA cycles
STA WSYNC   ;sync to cycle 105
PHA         ;*, 105, 106
PLA         ;107, 108, 109, 110
PHA         ;111, 112, 113
PLA         ;0, 1, 2, 3
BRK         ;4, 5, 6, 7, 8, 9, 10

 

Additional factors:

• You must ensure that the starting cycle for your delay is known exactly. STA WSYNC in uncontrolled conditions is not enough as you still have three cycles of uncertainty: a possible DMA cycle immediately after STA WSYNC, a possible playfield DMA cycle at 105, and a possible refresh DMA cycle at 106.
  
• For each cycle of DMA in cycles 0-8 (missile, display list, players, display list LMS) you must initiate the delay or interrupt sequence one cycle earlier for it to hit at the right time.
  
• Playfield DMA cycles starting at cycle 12 don't matter.
  
• The instruction pattern at the beginning of the IRQ routine doesn't matter.
  
• If you are initiating an immediate IRQ by CLI with the IRQ line active, the 6502 will execute one more instruction before initiating the IRQ sequence.
  
• If you are initiating an immediate IRQ by writing IRQEN with a POKEY interrupt active, the 6502 will execute two more instructions before initiating the IRQ sequence, at least if the next instruction is short (two cycles).
  
• If you are strobing STIMER to sync a 16-bit, 1.79MHz timer (atariksi's example), the write needs to happen 7 cycles in advance of the desired interrupt sequence start. This implies that all timers roll over immediately after STIMER instead of waiting one period.
  

 

What all of this also implies is that you cannot reliably avoid this problem with a 64KHz clock. The reason is that, while you can align the clock itself to fire the IRQ on an odd cycle, you're still screwed if instruction completion delays the 6502's interrupt response so that it lands on an even boundary. Therefore, either the 15KHz or the 1.79MHz clocks are the way to go for interference-free POKEY timers. (Which, embarrassingly, is the way the OP was doing it before I sent him off on this particular tangent by suggesting the 64KHz clock. Oops.)

 

There is one pertinent case that I haven't tested, which is if playfield DMA is occurring on cycle 10. This can only occur on a mode 2-7 line with wide playfield fetch that has been shortened to one scan line. It's difficult to test this case, though.

 

How do you figure 10 cycles on my example: NOP, CLI, STA STIMER.

 

Also, at 1.79Mhz if the divisor is 8-bits, the formula is 1789790/(A+4) instead of 1789790(A+7). Here's modified version using just 8-bit divisor-- this also locks up the system reset on 400/800:

 

;*** ATIRQ400.asm: Atari Timer IRQ measured to exact cycles so no WSYNC is required.

;*** This plays music on voice #1 and uses IRQ timer interrupt on timer #4. Voice #0 is for constant tone.

;*** There are three CLKs which can be used by either 8 or 16 bit divisors as controlled by 53768.

;*** The 15.6999Khz CLK and 63.921Khz CLK can be turned off via 53775 but 1.78979Mhz CLK is always on.

;*** The 15.6999Khz CLK is 1.78979Mhz/114 and gives the scanline interrupt at end of scanline. The divisor

;*** is 114-7 for 16-bit counter and 114-4 for 8-bit counter.

;*** The 63.921Khz CLK is 1.78979Mhz/28 and does not divide evenly into 29868 cycles/frame so cannot be used

;*** for color clock accurate or scanline accurate interrupts. This program also attempts to write IRQ vector

;*** directly at 65534/65535 by disabling ROM for XL/XE series (should have no effect on Atari 400/800).

;*** This program locks out SYSTEM RESET on Atari 400/800 where it's a NMI. Reset key can still be

;*** detected by location 54287; just the reset vector will not be called. In this program, the pink bar will turn

;*** blue when reset is pressed (switching value from 95 -> 127).

TIMERFREQLSB = 53760

TIMERFREQMSB = 53762

WSYNC = 54282

VCOUNT = 54283

 

DOSVEC = 10

CASINI = 2

WARMSTART = 58484

VMIRQ = 534 ;hardware irq ptr

 

ORG = 600h

;DW 0FFFFh

;DW StartAdr

;DW LastOffset-1

DB 0,3 ;# of sectors to load 1..255

DW ORG

DW StartAdr

Rts

StartAdr: Lda #MyReset,L

Sta CASINI

Lda #MyReset,H

Sta CASINI+1

Lda #0

Sta 580

Lda #2

Sta 9

Jmp WARMSTART

MyReset: Lda #2

Sta 9

Lda #MyReset,L

Sta CASINI

Lda #MyReset,H

Sta CASINI+1

Sei

Lda #0 ;no VBIs nor DLIs for maximum performance

Sta 54286

;Sta 54287

Sta 53774 ;disable all IRQs

Sta 54272 ;turn off screen

;Sta 53775 ;turn off serial/KB/15&63Khz CLK /1.79Mhz CLK is always on

Sta 54017 ;disable ROM and BASIC for XL/XE series via PORTB

Lda #TimerTwoIRQ,L ;general IRQ routine but we use only for timer #2

Sta VMIRQ

Ldy #TimerTwoIRQ,H

Sty VMIRQ+1

Sta 65534

Sty 65535

Cpy 65535

Beq ROMVectorSet

Lda #IdleLoop,L

Sta SelfModifyThis+1 ;Remove 5 cycles from background task (for Jmp [534])

Lda #IdleLoop,H

Sta SelfModifyThis+2

ROMVectorSet: Lda #64 ;Bit 6 = channel 1 @1.79Mhz, bit 5 = channel 3 @1.79Mhz

Sta 53768 ;bit 4 = channel 1+2 to 16-bit divisor, bit 3 = channel 3+4 to 16-bit

Lda #114-4 ;lsb 114-7 or 57-7 for two irqs/scanline

Sta 53760 ;timer freq = 1789790/[A+7] or [A+4]

Lda #143

Sta 53761

Lda #175

Sta 53763

Lda #160

Sta 53764

Lda #0

Sta 53766

Lda #1 ;1,2,4=timer interrupts

Sta 53774 ;enable IRQ #2

Lda #128

;Sta 53248 ;unrem to show sprite using 0 CPU cycles and 0 DMA cycles

Lda #144

;Sta 53249

Lda #255

Sta 53261

Sta 53262

Sta 53256

Sta 53257

Lda #32

Sta 53275

Lda #10

Sta 53266

Lda #12

Sta 53267

Ldx #0

;Stx 53775 ;resetting SKCTL does not have any effect on syslock

;Lda #3

;Sta 53775

Ldy #1 ;load ack parameters

Lda #65

NotMidScr: Cmp VCOUNT

Bne NotMidScr ;CF=1 when A=65

;Nop ;make no difference on syslock

;Inx

Sta WSYNC

Nop ;doing 3 cycles or less doesn't lock system reset

CLI

Sta 53769 ;start timer counter

;CLI

;Nop

;Nop

;Nop

;Nop

;Lda #34

;Sta 54272

IdleLoop: ;(29868 cycles in NTSC frame - 9*262 for Refresh = 27510 cycles so to keep the IRQ

; stable, cycles must be aligned to 27510 including IRQ routine). For PAL frame, use

; 312*114 = 35568 - 312*9 = 32760 cycles.)

;(27510 factors to 2*5*7*3*131)

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Lda 53767

;Sta 53274

;Nop

;Jmp IdleLoop

 

Lda #0

Sta 53274

Lda 1535

;Lda 53770 ;No longer random if bits 0,1 of 53775 = 0

ROL

Sta 53274

;Rol

Sta 53762 ;make construction site noise

Lda #48

Sta 53274

Lda 54287 ;reads 95 when no reset pressed and 127 when reset pressed

;Lda #64 ;which of these two instruction to rem out depends on IRQ routine total cycles

;Sta 53274

;Lda #96

Sta 53274

Lda #128

Sta 53274

Lda #144

Sta 53274

Lda #160

Sta 53274

Lda #176

Sta 53274

SelfModifyThis: Jmp Idle1 ;For Atari 400/800, this jmp and following NOP (5 cycles) will be removed since ROM vector not used

Idle1: Nop

Jmp IdleLoop

 

;*** H/W does jmp [65534] (7 cycles) and XL/XE OS does a CLD and JMP [534] for 2+5 = 7 cycles.

;*** Below routine 32 cycles+7+5 = 44 cycles on old OS (like on Atari 400/800).

;*** Optimized by using X/Y registers and not using it in main routine so PHA/PLA not needed.

TimerTwoIRQ: ;Pha ;3 cycles

;Lda #255

;Sta 53771 ;POTGO

;Nop

Inc 53274 ;change register (like color for example)

;Lda #0

;Sta 53774

;Lda #4

;Sta 53774 ;send ack to timer irq (optimized with Inc = 6 cycles)

;Inc 53774 ;Rol/Asl/Inc (6 cycles) for Ack using Timer #4 (only Inc for Timer #2)

;nop ;unpublished lines (Inc and Nop)-- used stx/sty instead-- replace

; inc with rol and reset causes temporary disturbance before resuming normal screen

Stx 53774

Sty 53774 ;do ack

Inc 1535

;Nop

;Lda #96

Ror 53274 ;change register (like color for example)

;Pla ;4 cycles

Rti ;6 cycles

 

;LastOffset: DW 2e0h,2e1h,ORG

[phaeron]

How do you figure 10 cycles on my example: NOP, CLI, STA STIMER.

 

I didn't say 10 cycles, I said cycle 10. That's numbered from WSYNC releasing the CPU on cycle 105 and missile DMA happening at cycle 0. NOP + CLI + STA STIMER off of a clean STA WSYNC means that you are hitting STIMER on cycle 111. Assuming no DMA contention, which there isn't in your case, the IRQ acknowledgement sequence must happen at cycle 4. That leaves a gap of 7 cycles, made up of a combination of STIMER-to-timer and timer-to-IRQ delays, and the 6502 waiting for the current instruction to complete before acknowledging the IRQ. I don't know the exact offset from when you hit STIMER to when the timer begins firing IRQs, but it's highly likely that there is a non-zero delay.

[NRV]

One question.. is doing:

 

lda #0

sta SKCTL

 

.. wait loop ..

 

lda #3

sta SKCTL

 

the only way to change the IRQ start at different cycles in a scanline ??

 

independent of the clock (15, 64 or 1.79)? and STIMER doesn't have any role in that??

 

thanks..

[Rybags]

Some testing would be needed... the Init state of Pokey is kinda weird.

 

Pure tone stuff still plays, but anything that uses Poly-counters doesn't... RANDOM reads 00 (?).

 

I haven't tried stuff like - if a serial transmission is under way, does it finish transmitting the current byte?

What happens with IRQ flags, e.g. if one or more are pending, does Init clear them?

 

Luckily for us, we can test some theories in super slow-mo, thanks to 16 bit mode + 15 Khz... you can get some rediculously low frequency settings there.

[Sheddy]

One question.. is doing:

 

lda #0

sta SKCTL

 

.. wait loop ..

 

lda #3

sta SKCTL

 

the only way to change the IRQ start at different cycles in a scanline ??

 

independent of the clock (15, 64 or 1.79)? and STIMER doesn't have any role in that??

 

thanks..

 

I think what you need to know is that STIMER only resets Timers, but not when they count down. This only happens at the next POKEY clock tick rather than from the time STIMER is written (as most of us probably used to think):

 

so for the 1.79MHz clock, STIMER does still give precise control to any cycle in the scanline - 1 clock tick evey cycle.

15KHz clock ticks only once per scanline so it is totally dependent on when the POKEY initialize is done

and the 64KHz clock is more complicated as 4 ticks happen in 112 cycles rather than the 114 in a scanline, so the IRQ start position in a scanline is not easily controlled anyway after the 1st IRQ.

 

As Rybags says, there might be another way to change the IRQ start reliably other than POKEY initialize, but as far as we know, nobody knows how to. It'll be useful to know if there is a way

Edited August 16, 2009 by Sheddy

[atariksi]

How do you figure 10 cycles on my example: NOP, CLI, STA STIMER.

 

I didn't say 10 cycles, I said cycle 10. That's numbered from WSYNC releasing the CPU on cycle 105 and missile DMA happening at cycle 0. NOP + CLI + STA STIMER off of a clean STA WSYNC means that you are hitting STIMER on cycle 111. Assuming no DMA contention, which there isn't in your case, the IRQ acknowledgement sequence must happen at cycle 4. That leaves a gap of 7 cycles, made up of a combination of STIMER-to-timer and timer-to-IRQ delays, and the 6502 waiting for the current instruction to complete before acknowledging the IRQ. I don't know the exact offset from when you hit STIMER to when the timer begins firing IRQs, but it's highly likely that there is a non-zero delay.

 

I just put up a sprite to get exact color clock position of where my color pattern shows and it doesn't change when I go from 16-bit mode to 8-bit mode so it looks like the delays don't affect 8-bit/16-bit mode although formulae are different. While playing with sprites on all this complex stuff, I am getting some sort of NTSC color mixing of BAK and sprite color (53266)-- looks like I have skewed the GTIA color clock by less than a color clock... Perhaps, now you will have to determine the cycle to decimal places!

 

So you are not saying IRQ firing and NMI firing is at cycle 10 (nor 10 cycles from WSYNC).

[atariksi]

Some testing would be needed... the Init state of Pokey is kinda weird.

 

Pure tone stuff still plays, but anything that uses Poly-counters doesn't... RANDOM reads 00 (?).

 

I haven't tried stuff like - if a serial transmission is under way, does it finish transmitting the current byte?

What happens with IRQ flags, e.g. if one or more are pending, does Init clear them?

 

Luckily for us, we can test some theories in super slow-mo, thanks to 16 bit mode + 15 Khz... you can get some rediculously low frequency settings there.

 

I just played around with the init clock stuff and it looks like to shifting of the 15Khz clock is quantized to some multiples-- it can't be done for every cycle.

 

Of course, if you leave Init state alone (default of what 800/XL/XE OS does), then regardless of where you STA STIMER, the 15Khz won't interfere with NMIs.

[Rybags]

The OS does use Init State... although not really intentionally.

 

The cold/warmstart always clears the Hardware Registers. So, it's putting 00 in SKCTL and is also hitting WSYNC. That is enough to cause a condition such that when SKCTL is initialised to it's normal op state, the relative alignment will probably always be the same.

[Heaven/TQA]

How do you figure 10 cycles on my example: NOP, CLI, STA STIMER.

 

I didn't say 10 cycles, I said cycle 10. That's numbered from WSYNC releasing the CPU on cycle 105 and missile DMA happening at cycle 0. NOP + CLI + STA STIMER off of a clean STA WSYNC means that you are hitting STIMER on cycle 111. Assuming no DMA contention, which there isn't in your case, the IRQ acknowledgement sequence must happen at cycle 4. That leaves a gap of 7 cycles, made up of a combination of STIMER-to-timer and timer-to-IRQ delays, and the 6502 waiting for the current instruction to complete before acknowledging the IRQ. I don't know the exact offset from when you hit STIMER to when the timer begins firing IRQs, but it's highly likely that there is a non-zero delay.

 

I just put up a sprite to get exact color clock position of where my color pattern shows and it doesn't change when I go from 16-bit mode to 8-bit mode so it looks like the delays don't affect 8-bit/16-bit mode although formulae are different. While playing with sprites on all this complex stuff, I am getting some sort of NTSC color mixing of BAK and sprite color (53266)-- looks like I have skewed the GTIA color clock by less than a color clock... Perhaps, now you will have to determine the cycle to decimal places!

 

So you are not saying IRQ firing and NMI firing is at cycle 10 (nor 10 cycles from WSYNC).

 

 

new deterministic color shift???? suprahip?

[NRV]

I think what you need to know is that STIMER only resets Timers, but not when they count down. This only happens at the next POKEY clock tick rather than from the time STIMER is written (as most of us probably used to think):

Yep, that was what I used to think.. thanks

 

Well, for using the 15 and 1.79 clocks I suppose there is no problem with that method.. you just sync at the start of your program and then forget about it.. the problem now is the 64khz clock and the NMI's (but it sounds like the idea of starting in an even or odd cycle should work?).

 

So, if I want to count 1 scanline, with the 15khz clock I just use AUDFn with a 0 value, and if want to do the same with the 1.79mhz clock I use AUDFn with 114 (or 113?)..

 

Regards

[Rybags]

With 16 KHz, it's always Scanlines (-1).

 

Not totally sure about 1.79 MHz mode... with that mode we have the 4 cycle reload delay... then again I think all modes might have that delay (or 7 in 16-bit).

It only really becomes significant music-wise in 1.79 MHz mode because it has a large bearing on the Freq calculations, but in slower modes it barely makes a difference at lower frequencies.

[Bryan]

I've been messing a little with 64KHz mode and it doesn't look like you can achieve an odd and even cycle alignment, so it seems to be based on an already /2 clock. I'll try to post a demo program.

[Rybags]

It would be nice to get all this nicely doco'd.

 

I'm thinking with Init, maybe put the voices at AUDF=0 and voices 1/3 in 1.79 MHz mode first.

 

The solution might be some combination of doing that and using STIMER. Possibly even two-tone might have some influence, since supposedly Voice 2 can reset voice 1 under certain conditions.

 

 

As for this whole IRQ knocking out NMIs thing... I'm tempted to get out the C-64 and see if I can replicate the problem over there.

[phaeron]

Some testing would be needed... the Init state of Pokey is kinda weird.

 

Pure tone stuff still plays, but anything that uses Poly-counters doesn't... RANDOM reads 00 (?).

 

I just played around with the init clock stuff and it looks like to shifting of the 15Khz clock is quantized to some multiples-- it can't be done for every cycle.

 

The way the init function works for the polynomial counters, according to the schematics, is that it forces 0 or 1 bits into the counters one bit at a time. This is true for both the noise counters and the 15/64KHz counters. Therefore, you need to hold down INIT long enough for the counters to fully reset, or you may get false results -- 5 cycles for the 64KHz counter, 7 cycles for the 15Khz counter. Were you doing an STA SKCTL / LDA #imm / STA SKCTL? That would only be 6 clocks.

[atariksi]

Some testing would be needed... the Init state of Pokey is kinda weird.

 

Pure tone stuff still plays, but anything that uses Poly-counters doesn't... RANDOM reads 00 (?).

 

I just played around with the init clock stuff and it looks like to shifting of the 15Khz clock is quantized to some multiples-- it can't be done for every cycle.

 

The way the init function works for the polynomial counters, according to the schematics, is that it forces 0 or 1 bits into the counters one bit at a time. This is true for both the noise counters and the 15/64KHz counters. Therefore, you need to hold down INIT long enough for the counters to fully reset, or you may get false results -- 5 cycles for the 64KHz counter, 7 cycles for the 15Khz counter. Were you doing an STA SKCTL / LDA #imm / STA SKCTL? That would only be 6 clocks.

 

Okay, I'll look at the source when I get home and put more delays in (if they aren't there) between STAs to SKCTL.

[atariksi]

Some testing would be needed... the Init state of Pokey is kinda weird.

 

Pure tone stuff still plays, but anything that uses Poly-counters doesn't... RANDOM reads 00 (?).

 

I just played around with the init clock stuff and it looks like to shifting of the 15Khz clock is quantized to some multiples-- it can't be done for every cycle.

 

The way the init function works for the polynomial counters, according to the schematics, is that it forces 0 or 1 bits into the counters one bit at a time. This is true for both the noise counters and the 15/64KHz counters. Therefore, you need to hold down INIT long enough for the counters to fully reset, or you may get false results -- 5 cycles for the 64KHz counter, 7 cycles for the 15Khz counter. Were you doing an STA SKCTL / LDA #imm / STA SKCTL? That would only be 6 clocks.

 

Okay, I'll look at the source when I get home and put more delays in (if they aren't there) between STAs to SKCTL.

 

I tried all sorts of delays between STA zero and 3 to SKCTL and still 15Khz interrupt is quantized to certain positions. For example, if I burn 39 cycles after WSYNC with instructions then whether I burn 39,40, or 41, I get the same exact color pattern. Similarly, burning 42,43,or 44 cycles produces the same pattern. Now take into account the refresh cycle that's lurking there, it's at least /4 quantization factor.

[atariksi]

It would be nice to get all this nicely doco'd.

 

I'm thinking with Init, maybe put the voices at AUDF=0 and voices 1/3 in 1.79 MHz mode first.

 

The solution might be some combination of doing that and using STIMER. Possibly even two-tone might have some influence, since supposedly Voice 2 can reset voice 1 under certain conditions.

 

 

As for this whole IRQ knocking out NMIs thing... I'm tempted to get out the C-64 and see if I can replicate the problem over there.

 

I replaced the 6502 on the Atari 800 CPU card with a 65C02-14Mhz, and I can't get the system reset to lock up anymore (even after adjusting interrupt cycle timing and removing r/m/w instructions). So 6502 is involved in helping lock up the system reset NMI.

[Bryan]

I tried all sorts of delays between STA zero and 3 to SKCTL and still 15Khz interrupt is quantized to certain positions. For example, if I burn 39 cycles after WSYNC with instructions then whether I burn 39,40, or 41, I get the same exact color pattern. Similarly, burning 42,43,or 44 cycles produces the same pattern. Now take into account the refresh cycle that's lurking there, it's at least /4 quantization factor.

 

What's interesting is that there's nothing that really forces Pokey and video to be in sync. Pokey doesn't have a RESET pin, so I wonder if there's any chance of different start-up alignments.

[atariksi]

It would be nice to get all this nicely doco'd.

 

I'm thinking with Init, maybe put the voices at AUDF=0 and voices 1/3 in 1.79 MHz mode first.

 

The solution might be some combination of doing that and using STIMER. Possibly even two-tone might have some influence, since supposedly Voice 2 can reset voice 1 under certain conditions.

 

 

As for this whole IRQ knocking out NMIs thing... I'm tempted to get out the C-64 and see if I can replicate the problem over there.

 

I replaced the 6502 on the Atari 800 CPU card with a 65C02-14Mhz, and I can't get the system reset to lock up anymore (even after adjusting interrupt cycle timing and removing r/m/w instructions). So 6502 is involved in helping lock up the system reset NMI.

 

Which cartridges/software is suppose to be incompatible with 65C02? So far these games worked right off the bat-- Hero, Pole Position, Galaxian, Topper, Millipede, Joust, SpyHunter, and Ms. PacMan.

[Bryan]

Which cartridges/software is suppose to be incompatible with 65C02? So far these games worked right off the bat-- Hero, Pole Position, Galaxian, Topper, Millipede, Joust, SpyHunter, and Ms. PacMan.

 

Replying to yourself?

 

You may have problems with demos as they sometimes use undoc'd opcodes, none of which are supported in the 65C02. I don't know about which games do.

[atariksi]

Which cartridges/software is suppose to be incompatible with 65C02? So far these games worked right off the bat-- Hero, Pole Position, Galaxian, Topper, Millipede, Joust, SpyHunter, and Ms. PacMan.

 

Replying to yourself?

 

You may have problems with demos as they sometimes use undoc'd opcodes, none of which are supported in the 65C02. I don't know about which games do.

 

I was trying to follow up to what I wrote before-- didn't want to search down the original message.

 

I guess games didn't use the read/modify/write on hardware registers for anything.

[emkay]

What's interesting is that there's nothing that really forces Pokey and video to be in sync. Pokey doesn't have a RESET pin, so I wonder if there's any chance of different start-up alignments.

 

No miracle there. Not sure what the real intention was to add arcade POKEY to the computer Atari 800.

Probably it was rather the potentiometer and keyboard features than the sound capabilities.

POKEY's counters are simply built in for having them in machines where the chip is controlled by a separated CPU, and the aimed clocking is too high in the A8 for 100% correct octaves (the low octaves miss some lower notes) . The timers are good when turning the screen off, for having some clean interrupts. But with screen turned on, you have all that ANTIC offers, just like DLI, VCOUNT.... and the system's VBI.

 

POKEY's timers still mess up with ANTIC's NMI. I wonder what this thread is about.

[atariksi]

<!--quoteo(post=1819188:date=Wed Aug 19, 2009 3:49 AM:name=Bryan)--><div class='quotetop'>QUOTE (Bryan @ Wed Aug 19, 2009 3:49 AM) <a href="index.php?act=findpost&pid=1819188"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What's interesting is that there's nothing that really forces Pokey and video to be in sync. Pokey doesn't have a RESET pin, so I wonder if there's any chance of different start-up alignments.<!--QuoteEnd--></div><!--QuoteEEnd-->

 

No miracle there. Not sure what the real intention was to add arcade POKEY to the computer Atari 800.

Probably it was rather the potentiometer and keyboard features than the sound capabilities.

POKEY's counters are simply built in for having them in machines where the chip is controlled by a separated CPU, and the aimed clocking is too high in the A8 for 100% correct octaves (the low octaves miss some lower notes) . The timers are good when turning the screen off, for having some clean interrupts. But with screen turned on, you have all that ANTIC offers, just like DLI, VCOUNT.... and the system's VBI.

 

POKEY's timers still mess up with ANTIC's NMI. I wonder what this thread is about.

 

POKEY's timers at 1.78979Mhz (558ns/tick) are more accurate than ANTIC's and even the standard PC timer which runs at 1.19318Mhz (838ns/tick) and was being used in PCs up till and including Windows XP. In fact, you can simulate the VBI of ANTIC by using divisors of (165,116) and the DLIs using the 15Khz scanline rate. If you think you were getting better accuracy for your notes with PC applications relying on 1.19318Mhz or using ANTIC, you are mistaken.

 

And it's not POKEY screwing with the ANTIC's timing; as far as experiments show, putting a 65c02 (w/enhanced instructions) does not cause masking of NMIs via IRQs. Timers are good even with screen on as long as you know where the timer will strike (DMA cycle or CPU cycle) and DMA cycles are spread out uniformly so that latency is minimized except in 40+ byte/line text modes.

[analmux]

I tried all sorts of delays between STA zero and 3 to SKCTL and still 15Khz interrupt is quantized to certain positions. For example, if I burn 39 cycles after WSYNC with instructions then whether I burn 39,40, or 41, I get the same exact color pattern. Similarly, burning 42,43,or 44 cycles produces the same pattern. Now take into account the refresh cycle that's lurking there, it's at least /4 quantization factor.

 

How about the following code?:

lda  #0
ldx  #3
sta  skctl
sta  stimer
sta  wsync
stx  skctl
sta  stimer

 

I might be wrong but, as far as I remember, in some case one needs to trigger STIMER 2 times to be sure the (15khz or other) divisor is reset with 100% certainty.

Edited August 20, 2009 by analmux

[Rybags]

POKEY was specifically developed for the computer range the way I see it. Otherwise, why have 8 Pots, and why have keyboard support at all, especially given that the keyscan can't handle multiple presses.

 

Atari was still using discreet logic sound for some arcade games even after the computers came out... Asteroids Deluxe used discrete + Pokey but plain old Asteroids didn't.

 

Re - sync of 16 Khz Timers, I got them to move... the only reason they appear locked to Antic is like I said before - the warmstart OS routine is the cause of that.