Interrupts with 65c22

[Dan Moos]

Can I cause a 65c22 to send a interrupt just by writing to its registers?

I have all the interrupt enable set to 1s. If I try to write all ones to the flag register, nothing happens. Also, if I read the flag register afterwards, all bits are 0s.

I don't have a need to generate interrupts this way. I'm experimenting before trying to use the handshake lines to do it. I'm just curious.

[GARTHWILSON]

You cannot generate interrupts by writing to the interrupt flag register (IFR). However, if you wanted to make the VIA generate an interrupt without outside stimulus, you could set up a timer to interrupt when it times out.

[BigDumbDinosaur]

GARTHWILSON wrote:

You cannot generate interrupts by writing to the interrupt flag register (IFR). However, if you wanted to make the VIA generate an interrupt without outside stimulus, you could set up a timer to interrupt when it times out.

Or, you could wire one of the CAx or CBx inputs to any of the parallel outputs and trigger an interrupt by toggling the relevant output. Of course, the question is why?

[Dan Moos]

Thanks guys!

There really isn't a "why". Just experimenting.

[Chromatix]

I think if you have a timer interrupt enabled and that timer in one-shot mode counting Phi2 cycles, writing $0000 to the timer will give you an interrupt almost immediately, probably after the next instruction. This assumes you have a free timer to play with. The interrupt occurs upon wrapping the counter around to $FFFF, and it works for either of the two timers within the VIA.

[Dan Moos]

Ok, now I'm studying using the handshake lines to generate interrupts. This is going to be for interfacing a PS/2 keyboard to my build.

I want to use CA1 to generate an interrupt when key press data is ready. It appears from my reading that CA1 is edge triggered. Is there a pulse width I should have for that signal? I would rather not have to have the CPU need to respond with the "data taken " signal, although maybe that's just what needs to happen. If I did use the "data taken" signal, I suppose that would be the natural time to release the "data ready" signal.

Basically, here is the sequence I am wanting to do:

AVR uController gets and decodes data from PS/2 keyboard.
uController puts the data on port pins of VIA
uController sends "Data Ready" signal, generating interrupt
CPU handles interrupt and takes data.

I guess as I write this, it seems more obvious that I need to complete the loop with signal "Data Taken"
signal so that the uController knows what to do next.

[drogon]

Dan Moos wrote:

I guess as I write this, it seems more obvious that I need to complete the loop with signal "Data Taken"
signal so that the uController knows what to do next.

It depends on your needs - so the Apple II didn't have interrupts and the keyboard output was 7 bits plus strobe (in the top bit), so you simply looped, polling the memory location of the keyboard until the top bit was set, read the data, then reset the top-bit (which was a flip-flop on the motherboard, nothing to do with the keyboard).

That was effective, but there was no buffering, so if you typed a 2nd character before the first was read then you lost the first one...

For your application, you might want to look at Handshake Mode in the VIA using both CA1 and CA2. This will generate the interrupt for you, then send the ack to the MCU automatically when you read the input register. It was designed for parallel transfers like that.

-Gordon

[Dan Moos]

I have CA1 set to "pulse".

It seems to pulse on any read or write to any register in the chip. I had expected it would only pulse on a read or write to PORT A.

This is normal, or am I missing something? Seems like this would cause mayhem. Say my peripheral is waiting for a handshake pulse after sending data to PORT A, and some unrelated activity on PORT B pulses it prematurely?

[floobydust]

Dan Moos wrote:

I have CA1 set to "pulse".

It seems to pulse on any read or write to any register in the chip. I had expected it would only pulse on a read or write to PORT A.

This is normal, or am I missing something? Seems like this would cause mayhem. Say my peripheral is waiting for a handshake pulse after sending data to PORT A, and some unrelated activity on PORT B pulses it prematurely?

I get the feeling you're implementing Daryl's AVR PC keyboard controller... or basically the same thing.

According to the W65C22 datasheet, Port A would be the better port to use for handshaking with the keyboard controller. Sections 2.1 thru 2.4 cover the handshaking capabilities.

The keyboard controller should trigger the CA1 line when it has data to be sent to the 6522. This (when correctly configured) would generate an interrupt to the processor. The interrupt service routine would then poll the 6522, figure out what generated the interrupt and then read Port A and get the data. CA2, if properly configured, would automatically respond by generating a pulse or simply toggling the line after the data is read from Port A. This saves some additional coding to send a data taken response back (to the keyboard controller).

Obviously, you need an interrupt service routine for all of this to work. Once you have the AVR keyboard controller working, it shouldn't be too difficult to get it working with Port A. The CA1 line is used as an input from the keyboard controller and the CA2 line is used as the handshake line back to the keyboard controller.

Current status/code?

[thedrip]

semi-related observation of the weekend.

My Rockwell R6522 (maybe china relabel?) which is supposed to be a 1-2mHz part works great at 3.3mHz. At 4Mhz the ports don't respond to input/output in any way, but the timer still works.
In fact, it's successfully creating an NMI tick at 8 and 10Mhz clock speed.

Interesting failure mode.