6502.org

UPDATE:

OK, so just a brief recap. I will have two VIA's, one ACIA, one TMS9918 and FOUR slots that could cause an interrupt.

One of the VIA's is wired to /NMI because it will drive the PS/2 keyboard and SD Card. I figure keyboard input should at least always have priority to allow to (possibly) recover from a crash, etc.

So that leaves 7 IRQ devices. My target speed is between 1 - 4MHz tops. I don't think the TMS chip can handle much greater than 2MHz without wait-states. Which made me think that I might want to arrange everything like the picture below.

I assumed anything approaching 2-3MHz should probably use a totem-pole arrangement but I'm not 100% on that. However, it also bothers me a little that only one device is really using that totem-pole arrangement! In fact, /VIA2_IRQ is mostly to drive audio chips and joysticks.

So I think this is a wasted effort to go totem-pole unless you guys think differently. I've already got 19 chips on this design! It's going to be a big board.

At the end of the day, I will still be happy to restrict the machine to 1-2MHz tops. I guess my question now is, is it worth the effort to use totem-pole like I am doing?

Thanks again!

Remember that the NMI input is Edge triggered - and the VIA flags interrupts from multiple sources by keeping it's IRQ output low, so you'll only see one interrupt to the 6502, so the NMI handler will need to poll the VIA at some point if you are expecting interrupts from more than one source on that particular VIA.

-Gordon

Thanks to both of you for your response.

Actually, I think I misspoke. My intention was to only have one true /NMI and the idea was to tie it to a keyboard. But the more I think about that, the more it doesn't really make sense. I was thinking you could press some keyboard sequence (much like the RESTORE key on C64) to interrupt just about anything and return to BASIC. I think it does make more sense to tie it to a "monitor" button. So pressing it would load a system monitor or something similar. I'll see about going with that.

This is my most ambitious project to date. My third SBC and the goal is to pay homage to the computers I most adore. C64, VIC-20, Apple II, TI-99/4A, etc. I think most of the design is nearly complete. I'm finishing up the smaller details like the IRQ, etc.

It will have: TWO VIA's, 6551 UART, MAX238, TMS9918, two AY-3-8912 audio chips, 32KiB RAM (minus I/O), 32KiB ROM, 32KiB video RAM (two banks controlled by VIA) and a couple handful's of glue logic (the TMS9918 takes a lot of glue) and SD Card (using Ada Fruit breakout board).
YES! This is what's holding me up at the moment. I'm re-reading through the primer, etc. I'm studying other designs too. But I'm always interested in a concrete example that uses all these interrupts.

As for priorities, the top priority will always be VDP. There are timing things I want to do at the end of the vertical blank and need to make sure it takes priority. Second would be UART.

Thanks for all the input!

Maybe. Maybe not.
It's true that having lots of interrupt sources will mean "more" cycles spent figuring out who's interrupting, but you need to ask, is "more" enough to matter? How many times per second will we have to figure this out? That'll depend on the devices. The keyboard, for example, interrupts so infrequently as to hardly matter.

So, what are the tradeoffs between the two options? A priority encoder makes sense if maximum speed really is crucial, and you don't mind adding extra hardware to the design. But in other circumstances it'll be better to solve the problem in software. Even if you do end up consuming a lot of cycles, that may still be a perfectly valid choice.

-- Jeff

Also in addition to this - if you can achieve "work" during the interrupt, then it's never wasted cycles. My favourite 6502 machine, the BBC Micro had a 100Hz interrupt tick and during that, it did a lot - poll the keyboard, run the sound system and several other tasks. Other peripherals like the serial port had their own interrupt code and at the end of the interrupt, if it wasn't "serviced" then it did a JMP (foo) to carry on with user-provided IRQ handlers. This managed extra peripherals that may be plugged into the "1Mhz" bus (a daisy chainable cpu level bus), the user port (half a VIA) or anything else. (The disk system used NMI)

So it was never wasted as it was all there for good reasons.

My Ruby 816 system has a 1000Hz interrupt and one thing that does is blink a 'heartbeat LED' using a balanced PWM to give it 2 pulses a second that fade in/out (quickly, as 2 a second) That serves no real purpose at the end if the day but it's pretty.

As an experiment, calculating Pi to 200 places - so pure compute:
Turn off the LED heartbeat and run it again:
So I "waste" 97mS in about 23 seconds which is less than 0.2%. I can live with that for a pretty LED.

-Gordon

It takes about 7mS on my i5 Linux desktop. It's written in BCPL - the compiler compiles itself in under a second on my Linux desktop. The CINTCODE (target VM for the BCPL compiler) is somewhat inefficient and written in C under Linux. It's pure 816 on Ruby.

It's not my code - came with the BCPL distribution and it's known as "Machin's Formula"

Code here:

https://unicorn.drogon.net/pi.b.txt

-Gordon

It's not a bad idea, and I can see how it'd improve matters. Just reminding everyone that this example of a status byte is one that's not encoded, and a priority encoder is a different animal. (Edit: the PIC you mention is a related subject.)

The status byte lets you query all device bits with just a single LDA (or LDX or LDY, perhaps); also you can query one or more individual bits with just a single BIT or similar instruction. But the status byte doesn't instantly tell you which among all the requesting devices has highest priority. In contrast, a 74xx540 delivering the output of an 'HC148 will let you do this !'HC148 datasheet attached below. I don't necessarily advocate this level of fanciness. I'm just scoping out the available tradeoffs. (Even fancier would be to use the CPU's VPB output to gate the '148 -> '540 onto the bus. That's simplifying slightly. But it would eliminate even the two instructions just listed. )
I agree we should give high priority to the UART, but not so much when it comes to the jiffy IRQ. Its interrupts are comparatively infrequent; also, I don't quite get your point about their periodic nature having a bearing.
Certainly for some projects this mantra is valid, but it would be a mistake to accept it generally as some kind of guiding principle or golden rule. Likewise we know totem-pole IRQs plus an AND will be less constraining in some ways than the Open Collector approach, but the latter uses less hardware. For Cecil's application I wouldn't summarily dismiss the Open Collector option. There are one or two points in the ISR that'd need careful attention, but attending to those might be more fun and educational than accommodating the totem-pole and the AND. It depends how he enjoys spending his time.

-- Jeff

I've got Thoroughbred's Dictionary-IV (very powerful timesharing form of business BASIC) development software on my server. I'm curious to see how well it can do the computation.

My bad. I should've made clear that Cecil's project is among those -- the majority -- for which the "protect the foreground" principle does apply. But exceptions exist. I recall one project where the only context that mattered at all was the ISR, and I allowed it to be lengthy. And why not! Everything else, including the foreground task, could take a rain cheque. Regarding "protect the foreground" and other points mentioned, what I'm stressing is that goals and circumstances vary widely from one project to the next. The shrewdest approach is one that's always appraising the tradeoffs -- perhaps unexpected -- which prevailing conditions allow.
Yes, and even just an (E)EPROM will suffice if it contains an appropriate table. The various interrupt sources would be synchronized by a register if necessary then fed to the (E)EPROM address inputs. And (E)EPROM outputs are a full 8 bits and can tri-state, unlike those of the 'HC148.


By the way, you don't need a priority encoder to pull off the snappy little dispatch snippet I posted. Even an unencoded status byte will work.Notice I went down to only 7 bits, and the size of the Vector Table is 256 bytes (128 16-bit enrries). To reduce that, it may be desirable to use even fewer bits, as follows.

In the following example I'll assume we have many interrupt sources, but only two that are critical. ("Critical" could mean high volume and/or sensitive to latency.)Now the vector table has only four 16-bit entries. It will tell you where to immediately go if CriticalSource_A is active, if CriticalSource_B is active, or both A and B are active. For the fourth case -- ie, neither A nor B -- the Vector Table sends us to an unexciting routine that polls the remaining sources. So it's a hybrid approach.

We're spending some memory to support this, and the amount doubles for every additional input to the lookup. A priority encoder doesn't need the lookup at all. But with a priority encoder it's the input wiring which determines the various priorities. If you move that decision to a lookup table in RAM you can shuffle the priorities at will, even on the fly -- a powerful advantage in some scenarios.

-- Jeff

Thanks everyone for such great information and comments.

For the record, this whole project is educational for me. With the added benefit of (hopefully) creating a computer I wanted back in 1980. Other than a few modern conveniences (like SRAM, SD and EEPROM), this computer could have been built in 1980 (albeit expensive).

Anyway, nothing is really set in stone at the moment. My schematics are 90% done. And you know the last 10% is always the hardest. For example, I have two VIA's. Well, even after adding an SD card, TWO audio chips, etc. I have a few pins left over for the VIA's that I'm struggling to find something to use them for. Mainly pins like CB1/2, etc.

So then I noticed...that one of my VIA's is mostly devoted to audio. So why do I need an IRQ on it at all? I guess because I hate leaving any pin unused.

I may start a separate topic on "what to do with unused pins?". LOL

Example of my VIA setup below:

Back to the topic on hand...if I decide to ignore this VIA's IRQ...I would then only have one VIA (keyboard, user port and SD card) a VDP (IRQ ever 1/60th of a second for raster interrupts) a UART and expansion slots.

So I guess I am wondering...is it bad practice to just simply ignore IRQ pins if I can't find a legit reason to use them?
I think I like the idea of having a "heartbeat" that occurs X times per second. That could then maybe read from RAM for the audio. Maybe handle the SD card, etc.

Hmm, if you have a VIA and don't connect the IRQ up, you're certainly losing out on some future possibilities. It seems like it shouldn't cost much to add it. (I wouldn't always be in favour of adding things just because you can.)