6502.org

Hi all
I've designed a circuit to allow an interrupt to be generated (via a latch) by pressing a push button
and then the /IRQ signal is cleared by writing to a particular address. (the 'clear interrupt pin address' if you like)
I'd welcome any comments as I would like to add it to a 6502 single board computer which I made.
Attached is a schematic and a description follows:

I've put active low signals prefixed with a slash e.g. /IRQ for the active low interrupt request.

Starting with IC5, this is a D-latch which latches the /IRQ after the push button is pressed. (R1 is just to have a pull-up rather than
directly tying signals to 5v)

The D input is permanently high as is the /preset input. The /preset input is permanently inactive (unused).
The AND gate IC4 ensures that IC5's Q output is LOW and therefore /Q is HIGH (i.e the latch is reset when the 6502 is reset.)
Therefore the /IRQ output will be high (inactive) after 6502 is reset. If the pushbutton is pressed, IC5 is clocked (maybe a few times due to bounce), and the latch is then set - the Q output goes HIGH.
Therefore the /Q output goes low and the /IRQ output connected to this output now goes low.

Assuming the 6502 is correctly programmed to handle the interrupt, the ISR fires and in this ISR the code will then
be programmed to write to the address which is decoded in the schematic (the 'clear interrupt pin address' indicated by /Addr)
This asserts /Addr in the schematic, thus causing the input to inverter IC1 to go LOW.

When Phi2 goes HIGH, IC2 output will go LOW.
With the R/W signal LOW (i.e. write cycle) IC3 output will now go low, resetting the latch IC5, the the (IRQ) is not HIGH (deasserted).
when Phi2 goes LOW and the end of the cycle, IC3 output goes HIGH and IC4 output goes HIGH, so a pulse was generated to clear the latch (IC5)
and deasserting the /IRQ

Data for this write operation is ignored.

Some debounce may be needed - perhaps with a delay
Comments welcome
Regards
Russell

Debouncing is always necessary for pushbuttons. If you want the interrupt, how about using a 6522 VIA's CA1, CA2, CB1, or CB2 as an interrupt-on-change input? You could run it to another I/O pin also so you can read the level (not just the edge) and see when it's ok to re-enable the interrupt. Assuming you have one or more VIAs available anyway, this would let you accomplish the purpose with no additional hardware, and you can do the debouncing in software.

Hi, thanks for reply. That would probably be easiest. I was trying to avoid adding a 6522 (already have an 8255 for the I/O).
It's a bit of an experiment. Maybe will add a 6522 (or 6532) later.
Russell

I don't think that the circuit will work the the way you think its will. Unless you are expecting a very long interrupt response time and you need to latch the event, the circuit is pretty much redundant.

The keypress will be latched and the interrupt asserted as you expect, however, the response and subsequent program code will not be assisted much by the circuit. As pointed out above, you will require delays to prevent multiple interrupts. Those delays will require the masking interrupt until the whole sequence is complete.

Once the key is pressed and the interrupt asserted, the interrupt handler then does whatever it needs to (the response to keypress) but must not clear the interrupt (via your circuit) and re-enable interrupts because that will simply retrigger the interrupt while the key is still bouncing. Remember the the CPU is much faster than you think.

Once the interrupt is responded to, and whatever the response is, is completed, you will have to complete the debounce delay before clearing the interrupt (probably a few/10s milliseconds). Of course now you have to somehow sense the key release. The key release will probably also trigger the interrupt since the key release is also not-clean.

To make matter more complicated, the IRQ on the 6502 is level sensitive, so enabling interrupts before the latch is reset will trigger another interrupt in the CPU.

You have no way of directly sensing the state of the key since you can only detect the change. Keeping track of the state from reset (you do at least clear the latch on reset) will eventually fail.

It may be better to use some other means to read the switch directly via whatever I/O device you choose. Periodic scanning is often simpler and more predictable in behavior than interrupts. Use interrupts when response speed is important. Entering and leaving interrupt handlers (state preservation and recovery) is often more involved/longer than expected.

Hi - thanks yes, all noted. I'm looking to experiment with external interrupts, but I suppose a manual pushbutton is not the best idea, because of the required delays in processing to overcome debouncing.

(On the topic of debouncing, I'm fairly sure there's no need to introduce a delay. The crucial observation is that the first closing of the switch (after some period of being open) is definitive, and can be acted on. But by the same token, the first opening of the switch can't be registered until it has been closed for some short while.)

Russell, I think your approach is sound except for the lack of debouncing. I've edited your diagram to show some remedies. Version (a) relies on a RC delay followed by a Schmitt trigger (to produce a distinct transition) then another inverter. The second inverter could be omitted if the pushbutton pulled to ground and R2 pulled to +5 instead of the other way around. Versions (b) and (c) take another approach. No Schmitt is required and no delay is introduced, but the first "bounce" of the button is the only one that matters; those that follow have no effect. These versions requires a SPDT pushbutton (not SPST). Not sure why you've included this. I guess maybe a resistor used to be recommended for older TTL logic families but tying directly to +5 is perfectly alright with modern HC and other CMOS families. The only other reason to have a resistor there is to make it easy to pull /PRE low for test/debug purposes.

-- Jeff

Welcome, rodders!
Bouncing and (de-bouncing) are certainly highly pertinent! But can you explain your other point (below)?
I'm not sure I see what the problem is. Doesn't your objection disappear once the debounce issue is solved?

Cheers, and thanks for posting.

-- Jeff

Thanks all for the replies and the ideas. The Schmitt Trigger is a nice idea.

Jeff:
My concern with with the original circuit is that there is no way of differentiating between a press and a release if the key bounces on either action. I can't recall if there is any simple means of checking the IRQ line without actually triggering an interrupt.

The program could keep track of the toggling state, but all you need is one of:
a clean release that doesn't set the flip-flop and there won't be a key release interrupt,
a brief press that is less than the de-bounce delay so there won't be a key release interrupt,
a lot of bounce (bad press by operator) so the flip-flop is still being clocked after the de-bounce
and you've lost track.

Thanks all for the replies and ideas. I tried my circuit and it works with a few bounces which is expected.
I'll probably drive the IRQ line with a 555 at a few Hz. The main thing is a bit of learning as I hadn't played with 502 interrupts before.
cheers
Russell

You said you had an 8255. I had to look it up, as I was not familiar with it. I was surprised it doesn't even have any timers. I would encourage you to use something like a 6522 VIA instead (or in addition), which is far more capable partly because it has two timer/counters onboard with multiple modes of operation. It's bigger than the 555 of course, but does not need the supporting parts, and is fully programmable in software, unlike the 555, and can be used for lots of things at once.


The 6502 has really outstanding interrupt performance, way better than that of other processors of its day, something that's very important in my uses.