A couple of handy OLPC XO Sugar utilities

I've recently been working on a few new Activities for the XO. As a result of this, I've discovered that there isn't a complete set of utilities for dealing with Sugar's internal tracking and record-keeping of Activities.

You can use the Journal Activity to install the ".xo" files for new Activities. You can use the Sugar Activity toolbar to "remove" an Activity. This removal is far from effective; it oftentimes does not actually delete the Activity's files in /home/olpc/Activities, and just as often, it doesn't remove Sugar's internal record of the Activity.

You can also manually install Activities via the 'sugar-install-bundle' utility, which can be run from the command line in the Terminal Activity. However, if you've already installed and then removed an Activity, it is very likely that 'sugar-install-bundle' will crash, complaining that the Activity already is installed, since Sugar never deleted its internal record of the Activity. This can be very frustrating when you're testing the installation of a new Activity, and need to remove and reinstall it multiple times.

I ended up poking around in 'sugar-install-bundle' (which is a Python script), and discovered that it calls some other Python modules in /usr/lib/python2.5/site-packages/sugar. These, for someone hoping to create an Activity, might be worth looking at, particularly the ones in the "activity" and "bundle" subdirectories. ".../activity/registry.py" is a particularly good one.

After all that poking, I saw the classes and functions needed to list all of the Activities that Sugar currently is aware of. These are stored in Sugar's registry (a binary database similar in use to the registry under Windows). I also saw how to remove the entry for a specific Activity from the Sugar registry.

Each entry has a name (e.g. "Sonata"), an icon, a "bundle ID" ("com.ywwg.Sonata"), an installation path ("/home/olpc/Activities/sonata.activity"), a command to launch the Activity ("sugar-activity SonataActivity.SonataActivity"), and a show-launcher indicator.

The Activities appear to be accessed and referred to by their installation paths, rather than their names or bundle IDs (which is a bit surprising to me, but using the path as the primary access key may allow both the names and IDs to be non-unique).

I've created a couple of handy utilities, 'sugar-list-bundles' and 'sugar-forget-bundle'. Both are short Python scripts, and can be run from the Terminal Activity's command line. They can be downloaded in a ".zip" file from here.

'sugar-list-bundles' doesn't take any arguments. It just dumps out the info on all the Activities currently listed in the Sugar registry. It lists the name, ID, path, and command for each Activity. To run it from the command line (assuming you've unzipped the utilities into the current directory):

./sugar-list-bundles

'sugar-forget-bundle' takes one argument, the name of an Activity. This name must exactly match one of the names dumped out by 'sugar-list-bundles' for 'sugar-forget-bundle' to be able to use it. 'sugar-forget-bundle' will remove the Activity's record from the Sugar registry. It will NOT delete the directories or files associated with the Activity. For example:

./sugar-forget-bundle Sonata

will cause Sugar to "forget" that the Sonata Activity is installed. It will NOT remove /home/olpc/Activities/sonata.activity or any of the files under it.

I'm sure there must be equivalents to these two utilities floating around (especially around the OLPC XO development team), but I haven't stumbled across them. I hope you find them handy.

Quick notes on the OLPC XO Terminal Activity

Well, I've realized that to really figure out what I did right / wrong to get DOSBox sound working on the XO, I'll need to reimage the OS and start from scratch, and I'm finding all kinds of things to do to avoid going down that road just yet.

One of them is looking at the Terminal Activity as part of my process for learning how to create a good Sugar-friendly Activity. Plus I'm hoping that it might be something that I can hack into the "Sugar wrapper" that can be used to run non-Sugar-ized apps as Activities on the XO without having to put Sugar hooks into their internals. In other words, an Activity that launches from the Sugar "Activity launcher" screen, displays an icon in the "active Activity ring", runs the non-Sugar app, then tells Sugar to remove the icon from the "ring" when the app exits. This would be very handy for Activity-izing apps like DOSBox and other emulators. And thus for running old freeware DOS and Apple programs on the XO.

Anyway, the Terminal Activity is pretty neat. The source code is very short, consisting of about 200 lines of Python. It uses a Python library called 'vte' to do all of the heavy lifting. 'vte' is, to put it mildly, a bit underdocumented. 'vte' is essentially a Python wrapper around the Gnome VTE widget.

So, to help others who might be curious about how the Terminal Activity does its thing, here are some handy links:

The Terminal Activity source code

earobinson's example Python vte.Terminal window
He ordered a G1G1 XO in November, so maybe we'll hear more from him...

The magic of Google code search lets us browse the vte source files
Of particular note: The "README" file, the "python" directory (and "python/vte-demo.py" in particular), and the sparsely populated "doc" directory.

The Gnome VTE Reference Manual
Not as useful as I had hoped, but does list out the API.

Happy hacking.

Dance Dance Revolution on the OLPC XO?!?

Dance Dance Revolution on the OLPC XO?!? Can it be true? Well, sort of. There's a nice open-source DDR clone called pydance that is fairly XO-friendly. It is written in Python, doesn't need gamer-l33t hardware to run, and gives a nice imitation of DDR.

Here's a really lame video I shot of Pydance on the XO:



Here's the songs I've created so far to use with Pydance on the XO:

I tried a few other DDR clones, and they either take a lot of work to get running on the XO, or need high-end hardware features.

I've created a first pass at a XO Activity that can be downloaded and installed. I would very much appreciate people trying it out and letting me know if it works for them. I don't think it requires any software packages installed before it to run, but I could be mistaken, as my XO now has a lot of stuff installed on it, so it is hard for me to tell.

I inclulded a couple of songs and dance tracks with the Activity so you can use it right away. But that does make the download larger, over 8 MB. Both songs are now Creative-Commons licensed; the song "Wolfie" is one that I created, with profound apologies to W. A. Mozart.

The Pydance Activity ".xo" file can be installed via the standard Journal method, but for now I advise using the Terminal and doing it by hand.

Also, the installed Pydance Activity can be run from the "Activity launcher" screen, but it currently has some issues. It is better to run it from the Terminal.

So, without further ado, here is one way to get and run 'pydance' on the XO:

1. Fire up wifi networking on your XO.
2. Start up the Terminal activity.
3. In the terminal activity, type in this:

   wget 'http://joviko.net/download/pydance.xo'

4. This will take a while, since the file is over 8 MB. If it finishes really quickly, you probably don't have wifi working on your XO.
5. Type in this:

   sugar-install-bundle pydance.xo

6. This will also take a couple of minutes. You should see lots of information about things being extracted, inflated, created, etc.
7. At the end, you should see:

   /usr/bin/sugar-install-bundle: 'pydance.xo' installed.

8. That's it! You're ready to play Pydance!

Now that you have it installed, the best way to run it is from the terminal. This will take a bit of typing:

python Activities/pydance.activity/PydanceActivity.py

HINT: The Terminal program has a very handy "typing autocompletion" feature. You can just type in part of a filename or program name, and press the "tab" key (|<-- over -->| on the XO keyboard). This makes typing in the above line faster ("{tab}" means "press the tab key"):

pyt{tab}{space}Ac{tab}pyd{tab}Py{tab}{enter}

When Pydance starts, it should begin by playing music and displaying a menu. (If it doesn't do this, let me know!) The mouse cursor will disappear. You can move between the menu items with the up and down arrow keys. Go ahead and select "Play Game" by pressing the "enter" key.

On the XO, you'll want to select a "4 panel" pad (so you can use the arrow keys on the keyboard or on the XO's display bezel). Use the up and down arrow keys to move to "4 panel" and then press "enter". Do this again to select "Single" mode (just one player, not two), and "Normal" (not repeating).

Another screen will appear, with the two songs that are available. Select either one using the up and down arrow keys and "enter". You can change the difficulty level by pressing the left and right arrow keys.

Now get ready! Notice that there are 4 "empty" arrows at the top of the screen. Arrows will slide up from the bottom of the screen and fill the empty arrows. When one of the empty arrows is filled, press the corresponding arrow key on the keyboard (or on the display bezel). Repeat over and over until the song ends. You want to press the key at the exact moment that the arrow at the top of the screen is filled in. The more accurate the timing of the presses, the higher your score.

When you are done playing, press the "solid X" key in the upper-left corner of the keyboard (the Escape key). Do this several times to completely exit from the game.

NOTE: If you run Pydance from the "Activity launcher" screen, there currently are some problems:

• The game doesn't completely exit correctly. The icon for the game will be stuck in the "Activity ring". To fix this, you must restart Sugar (press the "ctrl", "alt", and "erase" keys at the same time) which will kill ALL the Activities that are currently running, or restart the XO.
• The game is really sluggish and stutters when the "DJ" speaks. This still happens a bit when run from the Terminal, but it isn't nearly so bad.
• The game's icon isn't quite perfect yet. Nobody ever accused me of being a great artist.
  

Here are some things to try if Pydance doesn't seem to be working:

• The "pydance.xo" file might have been corrupted during download. You can check this by running 'md5sum' on the file:
  

  md5sum pydance.xo
  

  The result should look like this (for the old version, no longer available):
  

  e50f202a82013cb3f9e752be5b6cfdce pydance.xo
  

  or like this (for version 2):
  

  df93ea251a1a1708037897434489d8c3 pydance.xo
  

• It could be that the 'sugar-install-activity' didn't finish right. You can try to manually reinstall Pydance from the ".xo" file like this:
  

  cd
  cd Activities
  unzip -o ../pydance.xo
  cd
  

HyperCard on the OLPC

One of the most amazing things that came on the early Macs was a nifty (and free) program called HyperCard. HyperCard, under the covers, was an amalgam of a relational database and a high-level fairly-object-oriented programming language. On the surface, it appeared to be a rolodex-like stack of 3x5 index cards. Right away, without needing to learn any programming concepts, you could put images, sounds, and text on the cards, link the cards to each other, and even link them to programs outside of HyperCard. It was both very powerful and very intuitive, and a lot of people--especially teachers--went nuts over HyperCard and used it for everything. Thousands and thosands of stacks, some of which were quite sophisticated applications in their own right, were created.

My impression is that Apple management never really understood what HyperCard was or why some of their users were so fanatical about it, and saw it more as an expensive burden that didn't generate revenue rather than a key part of what made a Mac so special. I, like many many others, was quite sad when Apple officially dropped support for HyperCard a few years ago.

To me, HyperCard seems like the ultimate Activity for the OLPC XO. When I first started playing with the eToys Activity, I immediately thought, "Aha! This is a grandchild of HyperCard!". It would be really nifty if all of those old HyperCard stacks could be somehow run on the XO, either directly via some sort of HyperCard clone or stack "player", or by some form of conversion / translation to Squeak or Python or HTML. My guess is that a lot of those educators who were HyperCard fans would get very excited about the XO if they know they can run their old HyperCard stacks on the XO and even create new stacks.

Given the popularity of HyperCard, quite a few clones have popped up over the years. I fully expected to find a Free/Open-Source clone that runs on Linux, and halfway expected to find that said clone is already installed on the OLPC XO. No such luck. It seems as if most of the FOSS clones have either morphed into something else (these descendants can arguably include Wikis, the Web itself, and even Squeak), died, or stalled out. (From what I can tell, the FreeCard /XulCard folks are either still redesigning their project or have stopped work on it.)

There is one FOSS clone that is still chugging along, PythonCard. It is Python-based, runs on Linux, and looks pretty sophisticated. It also looks like a natural fit for the OLPC project. (Note that PythonCard is inspired by HyperCard, it is not a direct clone, so it cannot run HyperCard stacks.) I decided to see how hard it is to get it running on the XO. It ends up that installation is a little rough, but not too bad. Here are the steps I took to get it working to the point that I could play the tic-tac-toe sample "stack":

1. Get networking running on the XO so that 'yum' can download software packages.
2. Start up the Terminal activity.
   
3. Use 'yum' to install wxPython, which is needed by PythonCard; this will install a few packages, totalling about 20 MB.

   sudo yum install wxPython

4. Download the latest version of the (Mandrake) PythonCard RPM from here.
5. PythonCard isn't quite set up to run on Fedora 7 or XO Linux; it really is set up to run on Mandrake (which is a close sibling to Fedora). So PythonCard thinks it needs a software package called "python-base", which, from what I can tell, is mostly the Python stuff that Mandrake needs. So it doesn't exist on Fedora, and I think that PythonCard doesn't really need it; PythonCard just needs Python 2, which is already installed on XO Linux. So when installing the PythonCard RPM, tell it not to worry about dependencies and just go ahead and install.

   sudo rpm -Uvh --nodeps PythonCard*rpm

6. PythonCard currently uses Python 2.4 (there is a recent note on their developer format indicating that they are updating to 2.5). The XO has Python 2.5. So the PythonCard installer puts the PythonCard library in the slightly wrong place. This is easily worked around by created a symbolic link from where the library should go to where it actually is (all on one single line):
   

   sudo ln -s /usr/lib/python2.4/site-packages/PythonCard /usr/lib/python2.5/site-packages/PythonCard
   

7. PythonCard should be ready to run. Go to where the sample "stacks" have been installed and try to run the tic-tac-toe example:
   

   cd /usr/share/PythonCard/samples/tictactoepython
   python ./tictactoe.py
   

The next step is probably to "Activity-ize" PythonCard, so that it can be used without running the Terminal activity. It might be worthwhile to create something equivalent to the HyperCard "home stack" so that XO users can start playing in PythonCard without immediately having to jump into the programming aspects.

Marathon / Aleph One on the OLPC XO

I've added a couple of sucky pictures of Aleph One running on my XO laptop. They primarily demonstrate my complete inability to do anything with a camera beyond taking pictures of my thumb. (To be honest, considering my current hangover, they're pretty good, all things considered.) The game is nice and sharp on the XO; the blurriness is 100% due to camera operator error. The game graphics settings for these pictures are 1024 x 768, fullscreen on, 16 bit colors, "lightest" lightness.

Great news. Marathon (Aleph One, SDL port) works extremely well on the XO without a lot of flailing around. Graphics, sound, everything works, and it runs at normal speed. You can adjust the window size to fit the XO's screen, map the keys to use all of the XO keyboard (even the "Hand") keys.

I used an older version of the SDL port of Aleph One, because I could find a Fedora executable RPM file for it.

Here's what I did to install it:

1. Get networking going on the XO so you can download stuff.
2. Fire up the Terminal activity.
   
3. Download the Aleph One executable from here.
4. Download the M1A1 (Marathon 1 port) data files from here (38 MB).
1. The Durandal data files are at the same place (29 MB).
2. And the Infinity data files too (39 MB).
   
5. You can do this with 'wget' if you have problems with file corruption when downloading files via the Browser (I used tinyurl.com to make them a little easier to type in; they are the Aleph One app, M1A1, Durandal, and Infinity in that order):
   

   
   wget 'http://tinyurl.com/22f3dq'
   wget 'http://tinyurl.com/2pktd4'
   wget 'http://tinyurl.com/2y2wz6'
   wget 'http://tinyurl.com/2972x9'
   

6. Verify the files using 'cksum':

   cksum AlephOne*rpm

7. The checksum should look like this:
   

   
   2424315637 975702 AlephOne-20060701-1.i386.rpm
   2556424639 39747644 AlephOne-M1A1-1.0-1.noarch.rpm
   4011305905 30396946 AlephOne-Marathon2-1.0-1.noarch.rpm
   3852676019 40407980 AlephOne-Infinity-1.0-1.noarch.rpm
   

8. Install LUA, SDL, and libGLU plus all the supporting software:
   

   sudo yum install lua mesa-libGLU SDL SDL_net
   

9. Speex is also noted as being needed, but it is already on the XO.
10. Install Aleph One and the M1A1 data. If you get any "failed dependencies" in this step, let me know! I probably forgot to add something to the "yum" line that I had already pre-installed for a different game. If you get 'cpio' errors during this step, the download of one or both RPM files may have been corrupted. Download them again using 'wget' and check them with 'cksum'.
    

    sudo rpm -ivh AlephOne*.rpm

11. Done! Run Aleph One.

    
    alephone-m1a1
    -or-
    alephone-marathon2
    -or-
    alephone-infinity
    

12. Go to preferences, adjust the screen size, brightness, sound volume, keyboard mapping, etc.
13. Note that M1A1 starts with an "extra" scene; you need to go to the "flame dude" then to the left down a loooong hallway to get to the original start point.


14. Note that if you install ALL of the Aleph One files, that's about 100 MB, or 10% of the XO's total disk space! So, remove the .rpm files once you've successfully done the install and run Aleph One to test things out:
    

    rm AlephOne*.rpm

15. When you finally get to the point where Durandal has outsmarted you for the last time, and are ready to uninstall Aleph One, you can use 'rpm' again to get rid of it. The following instructions remove the Aleph One engine and ALL THREE games. You can pick and choose which games to remove individually if you prefer.
    

    su
    rpm -e AlephOne-20060701-1
    rpm -e AlephOne-M1A1-1.0-1
    rpm -e AlephOne-Marathon2-1.0-1
    rpm -e AlephOne-Infinity-1.0-1
    exit
    

16. If any of these 'rpm -e' commands don't work, you might have a different version of one of the Aleph One packages. To double-check, you can see the exact names of the Aleph One packages on your XO by running the following command (you don't need to be superuser to run this one):
    

    rpm -qa | grep -i aleph
    

M.U.L.E. on the O.L.P.C. XO

I made the first pass at getting the classic trading game M.U.L.E. running on the OLPC XO.

I loved playing MULE when I was a kid, and learned a lot about how companies and people behave in the real world. I liked how it wasn't just another racing, jumping, or fighting game. In fact, it had no violence at all, nor any adult themes (beyond the brutal realities of the free market system).

I strongly believe that it should be a part of every Econ 101 course, and that every student working towards an MBA should be required to win a tournament game against a cartel of ruthless 12-year-old monopolists before being allowed to graduate. I also think it is an excellent learning aid for youngsters who need to know how the capitalistic world works in the industrialized nations, and thus is a natural fit for the XO.

MULE's biggest weakness was and is that it takes a little while to learn how to play. It isn't complicated, but it isn't obvious either. You can't just mash buttons or wiggle joysticks and pick it up. You really need to read the manual or better still watch experienced players go at it. Once you learn the basics, though, you enter a world that is simple on the surface, yet leads to amazingly complex interactions between the players.

Anyway, I first considered using the ultimate emulator, M.A.M.E., to get MULE running on the XO. I downloaded SDLMAME precompiled for Fedora 7 via here, did the 'rpm -ivh' routine, and it installed fine and seemed to run OK. I'd guess that it would probably need some supporting software installed via 'yum' to be happy on a stock XO, but I've already installed things like SDL and Timidity++, so I'm not sure what exactly it would need. But setting MAME up can be a pain, and I wanted to use an app where I could just fire it up and play.

My second thought was to use iNES, an emulator for the NES that has been around for a long time and runs on many platforms. I downloaded the Red Hat version from the iNES website, uncompressed the .Z file on my Mac ('uncompress' isn't on the stock XO), and un-tarred the resulting .tar file on the XO. Then I ran 'ines' with the NES MULE ROM file (of which I will write no more), and there was MULE in all its glory, running at the correct speed and using the entire XO screen. Wonderful! Except it had no sound.

Thanks to cmonkey, the sound problem is solved. Just run this line and reboot the XO to get sound to work for iNES and a lot of other programs (but not DOSBox, sigh):

sudo echo "/dev/modprobe snd-pcm-oss" >> /etc/rc.local

'ines' uses SDL and looks for /dev/dsp, which the preceding line tells XO Linux to load the driver for and create.

In the long run, the best option is probably to get OpenMULE or one of the other recent noncommercial MULE clones running natively on the XO. This would allow MULE to be played over the XO mesh network and would avoid all intellectual property issues. I'll look further into that. But first, I've got a few Mechtrons to teach a lesson to.

Some handy OLPC links

Here are a few links with news and other handy stuff for the OLPC XO:

• The OLPC News
• The OLPC News Forum
• Doug Johnson's Blog (with some excellent comments)
• The HPI Software Architecture Group Squeak Games