Smoke Test

Well, it seems I've been a bit lazy so far.  With the new year came the end of my Christmas vacation, and so I had to pay a bit more attention to work, etc.  I'm sure I'm not the only one!

Despite the lack of real progress, I thought that it might be worthwhile to demonstrate the workings of the rotary controller.  So, I posted a video of me stepping the controller through its paces using the joystick demo code I originally wrote while developing Fahrfall.

CoCo Joysticks

I'm using the joystick port on the CoCo to read the rotary controller.  That seems obvious enough, but the output from the rotary encoder is digital and the CoCo joystick inputs are analog.  I resolved that discrepancy using pull-up resistors, forcing the joystick inputs to always read either high or low (and not in between).  Given that understanding, the basic process for reading those inputs is the same as I described in the Fahrfall blog.  In this case we should be able to do only one value check per axis, since there won't be any "in between" readings.

Debounce

The rotary encoder I am using is mechanical.  Like all mechanical switches, there will tend to be some "bounce" when the contacts close.  It is possible to do switch debouncing with hardware, but it complicates the electrical design and construction.  Consequently, I didn't add any such hardware.

I'm not sure if debounce is usually an issue with game controllers or not.  In most cases, false readings probably just work themselves out with the next read.  But with the quadrature signal coming from the rotary controller, the sequence of values becomes important.  This is especially true if we were to miss a transitional state.

I found several references to people having switch bounce problems when using rotary controllers with Arduino projects.  I don't know if any of the techniques they use to fight switch bounce will be helpful on the CoCo or not, but I suspect that I may have to do something to account for switch bounce in software.

Keeping Up

A related problem with the rotary encoder will be the sampling rate.  The encoder I am using is rated for 24 pulses per revolution.  That number represents the number of full cycles per channel in a given revolution.  But since the signals are bound together using quadrature encoding, the real number of transitions to consider is 4x that, or 96 transitions per revolution.

The most common rate for sampling joysticks in an arcade game is around 60Hz.  It seems reasonable to suspect that someone could turn the controller knob more than 2/3 of a revolution during a second!  So, the sampling will have to happen more frequently.  If a game plays sound, there will need to be a routine running at a rate of several kHz in order to feed the DAC for audio output.  Maybe piggy-backing on that routine to read the controller input will be good enough to keep pace?  It might even fix the debounce issue for free?

Well, I guess we aren't going to find-out today...  I'll try to knuckle down on this and report back in a day or two.  Until then, stay tuned! :-)