You can always add a 3-pin jumper for all IRQ outputs from the various devices (VIA, UART, etc.) and have the luxury of connecting to IRQ or NMI or just leave the jumper off. Same can be said for a 2-pin jumper, connect to IRQ or not.

Also, when you're considering software, note that the BRK vector is shared with the IRQ vector, so you might want to add some header code at that vector to determine which happened: an actual IRQ or the BRK instruction. I use a short piece of code in the ROM for that... and also for the exit routine via an RTI. The old Vic-20 used a similar routine, albeit had to move the index registers to the accumulator to push on the stack (and inverse when pulling from the stack), so that added more clock cycles and memory to the routines.



It's a small amount of overhead, but if you're running a 4MHz CPU clock, simply polling each IRQ capable device won't take very long. Note: the number in parenthesis is the number of clock cycles for each instruction. A branch instruction is 2 cycles if not taken and 3 cycles if taken. For the IRQ vector, the branch is not taken, which saves 1 clock cycle. I keep a vector table on page $03 ($0300) for entry and exit of IRQ, NMI and BRK vectors. I also defined 8 spare vectors so you can add hardware/software and insert pre- or post- the existing routines.

_________________
Regards, KM
https://github.com/floobydust

And even if using the VIA but not needing interrupts you don't need to enable them in the VIA.

Also:



Thinking about this - Yes, my Ruby board "wastes" 0.2% cpu cycles on a pretty (for me) heartbeat LED, but again, I go back to what I consider to be the pinnacle of 6502 systems in the early 80's; the BBC Micro.... And in this case, the sound chip.

The sound chip is not anything special or clever. simple 3 channels of square wave plus a channel of noise. You could vary the pitch and amplitude and was often compared (usually badly) to the SID chip in the C64 which was much more capable, however... The clever part was the 100Hz software interrupt which was the central ticker in the Beeb - the sound system has a programmable pitch and amplitude envelope and channel synchronisation commands. The magic happened on the 100Hz interrupt with the OS updating the amplitude and pitch 100 times per second for each channel. So there is plenty of scope for substituting hardware for software when you need things to change regularly - like an old sound chip hung off a VIA port. (the BBC Micro had a "slow bus" which was essentially driven off a VIA and interfaced to several chips including the speech chip (and ROM), sound chip and the keyboard.

Studying the schematic of the BBC Micro might give you some ideas too. See e.g. here: http://www.8bs.com/boards/BBCBschematicJTribbeck.png

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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

Hello everyone! It's been a while since I've been on this project.

So I have decided to ramp some stuff down. I've dropped three expansion slots so that I now just have one.
My total number of devices that generate interrupts is now FIVE.

In order of priority (most to least):
VDP
UART
VIA1
VIA2
Expansion Port

This brings up a problem. I'm looking at using a totem pole setup and having each device go into an AND gate. They don't make 5 input AND's. The closest for a single chip is 8 inputs. Which is the SN74HC08AN.

However, I'm not sure if using HC components is what I want to use. I still get confused on when it's safe to mix types.

Worse case, I can drop one of the VIA's. I was just keeping it on there so that I could use it as a timer.

The big components I'm using are the TMS9918 (NMOS), 6551 (probably use NMOS to avoid that bug) and the two VIA's. Plus whatever could be plugged into the expansion.

Do any of you see an issue running with that particular chip? (SN74HC08AN)

My max speed would be 2 Mhz. with maybe seeing if I could push to 3 or 4 MHz. But 2 Mhz is my target.

Thanks for any tips.

_________________
Cat; the other white meat.

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

Yes 74HC will be fine. And, 8 inputs, yes -- but that's in four separate gates of two inputs each. It doesn't mean you'd get 8 interrupt inputs.

In a case like this you'd be OK cascading the gates, which at best would allow as many as 5 interrupt inputs (as shown below). But it's possible to do better. For example, cascading an 'HC11 triple 3-input AND would allow up to 7 interrupt inputs.

-- Jeff

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

That is, in fact, exactly how the RESTORE key on the C64 works. That "key" is not part of the regular key matrix (and not scanned) but is a momentary switch with its own separate output that is debounced before being fed directly to the NMI line. (The NMI routine does something along the lines of reinitializing the I/O and then checking to see if the STOP key is also currently pressed, indicating it should restart BASIC at the input routine as well.)

I've attached below the diagrams from the C64 service manual showing the keyboard matrix side and block diagram (the vertical line at "RESTORE" is connected to ground above) and the circuit on the motherboard that debounces the switch (the /NMI line has a 3k3 pullup on it that's not on this fragment of the schematic). You might be able to get away with something simpler from Garth's reset circuits page, but at least some of the Commodore designers—Bil Herd for certain—were firm believers that a 555 or similar one-shot was absolutely necessary for reliable resets and NMIs. (If you're uncertain about your choice of circuit, you could use their technique of producing ten thousand machines and testing each one.)

Using NMI as a "soft reset" to recover from programming errors or similar seems to be a fairly common technique. As well as being used on Commodore machines and BDD's boards, it's also used in my (6800-based) National/Panasonic JR-200: the "BREAK" key on that keyboard is part of the regular keyboard matrix, but that matrix is scanned by a microcontroller that generates a separate NMI output when that key is pressed, rather than putting the key code into a register as it does with all the other keys. I seem to recall that the KIM also had NMI on a debounced switch.

The Apple II used RESET instead for this, freeing NMI for other purposes. To determine whether a reset was a cold or warm start it had a checksum for a vector in the zero page, using that if the checksum was ok or doing a complete machine initialization if it was not. The downside of this technique is that unlike an NMI you don't get the previous program counter and flags pushed on to the stack, which you might want if you're interrupting running code in order to debug it.

_________________
Curt J. Sampson - github.com/0cjs

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

The BBC Micro also uses RESET (and a 555 timer) for this. It has a different way to detect a power-on reset though - one of its VIAs has its reset pin driven by an RC circuit, instead of the shared reset line used by everything else, so soft resets don't affect this VIA. It then reads the interrupt enable register as a kind of flag to detect a hard reset - I guess there's never normally a time when all interrupt sources are disabled.

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

That's really clever! I wished I had known that back then. The best I did was:



lol

Thanks everyone for the suggestions. I've convinced myself to use /NMI for a "hardware abort" or debug switch. But instead of using a 555, I thought I would use a DS1813 instead. Which are a little pricey but saves board space.

_________________
Cat; the other white meat.

I see DS1813 being mentioned several times and looked it up. Far as I can tell, it is same as the 50-cent MCP130 that I use in about every board design except it is 5 times more expensive. So why DS1813?
Bill

Well, for what it's worth, the DS1813 also provides for a manual reset switch. It's simply wired from the reset output to ground. When pressed and released, the DS1813 performs the hold time again, same as power on.

According to the MCP130 datasheet, this is not the case. Perhaps it also provides a reset timer when using a switch the same way, but I don't know.

_________________
Regards, KM
https://github.com/floobydust

Ah, that is a difference between mcp130 and ds1813. It is possible to add reset push botton to mcp130's reset (it is open drain with internal 5k pull up), but the reset is not stretched for the nominal 250ms, it is not debounced, in fact. To generate manual reset that stretches for the nominal 250ms, the reset button should connect to the VCC terminal of mcp130 and the VCC terminal should connect to 5V supply through a 1K or so current limiting resistor.
Bill

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