atariksi Posted August 14, 2009 Share Posted August 14, 2009 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 15, 2009 Share Posted August 15, 2009 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. Quote Link to comment Share on other sites More sharing options...
NRV Posted August 16, 2009 Share Posted August 16, 2009 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.. Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 16, 2009 Share Posted August 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted August 16, 2009 Author Share Posted August 16, 2009 (edited) 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 Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 16, 2009 Share Posted August 16, 2009 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). Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 16, 2009 Share Posted August 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 16, 2009 Share Posted August 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 16, 2009 Share Posted August 16, 2009 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? Quote Link to comment Share on other sites More sharing options...
NRV Posted August 16, 2009 Share Posted August 16, 2009 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 Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 17, 2009 Share Posted August 17, 2009 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted August 17, 2009 Share Posted August 17, 2009 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 17, 2009 Share Posted August 17, 2009 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 17, 2009 Share Posted August 17, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 17, 2009 Share Posted August 17, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 18, 2009 Share Posted August 18, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 18, 2009 Share Posted August 18, 2009 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted August 20, 2009 Share Posted August 20, 2009 <!--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. Quote Link to comment Share on other sites More sharing options...
analmux Posted August 20, 2009 Share Posted August 20, 2009 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 20, 2009 Share Posted August 20, 2009 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.