What will happen if RESET line, NMI line, and IRQ line are pulled low at the same time?

The priority sequence goes by the way below.

RESET – first priority
NMI – second priority
BREAK – third priority
IRQ – last priority

While RESET line is pulled low for thousands of clock cycles, the microprocessor is frozen as long as clock cycles are fed to the microprocessor. After RESET line is pulled high, the microprocessor resumes to proceed RESET handler prior starting to run a normal program.

While NMI line is pulled low for thousands of clock cycles, the microprocessor proceeds NMI handler until RTI is reached. Next NMI handler will NOT start second time until NMI line is pulled high and then low again.

While BREAK instruction is fetched, the microprocessor proceeds IRQ handler with BREAK flag set.

While IRQ line is pulled low for thousands of clock cycles, the microprocessor proceeds IRQ handler with BREAK flag cleared. Next IRQ handler will repeat many times as long as IRQ flag is not disabled.

My understanding is that I get this information from Understanding the Apple II+ manual by Jim Sather chapter four about 6502 microprocessor. Can you please confirm if the interrupt priority information is correct?

How do the microprocessor know to start BREAK handler since BRK is not fetched yet? For example, LDA opcode is read from memory and is fetched until BRK is reached. After BRK is fetched, it will disable IRQ flag before BRK handler starts until RTI is reached and enables IRQ flag to start IRQ handler if IRQ line is still low.

I think that opcode ($00 to $FF) fetches for first clock cycle before the microprocessor tests RESET flag, NMI flag, hidden BREAK flag, and hidden IRQ flag. It is possible that BRK sets hidden BREAK flag. It does the same thing to do with RESET line, NMI line, and IRQ line to set or clear RESET flag, NMI flag, and hidden IRQ flag. If one of four flags is true, interrupt handler starts to proceed for second clock cycle until seventh clock cycle before normal program resumes.

Please note that I mention RESET flag, NMI flag, hidden BREAK flag, and hidden IRQ flag. They are hidden and they are not shown in the status processor as seven flags. The hidden BREAK flag and hidden IRQ flag are not the same as visible BREAK flag and visible IRQ flag found in status processor. All four hidden flags are used to test the condition prior starting interrupt hanlder after opcode is already fetched during first clock cycle.

Please confirm if my guess is correct.

Bryan Parkoff

I cannot pass up the oportunity to recommend again the programming manual now offered free on WDC's website:
http://www.westerndesigncenter.com/wdc/ ... manual.pdf

When the processor comes out of reset, the interrupt-disable flag (I) will be set, so IRQ\ has no effect until your program clears that flag. Note again that it is a disable flag. BRK however does not respect the I flag. Note also that NMI\ is an edge-triggered interrupt input, whereas IRQ\ is level-sensitive.

The only way to test the break flag (B) is PLA PHA AND#00010000B and then branch on the resulting Z flag. PHP PLA AND#00010000B won't work, because it's as if the B flag doesn't actually exist in the processor-- it's only a bit position in the stacked status byte.

Some good past topics on BRK:
viewtopic.php?f=2&t=1649
viewtopic.php?f=2&t=24

and some of your questions would probably be answered at this topic: viewtopic.php?f=8&t=1797
Also of interest: viewtopic.php?t=1634

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just to reinforce Garth's statement. The 6502 pushes the PSW (P) onto the stack. During that operation, the state of the B bit is set if the BRK instruction is the source of the interrupt, otherwise it is cleared. As Garth stated, the B bit is a figment of the imagination, and only exists in the version of the PSW pushed onto the stack immediately before fetching the first instruction of the interrupt service routine. Thus the instruction sequence

works because the PHP instruction does not have the capacity to set/clear the B bit. That functionality is reserved for the 6502 HW itself; there really isn't a B bit in the PSW, just a bit reserved for the HW to insert a bit when pushing the PSW during an interrupt. Another way to look at it is to consider the PSW (P) as consisting of only 6 registers: {N, V, D, I, Z, C}. Bits 4 (B) and 5 (reserved) don't have any physical hardware in the PSW. Therefore, the instruction sequence

will always indicate that the B bit is 0 because the push occurred outside of an interrupt.

_________________
Michael A.

Sorry, but no cigar. All software (BRK & PHP) pushed processor status bytes will have the B-bit set on the stack.

Only true hardware interrupts (NMI & IRQ) will have the B-bit forced low when the processor status is saved on the stack.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Hi Bryan,

Is it pure curiosity that prompts your question? If there's a specific situation or problem you're trying to address, it would be helpful to share the details with us.

In any case, don't forget there's a lot you can learn from the Visual 6502 project. For example you could run a simulation of RESET, NMI and IRQ pulled low at the same time. http://visual6502.org/

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Please excuse the incorrect information posted earlier. Should have checked the implementation before spouting off. Klaus is absolutely correct.

Corrected example:

_________________
Michael A.

Hi,

Unfortunately, your comment does not answer my question. The 65xx programming manual from WDC does not say deep technical detail how interrupt works, but it only gives you the source code how to use interrupt handler.

I am talking about interrupt priority.

RESET – first priority
NMI – second priority
BREAK – third priority
IRQ – last priority

Let’s assume if I am correct.

If RESET line, NMI line, and IRQ line are low at the same time after disabled IRQ flag is NOT enabled, then the sequence begins below.

1. The current instruction is to be completed.
2. RESET handler is taken during 7 clock cycles and disabled IRQ flag is enabled.
3. RESET handler is interrupted by NMI line.
4. NMI handler is taken during 7 clock cycles and disabled IRQ is ALREADY enabled.
5. NMI takes place until RTI is reached.
6. Disabled IRQ flag is NOT enabled after status processor popped out of stack.
7. Return to RESET handler, but IRQ handler is taken during 7 clock cycles and disabled IRQ flag is enabled.
8. IRQ takes place until RTI is reached.
9. Disabled IRQ flag is NOT enabled after status processor popped out of stack.
10. Return to RESET handler to complete initialization before normal program starts.

I need to know if 6502 microprocessor is frozen after RESET line is pulled low for thousands of clock cycles. It is like pulling READY line low. It should do nothing and no normal program can execute anything until RESET line is pulled high before RESET handler starts.

If BRK is fetched **AND** IRQ line is pulled low during first clock cycle, then BREAK handler takes place until RTI before IRQ handler takes place.

If any instruction other than BRK is fetched **AND** IRQ line is pulled low during first clock cycle, then IRQ handler takes place.

If any instruction is doing **AND** IRQ line is pulled low during second through seventh clock cycle, then any instruction is to be completed before IRQ handler takes place.

Do I explain more clear?

Bryan Parkoff

For some of this, I would have to actually try it to find out; but it seems rather academic since we don't expect the processor to do anything with these until the reset routine sets these things up. That's probably why the information is hard to find.

If the NMI\ liine goes down at the same time the RST\ line does, the reset essentially clears the processor so that it won't remember the NMI\ line had been up. Since it doesn't see the falling edge, it probably won't acknowledge it. Here again however, whatever I/O IC caused the interrupt on the NMI\ line normally gets the same RST\ signal the processor does, and it will clear its own interrupt output and status. It should not be able to generate interrupts again until the reset routine sets it up to do so.

The same goes for I/O ICs that pull the IRQ\ line down. They should be incapable of doing that from the time RST\ goes down until the reset routine (or later routine) sets them up to be able to generate interrupts under the conditions the programmer chooses. When things are set up as desired, then you do CLI (clear interrupt-disable bit) in the program. Before the first CLI, the processor is basically blind to the IRQ\ line.

A low RST\ line will keep the processor inactive indefinitely. When the line goes high, the reset vector is fetched and the reset routine is begun.

Without researching it, I really don't know where BRK ranks relative to IRQ. I have never used BRK except in school in 1982. It mainly had its usage in patching PROMs and it outlived its original purpose; but then some programmers started using it in multitasking OSs, but the 6502 is not very good at multitasking anyway. I've done a lot of real-time work with a sytem of multiple prioritized interrupts and alarms to carry out scheduled tasks, with interval lengths ranging from nine microseconds to fifteen minutes. These have an effect of multitasking except with much better control of timing than a multitasking OS can give you. I never, ever use BRK though. [Edit, 5/15/14: I posted an article on simple methods of doing multitasking without a multitasking OS, at http://wilsonminesco.com/multitask/index.html.]

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

A Reset signal is usually also asserted to the IO chips. They will forget their IRQ or NMI requests.

If after a reset the NMI pin is stuck low, the NMI interrupt is not executed. NMI is edge sensitive! Only a new high to low transition after the reset pin goes high would be executed.

If after a reset the IRQ pin is held low, the IRQ interrupt is only executed after a CLI. A reset does set the I-bit in the processor status.

BRK will be executed anywhere in the instruction stream, provided that there is no NMI or IRQ before the BRK opcode is decoded. The NMOS 6502 has a bug, where a simultaneous BRK and NMI or IRQ would only execute the respective hardware interrupt vector once, leading to potentially loosing either interrupt.
http://visual6502.org/wiki/index.php?ti ... _and_B_bit

As far as I know, on the CMOS verion of the cpu the NMI and the IRQ if enabled would be executed ahead of the BRK. The BRK will be executed after RTI from the hardware interrupts.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

As Jeff says, visual6502 is the most convenient tool to see what the 6502 actually does. It models an nmos 6502, so it can only suggest what a different implementation might do.

See for example:
http://visual6502.org/JSSim/expert.html ... re=nmi,res
where NMI goes active during the period that RES is low - the NMI is ignored.

Bryan: you speak of the 6502 having a reset handler and an IRQ handler, as if the CPU has software inside to control its actions. I may misunderstand you, but it would not be the most helpful way to think of the 6502 internal activity if you seek a very detailed version of the truth. I encourage you to study the visual6502 model, and Balazs' schematics, and to read some of the previous discussions, such as viewtopic.php?t=1817 and viewtopic.php?f=4&t=1634 - any mention of D1x1 is worth following up.

Cheers
Ed

In a project I was on in the late 80's, there was another man involved briefly, and he did do that kind of thing but just made it a subroutine so JSR BREAK was needed to call it. It did show status and allow you to look around at not only the processor registers but also things in memory, so I'm not sure why he didn't use BRK instead except that maybe he wanted to shorten and streamline the ISR so it wouldn't have to check the B flag. Since then, I've mostly used other instructions to directly output exactly the information I wanted and keep going without stopping in a debugging routine. Especially in real-time work, you can't afford to stop the process.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Earlier in this discussion, Garth posted two code sequences to test the B bit. I stepped into the conversation to try to clarify the point he was making by adding some comments to code sequences. In the process, I mis-stated the default value of the B bit on the stack: 0 instead of 1.

I had run into this problem when testing my 65C02 FPGA core earlier this year. The value of the B bit on the stack is set by BRK and PHP, and cleared by NMI and IRQ. I located the information I needed to correct my FPGA core implementation on this page. At the bottom of the page is a discussion of the stack frame of a BRK ISR, and an example of how to adjust the return address on the stack of a BRK ISR if the second byte is not used as a dummy byte. Of course, the code example provided assumes that the B bit in the PSW (P) on the stack is set, and that no registers were saved. If registers were saved, then adjustments to the base address values in the LDA StkBase,X and LDA StkBase+1,X instructions are required.

_________________
Michael A.