Garth wrote the following here:

Do I only need to AND the /IRQ lines from the VIAs or should I AND all /IRQ lines? (I don't plan on anything more than 2MHz if it matters).

_________________
- Billy

What matters is that you not connect totem-pole outputs together such that one is trying to pull down while another one is trying to pull up. The W65C22S has totem-pole IRQ\ and NMI\ outputs for the purpose of making it so the so the output can get yanked back up more quickly when the interrupt condition is cleared, rather than floating up slowly by way of a pull-up resistor. The behavior of this design however requires the AND gate even if you're using a slow clock rate, so the IRQ\ outputs don't fight each other and cause heating, invalid output levels, and other problems. If you have some totem-pole IRQ\ outputs and some open-drain outputs, connect them as I show in this diagram in the interrupts primer.

_________________
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?

Ok, thanks!

_________________
- Billy

Another way to connect the /IRQ output of the W65C22S (the version with a totem-pole output) to the IRQB input of the 65C02 is through a small Schottky diode, with the anode attached to IRQB on the MPU. You can connect any number of W65C22Ses that way if each has its own diode. The IRQ outputs of open drain devices would continue to be directly connected to IRQB on the MPU, as would the pull-up resistor. This method would be most practical if there were more than three of the W65C22S in the circuit, as the number of required inputs on the AND gate would start to become unwieldy.

Assuming you use the AND gate method to drive IRQB, be sure to tie unused gate inputs to Vcc. If you forget to do this and leave one floating, it may pick up noise and generate spurious interrupts. Similarly, if you mistakenly connect one of the AND gate inputs to ground, IRQB will be continuously held low and the MPU will get stuck in an interrupt loop from which there will be no escape.

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

BDD,

Is this diagram correct? (Please excuse the drawing, I am on my Chromebook)

I think I will use this as opposed to the 74HC08 as it takes up less space (and the symbol for the Schottky diode looks cool ).

_________________
- Billy

That'll work.

_________________
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?

I am finishing up on my preliminary design but I wanted to ask a few more questions regarding interrupts.

1. What exactly does the /VP or VPB pin do? Can I use it to tell where an interrupt came from (if I only have 2 chips)?
2. If I am planning on using my VIA(s) for GPIO does it make sense to even connect their /IRQ pins?
3. In my current design I don't have anything connected to /NMI, instead it is pulled through a 3.3K resistor to +5v. Is this okay?

Thanks to all of you for your valuable time! I should have a schematic done soon (which I'm sure I will have tons of fun debugging).

_________________
- Billy

#1: I have never used it, so I can't really comment beyond what's in the data sheet. I'll leave that to BDD or someone else.
#2: Absolutely. You'll want it for the timers too, not just I/O. Leaving the IRQ\ connections out will cramp your possibilities later.
#3: Yes; but why not have pin headers with removable shorting bars to select whether to have a given IC's interrupt output to go to IRQ\ or NMI\.

_________________
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?

I'll connect the /IRQ pin of each interface IC to a header to select between /IRQ and /NMI on the processor (if I am correct, the Schottky diode for the VIA will need to go before the header to allow for multiple devices to be connected to /NMI without burning out the VIA).

_________________
- Billy

It can safely be left unconnected, which is what almost everybody does. The usual way to tell where an interrupt came from is to begin the Interrupt Service Routine with a handful of instructions that interrogate the status registers of whatever peripheral chips might've caused the interrupt. The code then branches accordingly. /VP is for an optional hardware enhancement that makes the branch happen automatically, without any extra code.

That's right. Have fun!

-- Jeff

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

I assumed that I could use it to easily tell if the interrupt came from a specific chip and was hoping that I could use it to branch my interrupt code as soon as possible based on if the interrupt came from the serial bus (ACIA) or not. Too bad the datasheet doesn't really have any information other than:
Which doesn't really glean any useful information. So it looks like I'll just leave it as NC.

_________________
- Billy

I think the data sheet gives the needed info, but relies on your resourceful design thought process for how to implement it. The various interrupt sources could go to a CPLD which would have the logic to respond to the vector addresses (it would have to look at all 16 bits) and put the right ISR address on the data bus. Most I/O ICs still have several possible interrupt sources though, so in many cases, even if you know which IC caused the interrupt, you will still have to examamine its status register to see which source caused that IC to generate the interrupt, if indeed you had more than one enabled.


Jeff is of course right; but I'll go on. I put this in the 6502 interrupts primer, but I'll repeat it here. I have seen many ISR examples in the books that are much, much longer than necessary, polling every single possible interrupt source ever, even though in most cases you won't have more than a couple of them enabled. There is no sense in wasting time polling for interrupt sources you have not enabled. If you have four ICs that could generate interrupts, and only two sources enabled, there will be at least two ICs your ISR doesn't need to poll, and maybe three. Of the one or two left, poll only the status bits corresponding to the interrupts you have enabled.

Also, with the exception of that first 6502 class I took in 1982, I have never used BRK; so there's no sense in wasting my processor time examining the B bit. (This is discussed in the interrupts primer too.)

_________________
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?

If you have one high priority device that you really care about servicing quickly, that's what NMI is for. Acorn's Beeb uses NMI for the (optional) floppy disk controller - there are very few ticks available to service incoming bytes from floppy.

For serial, even at 115200 baud you have 86 ticks to deal with each byte (or more if you're running faster than 1MHz) so IRQ is probably good enough. The usual approach is for the interrupt service routine to check the most urgent chip first - for example, check the serial chip before the timer chip, if you think you might otherwise miss bytes. Or, if you're running a high speed timer for some critical reason, check the timer chip first.

VPB is one of those signals that a first-time builder should not be considering. As Jeff suggested, ignore it for now. That said, I'll explain how it could be used.

When a hardware interrupt occurs or a BRK instruction is executed, the MPU executes a series of steps to save its state on the stack and then jumps to the interrupt service handler (ISR) code. The jump occurs by loading the program counter from a location in memory that points to the ISR that is expected to process the interrupt. As there are several interrupt types, there are several addresses involved, which are collectively referred to as the interrupt vectors. On the 65C02 or the 65C816 when operating in 65C02 emulation mode, the vectors are as follows:

Code:

$FFFA/$FFFB  non-maskable interrupt (NMI)
$FFFC/$FFFD  hardware reset
$FFFE/$FFFF  interrupt request (IRQ)

The addresses stored at these vectors are often burned into ROM, but in a unit whose operating system runs from RAM, the vectors will likewise be in RAM and could be changed. However, it gets even more interesting.

A system could be designed to prioritize IRQs, which means it would have hardware logic that can identify each interrupting device and assign it an ordinal number (interrupt number). A pecking order can be established based upon the interrupt number, making some interrupts more important than others. Nowadays, this function would be part of the glue logic in a CPLD or FPGA, but in the past was done with discrete devices. In either case, the glue logic, upon detecting an IRQ and determining which device caused it, could trick the MPU into jumping directly to the ISR for the interrupting device, eliminating the need to check all devices to see which one is interrupting. The result would be improved interrupt processing performance.

The trickery comes in two parts:

1. The glue logic does nothing until the MPU asserts the VPB output, that is, pulls it low. When VPB goes low it means the MPU is fetching from the interrupt vector. It does this by performing consecutive reads from the least significant byte (LSB) at the vector address (at $FFFE in the case of an IRQ) and then the most significant byte (MSB) at the vector address (at $FFFF in the case of an IRQ). The address bytes are internally loaded by the MPU into the program counter (PC).
   
   
2. The glue logic, in response to VPB going low, prevents ROM or RAM from actually driving the data bus and instead, takes control and places an alternate ISR address on it, first the LSB and then the MSB. That address is determined by the glue logic analyzing the interrupt number that it generated when a device interrupted. The MPU is none the wiser that the glue logic is talking to it and loads the alternate address into PC instead of the address at $FFFE/$FFFF. Hence execution is directed to the ISR associated with the interrupting device.

The logic to do all this is not particularly simple to implement, which is why it is something best left for a future project.

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

Hopefully I can keep my ISR simple. I am tempted to load the ISR into RAM and prompt the user as to what interrupts should be enabled / disabled (to reduce the effective size of the ISR) but that may be more trouble than it's worth.

_________________
- Billy