The summer of code started out on the right track. I decided to take pspmaps to the next level, and bought a tiny inexpensive usb gps to attach to the zipit. I made some great progress and someday I'll write all about it here, but not right now because I didn't quite finish anything to my satisfaction. Before I got there, I inherited a beat up crate of old school vinyl records from the turn of the 70s that otherwise would've landed in a dumpster somewhere. I couldn't let that happen, so I spent most of my free time over the summer converting the vinyl to mp3s for the zipit in the car, instead of polishing up the gps code. By the time I finished I'd lost my thread, misplaced my notes, and forgotten my passwords to both github and the scratchbox virtual machine I used for zipit development. Getting old and forgetful can be a real bummer sometimes.
Eventually the passwords came back, but I could not get any traction with the gps coding. My lack of progress was duly noted on the zipit IRC channel, and it was suggested that I should try to do something really dead simple to get back in the groove. Perhaps due to the sad state of my notes -- a jumbled mess of post-its and random scraps of paper -- the ctodo program was put forward as an award winning solution to this particular problem. One that could possibly fill a small gap in the productivity apps available on the zipit. So I gave it a quick compile on my laptop, but it segfaulted on my first key press. Award winning gold smiley program indeed...
I fixed that particular segfault, submitted a pull request from my fork of the project on github, and to my total astonishment the change was accepted and merged into the main upstream branch no more than a minute later. I really gotta learn me some organization skills like that ctodo author. Could running ctodo on the zipit could do that for me? Nope. It works on the laptop, but locks up the zipit. Maybe it's the screen size. I don't know. I give up. I can already do the same thing on the zipit with emacs if i were so inclined. I just happen to prefer scraps of paper and dusty piles of sticky notes.
Someone else on IRC suggested that noisy apps are fun on the zipit, and could I maybe finish porting the little piggy tracker that I'd abandoned unfinished many months ago. Sure, why not? I eventually figured out where I'd left my work on that project. What is it that makes some people (mostly object oriented C++ zealots and Apple computer users) name things like directories and source code files with a leading capital letter? It took nearly 3 weeks before I thought to search for a directory starting with a capital L. Oh, look, there it is!
Anyhow, when I previously abandoned lgpt I'd gotten it running, but the screen was completely black. This time I tried it first with an official build on the laptop and worked out the key sequence to quit -- right, right, A -- and then typed the same sequence on the zipit. Voila, it exited the program gracefully. Once I had that down, I located the logging function and instrumented just about everything that could possibly alter a pixel on the screen with debug messages. I found and fixed a few small coding oversights and eventually got the display working. I suspect the particular lgpt display code option I selected for my zipit build (generic SDL on the framebuffer) was written long ago, but never tested. Perhaps only the windowed (non-framebuffer) SDL code, and display code tailored for particular gaming devices, was ok. There were no guidelines other than the source code itself to help me out, so this was much harder than it really should've been. And to bump up the frustration level, once I got it displaying things and making sounds, I quickly discovered that it eventually crashes at random times when I try to use it on the zipit. I give up. Again.
After all this I was getting pretty desperate for something -- anything -- that I could call a success, so I set my sights a bit lower. Ok, a lot lower... I still like noise makers so I dug up a 12 year old drum program, the drumpiler which reads ASCII formated rhythms and pushes the expected sounds out through the speaker. Now that's something maybe I can understand. Write yourself a rhythm in emacs and then run it through a compiler.
The goodies will be posted right here, just as soon as I've created a satisfying rhythm I can call my own. Or maybe sooner, when I come to the realization that I actually have no musical talent to speak of.
Update: Yep, it's confirmed. I have no musical talent. I tried to whip up a simple GoGo beat, but it was so totally wrong that I had to rename the file to nogo.txt It's included in the iz2s package for your enjoyment.
drumpiler-0.9.1-iz2s.zip
Listen and laugh.
Update 2: I decided to keep going with the command line noisemaker thing for a little while longer, so I made an openwrt build of the drumpiler.
drumpiler-0.9.1-wrt.tgz
I also decided to investigate the similar jdkdrum program that should be available for openwrt from the openwrt-zipit package, but for some unknown reason the package failed to build. This one lays out the drum tracks horizontally instead of vertically, if that's more your style. I built it first for iz2s and it was somewhat sluggish starting up, but then it ran just fine once it started making noise. There's a bunch of floating point math involved in mixing the tracks before it plays, so I converted it to fixed point and now it's quite snappy on iz2s. I used the compiler on the zipit itself to build it for openwrt. That took less than a minute and went without a hitch, so I don't know what's wrong with the official package. Also, the original source worked ok with very little start up delay, most likely due to the superior eabi floating point implementation in the openwrt distribution. Here's the goodies.
jdkdrum-iz2s.zip
jdkdrum-wrt.tgz
And here's the jdkdrum fixed point patch.
I'm currently thinking about shifting away from the command line (but sticking with the console) to investigate the pineapple tracker, or one of several other forks of hardware chiptune tracker project code that you can find kicking around on github. I think it might be fun to get another ncurses style tracker running on the zipit, if I can squeeze it onto the tiny screen.
Update 3: I built both trackers (compiled and debugged them on the zipit itself) and they both appear to work ok. Pineapple tracker is quite a cpu hog, however I haven't yet tracked down the reason why. That's because the hyperbola tracker is small enough to fit easily on the internal zipit jffs. And with a few small code tweaks, it fits on the zipit screen with the 5x8 font. It's also very light on the cpu.
Debugging an ncurses application on the zipit with gdbtui was fun, but challenging. Even with an ssh session I kept hosing up the screen. If only I'd noticed this tip about the gdb tty command before I got things working. That lets me run gdb in a nice large ssh window on the laptop while ncurses operates on the zipit console. Perfect. I should probably debug a few more ncurses apps before I forget this handy trick.
Pictures and new goodies will be posted real soon now.
lgpt-iz2s.zip
hyperbola-iz2s.tgz
pineapple-iz2s.tgz
Update 4 (January 2016):
I Compiled some trackers for openwrt. Still gotta work on the pictures...
hyperbola-wrt.tgz
pineapple-wrt.tgz
These require an OSS compatible libSDL (otherwise they sound like garbage).
libSDL-1.2.so.0.11.3-wrt-alsa-oss.tgz
or
libSDL-1.2.so.0.11.3-wrt-alsa-oss-sticky.tgz
Unfortunately these libSDLs cause the gmu supplied on the jffs to segfault, so use with caution. The older gmu (version 8) that I have on my SD card works ok though. Investigation is ongoing... I think maybe it's something to do with the sdl timer code used in gmu9. I don't have a working autotools on my openwrt zipit, so I had to use the iz2s config.h file.
Meanwhile slug_ over at engine12.com, who still has a real working openwrt zipit dev setup (mine died in a disk crash), applied the sticky key patch, enabled oss, and made a real openwrt package. So this one actually works, and as an added bonus the official openwrt gcc is newer and better, so the resulting lib is smaller -- only 4k or so larger than the old one that comes with with the openwrt jffs.
libsdl_1.2.14-2_pxa.ipk
