Monday, October 31, 2016

Pumpkin Pi

Pumpkin with PI symbol and Arduino-controlled Neopixel LEDs



Neopixels are individually addressable RGB LEDs. I bought an 8x1 array to try them out and decided they would make a good pumpkin light. Add an Arduino Nano, 4 AA's, a capacitor and a resistor and voila. Turns out you could see them from the street quite well.


The capacitor and resistor were added per Adafruit's Best Practices page for Neopixels.

Friday, August 26, 2016

Vintage Atari CX22 Trak-Ball with USB interface.

The trackball, or Trak-Ball as Atari dubbed it, was a fascinating controller to me in the arcades. There was a mystery at work under the controller panel transferring the rolling motion of the ball to the character on the screen. They were too expensive to own for my Atari computer, so I played Centipede (not very well) at the arcade. I didn't really understand how trackballs worked until college. That's when I found out the mouse was just an upside down trackball with the optical encoder wheels and all. I recently picked up an Atari CX22 Trak-Ball at a vintage gaming show and turned it into a USB device. I plan on taking it to work to control my Mac just for the sake of irony. In the meantime, it's great for a mean game of Missile Command on the emulator.

Thank-you Dan Kramer for designing this awesome piece of hardware!



Atari made a few Trak-Ball models: the CX22 (for the 2600 and 8-bits) in the classic brown and beige colors, the CX80 with the mid-80's XL motif, and the CX53 for the 5200. The original CX22 only worked as a joystick simulator and a revision included a selector switch to allow true trackball control. This true trackball mode can be used to play Missile Command on the 8-bit computers by pressing control-T. Totally different and much closer to the arcade experience than the joystick. I put some links to trackball history and documentation at the bottom of this post - make sure you check out the concept drawings at the online Atari museum in the last link.

Decoding the Trak-Ball

The CX22 service manual gives a nice theory of operation for the trackball. The ball spins two rollers which rotate optical encoder wheels in each axis. The encoders have two signals in quadrature phase (like a sine and a cosine waves) used to determine the speed and direction. The direction is determine by finding which signal leads the other. To have a joystick mode, the CX22 does this with discrete CMOS logic chips. The quadrature square waves are fed to a CD4013B D-type Flip Flop - one signal acts as clock and the other data. When the data lags the clock, a logic 1 is latched in at the falling clock edge. When the data leads, the result is logic 0. In trackball mode, the clock and direction out are selected by the switch and sent to the controller port. In joystick mode, the clock triggers a one-shot 4538B chip configured for a 9-ms pulse width. The one-shot output gates the direction signal sent to the output. Thus, there's at least one 9-ms joystick direction pulse that is extended for each encoder wheel clock tick occurring before the 9-ms is up.

USB Device

Using the HID-Project library for the Arduino, I configured my Leonardo board to act like a USB mouse. The code is incredibly simple because the direction decoding is already performed by the CX22 hardware. (The Arduino could certainly decode the signals if the clocks were sent directly - here's a tutorial with multiple software approaches to quadrature decoding. Good to keep in your back pocket for building a spinner controller.) The code polls the clock signals and sends incremental mouse movements over USB to the OS. It also polls the digital input for the fire button(s) and sends mouse clicks. For some visual feedback, I blink the on board LED every time motion is detected. 
Here's my sketch:

#include <HID-Project.h>
#include <HID-Settings.h>

const int XINC = 6;
const int YINC = 6;

int xdir = LOW;
int xmot = LOW;
int ydir = LOW;
int ymot = LOW;

void setup() {
  // put your setup code here, to run once:
  for (int i=0; i<6; i++) {
  pinMode(i,INPUT_PULLUP);
  }
  pinMode(13,OUTPUT);
  Mouse.begin();
}

void loop() {
// poll the xmot and ymot looking for state changes
// when state change, increment mouse movement


int xold=xmot;
int yold=ymot;

ydir=digitalRead(0)*2-1;
ymot=digitalRead(1);
xdir=digitalRead(2)*2-1;
xmot=digitalRead(3);

if (xmot!=xold) {
  Mouse.move(xdir*XINC,0);
  digitalWrite(13,1);
}

if (ymot!=yold) {
  Mouse.move(0,ydir*YINC);
  digitalWrite(13,1);
}

int f=!digitalRead(4);
if (f) {
  Mouse.press();
  digitalWrite(13,1);
} else {
  Mouse.release();
  digitalWrite(13,0);
}

//Serial.println(x);
}

Thanks for stopping by!

Trackball Links

Tuesday, August 9, 2016

Playing Kaboom! on an Atari 8-bit Emulator with Real Paddle Controllers

I'm on a quest to educate the Boy about the history of video games with the hope he'll want to learn something about computers other than downloading iOS apps or playing FPS's on Xbox. Potentiometer controllers (paddles) showed up on the earliest home systems like the Odyssey and Pong. We got to play an original Magnavox Odyssey at a Smithsonian event. That was an interesting system with multiple pot's for each player - one for moving the player and one for adding "english" for directing a shot. At another show, we played an original coin-op Pong machine - those controls are sensitive!

I picked up a pair of Atari-style Gemini paddles for $5 at that gaming show and hooked them up to my Windows machine using an Arduino Leonardo running a gamepad HID library. The boy was intrigued because they are so different from an Xbox controller or a mouse; and I got him to play Kaboom! on an Atari 800XL emulator. Definitely different from Breakout or Pong:


Tell me that's not at least as fun as many casual iOS games. I really like the reveal of the 1812 Overture as one advances in the game. Other paddle games are discussed over at AtariAge.

My $5 deal:

Technical Details

The paddles are 1-megaohm linear potentiometers tied to 5V. To measure the resistance, the original Atari system would measure how long it took to charge a capacitor. It actually counted the number of TV scan lines. The higher the resistance, the longer it took. This was a straightforward way to do it with a purely digital readout system and the 8-bits have a custom POKEY chip that does the work. (The POKEY designer Doug Neubauer tells a couple entertaining stories.) This is called an analog-to-digital converter by many - it is, but not in the sense of modern ADC's. It's a current-measuring ADC (with the current source being the potentiometer series resistance biased by +5V) vs. a typical voltage-measuring ADC. Many modern microcontrollers have voltage ADC's built in, so my implementation uses a voltage divider instead of an RC charging circuit. Despite some erroneous circuit diagrams found on the interwebs, the pot in the paddle has one end floating. Thus, the readout circuit needs an external drop resistor to make up the voltage divider. Here's my circuit:
The microcontoller is a Leonardo because it runs an ATmega 32u4 microcontroller with an on board USB interface. Two ADC channels are used to read the voltages from the dividers. Digital inputs D0 and D1 are used to read the trigger buttons. The software relies on the HID Project. I started using the absolute mouse device, but switched to the 16-bit axes on the gamepad device. My method isn't new; however, I added some integer math to compute the resistance value from the voltage that I haven't seen elsewhere. Otherwise, the reading will be highly nonlinear. Atari went out of their way to use linear potentiometers in the design (vs. logarithmic which are used in audio volume controls), so it's only fitting to keep the system linear. The code also includes a startup calibration to find the minimum voltage when the paddle is turned completely counter-clockwise. 

Here's my sketch:

#include <HID-Project.h>
#include <HID-Settings.h>

int oldx;
int x=0;
int calx=0;
int oldy;
int y=0;
int caly=0;

int readpaddle(int p) {
  int a=0;
  for (int x=0; x<32; x++) { 
    a+=analogRead(p);
  }
  return a;
}


int paddlemap(int a) {
 return 65535-uint32_t(uint32_t(1072693248)/uint32_t(a));
}

void setup() {
  // put your setup code here, to run once:
pinMode(0,INPUT_PULLUP);
pinMode(1,INPUT_PULLUP);

delay(2000);
Serial.begin(9600);
Serial.println("calibrating");
for (int i=0; i<10; i++) {
  int temp=paddlemap(readpaddle(0));
  calx=max(temp,calx);
  Serial.println(calx); 
  temp=paddlemap(readpaddle(1));
  caly=max(temp,caly);
  Serial.println(caly);  }
Gamepad.begin();
}

void loop() {

boolean changed=false;

oldx=x;
oldy=y;
int tempx=paddlemap(readpaddle(0));
tempx=max(tempx,calx);
x=map(tempx,calx,32767,-32768,32767);
delay(7); //need to clear residual from ADC and limit update rate
int tempy=paddlemap(readpaddle(1));
tempy=max(tempy,caly);
y=map(tempy,caly,32767,-32768,32767);

if (abs(x-oldx)>63 || abs(y-oldy)>63){
  changed=true;
}

Gamepad.releaseAll();

if (!digitalRead(0)){
  Gamepad.press(1);
  changed=true;
  }
if (!digitalRead(1)){
  Gamepad.press(2);
  changed=true;
  }

if (changed){
  Gamepad.xAxis(x);
  Gamepad.yAxis(y);
  Gamepad.write();
}

//Serial.println(x);
}


I'm pretty happy with the results. My code uses the full range of the paddles, but I've read the 2600 used only a limit motion range. I need to ask the 8-bit community about that. I need to trim it down to act more like the real hardware which uses only about 2/3 of the range. (Thanks to the guys over on the Atari 8-bit Computers FB group!)

Thursday, July 21, 2016

Summer Retro Game and Movie List - An Abridged Armada Chronology

While more cerebral types publish summer reading lists (you know who you are), I'm opting for an easier way out. Summer is half over and there's not enough time to squeeze in all that reading if you haven't started yet! Instead I offer a list of retro video games and 80's and 90's movies based on a list found in Ernst Cline's Armada, which was compiled by the protagonist's lost father under the heading of "Chronology." In the story, the Chronology is provided as circumstantial evidence pointing to a vast government-entertainment complex conspiracy to covertly prepare and train the populace to fight in a coming alien invasion. Sounds plausible. But even if you don't subscribe, that's no excuse to avoid this historical retrospective in the last few remaining weeks of summer.


I'm updating the list with my thoughts, experiences and links as I work my way through it. If you play along, please leave me a comment on the list page.


Sunday, June 26, 2016

Lightsaber Crystals

This is a pseudo guest post by my son (aka "the Boy"). He and a friend were in the backyard dueling with their "build-your-own" lightsabers from Disney World. In an epic exchange, one of the lightsabers fell apart and a little door popped open revealing three plastic crystals in the flashlight handle. When you pull them out in different combinations, the energy vibration sound changes. We've had these toys for a few years and this is the first we've known of this. There are a few comments on blogs around the web, but not a whole lot of info is out there. "Dad, will you put this on your blog so we can get the word out?" So here we are.

To find the crystals, take off the grip pieces from the flashlight handle, like you're going to change the batteries. Right next to the battery compartment, is the crystal chamber. Here's step-by-step photographs showing the sequence:
The crystals pull out by the top edge where there's a little ridge. They go back in easily the same way. If you have trouble reinserting them, rotate them around and make sure they are in the right slot. It's not too hard to force them in the wrong way making it difficult to pull them back out. Here's a close up of the compartment with and without the crystals:

With three crystals, there are eight possible combinations, but turns out there are only three different sounds. Here's a truth table with links to the sound files.

Extra credit if you draw the logic circuit to implement the truth table.

Saturday, June 11, 2016

HO Trains and DCC++: Part 2

Controlling a DCC++ base station using JMRI and WiThrottle on an iPad.

At breakfast this morning the Boy asked, “Dad, can we fix Gordon today?” Gordon, from Thomas and Friends, didn’t work when the trains were rediscovered. So today, we took him apart to diagnose the problem. He simply wouldn’t run. Turns out the fix was easy: the contact leafs that rub against the drive wheels to pick up power needed a little extra bending to make a low resistance connection. Once we did that, we also had to run him out a little - I suppose the lubricant in the gear box needed to be redistributed. That and little machine oil and he was up and going. The Boy wanted to put this on the blog. Here is a picture of Gordon in a state of disassembly.

Last time, I was setting up a DCC++ base station to control our one DCC locomotive. Since then, I installed JMRI on a netbook running Xubuntu to have some better control. JMRI is a Java-based train control system that supports DCC++ for output. My netbook was running XP and wouldn't support a recent JMRI version, so I installed Xubuntu as a dual boot. JMRI installation on Xubuntu was pretty straightforward and I also have it auto-starting now on login. It has a server for network control, to which an iOS app called WiThrottle (free version) can connect. Installed that on an iPad and now can control the locomotive over wifi.

Not a bad outcome.

The next challenge is sound on board.

Monday, June 6, 2016

HO Trains and DCC++: Part 1

The Boy has rediscovered the model trains. Several years ago we started by resurrecting my 1990’s N-scale layout, which is 2’-x-4’ and could slide under the couch.  This was followed by  Dad’s post-war Lionel O-27, which was augmented by modern Fast Track and my 1970’s banjo crossing. The Fast Track was a game changer - the stuff works perfectly. It’s reliable, easy to join and doesn’t cause derailing. This was the first time the young-version Boy didn’t get frustrated while running trains. We added 21st century Thomas with a whistle. Finally we added an HO scale Thomas and Friends set. He was able to put together the track with this set himself. It also made several airplane trips in a carry-on back and forth to the Grandparents. But, then the XBox replaced the trains.

Most recently, the Boy pulled out the HO scale trains, built his own layout, and began running a Union Pacific (UP) diesel, boxcar and caboose. He’s using my 1980’s power supply, which was advanced at the time because it had a low-pass filter on the throttle to simulate gradual acceleration and deceleration of the train. Modern control, however, uses Digital Command and Control (DCC). The UP diesel has a DCC decoder. When we bought it, I figured I’d buy a command and base station soon after, but never found the opportune time.

Then last month the Boy has been talking about DCC nonstop and then he discovered locomotives with a Bluetooth interface. Time to do something about it. After researching DCC and reading the NMRA standard, I realized it could be implemented on an Arduino. Using my Google foo, lo and behold, I stumbled upon DCC++. I didn’t think it was the right time to invest in trains with dedicated Bluetooth interface and I have a couple Arduino Unos sitting around - this is the ticket.

Install DCC++

The DCC++ base station code can be downloaded from GitHub here. I used the standard Arduino IDE v1.6.5 to install it. The first time around compiling, it failed with the error:

Accessories.cpp:66:20: fatal error: EEPROM.h: 
No such file or directory #include <EEPROM.h>

Turns out in Arduino, all #includes no matter where they are used must be declared in the .ino file. I learned this interesting tidbit hereAfter adding #include <EEPROM.h> to the .ino file it works fine. I posted an issue to the GitHub site, so I imagine it'll be fixed. This is the first time I've contributed to someone else's code, although it is a pretty minor bug fix.

Prepare the Arduino Motor Shield

Per instructions here, I cut the indicated traces. The picture below shows the Vin trace cut - this disconnects the external power supply used to drive the motors through the motor shield from the Vin pin on the Arduino.
There are also a couple of jumpers to be installed. The final configuration is shown below.

Test the Uno

Before powering the motor shield, much less trying to control a train, I wanted to make sure I could talk to the DCC++ software on the Uno. Using Hyperterminal, I connected to the Arduino and sent the <s> status command. The response is shown in the picture.


Test the motor shield

Now that the software was working, I wanted to test the shield before using a train. I measured the voltage out when powered on. Using the <1> command turns the power on, which should be a 5-kHz square wave with almost 12-V amplitude (there might be some voltage drop in the driver chip). Note the LED’s by the terminal block are now also illuminated greenish-yellow. My digital volt meter is pretty decent at measuring root-mean-square (RMS) AC voltage and indicated 7.9 V for an expected 12/sqrt(2) = 8.5 V. (9/21/16: I was re-reading this and realized this statement is not correct. The RMS of a square wave is the amplitude. The sqrt(2) factor is for a sine wave. The low voltage reading on the voltmeter could be due it's frequency response. Or, it's possible there's a lot of loss in the driver. I need a scope to diagnose it.) That’ll do.

First run - throttle control

Now it was finally time to try it out. The DCC++ wiki gives an example command to move the train: <t 1 03 20 1>. This command tells locomotive “03,” which is the default encoder address, to move forward at speed 20. It worked. It worked without any fiddling. It’s nice when things just work. Though it is kind of anticlimactic. 

In Part 2, I’ll talk about our experience setting up iPad control.