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:



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



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

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



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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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:


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.

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

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

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.

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

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Yep!



I have both actually.



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

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

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

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

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

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

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

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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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