I have two VIA's and one UART (65c51).
One thing I would like to do is have some jumpers on the board so that you can pick which IC connects to the 65C22's /IRQ and which connects to /NMI. Which would leave the third floating.

If you look at the attached image, you can see that you cannot attach two devices to the /IRQ and you cannot attach two devices to the /NMI. However, you CAN attach the same device to both /IRQ and /NMI. Which would not be desired but I don't think it would damage anything, would it?

Obviously, if there is a better solution I am all ears. One of my VIA's is completely open (both ports are user ports) but the other VIA is connected to a PS/2 keyboard. And of course, the UART is driving the serial connection.

On a side note, I'm only thinking about this because I'm not quite sure where the /NMI should be attached. Since my design involves heavy use of a PS/2 keyboard, I thought about just making that VIA tied to /NMI so it would always process key presses. But I'm not sure how that would work. I saw a design where the guy put the PS/2 clock directly on the /NMI but I'm not sure I want the CPU stopping every few KHz.

Thanks for any suggestions.

_________________
Cat; the other white meat.

NMI is a get out of jail free card... because you can't disable it, it's always going to respond to a negative going edge (IRQ is level sensitive and requires something to remove the IRQ before the handler finishes, or it will trigger again after the RTI). Which means that in a situation where you want something to which an otherwise unresponsive system to respond, NMI is the way to go.

And generally, that input might be caused by a keystroke. So it's not a _bad_ idea to hang the PS/2 clock signal (negative going!) onto NMI to start/continue clocking PS/2 data into keycodes. However, there's a but (there's always a but). As I and others have discovered, a naive implementation of the protocol can be confused by random data glitches, and get stuck in a continuous loop outputting incorrect keycodes, with no way out.

One way to avoid that is to reset the bit counter if there is too long a delay between pulses (which detects the case where a random bit has started the detection, ten further bits have been received to decode into a false keycode, and a left-over bit has started the next keycode and is waiting hopelessly for more bits), but that generally requires some sort of external free-running timer - perhaps in a VIA.

I think the only issue with your proposed design is, as you observe, the possibility of connecting IRQ and NMI together. That's not a good idea because it will trigger both interrupts, but as it's a hardware link that allows it, it's easy to avoid. But (another but!) a change to software may require a commensurate change to the link; that might be a pain.

Have you considered alternative approaches? All the chips you want to attach to an interrupt have internal registers which you'll likely have to read anyway; if you AND their interrupt outputs together (so the output goes low when an interrupt occurs) you can then easily enquire which chip caused it, and that allows you to tie any number of chips to a single IRQ input (at the expense of a slightly more complex interrupt handler) and allow interrupts from any of them, without requiring any hard links.

Neil

You can also basically use the VIAs as a programmable PIC if you attach things to the 4 peripheral control lines; or add a 74xx148 if you need loads of devices.



Someone here recommended to me hanging a single denounced switch off of NMI to use as a debugging "break" signal. Or if you're really fancy, and if your PS/2 is being handled outside of the CPU in hardware, you could make it drive the /NMI when it sees the user press the magic Ctrl+Break combo key on the keyboard.

Hello cbmeeks,

TIPP: Maybe you can feed the VIA output signals through gates (made of discrete parts, M²L = Mickey Mouse Logic) with open collectors towards the UART ? That way selection might become a question of programming the VIA's.

_________________
Gr tings, Louis

May your wires be long and your nerves be strong !

Thanks everyone for the suggestions!

I'm going to have a re-think about this and the more I read about it, the more I like the idea of a debounced button for /NMI. Mainly because I totally expect to have buggy code for a while. lol

Then, it would be a matter of simply choosing if a VIA or UART is tied to the /IRQ.

Thanks!

_________________
Cat; the other white meat.

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

Thanks for the information.

After thinking about this last night and today, I think I'm going to just have a jumper to decide which VIA (or serial) would have the /IRQ. As for the debounce, I thought I would just use an ATMEGA328P as I have a little board space and the ATMEGA can do several things.

1) Debounce the reset button
2) Debounce the /NMI button
3) Provide power-on reset
4) Perform reset from button push.

The cost of a DS1318 (or whatever it is) is insane. I really wanted the power on reset which it provides but I think the ATMEGA could double-duty for a lot of that stuff.

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

The ATMEL uC could also provide a 1, 2, 4, or 8 MHz clock. I've used a $2 Nano clone to implement a full-featured ROM Emulator on recent SBC designs (with 'free' built-in EEPROM & Flash ROM programmer). Here's a Ben Eater compatible 8-MHz prototype I just started building up (NO PROGRAMMER REQUIRED);

That looks great!

I think I asked this before, but what do you use to make those graphics? I really like that look.

As for me, well, I have two different designs going. One is more "old school" but using some modern parts. The other is more focused on SMD and uses a couple Pico's for video, etc.

I'm almost to the point where I will start routing this design. I've always wanted a KIM-1 inspired board but using a large LCD and a PS/2 keyboard.

Thanks

_________________
Cat; the other white meat.

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