Subject: Re: [stella] more keyboard nonsense From: Mark De Smet <de-smet@xxxxxxxxxxxxxxx> Date: Mon, 6 Nov 2000 21:48:50 -0600 (CST) |
> >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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] more keyboard nonsense, John K. Harvey | Thread | [stella] Guidelines for setting tim, John K. Harvey |
Re: [stella] more keyboard nonsense, John K. Harvey | Date | [stella] recent pokeys, jim crawford |
Month |