Reasoning

The techniques that I used to do intelligent control of the pendulum easily scaled up to the acrobot.  A few hours of converting the code so that it would handle an extra joint and a new model of the system and the coding was finished (compared to about 4-6 weeks to develop the code itself).

What I didn't plan on was the memory limitations that are inherent in multi-dimensional arrays.  The pendulum look-up table required a 2 dimensional array (example - 100x100 = 1,000 elements).  The acrobot requires a 4 dimensional array (example 100x100x100x100 = 100,000,000 elements).  Not only does the look-up itself get very large and overwhelm the system memory, the queue I used to do a breadth first search (BFS) to build the look-up quickly used up the system's memory.  Thus, I was forced to go with very low resolutions (25x25x25x25 = 390,625 elements).

The success of this approach was limited, partially because of this memory problem and partially because I ran out of time to research the problem.  I didn't get the chance to develop the code that learns the parameters of the acrobot model so the only trials have been on an estimated model.

Here is some Mathematica code from which you can develop the acrobot inverse dynamics (credits to Chris Atkeson):
Derivation Code

This program used the model of the acrobot to create a look-up table of motor commands indexed by the state of the system (position and velocity for each joint).  This look-up table was generated by starting at the goal position and determining the previous states for each of the available motor commands.  Along the way, duplicate and latent trajectories are pruned automatically.
Table Generator Code (zipped)

This simulator program simply had the same model of the system that I used to get the look-up table.  For each time step, it used the lookup table just as the real acrobot would.  There is a bug in the code somewhere, but here it is.
Simulator Code (zipped)

These programs communicated between the 332 and the Sun.  The 332's function was to 1) collect data from the acrobot and send it to the Sun and 2) receive commands from the Sun and translate them into motor commands.  The function of the Sun was to receive data from the 332 about the state of the acrobot, find the appropriate command in the look-up table, and send that command to the 332.
Acrobot Invert Code (zipped)

As you can see above, the acrobot never got close to being inverted.  It would oscillate in a scissoring motion at about the same amplitude as shown above and never break out of this rhythm.

Some future work I would have liked to have done if I had more time:
1) develop the model parameter learning code
2) use a neural network to model the acrobot and use that to generate the look-up table
3) use a neural network to simulate the look-up table
4) convert Gary Boone's simulation code so that it uses a real machine
5) use a DAC to generate a continuous motor torque (rather than bang-bang control)

I also implemented the simple pumping heuristic described on Gary Boone's Acrobot Page.  While this was easy to do, the behavior of the acrobot performing this task was very interesting.  Here is the code:
Heuristic pumping code for 332 only (zipped)
Heuristic pumping code that uses the sun to collect data and issue commands (zipped) (used to collect data above)

It is interesting to note that the time lag induced by communicating with the sun resulted in a much slower swing-up response, although it is not rigorously documented here.