Garth, thanks again for the hints about the IRQ routine. I have them implemented right now and they seem to still work there.

Nother question on a peripheral. I had the ok for using the code for a 6532 port test. The test sets all the port bits as outputs, then it walks a 1 across each port and reads back the result. A stuck bit would be noticed immediately.

I cannot get this test to work in the same manner on the 6522, his answer was that the 6522 is a different animal entirely. Do you know if the 6522 input registers reflect the stored output bits? If they cannot be made to, then I must skip this form of testing.

I *DO* know I get some action in controlling the hardware, I made a simple loop to turn all the bits off and on and it works well in hardware, so its not a hardware issue. I just wonder if I can do the same test as he has done in terms of port testing, f you know if I can or not.

Thanks on any anyswer, either way...

Tony

_________________
"My biggest dream in life? Building black plywood Habitrails"

When you output something on PB (port B) and read it back, you'll read back what you put out there, because you're reading ORB (output register B). That's not the case with PA though. For example, if you put a high bit out in a particular position on PA but there's such a heavy load on it that the voltage at the pin is not allowed to come up out of the "0" zone, then when you read it back, you'll read back a 0, not the 1 that you wrote. That's because when you read PA, even in output mode, you're reading the level of the pin itself, and not the value you wrote into ORA. As I posted recently on the current capability of the VIA's outputs though, you'd have to put an awfully heavy load on the pin to keep it from going to the logic state you wrote to it.

Garth

then a port B test would be valueless because it couldnt read the true state of the pins. For the ports, I was planning to wire OR any inputs, so that they would be allowed to become outputs without huring anything. (basically, each port owuld have a pullup resistor and input by a 7407 open collector buffer).

guess its time to skip that test then if it cannot read the states. Thanks there. Port A would give a true and hoenst test while I cannot with B. Sigh. I *DO* want to read the true level of the pin, because if any of them are shorted to each other or just plain shorted, it would detect it. Hmmm, perhaps using the test for port A only then, will have ot try with that...

_________________
"My biggest dream in life? Building black plywood Habitrails"

Skip the 7407-- you can do it anyway without it. You can keep the pin to be normally an input by putting a 0 in the corresponding bit in the data direction register. Then write a 0 to the port bit, even though it's an input at the time. To pull the line down, turn that pin into an output by writing a 1 to the appropriate bit in the data direction register, and the 0 will get driven out on the pin regardless of what logic states were on that pin when it continued on as an input after that last write. To let the line go again, turn that pin back into an input by writing the 0 to the data direction register again. In output mode, reading port B will tell you what you wrote to the port; but the whole idea in output mode was to pull the line down anyway, right? so there's no need to read it. In input mode, you read the pin regardless, so you can see if something else is pulling the line down. If nothing is, your pull-up resistor will bring the line up to a logic 1, which is what you'll read even though the output register holds a 0 there. (Just remember that pull-up resistors may take a few clock cycles' time to get the line up to a valid logic 1, depending on the resistor value, the capacitive load, and the clock speed. IOW, just releasing the line and immediately reading it may still result in a 0 even though nothing else is pulling it down at the time. That's why WDC quit doing the wire-OR-type of IRQ outputs on their 65c22's. I have actually experienced the problem with this before with Rockwell VIAs. I didn't clear the interrupt condition early enough in the ISR, so the IRQ line still looked low at the end of the RTI and the processor immediately went back into the ISR, even though there was no true interrupt request at the time.)

Garth