Jump to content

Photo

How can POKEY IRQ Timers mess up NMI timing?


210 replies to this topic

#126 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Fri Aug 14, 2009 12:30 PM

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 cyclesSTA WSYNC   ;sync to cycle 105PHA         ;*, 105, 106PLA         ;107, 108, 109, 110PHA         ;111, 112, 113PLA         ;0, 1, 2, 3BRK         ;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

#127 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,672 posts
  • Location:Bay Area, CA, USA

Posted Fri Aug 14, 2009 9:11 PM

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.

#128 NRV OFFLINE  

NRV

    Moonsweeper

  • 392 posts

Posted Sun Aug 16, 2009 1:08 AM

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..

#129 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Sun Aug 16, 2009 1:36 AM

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.

#130 Sheddy OFFLINE  

Sheddy

    Dragonstomper

  • Topic Starter
  • 769 posts
  • Location:UK

Posted Sun Aug 16, 2009 5:51 AM

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 by Sheddy, Sun Aug 16, 2009 6:19 AM.


#131 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sun Aug 16, 2009 8:52 AM

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).

#132 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sun Aug 16, 2009 8:56 AM

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.

#133 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Sun Aug 16, 2009 9:29 AM

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.

#134 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 11,160 posts
  • Location:Baden-WŁrttemberg, Germany

Posted Sun Aug 16, 2009 9:49 AM

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? ;)

#135 NRV OFFLINE  

NRV

    Moonsweeper

  • 392 posts

Posted Sun Aug 16, 2009 12:25 PM

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

#136 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Sun Aug 16, 2009 6:15 PM

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.

#137 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Mon Aug 17, 2009 6:59 AM

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.

#138 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Mon Aug 17, 2009 7:02 AM

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.

#139 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,672 posts
  • Location:Bay Area, CA, USA

Posted Mon Aug 17, 2009 12:55 PM

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.

#140 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Aug 17, 2009 1:24 PM

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.

#141 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Tue Aug 18, 2009 4:36 PM

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.

#142 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Tue Aug 18, 2009 4:39 PM

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.

#143 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Tue Aug 18, 2009 7:49 PM

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.

#144 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Wed Aug 19, 2009 11:48 AM

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.

#145 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Wed Aug 19, 2009 12:34 PM

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.

#146 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Wed Aug 19, 2009 12:44 PM

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.

#147 emkay OFFLINE  

emkay

    Quadrunner

  • 9,669 posts
  • What's up?
  • Location:Holy Grail ;)

Posted Wed Aug 19, 2009 3:15 PM

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.

#148 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Wed Aug 19, 2009 10:19 PM

<!--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.

#149 analmux OFFLINE  

analmux

    Stargunner

  • 2,392 posts

Posted Thu Aug 20, 2009 9:22 AM

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 by analmux, Thu Aug 20, 2009 9:27 AM.


#150 Rybags ONLINE  

Rybags

    Gridrunner

  • 15,990 posts
  • Location:Australia

Posted Thu Aug 20, 2009 9:33 AM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users