Christmas Special

Sometime around Christmas rkdavis mentioned something about loading sdlBasic on the stock zipit jffs instead of rockbox.  Since I eventually want gmu on a zipit to be used as a dedicated internet radio, I figured maybe it was a good time to start separating the base jffs goodies from the rockbox stuff.

I also wanted to tinker with the wifi setup scripts.  I really like the easy dialog based EWoC wifi script included in later IZ2S releases, but I don't want to waste 200K of the jffs on the dialog executable.  So I dug deep into the dark old corners of the internet to review what could be done with ANSI escape sequences instead.  I found some really promising stuff and a related book that I'm gonna buy.  

But it proved difficult getting things to work well with the builtin echo command from the stock busybox sh.  And running ANSI escape codes with the external echo or printf commands from the IZ2S replacement busybox was just horribly slow.  So this is all I've got so far:  The previous SSID used shows up in green!  Not pretty, and my horrible photo skills don't help much either, but at least it's a marginal improvement.

Follow the directions from the previous blog post to install the smaller base system.  Then add whatever you want:  sdlBasic, busybox, tinyirc, or anything else that fits... (Hmm, it looks like you'll need to add either the full sed from the original package, or add busybox for its sed, otherwise the wifi scripts won't work.)

iz2jffs-base.tar.bz2

Anyhow, I trimmed down the old sdlBasic to something that I think will fit in the jffs on top of the base system.  I actually had to rebuild the executable because the previous build was pulling in libstdc++ due to my lame makefile.  That would have been 3 megabytes of completely wasted space on the jffs.  With libstdc++ out of the picture, I got all the libs needed for the sdlBasic runtime collected together.  I removed the docs and included only the Beast and Sokoban demos to save space.   Here's a nice blurry pic of me beating up on Sokoban level 1 to convince you that you absolutely must have it.

I personally don't want to mess up the jffs right now on my zipit by replacing rockbox with sdlBasic, so if anyone else tries it be sure to let me know how well (or not) it fits.

sdlbasic-iz2jffs.zip

Meanwhile, on the complete opposite end of the spectrum from this tiny stuff, I finally put up a download link for the Emacs I built for IZ2S way back when.  It's so handy, I feel compelled to share it.

More Small Thinking

Well, I managed to squeeze an extremely stripped down copy of IZ2S onto the jffs of a stock zipit, with rockbox, dropbearmulti, and the retawq web browser.  This means you can boot the zipit with no SD card and get on the internet in a pinch (kinda, sorta).  As you can see in this (somewhat blurry) picture of retawq browsing this very blog, with nothing in the miniSD slot.

But the main purpose is to be able to run rockbox from the jffs so you can swap SD cards with different music on them at runtime.

To make things fit I stripped and upxed all the executables.  The jffs does it's own compression, but upx compression is slightly better.  I also removed just about everything I could - fonts, languages, themes, plugins, libs.  You name it, it's gone.  There's about 800K left on the jffs if you find something missing that you just can't live without.  I made softlinks for the rockbox plugins directories, so you can play them off the SD card if you really want to.  Static linked executables from IZ2S can also run off the SD card, although if you want that, you should probably just boot into IZ2S itself.

One little gotcha trying to put this together was the IZ2S tar program.  I couldn't get it to *create* an archive.  Only untar seems to work.  So I had to relearn cpio to get test builds off the jffs with my softlilnks intact.  I haven't used cpio in like 30 years...

Anyhow, here's how to install.  Put iz2jffs.tar.bz2 on an IZ2S SD card and boot it up.  Then you want to delete just about everything on /mnt/ffs except the start.sh script, the wpa_supplicant directory with the wifi drivers, and the properties.txt file with your MAC address.  After that you can unzip the new stuff, power down the zipit, and boot it up without the SD card.

cd /mnt/ffs

rm Zcovery
rm Zipit2
rm *.xml
rm *.arl

tar -xjpvf /mnt/sd0/iz2jffs.tar.bz2

The SD card (with all your music) shows up in Rockbox as Files/share/sd0.

iz2jffs.tar.bz2

Update:  I've been fiddling with the busybox from iz2s enhanced because it has so many goodies.  It's almost 600K upxed, but it may be worth it since you can get 100K back by replacing the full sed and netcat utilities in /mnt/ffs/bin.  I've also compiled and upxed tinyirc (37K) and I'm still trying to decide if the upxed dialog utility is worth it for the wifi script at 150K.  Here's a zip with these if anyone else wants to play.

iz2jffs-extras.zip

Blank Slate

I've sorta lost momentum lately on the nano-x/fltk and sdlbasic projects, so I decided to spice things up a bit and take some risks mucking around with the internal flash on the zipit.  I had a zipit floating around that was loaded up with an older uboot and kernel from my earliest rockbox experiments on the wejp and z2lite userlands.  I thought it might be nice to replace all that with Mozzwald's spiffy looking OpenWrt rescue image.  So I booted it up in z2lite and ran his new uflasher script.  Not good.  Instead of the latest uboot and OpenWrt I get a blank white screen.  Probably shoulda booted z2sid instead of z2lite and flashed from there.  Oh well.  Live and learn.

Or maybe not.  I also had some unopened zipits with virgin stock in flash, just begging to be ruined as well.  Eh, why not...  I cracked one open, booted it up in IZ2S, and started tinkering with the stock files in /mnt/ffs.  It had no Zcovery app, just the start.sh script, the Zipit2 app, some wifi stuff and data files.  So I deleted the data files, replaced Zipit2 with an empty script file, and slightly modified the start.sh script to launch Z2covery (like it does in the updated stock filesystem you get after the virgin zipit phones home).  Then I created a modified version of the IZ2S Z2script.sh to work in /mnt/ffs on the internal flash instead of /mnt/sd0 on the SD card and saved that script as /mnt/ffs/Zcovery.  I also added dropbearmulti, the IZ2S power demons, and the fbcon drivers to /mnt/ffs.  Finally I booted it up without an SD card to see how much room I'd have leftover for a dedicated gmu internet radio (or rockbox) device running on the internal flash instead of the SD card.

Not bad.  Nearly 4 MB of the internal jffs is still available.  I think I can work with that.  Plus, the SD card automounts so I can use that to load different music, apps, or rockbox plugins on the fly at runtime, from a FAT formatted card.  Sweet!

Hopefully I can load this on virgin zipits to avoid the dreaded "Stock App of Doom" where the fresh from the box zipit gets permanently stuck in an infinite phone home and update loop.  I'm especially concerned about what happens when the update servers eventually go silent at zipitwireless.com.  Or have they already?

A Better Basic?

Remember way back in August, when I patched up an sdlBasic interpreter for the zipit and mentioned that there was more than one sdlBasic.  Well, there's been some lamenting lately on the zipit IRC that I shoulda picked a different one.  A better basic.  SdlBasic.  It's more shinier, and it comes with sound!  Ok, whatever.

Anyhow, I split the difference between the gp2x and linux makefile settings and compiled a version of the runtime for the zipit.  I still need to package it all up with some better zipitized example programs because it wants to run at 640x480, but the zipit is only 320x240.  The gp2x runtime package came with some patched .sdlbas files for 320x240, but they also had the keyboard controls modified to use the joystick instead.  Once again I split the difference and took the keyboard code from the original beast.sdlbas file and the screen size fixes from the gp2x code.  This is what it looks like with me fumbling around, trying to hold a camera and press the zipit alt-number keys to load the various .mod music samples. 

I think it shows a whopping 25 FPS!  35 if I run it without the music.  Shiny!

Files are here for now.

sdlbasic-iz2s.zip
sdlbasic-iz2s-src.tar.bz2

I Blame the Trees

Still not much happening in the software world.  The real world gets in the way.  We have electricity again, but we also have dozens of downed trees to cut up and remove, which leaves far too little time and energy at the end of the day for a whole lot of this stuff.  Gotta get me a chainsaw.

Anyhow, I did somehow manage to spend a few minutes testing things, trying to identify which lib causes the image display bug in the fltk example programs when the screen is rotated.  The pure microwindows nxview program is able to display pngs, jpegs, and bmps in any orientation so libnano-X is probably ok.  The next layer under fltk is the libNX11 X Windows compatibility layer.  So I took a ride in the wayback machine and dug up the ancient xv sources. 

Ah ha!  This program does all sorts of X11 trickery and only shows a blank splash screen when the nano-X server is running rotated. 

But it looks just fine in the native orientation.  So the problem is somewhere in libNX11.  Quite possibly in the cliping functions used by both FLTK and xv.

At this rate I should have it solved by Christmas.  I just hope it doesn't snow again for a while...

Update:

Apparently nxview has trouble with alpha blending.  Here it is in the native screen orientation.  The edges of the dice in the alphademo.png image blend nicely with the background color of the window.

And here it is with the -L orientation.

No blending!  I don't believe nxview uses libNX11 so that places at least some of the problems in libnano-X.

2nd Rate Utilities

This has not been a particularly fun week.  Winter arrived a wee bit early this year with a foot of sticky wet snow that plastered our third world electric grid, just recently recovered from the previous hurricane destruction.  Once again the local utilities proved to be not quite up to the task of restoration.  It's been a long, long 9 days so far without power and with temperatures most nights well below freezing.  Needless to say, all software projects are currently on hold. 

I did manage to get online (for a couple of minutes) only to find an email from my ISP announcing their nefarious plan to delete all my web files within a few short weeks.  Nice.  The Zipit Z2 Goodie Bag is now homeless.  Oh well.  The current location wasn't all that convenient with it's relatively tiny 20MB partitions.  It looks like I can get 100MB for files and a wiki for free on google sites, so it'll probably be moving there once the power company gets me some electricity.  And maybe I'll cancel cable TV to teach that ISP a lesson.  I haven't really missed it.  I just wish I could do the same with the local power monopoly...

Yet Another Calculator?

So it turns out Nano-X and FLTK 1.3 needed some extra lovin to get themselves working together real nice on IZ2S.  It took a while, but I finally got some freetype fonts loaded in the right place with the right config files.  Some small patches enabled kerning and anti-aliasing in nxlib and FLTK.

I also got the X11/rgb.txt color file installed so the Xlib example programs can use colors by name.  Unfortunately there's still some sort of clipping issue to work out when running nano-X -L to rotate the zipit screen to the proper orientation.  Images display fine when the screen is unrotated, but not when rotated.  Gotta fix that if I want to run Dillo on this thing. Anyhow this is what the mbasecalc calculator looks like, running with FLTK widgets on nxlib over nano-X.

It's got hex to decimal conversion (which I really like) and some nice shortcut keys for ease of use on the zipit.  I'm still thinking about tweaking the key bindings a bit though to minimize use of the ALT key.  And the calculator only uses part of the zipit screen, so it has room for more functions if I ever get really motivated.

Here's an FLTK font browser showing the list of fonts currently installed on my IZ2S setup.  Unfortunately there's currently a bug somewhere in either FLTK or nxlib that prevents all but the various sizes and shapes of the "helvetica" sans font family from loading. The good news is that font family looks pretty good, and fills most of  my needs.

I also fixed a few more issues with flwriter that were most likely caused by the jump to FLTK 1.3 from whatever old version it was last compiled with.  It works pretty well if you stick with the one working font family.  The default xhtml files load up just fine in the various browsers available on IZ2S, and the single rtf export file I created loaded up ok in word.  This is what flwriter looks like on the zipit with the anti-aliased fonts.

And here's the upgraded FLTK filebrowser with the shinier gtk+ theme and antialiased freetype fonts.  I'm not quite sure what to think of the microscopic  text in the preview pane.

Not too shabby though...

Refining the Layers

Just a quick update for now.  After playing with the FLTK demos for a while on the zipit I began to realize they could do with a bit of refining.  For example, the keymap still wasn't quite right, and nothing was really tuned to fit on the 320x240 screen.  I did a bit of tweaking in the microwin layer and got the alt key recognized as altgr so the keymap would work as loaded in all the microwin demos.  But then the nxlib layer needed another similar tweak before the fltk demos would work right.  I got that done, and moved onto the FLTK editor demo. 

I figure the editor demo might actually be useful as a simple text editor when launched from say gmenu2x, so I decided to take a look at that one first.  Most FLTK apps seem to have a few hardcoded window coordinates located in or near the main() function.  This turned out to be the case with the editor demo.  I adjusted the coordinates to fit nice and tight on the 320x240 screen and all seemed well and good until I hit the file save dialog.  Apparently the builtin FLTK dialogs are just a wee bit chubby for the zipit screen.  So I adjusted them a bit as well.  Here's the tweaked FLTK file dialog. 

I think it looks pretty nice on the zipit.

And since the simple editor worked out so well, I thought maybe I'd take it one step further.  So I poked around the internet and found some references to an abandoned old fltk word processor program that works with xhtml files and can export to rtf.  Hmm, that's almost borderline useful.  Maybe with some helper utilities to convert things...

So I compiled flwriter and tweaked it a bit for the zipit screen.  So far, so good, but it revealed a problem.  I still need to figure out how to install the fonts for nano-X.  I suppose that's next.  It'd be really nice If I could work out how to share the dejavu fonts in the netsurf package.

Layers and Layers (revisited)

Yet another of my long term goals for the zipit is to get FLTK working so I can build the Dillo browser, maybe murgaLua, and play with some light embedded GUI development.  FLTK applications have worked out quite well on some of the smaller linux distros like TinyCore and Puppy Linux.  So perhaps some of that good stuff could be squeezed onto the zipit.

Recently someone built FLTK 1.3 on Nano-X on DOS, so I figured if that was now possible, then a zipit port ought to be workable as well.  I followed some of the directions from the DOS port, and eventually figured out which options to select in the MicroWindows config file to convince Nano-X to build and run on the zipit.  The mouse was a bit tricky, but I eventually figured out the fake z2mouse was emulating a PS2 serial mouse, so all I had to do was softlink /dev/input/mice to the /dev/mouse device Nano-X was expecting, and it worked.  I still don't know exactly what to do about all the font options, but so far I haven't needed to sort that out just yet.

Now we all know by now that the framebuffer device on the zipit is actually a 240x320 pixel LCD oriented at a 90 degrees right rotation from the keyboard.  This must be accounted for whenever you want to display something on the screen.  Nano-X has a handy -L command line option to rotate the screen to the left for 320x240 pixels aligned with the keyboard.  But it also rotates the mouse coordinates, making the pointer 90 degrees off.  However, I found the spot in the Nano-X code where the mouse coords come in from all the various drivers.  So I added a 3 line zipit patch to rotate them 90 degrees to the right to match the real orientation of the screen.  And they remain matched up when the both the screen and the mouse are rotated by the -L command line option.  Nice!


I gotta revisit DirectFB and try to apply a similar mouse fix.  Especially now that I've got glinks running properly on SDL instead of DirectFB.  That leaves me completely free to discard the broken IZ2S DirectFB libs and start again from scratch.

I may also revisit the z2mouse driver itself.  The more I use it, the more I'm convinced that maybe the left mouse button should be on the play key instead of the center of the dpad.  It's nice for pointing and clicking to have all the functionality right on the dpad, with the lesser used center and right buttons off to the left on the play and stop keys.  But dragging anything takes 2 fingers, and it's really hard to get both of them in the confined space of the dpad.  So I'm thinking now that maybe the left and right buttons do most of the dragging work, so they should be moved off to the side of the dpad on the play and stop keys.  That leaves the center of the dpad for the center mouse button.  Easy to remember and it doesn't cross my fingers up dragging things around, or highlighting text.

Anyhow, FLTK seems to work.  Now I gotta just find me some FLTK apps to tinker with that work well in 320x240, or I suppose 240x320 if they don't need the keyboard.  These look pretty good, for example.  Perhaps eigenmath?  Or alsamixergui?

My Kingdom for a Calculator

Building the bc utility reminded me (yet again) that given it's form factor, the zipit really ought to have a decent calculator program.  Bc is ok I guess, but I can't remember more than the most basic syntax, and besides, it segfaults when I run it with the -l switch to pull in the math functions like sin() and cos().  I gotta see if I can fix that.  Maybe the IZ2S mathlib  is busted.  I sorta remember removing all references to doubles from  nightsky to get it to run right.  Maybe I need to rebuild a new libm.so with different floating point settings...

Anyhow, what I'd really like is to get bc working well and get a nice GUI wrapper for it like x-bc so I don't have to remember the syntax. I've already got something *almost* like that with the emacs calculator mode.

The emacs calculator has it's own command line math system like bc that works pretty well, and comes with a GUI that's ok with a real mouse, but quite a chore to navigate with the zipit dpad or via emacs key commands.  Besides, it's Reverse Polish Notation (RPN).  Yuck!  That's just not natural.  And finally, all the digits are still ALT key combinations on the zipit keypad which makes them difficult to type.  I suppose it could handy though if I want to calculate some numbers and paste them into a document, or vice versa.  I might look into tweaking the emacs lisp code to let me type digits into the calculator pane without the ALT key, but I'm not sure where my ancient lisp skills stand aftar all these years.

I did find a fairly simple SDLcalc program for the caanoo that might meet my needs someday.  It looks nice, but it has no keyboard input yet. Apparently the caanoo has a touchscreen?  Plus it's got some screen refresh issues, possibly due to the rotated screen on the zipit.  I think I'm gonna try to keep the GUI but add keyboard support and maybe switch to a bc backend when (if?) I get the bc mathlib problem fixed.

I'm not sure if it uses SDL, but the cal2x calculator for the gp2x looks pretty decent.  It even does some grahping if you're into that.  Me, I really want that hex button.  Unfortunately the source web site is korean and full of dead links.  Oh well.

Meanwhile, I thought to myself, there's gotta be an ncurses calculator out there somewhere that'll do the trick.  However the only ones I could find were all RPN style, like dcalc.  Err, yuck?

Then I stumbled onto tcalc, the mighty console calculator.  It's nothing more than a simple bash script, with ANSI escape sequences to draw the boxy graphics characters.  Wow!  Talk about retro, low-tech chic.  I had to dig up a console font with the box chars small enough to display the entire calculator.  And I had to adjust the ANSI sequences to move the whole display to the top left of the screen so it would show up on the zipit.  I'd like to add some color, but even so, I think it looks ok as is.

The last tweak I did was to adjust the key parsing routines to let me enter all the digits and the basic math keys without touching the dreaded ALT button.  That's a huge win for me!  It could do with a few function buttons, and once again, maybe a bc backend.  Someday, maybe...

tcalc-iz2s.zip

GMenu2X Revisited (again)

Looks like some of the issues I had with gmenu2x on the zipit have been discovered.  On the zipit IRC channel, dronz pointed out that launching programs with the gmenu2x wrapper setting chewed up memory like it was candy.  Not so good on the zipit with it's stingy 32MB of RAM.  The crappy uclibc versions of the fork and exec functions strike again.  So I created a fix, and rolled a new package along with the updated icons from a while back and some termula2x tweaks.

But what an ugly fix it was...  It turned out the execlp() call in gmenu2x was leaving the huge gmenu2x parent process hanging around, merely suspended and hogging up all the memory, waiting for the child process to die before exiting itself.  You can see it right there in the htop window launched from bash, which was launched from gmenu2x. 

I tried all sorts of clever  trickery with fork and temporary script files, but nothing really worked well until I got frustrated and tried something really stupid.  Running "killall -9 gmenu2x" in the bash shell launched from gmenu2x  did away with the pesky bugger.  So I simply added that to the wrapper script and voila!  It seems to work.  I may fiddle with moving the killall earlier in the wrapper script to free up the memory before the child process, but for now I think it's ok.

You can find the updated package here:

gmenu2x-iz2s.zip 

I still need to fix the launcher code to set the terminal right so emacs stops complaining about /dev/tty and bash no longer whines about not having job control.  The nanonote patch for this doesn't seem to work for me.   But I applied it anyhow, just in case I ever build a z2lite version of gmenu2x.  What does seem to work is running "setsid cttyhack emacs" instead of just emacs in the gmenu2x wrapper settings.  Same for bash.  Oh well, when I finally settle on a permanent solution for this, I'll probably have to do another gmenu2x package update.

The Long Way Around the Top

I'm not exactly satisfied with the ebook contents page produced by zpub, so I thought maybe I could make zpub build the html using the same algorithm as the original script.  But that uses the bc utility to assemble it's javascript and xml contents, and bc isn't included with IZ2S, so I figured I'd build it and see if it helped. 

At around the same time, I somehow got to wandering around on the nanonote wiki where I happened upon a shiny picture of htop running on the nanonote.  Ooh, shiny... Had to have it!  So I compiled it and tweaked the screen and keys a bit to better fit the Z2.  I love the way it lets you scroll to the right to see the entire command line.  Way better than the usual run-of-the-mill top utility!

Also around the same time I got to thinking about how I still really wanted a C compiler for IZ2S.  What's wrong with me?  That's just stupid.  But sometimes the only way to get these crazy ideas out of my head is to just go ahead and do it.  So I did.  Well... Ok, it's not really a compiler per se, but the PicoC interpreter is probably a better fit for IZ2S anyhow.  Since I had some previous trouble with floating point math support on the zipit I built two versions: one without floating point support, and one with it.

Unfortunately, before I got to test it all that much, I stumbled upon an SDL patch for the links browser.  What?  How did I miss that before?  With this patch I should be able to make a version of links for IZ2S that works properly, with or without the mouse, and without requiring the messed up DirectFB libs.  If it works, I can finally toss out the broken IZ2S DirectFB libs and remake them correctly from scratch whenever I get back to working on fltk, xdialog, vnc, or any of my backburner projects that need a normal working version of DirectFB.

Anyhow, I tweaked the links-sdl patch a bit for the IZ2S screen size, and for the current version of links.  I also added link traversal via TAB and BackTAB, and horizontal scrolling with the <> keys to make it more workable with zipit keyboard and the fake "mouse".  Initial testing feels good.  Gotta get it finished soon so I can patch bc back into the zpub script and see if it helps before something else pops into my head...

See?  The "mouse" actually works.

Look in the Zipit Z2 Goodie Bag for links to all the stuff.

Back to the Books

A long time ago, possibly in a galaxy far far away, I bought a couple of old H. Beam Piper books and started reading them.  Then Return of the Jedi came to the theaters and ruined it for me.  The Little Fuzzy characters prominently showcased on all the book covers reminded me way too much of those insipid ewoks!  So I packed them all up, never to be seen again until recently when I stumbled upon them buried in the attic.  I was well over my ewok phobia by now; watching the even more insipid Jar-Jar character with the kids had cured me of that eons ago.  So, to make a long story short, I finally finished reading the books, and enjoyed them enough to start searching for more.

Well, I visited the local bookstore and they had nothing so I went shopping on the internet.  Apparently many of Piper's books have lapsed into the public domain and are available for free at Project Gutenberg.  WhoHoo!  Score!  So I nabbed a few of the zipped .txt files and started reading them on the zipit with greader2x.  Not bad, but they're also available in epub format, and some of those come with pictures!  I had to have it.

After a tiny bit of research I discovered that epub is really just a zipfile with some xml packaging around html formatted books and/or chapters.  Once unzipped it can be read in a browser.  I found the ebook-tools C library which I might use someday to add epub support to greader2x.  But meanwhile there's epub-read.sh, a simple shell script to unzip, parse, and browse the contents of an epub file. 

The epub-read.sh script uses frames and javascript to provide a the table of contents, so I simplified it a bit for the somewhat limited browsers available on the zipit.  And thus zpub was born.  It works ok in glinks, but the text is kinda small for me.

You can edit the script and replace the call (near the end) to the glinks browser with links for text only epub reading, or with netsurf for something that looks more modern.

 
zpub.zip

Thinking Small

Apparently the Zipit folks have obsoleted the original built-in app on the Zipit Z2.  This means the jffs on the internal 8MB flash contains about 5.5MB of useless applications and data.  Worse yet, it's supposedly possible to get the stock app stuck in some sort of infinite loop of update requests if it's never been connected to Zipit wireless for an initial firmware update.  Now I've never experienced this myself, but I also haven't booted a new Zipit into the stock app for quite a while now.  If you're really worried about it you should probably bypass IZ2S and run the latest FlashStock to replace the firmware with uboot and the spiffy rescue image.  Then you can run one of the many uboot userlands like z2lite.

However uboot is significantly slower to boot than the stock bootloader, and all of the uboot userlands seem to require reformatting your SD card to ext2, which may significantly shorten the lifespan of the SD.  So I got to thinking, maybe I should consider replacing the stock app on the internal jffs.  Now, what could I fit into 5.5MB?  A minimal Rockbox installation would be sweet.  I could also go for a minimal gmu install to turn the Zipit into a dedicated internet radio device requiring no SD card.  But both of these apps are just a wee bit bloated for the 5.5MB available on the internal flash.  So how do I make them fit? We could use an IZ2S version of UPX to cut the executables and libs down to about one third the size.  Then things just might fit.

The UPX source compiled without a hitch and seemed to work just fine on the IZ2S rockbox executable.  Supposedly the source version of UPX has somewhat lower performance than the pre-built UPX executables, but sometimes you just have to take what you can get.  It's probably good enough for my purposes.  Now I just need to sacrifice the stock app on one of my Zipits and then see what fits.  Meanwhile, here's the UPX executable for IZ2S.

upx-iz2s.zip

Loose Ends

I managed to build both an IZ2S and a z2lite rockbox 3.9 release over the weekend.  You can find them in the Zipit Z2 goodie bag (link on the right).  I also built a common plugin package that works on both.  Well... Ok, I tested the rockblox plugin on both userlands and it seemed to work.  I'm extrapolating that success onto the rest of the plugins.  Actual mileage may vary.

Meanwhile the new ldraw forum is still active, and so the bug reports keep rolling in.  Maybe it's just that the programs simply need more documentation.  I've wondered for a while now how to best handle lsynth parts in ldglite, and how best to push them through lpub.  Others have apparently been thinking the same thing.  Fortunately I just got a new Windows 7 PC.  Just in time to shake out some of these issues, and to try the new All In One Installer for ldraw.  The result is I've gotta put out a new ldglite release with some updated search path support, in addition to the new color support I did a little while ago.  Also, I think I finally see how to incorporate synthesized parts in lpub.  The result should look something like this.

What worked for me was to break out the synthesized part(s) into separate files and make sure to tag them as part files with this meta-command in the header:

  "0 !LDRAW_ORG Unofficial_Part".  

This technique also works in one big mpd file if you don't want a bunch of separate files.

Basically Nothing to See Here

I finally made some progress on the software backlog.  I built the r3.9 rockbox for z2lite, with a complete set of plugins that should hopefully also work on IZ2S.  But I have yet to test it and package it all up.  Oh well.  Maybe this weekend.

Meanwhile, this tiny basic interpreter caught my eye.  Yeah I know, there are plenty of basic interpreters out there, some with the same name even.  SmallBASIC even looks useful with it's FLTK widgets and all, but I have a weakness for shiny things and a colorful screenshot pulled me in.  So I patched it for the zipit keyboard and applied this patch (except for the font doubler).  It seems to work ok with the example files.

SDL_basic-1.0.2-iz2s.zip (executable and source code)

Poor Man's GPS

Yeah, I know.  I really gotta go back and finish up some of the stuff I started.  But hey, sometimes you just gotta take the easy pickins.  My setup at home is still a mess, but I finally got a PC with Windows 7 on it at work.  So I naturally  wanted to test some things.  One of those things was VirtualBox, so I figured maybe I could start that up with quickie test of the IZ2S builder VM.  And coincidentally I'd just stumbled upon a picture of the PSP-Maps program running in glorious 320x240 pixels on the Caanoo.  Turned out all I needed was a few makefile tweaks to get it built for IZ2S.  And it seems to run ok too.  Woo-hoo!  Google maps on the zipit!

I tweaked the button mappings a bit so you can press the Zipit key and type a location with the keyboard. The arrow keys pan.  The +- volume keys zoom.  The <> keys toggle various map display modes.  And the Escape key brings up the menu. 

I was able to pan and zoom into NYC without any trouble, so I'd say it's useful already.  Here it is.

pspmaps-iz2s.zip
iz2s_libs.zip
IZ2S Makefile.

Source code
Tutorial

Summer Break

Wow, it's been quite a while since my last post.  In the meantime the Rockbox folks released version 3.9.  I built a test release of that for IZ2S and the sound quality has apparently returned to satisfactory levels.  So now I just need to build it (and the plugins) for z2lite and package up some releases to be back on track with the mainline Rockbox code.  However summer's in full swing here which means vacations, gardening, lawn work, and kids home from school are altogether too distracting to get much of anything done.  In fact the kids got a new dual band wifi router and relocated it into the living room, leaving my ancient wired network with all my zipit dev tools disconnected and out in the cold until I get motivated to crawl around the attic and connect them to the new setup.  Not likely under the oppressive summer sun...

So I gotta do something to keep busy until things cool off a bit.  Turns out things have picked up a bit in the ldraw world lately.  They got themselves a new forum, released a new batch of parts, and put out a new all-in-one installer which apparently installs ldglite as an optional component.  So now I've gotta deal with a burst of new bug reports rolling in all of a sudden.   Mostly about supporting all the shiny new colors folks are building with these days.  Here's the old ldglite color table.

And here's what they wanted, based on the latest ldraw package.

As you can see, I was missing quite a few of the new colors spread about the grey area.  Also some of the basic colors were redefined, which I've been resisting, but I finally gave in and implemented most of the "official" changes.  I only kept a few of the brighter candy colors from the original code.  It's all updated in CVS on the sourceforge.  I just need to do some releases...

Gmenu2x Revisited

I'm still working my way ever so slowly through the rockbox SVN revisions, searching for the one specific change that's dimming the high frequencies in the up to date rockbox code.  But since I can't hear so well these days I have to wait a bit between test builds for feedback on the zipit IRC channel from dronz who can actually hear the difference.  This occasionally leaves me some time to play with other stuff.

I found some SDL based vnc clients to play with, but they suffer from about as many issues as the framebuffer vnc clients.  I'll have to piece together a good one from all the best bits, someday when I have a solid block of time to think.  But not yet.

So I decided to pick at something a bit simpler.  Way back when, in the early days of my zipit experiments I did a test build of gmenu2x.  But then I got sound out of a rockbox build and put gmenu2x on the backburner.  Since I'd already done a build of gmenu2x I figured now I could spend my little snippets of time working on the config bits required to make it work right in IZ2S.  So I tinkered with the keyboard layout config file and setup a few apps to launch, run, and return to gmenu2x.  I also built the termula2x terminal program to see what that looked like when launched from gmenu2x.  The whole thing needs plenty more work, but all in all I think I like the way it's shaping up.  I can picture myself launching straight into gmenu2x for the car music player instead of hooking rockbox to the home key with e2bindkeys.

I put it here for now gmenu2x-iz2s.zip if anyone wants to try it.

I've recently updated the input.conf keymap file and some of the icons here gmenu2x-iz2s-icons.zip, and the source is available in the Goodie Bag.

Rockbox Revisited

Lately the nice folks on the zipit IRC channel have been full of useful rockbox tidbits, so I took a short break from the framebuffer goodies to do some more work on the rockbox goodies.  For the latest, check the Zipit goodie bag link on the right.

For starters, I finally built a t11 build for z2lite with the newer code from March so it matches the latest  IZ2S build.  I also found out on IRC that plugins built for z2lite (eabi) are somehow compatible with iz2s (oabi).  So I updated the plugins to fix some keyboard issues with bubbles and rockblox, and made new plugin packages that apparently run on either userland.  From now on I'll make a separate zip for the plugins.

However dronz on IRC discovered the r20 rockbox builds  from the January rockbox code have better high frequency sound than the t11 builds from the March code.  It'll take some time to track down and fix this so it may be a while before I get back to the vnc and framebuffer stuff.  Feel free to express your disappointment in the comments section.  ;^)

VNCx3

So it turns out there are at least three framebuffer vnc clients out there that might be useful in the IZ2S userland on the zipit.   There's the old ipaq/zaurus fbvnc that looks like a good fit for the tiny zipit screen.

http://pocketworkstation.org/fbvnc.html

There's a nice simple fbvnc here along with some other minimal fb programs.

http://litcave.berlios.de/

And finally there is directvnc which runs on top of DirectFB instead of directly on /dev/fb0.

http://drinkmilk.github.com/directvnc/

Naturally none of them really fit my needs.  The ipaq/zaurus fbvnc looks the most promising because it's got scaling, panning, and rotating already built in for use with small screens.  But the code is old and needs updating to make the keyboard and mouse work.  Also the nifty screen rotation goes the wrong way, so I can have the screen sideways, or upside down relative to the keyboard.  I borrowed the mouse code from the litcave fbvnc so at least that works now.  Panning also works.  I hooked in the battery monitoring code from rockbox, connected the backlight dimmer to some of the many variations of kbd led controls in IZ2S, and attempted to hook the volume control to alsamixer.  So if you don't mind working sideways with an onscreen keyboard instead of the real one, then you might be ok with this fbvnc as is. 

I suspect the keyboard will only take a small fix like the mouse, but the rotation is gonna be a challenge.  The rotation code is a bit of a mess with multiple unnecessary conversions back and forth between the local and remote coordinate systems, and massive hand unrolled loops to optimize the code at the point where it actually needs to draw the pixels.

The litcave fbvnc is no frills, and either uclibc doesn't like some socket call it makes, or else it's lack of password support is blocking me.  Either way, it's probably only useful to me as a source for the simpler mouse/keyboard code.

Directvnc connects and puts up a screen, rotated correctly by leveraging my previous work with DirectFB and SDL, but the mouse fails to move.  And the only keys I've verified are the Ctrl-Q key combo to quit.  I can probably borrow some working mouse code but once again the lack of panning or scaling makes this fairly useless on the zipit.

What I really need is the keyboard/mouse code from the litcave fbnc, the correctly rotated DirectFB screen from directvnc, and the rest of the goodies from the ipaq/zaurus fbvnc.  I may just end up with that eventually.

Layers upon Layers.

One of my goals for the zipit is to get gtk running on Directfb so I can have all sorts of goodies built outta gtk; like fbreader, some OpenStreetmap stuff, and even xdialog.  The Directfb folks have a recipe with about 100 steps to do this, but I'm not so good at following directions, so I haven't got it done yet.  I did manage to compile all the various bits and pieces, supposedly in the right order too.  But all the gtk programs I've tried (even the tiniest of demos) crash when I try to run 'em.  Prolly something's not configured right in one of the many layers leading up to gtk.  So I decided to start testing things from the bottom layer up.  

The first new layer in the gtk food-chain is Directfb.  Now iz2s comes with a Directfb of sorts.  It provides the g for the graphical links browser.  But it has a few warts, sorta like the iz2s alsa libs.  Once again the libs are compiled to look for things in a weird, nonexistent path.  The iz2s glinks works around this by explicitly linking with the fbdev and keyboard modules in their unusual location instead of allowing the main Directfb lib to load them on demand from the normal places.  That's fine for glinks, but it interferes with my plans to build more stuff on directfb.  Now apparently each consecutive version of iz2s has a different build of glinks.  And fortunately it turns out one of 'em was compiled with the normal lib setup.  But it had issues with the keyboard.  Oh well.  Also, I discovered the hack used to rotate the glinks display is really just a window rotate, and not a screen rotate, so the mouse does not reorient itself as well to match the display.  Once again, fine for glinks running mouseless, but not so good for me and my nefarious plans.

Then it hit me.  I've already spent a considerable amount of  time patching up SDL to solve various screen, keyboard, and sound issues.  And Directfb can be built to run layered on top of SDL in addition to running directly on fbdev.  Maybe I can fix both layers with one set of patches.  So I rebuilt Directfb with both backends enabled and tried it.  The SDL backend fixed the keyboard issue, the mouse rotation problem, and even the blinking cursor bug.  Whoo Hoo!  It doesn't support double buffer mode, but neither does the the fbdev backend, unless you run it without the 90 degree CCW rotation required to match the screen orientation with the keyboard.

I'll probably have to patch SDL yet again to add the rotated double buffering.  The SDL screen rotation code uses what they call a "shadow" buffer to hold the pre-rotated pixels.  So it's already double buffered.  The only difference is the timing of the updates.  The shadow implementation sneaks in the updates when you're not looking, whereas regular double buffering does it on page flips.  I honestly don't know how the SDL folks missed that.

Meanwhile I think I might just try to build fbvnc so I got something useful to show for all this work, not just a bunch of demos and an irrelevant mouse pointer for glinks.  And maybe I'll even do a little sidetracking and build FLTK_Directfb and then murga-lua, just in case I never make all the way up past gtk to the xdialog layer.  Otherwise, next up is the glib layer.  I gotta find me an interesting program that'll put glib through its paces without requiring a full up gtk install...

Blinker-be-Gone

Ok, so that pesky blinking text cursor interfering with all the SDL programs on IZ2S was starting to drive me nuts.  I know, there's a workaround, but who wants to make yet another wrapper script for every little SDL program I might happen to churn out.  But you know what?  I already made a new SDL lib for the ALSA sound support, so why not also patch it to get rid of that pesky blinking cursor.  Turns out the SDL_fbevents.c file already was already opening /dev/tty0 to access the keyboard, so I could also use that file descriptor to write the "\x1b[?25l" hide cursor escape sequence from the wrapper scripts whenever SDL switches into graphics mode.  One simple line of code and the nasty blinker is banished forever!  About time.

So I updated the SDL lib in here:  sdl-salsa-iz2s.zip


Still gotta replace it in all the other zip packages though...

Meanwhile I have a patch for directfp that might work, but only glinks uses directfb so far, and it still needs a wrapper script to load a different keymap.  So I'm gonna hold off on that patch.

I'm also sticking with a script for mplayer since it's a big static executable and apparently it works directly in the current tty rather than opening a free tty for the graphics.  So it needs a slightly different wrapper.

Here's what it looks like all cleaned up with the no-blink wrapper script.  You'll have to fetch the actual mplayer-rc2 executable from IZ2S 2.04.  This is just the wrapper and a config file that tells it to print as little as possible.

mplayer-iz2s.zip

On a Lighter Note...

So maybe all that e-reading makes you tired.  You need some lighter fare, like say some e-comics.  Or maybe you just want to review a new batch of pics from your camera.  If so, perhaps you've been looking for something like o2xiv.  It's a simple batch image viewer from the gp2x that also happens to work pretty well on the zipit.  Just don't ask me how to get those pics transferred from your camera to the zipit.  Maybe you got one of them SD cards with the built in wifi in your camera.  If so, perhaps this is for you.

 o2xiv-iz2s.zip

Careful, the zip file has the both the source code and a bin directory with executables for a bunch of different platforms.  You want the o2xiv.iz2s executable.  Put it in your bin directory and give it a shorter name that you can actually type on the zipit.  Or make a small wrapper script for it that kills that pesky blinkin cursor first.  It's up to you.

OK, enough with the fluffy light stuff.  Back in ancient times Gnu Emacs served a multitude of purposes as my preferred text editor, debugger, screen multiplexer, news reader, whatever...  Well it's back.  I finally compiled an IZ2S version of the real thing.  It uses every last bit of RAM and almost 100MB on the SD card (gotta prune it down a bit) but it's almost worth it.  Actually I'm not even close to sold on the tiny split screen.  But it makes for a nice screen shot.  Don't it?

emacs-iz2s.tar.bz2

When it Rains it Pours

The PDF reader got me thinking about ereaders in general.  I've tried FBreader on the on the eee-pc and thought it was pretty decent, but I'm not quite ready for the massive effort required to build the DirectFB version of GTK I'd need to run that.  Someday though...

So I looked around for a somewhat lighter ereader and found greader2x.  It only does txt files (and zipped txt files) but the build requirements seemed reasonable.  Well, I quickly realized that it needed the SDL_mixer lib for the built in music player, and that needed a different mpeg lib than the mpg123 I already had.  Fortunately I found a patch file on the net to convert it over to mpg123.  So I pressed on and built the lib and the greader2x executable.  It seems to work ok.  The music player is underwhelming compared to rockbox or gmu, but it played the few mp3s I tried on it.  Here it is, displaying the readme file that comes with it.  Simulated night reading with "oldbook" theme...

And here's the files:

greader2x-iz2s.zip

You'll need to fetch the GMU package for the codecs if you want music, and to be honest you may need it to run just the ereader part.  I haven't actually tried it by itself.

A Little Something for Nothing.

Well almost nothing.

Building all those libs required for netsurf got me thinking, "What else could I build to make use of all that stuff that I might want someday?"  PDF file viewers are occasionally handy, and always quite bloated with the libs.  So I figured maybe I could look twice as geeky, shopping for toys with a handy toy cheatsheet loaded up on the zipit.

I grabbed the sources for the nupdf program used on the nanonote and the dingoo and after a few false starts settled on the mupdf-0.5 lib to go with it.  Neither had a workable makefile for the zipit, so there was a little work involved to get them compiled, but nothing too difficult.  Now I still need to add a zipit keymap patch and move the nupdf config files to someplace sane, but it works ok for testing already.  Here it is showing off the super secret toy barcode decoder cheetsheet in glorious 320x240 resolution.

And here is a static build of nupdf for IZ2S.

nupdf-static-iz2s.zip

I suppose you could also use it for more serious stuff...

UPDATE:  I patched nupdf for the zipit keyboard and IZ2S filesystem and fixed the zip file above.  The nupdf source code changes and my makefile for the mupdf-0.5 libs are here.

nupdf-patch-iz2s.zip

Another batch of stuff.

Have I mentioned my short attention span?  The other day someone was talking up the netsurf broswer on the Zipit IRC channel and I thought, "Hey, that links browser is nice and all, but I'd really like something that renders the pages a bit cleaner."  So off I went on a compiling binge, building all sorts of libs required for netsurf.  It actually wasn't all that difficult to compile so I quickly loaded it up on the zipit and tried it out.  Looks pretty, but needs a zoom out function because it requires lots and lots of scrolling to see the pages as rendered.  And apparently you need a mouse to click on any of the links.  Why would anyone create an embedded web browser that doesn't support mouseless browsing?

netsurf-iz2s.zip 

Now I don't really think a mouse should be required to use a GUI program on a tiny screen like the one on the zipit, but I'd run into this before when playing with some SDL programs.  So I grabbed the z2mouse sources, added some key repeat code and built the fake mouse driver for IZ2S.  Since they share some device nodes and kernel modules, I tossed it in with the ebindkeys stuff from last week.

Run setup-mouse.sh and then you can toggle the mouse emulation on and off with the Options key.  If you also want ebindkeys you should run it before z2mouse, or you'll need to edit the ebindkeys config file to use event1 instead of event0. Because of this minor conflict, I set the Ctrl-Option key combo to terminate the z2mouse.  I'm not sure I'm gonna keep that in though because it currently leaves a z2mouse zombie process.  I also added an optional command line arg to z2mouse so you can set the key repeat rate for the mouse motion events.  The default is 20 motion events per second, but if that's too slow for you you can bump it up a bit.  Edit the z2mouse line in setup-mouse.sh and add a number for the event repeat rate, like "z2mouse 40" to double the default rate.

ebindkeys-z2mouse-iz2s.zip

z2mouse-iz2s.c

Now since freetype was among the libs I had to build for netsurf I decided to build the SDL_ttf lib and test that with the dgclock program in use on some other small gizmos.  You can use it to set the clock when you're not on wifi, and thus without ntp. 

dgclock-iz2s.zip 

I also built fbshot for screen captures and the sdl GUIlib okay program for testing the z2mouse.  And meanwhile, I'm actually starting to consider building the framebuffer version of gtk and then maybe xdialog so I can play with pretty scripted GUIs on the Zipit.

testprogs-iz2s.zip

Oh yeah, before I forget... here's the source packages for dgclock and nightsky with the zipit keypad mods and the matching onscreen hint messages.

dgclock-src-iz2s.tar.bz2

nightsky-src-iz2s.zip

A new day brings some new stuff for an old IZ2S.

Remember that bit about the double trouble?  Well, forget it.  Sometimes I have no idea what I'm talking about. 

I still don't really know what prevents me from puting a working libasound together.  It could simply be one of the zillions of ALSA config files is busted for all I know.  However I was successful with the salsa embedded ALSA lib.  I managed to build it and actually got some test programs from a beat up old Linux Journal to work.  I played with these for a bit, did some reading about "safe ALSA", and compared the way SDL wanted to use ALSA to the working mpg123 and aplay executables.  It turns out the simplistic buffering strategy used by SDL is probably ok for games, but not so good for gapless music playback on a stressed out low MHz linux box (like the zipit running IZ2S).  So I mercilessly hacked the SDL_alsa_audio.c file to make it behave more like the other programs.  Then I built a new libSDL with my changes, and with the tiny salsa library built right in. 

If you like, you can replace the old libSDL in IZ2S with sdl-salsa-iz2s.zip.  Then set SDL_AUDIODRIVER=alsa instead of dsp and go.  I recycled some rather under-utilized SDL_ALSA environment variables, just in case you want to play around and adjust the buffering scheme.  These are (lightly) documented in a text file included with the lib.

I also put together a real gmu-0.7.2-iz2s.zip package with the new libSDL since it no longer skips on IZ2S.  I must say GMU is really handy for debugging the audio code.  It's well written and easy to follow, unlike the gigantipus that is rockbox. 

I happen to like rockbox though.  So I rebuilt the IZ2S version with a more recent branch of code.  It has better (but not quit perfectly smooth) battery monitoring.  It can now change codecs on the fly and it no longer needs to move config files in and out of the /tmp directory.  It also seems to quit after 10 minutes on pause.  Perhaps that might help with the IZ2S power management?  I also let it use the standard linux file structure which prefers to install in the /usr/local directories instead of the embedded setup using the /.rockbox directory.  I'm not sure how much I like that, but for now it lets me keep the old and new versions installed at the same time for testing.  Here it is.  rockbox-iz2s-t11.zip

Finally, here's an ebindkeys executable for IZ2S with a setup to make the home key launch rockbox.  That's a single easy to find button so I can start it up in the car at night without turning on all the lights.  And here's another tip for the car.  Add a line to the startup script to soft link your music directory to /audio so it's right at the top of the rockbox file browser for quick and easy access.


Update:  It's a bit trickier to install rockbox themes on the new release.  You'll need to CD to the share directory on your SD card and temporarily rename the rockbox directory in there to .rockbox.  Then you can unzip an Ipod Video theme into the .rockbox directory.  Rename it to back to rockbox and you're done.

Also, unlike rockbox GMU only allows one key binding per function.  With the wide variation in default key mappings among IZ2S versions, this means that sometimes the volume is controlled via the +/- keys on the side of the zipit, and sometimes you'll have to use the prev/next keys.   So if you're using IZ2S 2.04 with it's default keymap and you want the volume controls on the side then you should edit the gmuinput.z2.conf file and near the bottom replace this:

Button73=280,Volume+
Button-74=281,Volume-

with this:

Button73=270,Volume+                                                                         Button74=269,Volume-

                                                                                                     
I suppose I could try to patch the code to work around this limitation.  Or maybe distribute several different GMU config files with the package.  I'll make a decision someday...

Double Trouble in the NightSky

Sometimes I have trouble focusing on one task.  So as you might have guessed, the internet radio plugin project took a hit this week.  I couldn't get a pipe, named or anonymous, to push the internet samples into the guts of rockbox.  Something, perhaps the rockbox buffering, perhaps my incompetence, always seemed to get the pipe closed before I got any data out of it.  So I went to plan B.  Just use rockbox as the GUI to select a pls file and pass its URL on to mpg123 or mplayer running in a slave process.  That was a quick failure on IZ2S when I discovered the IZ2S ALSA lib is busted and I've been unwittingly using the OSS compatibility layer instead.  Maybe that could explain the performance differences between the Z2lite and IZ2S versions?  I haven't got a clue.  But now I had a new mission to build a working ALSA libasound for IZ2S because with the OSS drivers there's no way to get rockbox and another player to share access to the sound device.  I think it bypasses the mixer, or something like that in sound system jargon.

Now as you might have guessed, this has not gone well.  The IZ2S scratch build environment appeared to come preloaded with an ALSA lib version 1.0.18 to build with, but as I discovered this was broken.  Apparently it was compiled in a buildroot environment and then pasted into the scratchbox env without testing.  When I tried to build some test programs they failed to link because the ALSA lib was built using an incompatible floating point option.  It used FVP floating point, but the scratchbox compiler was using FPA.  You'd think this would be simple as the xscale processor in the zipit doesn't have any floating point support, but what it really means is it just has to be done by some sort of software.

This led me to various history lessons on the deepest dark secrets of the wide variety of ARM floating point options, and on a quest for the mysterious missing libfloat which promised to let me at least link the test programs.  I don't think there's any chance it'll run because the VFP and FPA formats are word swapped.   Anyhow, I discovered that while there are some working VFP static linked programs in IZ2S, the static linked (and functional) ALSA utilities are not among them.  They were built with FPA floating point and ALSA 1.0.21 in some unknown build environment.

Ok, so maybe I could just build a new ALSA lib in the scratchbox build environment.  That's worked pretty well for all the other shared libs I've built.  But no.  It doesn't work.  Deep in the bowels of the libasound it loses it's way "refining the config" and eventually decides it's "unable to find an usable client format".  It looks like part of the trouble is with the sample rates.  It should report something like 8k, 16k, 48k, 96k, 11.025k, 22.05k, 44.1k as available, but it only reports 8k and 96k.  Hmmm, could this be a floating point problem? 

At this point I'm pretty sure the floating implementation in the scratchbox build environment is broken.  It uses gcc 4.1.1 and bugs like this one lead me to believe it's the compiler or uclibc that's doing me in.  Remember way back when I couldn't get doubles to work in night sky, so I eventually replaced them all with floats and it worked.  The ALSA lib code has only a smattering of doubles so I may try the same approach.  But first I might try building the much smaller SALSA library which is suggested for embedded systems by the ALSA folks.


If this all fails I suppose I can return to the buildroot setup and try to build static ALSA, SDL, and pthread libs so I can try a static linked rockbox executable with VFP floating point on IZ2S.  That doesn't sound like very much fun though.

Meanwhile, I really think I'm gonna need a debugger to get to the bottom of this.  Perhaps I should try to build gdbserver...