My skunkworks project

[ChildOfCv]

Seeing how it's getting harder to repair these things, I decided to see if I could come up with a viable replacement. It shows promise, but still has a bit of jitter.

 

[Pixelboy]

Um, so what you're working on is a replacement for the Roller Controller? It's not 100% clear from your picture.

[Ikrananka]

Yeah, you definitely need to be a little clearer about what you're actually trying to do.

[ChildOfCv]

Yeah I'm using a mouse optical sensor in an attempt to replace those code wheels.

 

Joystick passthrough works perfectly, but the optical sensor is being a pain. Of course, it could be that mounting it securely will be enough to make it consistent, but that remains to be seen. So far I haven't done anything permanent to the roller controller case itself.

[Ikrananka]

Interesting, keep us posted on your progress.

 

So far I've been lucky and all of my Roller Controllers still work.

[Pixelboy]

Very interesting. T'would be nice if this ended up as a "modern" Roller Controller for the CollectorVision Phoenix, although if it's connected via the Phoenix's expansion port, it may require the use of a custom FPGA core that receives the controller interrupts via some pins of that expansion port, instead of the regular DB9 connectors.

[ChildOfCv]

Very interesting. T'would be nice if this ended up as a "modern" Roller Controller for the CollectorVision Phoenix, although if it's connected via the Phoenix's expansion port, it may require the use of a custom FPGA core that receives the controller interrupts via some pins of that expansion port, instead of the regular DB9 connectors.

 

I assume the Phoenix still uses the quadrature pins as intended? If so, then that shouldn't be a problem. My only connection(s) to the expansion port here are for ground and power. Of course I haven't yet tested the quad output either. I need a Roller Controller game for that (Slither should be arriving any day now). At the moment I'm only doing joystick emulation.

[digress]

What about an older serial mouse with a db-9 port? Some of them were even trackballs

[ChildOfCv]

The main problem is that the old serial mice were exclusively mechanical ball mice. Or at least, I haven't seen a serial mouse that's optical based. Of course, there are many microcontrollers that can read a USB plug directly.

 

But my hope is that that purpose-built board will work directly, so that I don't have to salvage any existing electronics. Of course, even better would be if everything could be done with off-the-shelf components, but optical sensors have to be paired with a proper lense, and the PCB needs to be designed around mounting and retaining all of that. So this is not quite the same as just buying a chip.

 

And on that note, I solved one mystery about instability of the sensor: The reset pin. The handy board that I bought has a voltage regulator and level shifters so that a 5V device can talk to the 1.8V mouse chip, which takes up to 3.6V on any input. The reset pin is active low, so it needs to be held high. The problem is that the board feeds the reset pin directly into the chip. So the Arduino's +5V was overdriving the poor optical sensor. Eventually, even the Arduino's power LED would start to pulsate, which I did not consider to be a good thing. A note to designers: Please post these gotchas and not just a simple pinout!

 

Well, the board designer also has a pull-up resistor on reset, so I should probably just not connect it at all. The remaining question is whether the chip is already too damaged.

[+evg2000]

Not sure why you've wired the chip the way you did. I would suggest that you use a 180 ohm resistor to each of the LED on the chip. and don't use the same ground for both sides, input/output. You want to isolate the arduino from the colecovision. I did something similar for the paddle control I created.

[ChildOfCv]

Could you be more specific?

 

If you mean the optical mouse chip, I didn't wire it. It came as a pre-assembled board with the level shifter components, voltage regulator, and the lens. It talks to its host controller over SPI. It also has a "motion" output line that can be used as an interrupt trigger, and of course the reset line.

 

The only LED I mentioned is the power indicator LED built on to the Arduino. And I'm pretty sure they put it in series with a current limiting resistor.

 

Anyway, how can the Arduino pull a pin towards Coleco's ground if it doesn't share a common ground with the Coleco? The original roller controller shares both +5 and ground with the colecovision. It has a pass-through power plug that sits between the Coleco's power brick and the console and powers the RC itself. It does this so that its active components can pull pins high or low as needed. Perhaps you could tell me more about your paddle project?

[ChildOfCv]

For reference, this is my current pin setup:

/* * Pinouts for Mega2560
 * 
 * PMW3390 board:
 *   50  MISO
 *   51  MOSI
 *   52  SCK
 *   53  SS
 *   3   INT (subject to change.  External int 0 has pretty high priority, and reading the SPI data
 *            can cause a missed pin change interrupt from the ColecoVision, causing keypad/joystick
 *            crossover.  Currently just setting a flag with this handler and letting the main loop poll
 *            when it checks the flag)
 *   8   RESET (probably will be completely removed)
 *   
 * Input 1 to CV:  PORT A
 *   22  Pin 1
 *   23  Pin 2
 *   24  Pin 3
 *   25  Pin 4
 *   26  Pin 5
 *   27  Pin 6
 *   28  Pin 7
 *   10  Pin 8 // For pin change interrupt
 *   11  Pin 9 // For 1-shot PMW output
 *   
 * Input 2 to CV:  PORT C
 *   30  Pin 1
 *   31  Pin 2
 *   32  Pin 3
 *   33  Pin 4
 *   34  Pin 5
 *   35  Pin 6
 *   36  Pin 7
 *   37  Pin 8
 *   5   Pin 9 // For 1-shot PMW output
 *   
 * Input 1 from joystick:  PORT F
 *   A0  Pin 1
 *   A1  Pin 2
 *   A2  Pin 3
 *   A3  Pin 4
 *   A4  Pin 5
 *   A5  Pin 6
 *   A6  Pin 7 // Not needed, but done to keep the bits lined up
 *   A7  Pin 8
 *   
 * Input 2 from joystick:  PORT K
 *   A8  Pin 1
 *   A9  Pin 2
 *   A10 Pin 3
 *   A11 Pin 4
 *   A12 Pin 5
 *   A13 Pin 6
 *   A14 Pin 7 // Not needed, but done to keep the pins lined up
 *   A15 Pin 8
 */

So, no LEDs wired up at the moment.

[ChildOfCv]

Some progress.

 

Joystick passthrough seems to work. At first I was concerned about the time it takes the pullup inputs (1-4,6) to rise after you release a button. I tried using external resistors instead of the Atmel internal pullups on the hypothesis that it had limited current for pulling up each pin, but external 20K pullups had the same issue. Then on a whim I tried watching the pins on the standard controller when it's plugged into the CV instead, and found the same lag. All that concern over nothing.

 

Joystick emulation of the roller also seems to work. I was able to clear the entire first level in Mouse Trap using the track ball. Yay, I guess.

 

Now working on roller mode. I did some debugging on the e-w axis only, so far. It's now mostly functional. But I also noticed that the optical sensor almost monopolizes the MCU's time when you're really spinning the ball. This results in slower "ticks" to the Coleco's quadrature inputs, which means that you move slower while rolling fast, followed by a burst of speed as you slow down. I'll have to fine tune the optical sensor and service routine to throttle its demands. It seems that there are registers to play with such as DPI and delay between signals, which may help with that.

 

Of course the most critical challenge is finding a way to mount the optical sensor so that it gets a good view of the ball. Apparently when it looks at a spherical surface, aiming is critical. So just tossing the sensor under the trackball gets you a lot of nothing. Whatever its focal point is probably needs to be perpendicular to the very bottom of the track ball. So finding a good way to secure the sensor, where it can also be fine-tuned, will require a bit of ingenuity.

 

Either way, it's been fun so far.

[ChildOfCv]

Next update: Both axes are hooked up and I now have full movement. On a grumble note, why did Arduino's designers have to flip port C in relation to port A? That caused me a bit of debugging frustration.

 

Testing out Slither, though, it seems as if there's something not right. According the the manual, either upper button should fire up while either lower button should fire down. But I can only fire shots using player 2's buttons. Is the manual wrong, or is there a bug to fix? Maybe I should try a joystick and button game like DKJr to see if the controls are working like they should.

 

Mechanically, I think I need to replace the bearings in the vertical roller. It rolls down as it should, but it binds when rolling up. Might need to take a bearing up to the local industrial supply to see if they have a usable replacement. Or destroy a fidget spinner. Any excuse to destroy a fidget spinner works.