A 4x4 keyboard is wired with the port B of a 6522. When a button is being pressed , it will cause an IRQ interrupt through the CA2 line of VIA.
WRITE A PROGRAM which will read from port A of VIA the button which is pressed and save the button's code in the 0050H,0051H,..... until the button "ENTER" is pressed....... I hope someone could solve this problem because I cannot. Please answer........

I abstracted out the location of the port and the value of ENTER. Change the beginning of the program to say the location of the VIA port and value of ENTER. Also make VIA_IRQ the IRQ routine.

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"

I believe that your solution helped me a little, but still I have not understood where you program the port Α of 6522 and the CA2 in order to cause an IRQ interrupt to the CPU please read my solution and tell me where is the mistake:

I didn't know I had to program the VIA.

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"

You didn't say in your original post that the 6522 must be programmed to generate the IRQ. I'd assumed that external logic did that.

But, as far as I know, the 6522 can't generate interrupts when the bits of a port change state. I know that the BBC Micro, for instance, has a NAND gate that generates an IRQ from the keyboard. Some other parallel port chips have circuits that can be set up to generate interrupts when bits change state, but not the 6522.

Or am I mistaken?

Could you clarify the hardware side of this 4x4 keypad please.

From the description it sounds like you are talking about an unencoded 4x4 switch matrix with (say) the row inputs connected to port B (which has the relevant 4 lines set as outputs) and the (say) column outputs connected to port A (set as inputs). You would then need to write a keyscanning/decoding routine AND have to think about the keypad hardware. You'd need four pull up resistors for the port A lines, a 4-input NOR gate across the column outputs with it's output wired to CA2, and diodes across the switches unless you organise some sort of open collector driver for the rows on port B.

However, your code would seem to imply that you are treating the 4x4 keypad as a DECODED jobby where the scanning and decoding is done in hardware and it merely presents a 4-bit output representing which key has been pressed. In which case it will either produce some sort of STROBE signal (e.g. the 74C922) or you will still need some sort of 4-input OR/NOR across the ouput to detect any change from the NO KEY PRESSED state - which incidentally would mean you would lose the use of one key.

OK! Let me say it again:
First of all this is an exercise from my college that i have to solve!
this exercise wants to program VIA when a button is connected to port B of VIA( no the whole keyboard) . Furthermore, it asks to program the VIA in order to cause an IRQ interrupt through CA2 line. When VIA is programmed and the IRQ interrupt is caused , the exercise wants cpu to read the code of the button from port A of VIA and save it to 0050H, 0051H...(i assume, because it is not so clear)
Sorry for disturbing you!
But the exercise they gave me is not so clear and at the moment i cannot find the person who wrote this thing for details!
Please help me i have to give the answer on friday!

I think you should post the exact text of the question as your second attempt at explaining it made less sense than the first.

For instance why mention a 4x4 keypad if there's only 1 button connected?
If the button (or even the entire keypad) is connected to Port B, how can you expect to read it via a read of Port A?

If there some sort of diagram with the question that might help explain things.....

Well, we are not in the habbit of doing people's homework for them, but without actually writing the whole program, we can give you the steps that need to take place so you'll understand it better than if someone just gave you the completed code.

First, it sounds like the 4 rows and 4 columns of the keypad are connected to PB. Is that right? If they are, the only reason to read PA is to turn off the CA2 interrupt, not to get any info about what key is being pressed. When the time comes, you'll read PA, but discard the information. Otherwise, leave PA available for something else, which you can still do without affecting the keypad job. Actually, with a few tricks, you can use a sigle 6522 VIA for more things simultaneously than I'm sure you imagine.

Without external ICs (like the keypad encoder mentioned above), 4 bits of PB will be connected to the keypad columns, and 4 bits to the rows. Let's say PB0-PB3 go to the columns, and PB4-PB7 go to the rows. Each row will have a pull-up resistor to Vcc so it will be in a high logic state unless a key on that row is pressed to connect it to a column whose voltage is low.

Next you need a way to generate the interrupt from CA2. The most straight forward way to take care of the hardware part of that would be to connect each row to one input of a 4-input NAND gate. (A second choice would be to connect each row to the cathode of a diode, and all the anodes to CA2. Then put a pull-up resistor on CA2.)

You'll need to do a few things to set up the VIA. First set the data direction for the port B bits by writing to DDRB (VIA register 2). To do it as mentioned above, you'll make the columns outputs by writing 1's to the four column bits, and make the rows to be inputs by writing 0's to the four row bits. If PB0-PB3 go to the columns as mentioned above, you'll write 00001111B (0FH) to DDRB. Then when you write to PB, it will only affect the 4 least-significant bits, and you can read the 4 most-significant ones as needed.

To set up CA2, you'll need to write to the PCR (VIA register 12). The figure in the data sheet is self-explanatory there. Set it up to generate an interrupt on a falling edge (PCR=XXXX0010B). After your interrupt-service routine (ISR) is in place (more on that in a minute), you will also need to enable the interrupt by writing to the IER (VIA register 14), a 1 to bits 7 and 0, and at this point, you'll probably want 0's in the other bits.

For the interupt service, once you have verified (by reading the IFR, or VIA register 13) that CA2 is indeed the source of the interrupt, you will need to scan the keypad. First set the first column low (XXXX1110B) while keeping the others high, and then read the rows to see if any one of them is low. If they're all high (1111XXXXB, verified by ANDing with 11110000B and seeing if the result is 11110000B), you move on to set the next column low and again read the rows, and so on, until you find which one of them shows a key being pressed. It's possible that keybounce would make it appear that even though there was an interrupt, no key was pressed. Just keep scanning and the keypress will show up. From your description, it sounds like that when a keypress shows up, the value you read at PB (not PA) will be the key value itself that you will put in a key buffer that starts at 0050.

You must use a delay for debouncing so that the normal switch contact bounce does not register dozens of keypresses when there was only one. You can avoid looking for further keypresses until there has been perhaps a tenth of a second of continuous no-key-pressed status. Keeping the computer tied up in the ISR for this long however is generally not something you want to do. It is usually preferable to do something like using a VIA timer to generate an interrupt every so many milliseconds to go back and check the keypad status again and record what it found, so the computer can get on with its work. For example, do you want the computer to do something when you press a key (instead of waiting until you release it)? That's more user-friendly. The computer will have to be freed up to be able to do that. This is one of the many things a real-time clock, or RTC, even done in software using the VIA's T1, is valuable for, even if you don't care about keeping the time of day. The RTC will come in even more valuable if you want to have auto-repeat, and be able to set the repeat speed as well as the delay before repeating begins. I've done this many times over the years. It's not super complicated, but probably beyond the scope of your project. You don't need to implement that, but de-bouncing is mandatory if you are storing keypresses in a key buffer. So far we have not gotten into muli-key combinations either, like shifted keys where you hold the shift key down while pressing another key, or doing 2-key rollover.

After the ENTER key is pressed (which you verify by comparing the PB value to that of the ENTER key), it sounds like you can disable the interrupts (either with the IER or by making all the columns high), then, when the background program is ready, have it turn off the CA2 interrupt by doing a dummy read of PA, and re-enable the CA2 interrupt in the IER. If the end of the key buffer in memory is reached before ENTER has been pressed, you will probably want to turn off the interrupts then as well.

Each time a key is pressed, you will record its value (read from PB-- again, not PA) with an STA ZP,X instruction, and increment X each time. When the background program is ready to re-enable interrupts after the ENTER key is pressed, it will set the X value back to the beginning of your key buffer so the first subsequent keypress gets recorded at 0050. Note that the ISR will need to keep its own record of the X value somewhere in memory since the background program would also need X and overwrite it.

Thanks a lot GARTHWILSON!!! My intention was mostly to understand some things rather than just do my homework! The problem is that nobody at the college cares if you learning! So i have to search and ask a professional ! thanks again!

As you get into it, feel free to ask more questions. It's good to see someone who has not lost touch with what education is supposed to be for, like the schools have. (That's a subject I better not get started on!)