There are lots of ways to do all of these.
Quote:
1) How to read a button on PA0, for example.
Use the pushbutton switch to ground the PA0 pin, and have a passive pull-up resistor of say 10K. Then read the port and test the bit and branch something like this:
Code:
LDA PA0
AND #1
BNE/BEQ
or, if you already have 1 in A, you could do
Code:
BIT PA0
BNE/BEQ
Using BIT has the advantage that it does not change the value in A, so you can re-use it over and over; for example, you could have a loop that keeps checking the bit without having to re-load A every time through the loop, and check until the button gets pressed. The computer can't do anything else while it's twiddling its thumbs waiting for this input this way, but it's sure simple.
Quote:
2) How to read a classic Atari 2600 joystick on PA.
If I may save the time to research it myself, can you point to a page showing how the joystick works. It would have a pair of potentiometers I'm sure, but does it have any other electronics, to act as some cheap form of A/D (analog-to-digital) converter? [I started writing this before Michael posted above but I got called away.] I seem to remember the Apple II discharged a capacitor, then let it charge up through the pot, and there was a comparator that detected when the voltage on the capacitor reached a threshold, and the comparator's output went to a VIA pin. The lower the resistance of the pot at the moment, the less time it took for the capacitor to charge up to that level. Then the processor would use one of the VIA timer/counter references to see how long it took and therefore the position of the pot.
Quote:
3) How to read a keyboard matrix (like this one:
http://mainbyte.com/ti99/keyboard/keyboard.html).
One way would be to have PB set as outputs going to the columns, and PA set as inputs going to the rows. Put passive pull-ups on the rows. Clear the output bit corresponding to the column you want to check, then read PA and see if it's something other than all 1's. If it is, you can do something like shift left repeatedly and branch on the C bit to see which key was pressed. Otherwise, go on to check the next column the same way, cycling through the keyboard. Actually, since most of the time there won't be any key at all pressed, the program would be more efficient if you first activate
all the columns, and see if the rows byte is $FF. If it is, there's no point in checking every row individually.
To prevent shorting two column outputs together with multiple simultaneous key presses, keep PB holding 00 and write to DDRB so only make one column at a time is an output while the others are inputs (meaning they're basically inactive for this application).
Quote:
4) How to display byte to PA and light some LED's (8 LED's for debugging).
You can connect them directly from the PA pins to ground or Vcc, but put a 470Ω in series to control the current.
See what I say about debugging in the
http://wilsonminesco.com/6502primer/debug.html]debugging chapter of the 6502 primer though. LEDs are not as dependable as a software beeper, since they are more likely to be turned on and off by wrong program behavior than the beeps, making it look like things are fine when they're not. The software beeper can be made to produce different frequencies and lengths of beeps to have different signatures. LEDs tend to be better when you can't take the time for a beep, or when you're using them more as status lights than trying to figure out where something is crashing.