Dummy ISR for VIA

[sburrow]

Hello everyone.

I'm thinking of adding a 6522 VIA to my board. But before I can do that, I'm making sure I can do it properly in software. I want to create a "dummy" ISR for the VIA. This is a fairly basic question so I'm putting in the Newbie section. Hopefully that's correct.

Let's say there are two VIA's, with an AND gate used on the /IRQ line. The IRQ-ISR would look like:

Code: Select all

irq_isr:
BIT via1_ifr ; test VIA1
BMI via1_isr ; if it was VIA1, branch
BIT via2_ifr ; test VIA2
BMI via2_ifr ; if it was VIA2, branch
RTI ; else, error, just exit

So I know I wouldn't *need* the second test, but just for clarity's sake let's keep it. Now to VIA1-ISR.

Code: Select all

via1_isr:
PHA ; push A
LDA #$7F ; load %01111111
STA via_ifr ; store into IFR to 'clear flags'???
PLA ; pull A
RTI ; exit

VIA2-ISR would be similar.

So here is where the main question arises. I want a 'dummy' handler, and so I want to clear all of the interrupts and exit immediately. According the datasheet (WDC, Rockwell, etc) I am seeing that you "write 1's into the IFR to clear all interrupt flags". This seems weird because a 1 normally say "there is an interrupt here!". Am I... doing this right? Am I understanding the datasheets correctly?

I don't care which flags were set, I don't care why I'm even here. All of this is a fluke and should never happen. BUT, in the off chance, I want the computer to not glitch or infinite loop. This seems like the quickest way to exit cleanly. What do you think?

Thoughts? Experience?

Thank you everyone.

Chad

[Alarm Siren]

This is how I did it on my university project, worked fine.

Code: Select all

ClearTimer1IRQ:
    LDA     VIA_ORA         ; Get current state of output port A
    EOR     #%00000001      ; Flip bit 0
    STA     VIA_ORA         ; Put it back.
    LDA     #$FF            ; Clear the interrupt from the VIA's IFR register.
    STA     VIA_IFR         ; I'm clearing all the flags even though it should only be T1, just in case.
    RTS

Note that this function is the very first thing executed by the IRQ handler in my code.

Like yourself, I just set all of VIA_IFR to 1s and pray.

[gfoot]

In the top level ISR, rather than only servicing one device, I would continue to service remaining devices if they require it. Otherwise you'll return from the interrupt and just get interrupted again, then have to check everything from the beginning again. It's not a big deal though.

You might as well load the IFR into A as the service routines probably benefit from having it there anyway - then your service routines can do things like LSR to shift each bit in turn into the carry flag and branch to other handlers.

Example of both of the above:

Code: Select all

    lda via1_ifr
    bpl skip_via1
    jsr service_via1
skip_via1:

    lda via2_ifr
    bpl skip_via2
    jsr service_via2
skip_via2:

I believe you can just clear the flags by writing %01111111. It's a special operation for sure, not completely intuitive. Note that the IER is similar - when you write to it, bit 7 indicates whether you want to set or clear other bits, and the remaining bits indicate which bits of the IER to set or clear. So writing %01111111 would clear all of them, writing %00000010 would clear just bit 1, and writing %10000010 would set bit 1.

Usually though you don't want or need to clear the bits directly - they are usually cleared as side effects of you actually servicing the thing that caused the interrupt. So for example if data arriving on Port A caused the interrupt, then when you read that data it will clear the interrupt. Not always though, sometimes you do need to clear them directly, and it does depend how you configure the rest of the registers.

[sburrow]

Hm! Thank you both. Now I have two others saying the "write 1's to IFR to clear flags" will work.

George, this whole thing is a backup of a backup. Right now I don't have the VIA onboard. So what if I don't have it plugged in at all? Shouldn't generate an interrupt. Then I plug it in. Regular ol' /RESET will not enable any interrupts, so *still* shouldn't generate an interrupt.

Me messing with code could cause the VIA to start interrupting, but this particular situation is to handle those interrupts that were never really 'intended'. It's a safety measure, that is all. I intend on putting *real* interrupt code in there eventually!

Thank you both again.

Chad

[GARTHWILSON]

sburrow wrote:

but this particular situation is to handle those interrupts that were never really 'intended'. It's a safety measure, that is all.

The VIA cannot pull the IRQ\ line down unless you enable it in the IER and the condition you set up to interrupt actually occurs.  It won't ever generate an interrupt without permission.

[gfoot]

A bigger problem is if you really do want to support the VIA being unplugged - you'd need a pull-up up resistor or manual jumper in its place to ensure the IRQ line doesn't float low.

I have found it useful in the past to provide IRQ and NMI handlers that just print a message on the screen, as it helps to rule those things out (or point the finger at them) if the system isn't behaving itself properly later on. BRK is the main one that ended up getting hit due to memory system issues or accidentally jumping into zeroed memory areas. I've never bothered actually trying to clear unanticipated interrupt conditions and carry on though.

[Paganini]

Hopefully there is already a pull-up resistor on IRQ\

[sburrow]

Paganini wrote:

Hopefully there is already a pull-up resistor on IRQ\

Yep!

gfoot wrote:

you'd need a pull-up up resistor or manual jumper in its place to ensure the IRQ line doesn't float low.

I have both actually.

GARTHWILSON wrote:

It won't ever generate an interrupt without permission.

I get nervous. What if the future me is screwing around and oops! Well, I suppose that's why there is a RESET button...

Good points. I have been thinking this over and will continue to do so for a bit. I have time.

Thank you everyone!

Chad

[drogon]

sburrow wrote:

GARTHWILSON wrote:

It won't ever generate an interrupt without permission.

I get nervous. What if the future me is screwing around and oops! Well, I suppose that's why there is a RESET button...

Defensive programming...

So the very first thing you do is write the ISR to do nothing more than print the PC, registers and a dump of all the registers from the VIA(s) preferably in a format you can easily decode. Then it can halt or reboot the system.

This then becomes your unknown interrupt routine.

So your ISR then starts test and dispatch part for each new source of interrupts you add in and if the dispatch code falls-through, then it lands on the above bit of code. You can add and test each new source of interrupt one at a time,

Lather, rinse, repeat for each new source of interrupt, but at the end of the day, you still have the unknown interrupt code, sitting there, so that if something does trigger that you're not expecting at least you have some way of tracking it down.

-Gordon

[pjdennis]

Paganini wrote:

Hopefully there is already a pull-up resistor on IRQ\

The premise here is that IRQ\ is driven from the output of an and gate combining the IRQ output from two 65C22s. So the pullups will need to be on the inputs to the and gate in order to support leaving the 65C22s unplugged.

[drogon]

pjdennis wrote:

Paganini wrote:

Hopefully there is already a pull-up resistor on IRQ\

The premise here is that IRQ\ is driven from the output of an and gate combining the IRQ output from two 65C22s. So the pullups will need to be on the inputs to the and gate in order to support leaving the 65C22s unplugged.

Re-reading this now ...

Shouldn't that be an OR gate?

New 65C22's drive the /IRQ output so shouldn't be (traditionally) wire-or'd together, so we need a bit more logic.

(And pullups on the inputs as you mention)

-Gordon

[BigEd]

(It would be OR for active-high signals, but IRQ is active low. I'm fairly sure this is right!)

[BigDumbDinosaur]

drogon wrote:

Shouldn't that be an OR gate?

AND gate is correct.

[Alarm Siren]

Its an OR gate in the sense of the logical function it is implementing, but it would be an AND gate in this particular hardware implementation because the IRQ signals are active low.

I have this argument almost daily at work. I make simplified diagrams for the benefit of non-hardware people that simplify away the detail of active-low/active-high, and I change the gates to show the logical function (not the hardware function). People get confused anyway because they go and look at the ICD or schematic which something different grumble grumble.

[sburrow]

Alarm Siren wrote:

Its an OR gate in the sense of the logical function it is implementing, but it would be an AND gate in this particular hardware implementation because the IRQ signals are active low.

I have this argument almost daily at work. I make simplified diagrams for the benefit of non-hardware people that simplify away the detail of active-low/active-high, and I change the gates to show the logical function (not the hardware function). People get confused anyway because they go and look at the ICD or schematic which something different grumble grumble.

I'm just confused about all of this. Could you explain for a newbie like me? I have heard or-wired and and-gated a lot, not sure what is what honestly.. I use AND gates here because if either signal goes low, the result goes low. I don't understand why OR would be used at all, but then again I'm new at this. I only think in schematics, so perhaps I missed something in digital logic school.

...

...

Oh wait, I never went to school for this

Thank you for any clarification.

Chad