> >I don't know the specific timings of the keyboard controllers, but one
> >generally has to wait for mechanical switches to stop bouncing. The
> >contact is not a clean one, but rather a series of brief contacts
> >as the contacts close, then bounce a part, then close, then bounce...
> >This continues until the spring finally overcomes the switch bounce.
This seems like a reasonable reason. However, what if the user presses
the button a short while after you do the output? I think the better way
to debounce is simply to read 'slowly'. By slowly I mean not more than
once or twice a frame.(which is a different thing than waiting between the
reads and writes) This way if you read during a 'bounce' then it will look
like the button is not yet pressed. But if you read at the first contact,
then the next time you read, the bounce will have settled, and you will
again read the new value and not see a bounce. The only thing you have
lost in this case is a _really stinking fast_ button press that is
probably not needed in a program.
The initial reason I had thought is because of the maximum write
completion to data output on the output lines. A keyboard setup is
dependant on you writing an output signal, having it flow through the
keyboard, then you read it back. The data sheet I have indicates that the
maximum time from your write to the data output valid as up to 2 us, and
the read setup time is up to 0.3us. But obviously this is not even close
to 400 us.
Another idea could be because of the type of switch used in some of the
keyboard controllers. Many are membrane keys, which are rather resistive
for a switch, so it could be to allow signals to propogate through. This
doesn't really seem all that likely though...
A deeper look and comparison shows that the column reads are on the dumped
input lines of the TIA. This is important because these input lines run
through a resistor and have to charge a capacitor to propogate the value
to the input. I think that this is the most likely reason for the delay.
If you were to wire a normal switch to this input this would not be an
issue because a human's pressing interval will be far larger in magnitude
than the charge time of the capacitor. However the cpu can toggle the
lines much faster than the capacitor can charge and discharge through the
resistor. This is despite the fact that you are driving it quite strongly
with the pia's output.(as opposed to driving it through the paddles
resistors.)
A simple experiment would be to do a scan from one row that has no pressed
button(hold a button during the experiment) to a row that has a pressed
button, and then keep reading the inputs to see how long it takes for the
input to change.
If you really want, I, or someone else on the list can do the calculations
to figure out what the max time for charging the line is.
> Does this mean that it will be unique to each Atari system and clone, based
> on differing hardware?
Probably. If we are to assume that my possible explanation of the dumped
inputs is the source of the needed delay, then it would depend on
tolerances of components, etc which could vary by system.
FYI, I notice in the keyboard section of the stella programmers guide that
it says you read the columns on input 0,1 and 4. Note that this is for
one of the players. The other player is via input 2,3 and 5.
Mark
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
