6502.org

I'm trying to figure out what's going on with a particular behavior in the NES at the hardware level (related to VBlank flag reading for those in the know ), and it would help if I understood more about how short pulses (possibly shorter than a CPU half-cycle) to the interrupt pins are interpreted.

In Visual 6502, it looks like interrupts are polled during φ1 (internally the input from the pin is pulled low during cclk, so whatever value it has during φ2 won't be seen). Does this mean that the value on the interrupt pin right at the end of φ1 is the value the CPU will see? What are the approximate tolerances here, as I'm guessing the signal can't be too short and still be seen?

I don't know if this will help any, but 9 years ago I tried an experiment to test NMI (not IRQ) on a Rockwell R65c02 and found that it samples on every falling phase-2 edge (with a brief setup and hold time required), and seeing it low (after it was high, since NMI is edge-triggered), at any cycle of an instruction, even if for only one falling phase-2 clock, would make the processor start the interrupt sequence at the end of the instruction. I wrote about it briefly at viewtopic.php?f=4&t=225&p=1481h#p1481. Normally the I/O ICs that do the interrupting however will not release the line anyway until your ISR clears their interrupt condition, so it's not an issue.

Is "on the falling phase-2 edge" different from "during phase 1"? The finest resolution you get in the sim is a half-cycle, so it seems you wouldn't be able to distinguish it further there at least.

Here's an example of the smallest IRQ assertion interval that will trigger an interrupt for LDA #$FF: http://visual6502.org/JSSim/expert.html ... 6&steps=20 . Note that IRQ only needs to be asserted during phase 1, and that it's asserted during the last tick of the LDA (the instructions are viewed as starting when they are fetched here, even though Execute still shows the old instruction during the fetch).

The NES thing is an NMI btw (from the graphics chip). The 6502 seems to sample the NMI input each cycle and set a "pending NMI" flag if it goes from high to low. The point where it samples the IRQ input (usually during the last tick of an instruction) also seems to be the point where it checks if it got an NMI.

Slightly. If it went down after the falling edge of phase 2, and came right back up again, ie, the low pulse fit between phase-2 edges with room to spare on both ends, it would not be seen.

Seems odd that it would be on the falling edge instead of the rising edge though. During phase 2 the input from the pin is driven low, so the value has to be polled during the first phase. The state of the chip can't really change during the first phase though (if you ignore analog effects), so it seems that it would be the value at the end of phase 1, or equivalently at the rising edge of phase 2, that would matter.

Might be missing something though...

Turns out I was misreading the logic closest to the pin. Thought it was a suppression mechanism, but it's actually a latch. Now it does work out to the falling edge of phase 2, but I still need to figure what's going on the in the Visual 6502 links I posted, since those make it look like it's the interrupt pins' value during phase 1 that matters.

The CPU in the original NES is not a 65C02, but a Ricoh 2A03, which contains an original NMOS 6502 (along with sound and other support circuitry).

You should probably think of the visual6502 sim as seeing new input values at clock edges: the simulation responds only to clock events, and for each clock event it ripples through the effects until every node is stable. If you're thinking down at this level, you may need to think carefully about how you interpret the tabular representation.
Cheers
Ed

Yeah, it's prone to off-by-one errors.

The way I visualize stuff now is that each row represents the state after everything has stabilized, with state transitions "between" rows. That seems to work for external pins too, as any new values you see on them will have rippled through the chip for that row.

Still not seeing how the log from the Visual 6502 link I posted above is compatible with the pin being "sampled" (as in its value there determining what happens) on the falling edge of M2 though. Maybe I need to look at it fresh later.

It's probably down to the fine detail of how the code is written: I added the timed interrupt code, and maybe wasn't as careful as I might have been.
Here's the log:

For another step closer to the truth, it might amuse you to run a circuit simulation: viewtopic.php?f=8&t=1768

(As has been said, the reality is that there's a window around the clock edge, the setup time before and the hold time after, within which a synchronous input should be stable. Sometimes the hold time is zero, but not always.)

Cheers
Ed

Hi, ulfalizer. Sometimes it's useful to pursue more than one line of thought. The Visual6502 simulator is an amazing tool, of course. Taking a broader approach, I wonder if it'd be helpful to share with us something about the "behavior" you mention.

Are you trying to determine whether this VBlank flag gets read before or after the NMI from the graphics chip gets recognized, or is the question more complex than that? Dunno how many of us here are in the know about NES, but maybe we can ask a dumb question that'll spark something in your own mind!

-- Jeff

P.S.- As you may know, an interrupt can cause an opcode -- such as one that'll read VBlank ! -- to get fetched and then discarded. Following completion of the ISR, the exact same opcode will be fetched again. Can this possibly be pertinent? Details here.

Unfortunately it's a bit tricky to explain, but I'll do my best for a basic overview. I'm currently working together with blargg, who has scope readings from an actual NES, which lets me match up my findings from the simulators with the messiness of the real world.

Basically, there's a flag (it happens to be related to VBlank in this case), which is tied to NMI generation and has special behavior when reading it. The flag is set automatically at a particular point in the frame (to indicate that VBlank has started), and reading the register ($2002) that holds the flag does two things:

1. Holds the value of the flag in a separate read buffer so it can be read (this is mentioned in the tutorial).
2. Clears the flag. The purpose of the read buffer is to allow it to still be read.

The read behavior above happens during φ2 of the read cycle, but just to make things more complicated the duty cycle of the φ2 that comes out of the chip (called M2) has been modified in the NES; see http://wiki.nesdev.com/w/index.php/CPU_ ... escription.

The flag is tied to the NMI line such that NMI will be asserted while the flag is set (if enabled).

The messy part comes with reading the register right around the point where the flag is set. Since the read will pull it to zero, you sometimes get cases where the NMI is missed, because it isn't asserted for long enough to be seen. You also get cases where the value is missed, because the read buffer is initialized before the value is set, but the overlapping of the read with the setting still causes the flag itself to be cleared. In addition, you want to know the earliest point where the flag will read as set for timing purposes (this isn't purely academic - some games require pretty strict timing).

The above isn't really enough information to be able to draw conclusions, but it should give a flavor at least. Basically, it's messy.

Here you go