How can POKEY IRQ Timers mess up NMI timing?

[Bryan]

Do you have any Release Notes or other technical manuals for the 65C02 ? Maybe they have mention of it.

I've read them. They don't mention that particular issue, but they mention that the BRK one is fixed.

[atariksi]

Do you have any Release Notes or other technical manuals for the 65C02 ? Maybe they have mention of it.

 

I don't even remember reading of the bug anywhere what to speak of documents of correcting it.

[tebe]

http://www.atarionline.pl/v01/index.phtml?ct=nowinki&id=1258503422&ucat=1&subaction=showfull

 

http://atarionline.pl/pliki/tebe_thesnowman.7z

 

sample playing with Sheddy IRQ routine

[ijor]

Sorry for resurrecting this somewhat old thread...

 

I looked into this some months ago. It is a cpu bug. The same bug should be present in all the 650X NMOS variants, including Sally. It is, if you want, a variant of the IRQ/BRK concurrency bug. The bug can be seen by checking the CPU internal schematics.

 

The bug would be exposed when the NMI pulse is less than 3 clock cycles, and when the NMI is trigerred at certain specific clocks during the IRQ exception processing. Note that it doesn't matter when the IRQ signal became active, only the NMI signal to IRQ *exception processing* is significant.

 

In the case of the A8, the NMI signal as you all know is trigerred by ANTIC. And ANTIC triggers NMI at constant specific cycles on the scanline. So if you program Pokey interrupts to happen on every scanline at the very same specific scan cycle (note that this depends not only on Pokey timers but also on CPU execution), you would effectively mask NMI.

Edited December 29, 2009 by ijor

[atariksi]

Sorry for resurrecting this somewhat old thread...

 

I looked into this some months ago. It is a cpu bug. The same bug should be present in all the 650X NMOS variants, including Sally. It is, if you want, a variant of the IRQ/BRK concurrency bug. The bug can be seen by checking the CPU internal schematics.

 

The bug would be exposed when the NMI pulse is less than 3 clock cycles, and when the NMI is trigerred at certain specific clocks during the IRQ exception processing. Note that it doesn't matter when the IRQ signal became active, only the NMI signal to IRQ *exception processing* is significant.

 

In the case of the A8, the NMI signal as you all know is trigerred by ANTIC. And ANTIC triggers NMI at constant specific cycles on the scanline. So if you program Pokey interrupts to happen on every scanline at the very same specific scan cycle (note that this depends not only on Pokey timers but also on CPU execution), you would effectively mask NMI.

 

The bug doesn't show up in the 65C02, but I guess that's not NMOS.

[ijor]

I was doing some search and found this post. I already saw it some time ago, but I concentrated on the picture, and missed your comment, Bryan.

 

Here's /NMI vs phase2 clock (ph2). The 6502 datasheet states that /NMI will be sampled during the ph2 interval (ph2 high). So, NMI properly falls and rises during the ph1 part of the clock.

 

Just for the records because I don't think it is too relevant to the topic. But I think you are mis-interpreting the data sheet. Docs are a bit misleading, but what actually happens is that the CPU samples the pin on the falling edge of PHI2. It is clear once you check other docs (including later WDC/CMOS datasheet), or even the 6800 datasheet (6501 was supposed to be bus compatible).

 

Then, NMI shouldn't be changed close to the PHI2 falling edge. It is ok during PHI2, as long as it is early enough, or during PHI1 as long as it is late enough (as ANTIC does). Whatever the reason that the ANTIC developer (was Jay Miner himself?) decided to use PHI2 falling edge, it is very interesting that Pokey changes IRQ on the opposite PHI2 edge! (NMI and IRQ are sampled together by the CPU).

Edited November 10, 2010 by ijor

[Bryan]

Hey ijor,

 

I wonder if /NMI were re-clocked to the next rising edge of Phi2 if the problem caused by a 2-cycle pulse would persist. Either way, the NMIST bits hang around for a long time so an IRQ routine could quickly check them and jump to the NMI routine if needed. You just have to clear the NMIST bits as you service them which you normally don't have to do.

[Rybags]

But /IRQ wouldn't really matter anyway since it's level-triggered (other than maybe delaying by 1 cycle).

[ijor]

I wonder if /NMI were re-clocked to the next rising edge of Phi2 if the problem caused by a 2-cycle pulse would persist.

 

I considered this, and while I'm not 100% sure (and certainly didn't test it on hardware), I think it shouldn't fix the problem. Internally, the CPU would (should) still see the signal change at the same edge as before.

 

@Rybags: What I meant is that both signals, NMI and IRQ, are latched at the same edge by the CPU. Then, naturally, a system would be designed in such a way as generating both signal in the same edge. But for some reason (which might be just because ANTIC/POKEY were designed by different people), here they change in opposite edges.

Edited November 10, 2010 by ijor

[bged]

I wrote a test app (attached) to check interference between IRQs and DLIs, and indeed there is exactly one cycle at which a IRQ will block an NMI.

Hi! I'm pleased to say that I've recreated this situation on the visual6502 transistor-level simulator. We've recently made a few changes to make it possible to experiment with exact timings and instruction streams. The URL you need is something like this.

 

It's not too hard to modify these URLs for experimentation, although I know they look ugly. We've got some online docs for how they work. I plan to write this NMI/IRQ collision up on our wiki in our collection of curiosities. (The crucial point about visual6502 being that we can see what the causes are because we have all the transistors: this might be helpful to emulator writers and to other people interested in cycle accurate behaviour. On the other hand, we are modelling a specific NMOS 6502, and we only simulate to switch level, so for example unassigned opcode 8B doesn't misbehave in the expected way - it misbehaves in its own way, but we know why.)

 

Thanks to everyone for the various useful hints on this thread, and to Avery particularly for the Altirra documentation!

 

Cheers

Ed

[bged]

I've finally started to flesh out our visual6502 wiki page on interrupt timing.

 

It's a work in progress - my feeling is that we can certainly collect simulation URLs which illustrate interesting situations. We might be less definitive in explaining what's going on in words.

 

Comments and suggestions welcome.

 

Cheers

Ed