I worked through this exercise and I found one annoying edge case. Yep, 74x148 is a priority encoder and 74x244 (or more convenient 74x245) will place encoded priority onto a data bus.

I worked out for myself that it would be a good idea to pre-scale the priority encoder such JMP (VECTAB,X) uses even X. Dr Jefyll recommends the same although I did not work out Dr Jefyll's trick of using a larger pre-scale and using the priority encoder as the bottom byte of the vector address itself. That saves quite a few bus cycles but requires additional circuitry to handle the remainder of the vector - and all of the unrelated vectors.

74x148 has a "no selection" output and this is best wired on bit 4 such that nine even values may be produced. (0-16, not 0-14.) This leads to an 18 byte jump table where the last entry is for spurious interrupts or safe exit after all interrupt sources are serviced. It would be preferable if the spurious vector occupied jump table entry zero but this arrangement is sufficient.

I have yet to mention the annoying edge case. An interrupt may occur at any time. In particular, it may occur when the memory location of the priority encoder is read. In the worst case, the three or four signal lines from the priority encoder may be sampled in an inconsistent state. This occurs when the priority encoder transitions at the worst possible moment. At best, this will cause the wrong interrupt service routine to be executed. If the interrupt service routine is not written correctly, erroneous data may be queued - or worse. Furthermore, when the source of IRQ is not cleared, a second pass will be taken through the IRQ vector. This adversely affects the maximum frequency of periodic interrupts and may incur data loss.

In my attempt to resolve this situation, I sketched increasingly complicated circuits. After six chips, I thought that I might have the wrong approach. Indeed, a 74x573 *before* the 74x148 (and tied with the 74x245's output) is sufficient. This ensures that all *inputs* to the 74x148 settle during the read cycle for the priority encoding and guarantees that the multiple signal lines are in a consistent state when the data bus is sampled at the end of the cycle.

The 74x573 should itself be preceded with a network of eight pull-up resistors. Unless you plan to share priority encoded interrupts, this has the advantage that open collector variants of 6522 are immaterial and both variants may be mixed or substituted within one design. Unless there is a particularly clever way of scaling priority encoders, it remains possible to make a tree of interrupt sources with 8-16 fan-out at each branch.

Curious cases remain. A low priority device may interrupt. By the time the priority encoding is read, a higher priority device also wishes to interrupt. In this case, the last device to interrupt is serviced first. IRQs are typically executed sequentially. However, execution order may be significantly jumbled. This may lead to race conditions, priority inversion or resource exhaustion. The easiest way to avoid this is to aggregate or partition system interfaces.

As an example, a system with four UARTs should not place all input interrupts above all output interrupts. A continuous stream of input may exceed available buffers while output is starved. It is preferable to give priority to outputs or aggregate UART interrupt signals into a subordinate priority encoder which only aids the UART interrupt service routine.

Anyhow, four components are required: pull-up resistor network, transparent latch, priority encoder, tri-state buffer. I don't recall anyone getting the edge case correct with discrete logic. This would lead to experimental designs which mostly work but become increasingly unstable as interrupt sources are added. This is rather a shame because the very small number of registers in a 6502 contributes to its exceptionally good interrupt response time and it would be particularly suited to eight or more interrupt sources.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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

GARTHWILSON: You may not have stated such a requirement in one place but I appreciate the very desirable ability of a 2MHz 6502 to handle 48000 periodic interrupts per second. Unfortunately, it is a capability which is easily eroded by software overhead or the bus cycles required to store a larger program counter. The problem can be solved by increasing processor frequency. However, this increases overall energy consumption in addition to other implementation difficulties. Likewise, the drastic move of making a wider data bus has minimal gain unless all pieces of data are bus width aligned. Indeed, this would explain your hesitance with W65C816 and your advocacy of 65Org32.

You may not have set the interrupt criteria with the gravitas that I have accepted. Regardless, it is a question worth answering, partly for personal gratification but also because the current technology stack is a "house of cards" and getting worse. Unfortunately, I'm not the only one snagged with the problem of interrupts. It is a general cross-cutting concern which causes numerous problems. Indeed, if you get something working, add a privilege scheme and see if it still works. The answer is probably not.

Let's not be polite about the matter but the bodged NMI/IRQ/BRK system in 6502 is feature parity with MC6800. I hope that the Transputer fans, such as BigEd and drogon, would agree that a two level priority is preferable, in part because it avoids the rare but annoying case of priority inversion. Admittedly, we must credit to the Gang Of Eight for getting NMI/IRQ/BRK to work first time. With the benefit of 45 years hindsight (and all modern tools), amateurs (in which I include myself) struggle to achieve the same result on any timescale.

For example, MicroCoreLabs has weak implementation around reset and interrupts. randyhyde is silent on the matter. aleferri is similarly snagged with interrupts (although making good progress with this and other problems). Proxy and I share similar doubts. On anycpu.org, similar problems typically occur with unique processor architectures. Most unnervingly, we found that absolutely no-one knows if /ABORT may be used as a general purpose interrupt. Furthermore, Intel and AMD are both re-architecting x86 interrupts in a manner which is mutually incompatible. This leaves me with the concern that I might architect an interrupt methodology which would be considered obsolete by market leaders. Of particular note, I understand that Intel is collapsing previous work into a two level priority scheme.

After reading the forum archive in full (and then posting a bout of duplicate topics before data settled), it occurred to me that making a 6502 or 65816 system was tractable. This has its own gratification but it was not an objective when I joined the 6502 forum. Specifically, I was only interested in extending 6502 bytecode to 64 bit. Regardless, it occurred to me that it might be possible to advance a solution empirically - or at least understand the problem from personal experience. Unfortunately, I have now discovered that the reference material is wrong. Worse, we have multiple silos of expertize where any programmable logic expert could have corrected the discrete implementation if it were not quicker to type the correct solution into a CPLD or FPGA workflow. Indeed, while reading through anycpu.org, I subsequently discovered that the correct "double flop" solution was published on Fri 14 Jun 2019.

Anyhow, interrupts are a tough problem and I still don't have an answer. I have devised numerous schemes in an attempt to answer this problem. Some of them are quite elegant. However, it would be preferable if any of them worked. My favorite is a scheme which divides a 64 bit vector into a 4 bit priority field, a 12 bit core number, 8 bit for bytecode dialect and 40 bit for address with provision to shuffle these fields around by a few bits, if required. Unfortunately, there is no mechanism to queue lower priority interrupts. Meanwhile, allocating one interrupt per core only provides the guarantee that all interrupts run concurrently - which is extremely unhelpful.

A more promising avenue is a duplicate set of vectors for every address-space extension; much like 65816. Unlike 65816, vectors may be selected automatically based upon the top bits of the program counter and therefore execution mode is implicit. This allows a system to retain 6502 cycle count when operating within a 16 bit address-space. Interrupt performance only degrades as usage of the address-space grows. Hypothetically, it is possible to make a faster bus or a wider bus. However, both increase the difficulty of construction and both increase energy consumption. There are also cases where pushing extra data to a wider, unaligned stack obtains no speed advantage. We also have the minor problem that duplicate vectors within the same page break multiple legacy ABIs. Most notably, Commodore and Acorn ABIs are already incompatible with 65816. Compatibility workarounds may be incompatible with further vector extensions. There are further compatibility and performance problems when trying to get 16 bit RTI, 24 bit RTI, 32 bit RTI, 40 bit RTI and suchlike working with a high level language.

As a pragmatic example, audio sampling with 65816 in native mode has worse performance (lower maximum frequency, worse jitter) than 65C02. Whereas 65Org32 - with 32 bit aligned stack - always has better performance.

In an attempt to stay within a 16 bit address-space while minimizing interrupt cycle count, the general case of unlimited interrupt sources may be handled with a tree of priority interrupt encoders. However, after working through the details, designing a module and receiving example units, it occurred to me that CA1, CA2, CB1 and CB2 pins of a 6522 may be used to make a quad-tree of interrupts. This has the advantage of zero external components (beyond any pull-up resistor required for open collector compatibility) while retaining much of the functionality of dedicated circuitry. In this arrangement we have branch and leaf 6522 chips. Shift registers within branches may be unavailable but timers and parallel ports remain available.



Personally, I plan to have:-

• /IRQ connected to one 6522.
• /NMI doorbell tied to privilege bit as operating system entry point.
• /NMI panic switch moved to /ABORT, if possible.
• All further interrupt sources (such as 65SIB or 7SER variants) handled by a tree of 6522 chips.

In this arrangement, any interrupt source (such as subordinate 6522, I2C thermometer alarm or 65SIB peripheral) may be connected to the root 6522.

If anyone wants a priority interrupt encoder module, just ask. However, it appears that the magic of 6522 makes it largely redundant.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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

GARTHWILSON: Oh, good grief! I did not intend negativity about 65816 - only that 65Org32 has superior interrupt performance. As one of the strongest proponents of 65816, I'm surprised that you haven't switched. Assuming that your system doesn't use hooky opcodes, PHI2 out, /SO or the alternate bus phase, the switch should be trivial. Have I wrongly assumed that you were looking to the larger address-space and cycle counts of 65Org32?



My productivity seems like an illusion. I typically post weekly or much less frequently but I think about many topics in between. I also try to make my text flow by reading aloud. At the very least, it fixes some of the punctuation. I'm definitely not the infamous Rantarian who can type thousands of words per hour - on touchscreen!

I will write separately about security otherwise BigEd will quietly harrumph that another discussion has wandered off-topic.

Regarding ABORT, it appears to work perfectly in its intended form. However, I may assert ABORT during IRQ or NMI cycles. Does interrupt stack write or vector read get ignored or aborted? Unknown.

Regarding interrupts in general, they should work flawlessly between peripheral and processor. Designing a CPU's interrupt hardware is troublesome. Designing a larger CPU with the same interrupt performance is more troublesome.



I initially considered LDA STAT_REG // AND #%00011011 // ASL // TAX // JMP (VEC_TAB,X) or similar. Unfortunately, this may require dynamically populating multiple entries in VEC_TAB. VEC_TAB also has a gap. It may be preferable to implement priority encoding and shifting with a 256 byte table. For example, LDX STAT_REG // LDA PRI_TAB,X // TAX // JMP (VEC_TAB,X). This only services one interrupt source per invocation, is slightly slower than a hardware priority encoder, has less fan-in than a hardware priority encoder and is less flexible than selectively installing interrupt handlers in frequency order. However, the long PRI_TAB replaces one or more *sets* of discrete chips (which are often implemented wrongly) and the short VEC_TAB has no gaps or duplicates.

For ad hoc applications, an installer remains preferable. For five or more heavy, fixed interrupt sources, a tree of 6522 interrupts may be preferable. For six or more frequent interrupt sources, hardware encoding is fastest. However, these techniques are not mutually exclusive. Therefore, it is possible to have an interrupt installer before a hardware encoder of 6522 quad-trees. That would allow audio sampling ahead of 40 or more interrupt sources while only using one 74x148 and associated components.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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