Page 2 of 2

Re: Using NMI as a programmer's "panic" switch

Posted: Wed Feb 19, 2014 5:42 am
by BigDumbDinosaur
RichCini wrote:
I will give the DS1813 a try, but the trigger length is long and not knowing what people will be using this board for (I'm planning on making a run of boards for sale), I'm thinking that I should use an RC circuit with two HC14 gates as in the example I mentioned at the top.
If the trigger length (150-200ms) is a concern you can drive NIMB through a dual-input AND gate. Connect one of your AND gate inputs to the push button and /RST on the DS1813, and pull the other input up to Vcc through a 3.3K resistor. Connect the gate's output to NMIB—no pullup required here.

If you push the "panic" button, you will get the debounced NMI, since the DS1813 will hold its gate input low for 150-200ms, causing a corresponding low on the gate's output. If the other gate input is briefly toggled, NMIB will be correspondingly toggled, producing the desired short trigger length. If you need more to hook up more NMI sources use a quad-input AND gate, e.g., 74xx21.

As I earlier said, try not to make it complicated. :D

BTW, which microprocessor are you using?

Re: Using NMI as a programmer's "panic" switch

Posted: Wed Feb 19, 2014 1:39 pm
by RichCini
BigDumbDinosaur wrote:
BTW, which microprocessor are you using?
The WDC 65C02 although the board will work with the plain-jane 6502. The ROM code doesn't use any 'C02-specific instructions and runs at 1MHz.

I guess there's no reason for me to use the VIA with either the DS1813 or the R-C/HC14 solution, but connecting it to the VIA saves an AND gate at the expense of additional code if other interrupts are used on that chip. The interrupt line of each I/O device (6551 and two 6522's) can be configured with a diode (cathode to the device). I guess this addresses the fact that they can't be wire-ORed on the WDC devices.

If I don't use the VIA, there are 4 NMIB sources plus the "expansion buss" NMIB line. I don't think there is an 8-input AND gate (only NAND), so could I cascade the two 4-in AND gates in a 74LS21 with pull-ups on the remaining inputs? I really only have room on the board for one more LSXX chip.

Thanks again!

Re: Using NMI as a programmer's "panic" switch

Posted: Wed Feb 19, 2014 7:11 pm
by BigDumbDinosaur
RichCini wrote:
BigDumbDinosaur wrote:
BTW, which microprocessor are you using?
The WDC 65C02 although the board will work with the plain-jane 6502. The ROM code doesn't use any 'C02-specific instructions and runs at 1MHz.
Just an opinion, but if I were you I would not suggest or otherwise encourage the use of the NMOS 6502. Why use hardware with known bugs and a weak fanout? If you stick to the 65C02, not only do you get away from the NMOS hardware issues, you get extra instructions that can make for more succinct programs. For example, in your interrupt handler preamble, you could directly push the X- and Y-registers without going through the accumulator, thus saving some clock cycles. Plus the 65C02 automatically reverts to binary mode when interrupted, which the NMOS part does not do if in BCD mode—this shortcoming has trapped many a programmer over the years.
Quote:
I guess there's no reason for me to use the VIA with either the DS1813 or the R-C/HC14 solution, but connecting it to the VIA saves an AND gate at the expense of additional code if other interrupts are used on that chip. The interrupt line of each I/O device (6551 and two 6522's) can be configured with a diode (cathode to the device). I guess this addresses the fact that they can't be wire-ORed on the WDC devices.
A fundamental tenet of computer circuit design is that a non-maskable interrupt is best reserved for one high priority event, for example incipient power failure—or a panic button. The use of NMI in a wired-OR configuration should be avoided unless there is a compelling reason to do otherwise.

As the NMI input is edge-sensitive, the MPU cannot tell that it has been interrupted more than once when NMI is involved. I discuss this in my 65C816 interrupts article—see here for the details. The only thing connected to NMI in my POC unit is the "panic button." All other interrupts come in on IRQ.

Commodore used wired-OR on NMI in the VIC-20, C-64 and C-128 as a cost-containment measure, but introduced a booby-trap by virtue of NMIs being used for RS-232 processing. If the Restore key were hit at the exact instance that a 6522/6526 interrupt occurred, the 6502/6510/8502 couldn't tell if the NMI occurred because of a timer underflow, Restore keypress, or some other 6522/6526 event (e.g., a time-of-day clock alarm in the 6526). The default was to check for a timer underflow, which in the C-64 and C-128 occasionally tripped over yet another bug having to do with chip errata in the 6526. Oftentimes, it was necessary to patch into the NMI kernel code in order to sort out this mess in a satisfactory fashion.

Something else to consider is that if you vector your interrupt service routine so the programmer can patch into it to add features (e.g., to support new hardware), you need to be able to temporarily halt interrupt processing while the vector is being changed. With the 65(C)02, you can only change one byte of the vector address per instruction, which opens the door to a crash if an interrupt hits immediately after the first byte has been changed. If your interrupts are coming in on NMI, how would you temporarily tell the MPU to not respond to them until the vector has been changed? If you are using IRQ, it's easy, as all you need is to bracket the vector change instructions with SEI and CLI.
Quote:
If I don't use the VIA, there are 4 NMIB sources plus the "expansion buss" NMIB line.
See above.
Quote:
I don't think there is an 8-input AND gate (only NAND), so could I cascade the two 4-in AND gates in a 74LS21 with pull-ups on the remaining inputs? I really only have room on the board for one more LSXX chip.
You could. However, it's best to use 74AC or 74HC logic, not 74LS.

Re: Using NMI as a programmer's "panic" switch

Posted: Wed Feb 19, 2014 8:35 pm
by RichCini
BigDumbDinosaur wrote:
Just an opinion, but if I were you I would not suggest or otherwise encourage the use of the NMOS 6502. Why use hardware with known bugs and a weak fanout? If you stick to the 65C02, not only do you get away from the NMOS hardware issues, you get extra instructions that can make for more succinct programs. For example, in your interrupt handler preamble, you could directly push the X- and Y-registers without going through the accumulator, thus saving some clock cycles. Plus the 65C02 automatically reverts to binary mode when interrupted, which the NMOS part does not do if in BCD mode—this shortcoming has trapped many a programmer over the years.
Agreed. The netlist lists the C02 part. The only "old" chip on my test board is the 6551, which is a Rockwell version.
BigDumbDinosaur wrote:
A fundamental tenet of computer circuit design is that a non-maskable interrupt is best reserved for one high priority event, for example incipient power failure—or a panic button. The use of NMI in a wired-OR configuration should be avoided unless there is a compelling reason to do otherwise.
Yes, agreed.
BigDumbDinosaur wrote:
Something else to consider is that if you vector your interrupt service routine so the programmer can patch into it to add features (e.g., to support new hardware), you need to be able to temporarily halt interrupt processing while the vector is being changed. With the 65(C)02, you can only change one byte of the vector address per instruction, which opens the door to a crash if an interrupt hits immediately after the first byte has been changed. If your interrupts are coming in on NMI, how would you temporarily tell the MPU to not respond to them until the vector has been changed? If you are using IRQ, it's easy, as all you need is to bracket the vector change instructions with SEI and CLI.
I guess I could use an output on a VIA in "manual" mode (like CAx or CBx) to control an input on the AND to disable NMIs. I want to say that the IBM-PC used a port-disable for NMI, but off-hand I don't remember why...maybe memory parity error handling.

Oh, one more thing. Since you can connect the VIA interrupt output to either IRQ or NMI through a jumper, should I have pull-ups on all of the AND gate inputs (probably yes)? Is it OK to have a pull-up on the input and have it connected to the interrupt output of the VIA or would I need to remove the resistor? It's the difference between using a resistor pack and jumpers or discrete resistors.

Thanks again for the help.

Re: Using NMI as a programmer's "panic" switch

Posted: Wed Feb 19, 2014 11:22 pm
by GARTHWILSON
The pull-up resistor is always ok on an interrupt line. It won't hurt anything to have it even on one that is driven by a totem-pole output like one of WDC's 65c22's has. (I don't remember the exact designation off the top of my head. They offer both types, the totem-pole and open-drain output, the totem-pole output being better for the highest speeds where a pull-up resistor may not make the line float back up quickly enough in some cases.) The interrupt sources with totem-pole outputs should not be on the same line with other interrupt sources of either kind though, because you don't want one device trying to pull the line down while another is trying to pull it up, both low-impedance. If you don't want to use an AND gate to combine the lines, you could probably get away with diodes if they're of the Schottky type so their forward voltage drop is about a third as much as a standard silicon diode gives.

The VIA that's on the NMI line can be told in software of course to not interrupt until further notice; so although the NMI\ input to the processor is non-maskable, you can make sure it won't get hit during the changing of a vector. Since NMI\ is edge-triggered though, you'd have to be very careful if you combine two or more things on it, since if the times they pull down overlap, the processor won't see the second one, and the ISR would always have to poll other possible enabled sources to make sure everything is serviced and all connected interrupt outputs are high simultaneously again so the next NMI interrupt will be visible.

Be aware that the NMOS 6551 will stop in the middle of a byte if its CTS line goes false, and it won't finish the byte. I don't know if it's a big bug or just a poor choice made at the time it was designed. The 65c51 will finish the byte before stopping.

Although we urge anyone doing a new design to use the CMOS 65c02, I know that many are interested in the programmable-logic models, and I don't think there's a 'c02 for those so far. I would like to collect all the differences between the CMOS and NMOS 6502 and put them all in one place on a web page. (See this forum topic.) I have plenty of other things I'm working on, but this one, although on the backburner, is not being pushed off the back of the stove. I would also recommend at least 74HC, if not 74AC, over 74LS. There's really no reason to use LS anymore, except in times you only have the LS on hand and you really want to get the thing going in the next few hours.

Re: Using NMI as a programmer's "panic" switch

Posted: Fri Feb 28, 2014 2:29 pm
by Dr Jefyll
GARTHWILSON wrote:
I don't think there's a 'c02 for [programmable logic] so far
That's what I thought, too, but in another thread MichaelM points out we have at least the following:

(1) M65C02 on GitHUB or M65C02 on OpenCores
(2) cpu65c02_true_cycle on OpenCores

For further reference, see ElEctric_EyE's 6502-Core Comparisons. :)

-- Jeff

Re: Using NMI as a programmer's "panic" switch

Posted: Sun Oct 31, 2021 1:57 pm
by Dr Jefyll
GARTHWILSON wrote:
It sounds like you didn't de-bounce the switch. An RC followed by a Schmitt-trigger gate will do the job.
Yes, there are various ways to debounce a switch. Garth mentioned an RC followed by a Schmitt-trigger, and BDD's Maxim DS1813 suggestion is also good.

As shown below, several other options become available if the switch is a double pole type (ie, equipped with both Normally-Open and Normally-Closed contacts). These options may make better use of available resources (ie; if your project has leftover gates available).

-- Jeff