Memorial Day

I really like the English version of the latest jffs dronz put together!  It's got just about everything I want on the zipit.  But I did make a few changes over the Memorial Day holiday.

First I fixed a tinyirc bug so it no longer wraps the status bar when using the large 8x14 font.  I tend to use a smaller font so I didn't notice the bug right away.  Sorry.

Then I went to work, making it just a wee bit more user friendly, at least for me.  I'm starting to appreciate gmenu2x as a program launcher, so I wanted that available right away on boot up, with no extra work.  At first I tried to get it going from the Zcovery startup script, using the toybox nohup to work around a problem with the hangup signal.  (Just like we did in olden days with the dialup modems).  But nohup wants to redirect stdout, which is troublesome for text terminal programs launched from gmenu2x.  So instead I simply fixed the bin/gmenu script to trap sighup just like on slug's jffs.  No more hangups means I can launch from the Zcovery startup script.  Yay!

With that problem solved, I modified Zcovery to first start a shell prompt in the background on tty1, then switch to tty2 to run gmenu2x.  Works like a charm.  But I'm pretty old school, so I want to get at that command prompt on tty1 at least half of the time.  To make it easy to switch between gmenu2x and tty1 I modified the three keymap files so ctrl-alt-home always goes to the command line shell on tty1.  I'm not actually sure I got this right in the calculator keymap, but I may try to eliminate the calculator keymap someday by remapping the keys inside the script like I did with zcalc.  Then I'd only need to maintain two keymaps.  Anyhow, ctrl-alt-home should work from gmenu2x or any SDL or text program launched by gmenu2x.  Then alt-rightarrow will get you to the gmenu2x text screen on tty2 and another alt-rightarrow will get you to it's graphics screen on tty3.  Sometimes the gmenu2x graphics remain on the screen after ctrl-alt-home, but you can clear that by typing cls or by pressing alt-rightarrow then alt-leftarrow to go to the gmenu text screen on tty2 and back to the command shell on tty1.  In this setup, SDL programs tend to run the graphics on tty3, leaving the text screen on tty2 in limbo.  With gmu and links you can type ctrl-z and bg on tty2 to free up the shell, however this is not advisable when running things from gmenu2x as it wants to manage both tty2 and tty3 for it's program launching scheme.

Once things were working satisfactorily, I decided to Americanize a few settings.  I changed the timezone file and switched the time format in the clock and alarm scripts to 12 hour time with no seconds because that's what I use here.  Since 99.9% of the time I only read things in English on the internet, I decided to compile an ASCII only version of links with SSL to save 200k on the jffs.  I'm seriously considering using the much smaller SSL-free ASCII only version to save even more.  I can always keep a full version of links on the SD card.  I also removed the green gmenu2x background.  I'd prefer to simply replace the wallpaper file if I ever get tired of the blue one.  That saves a few more K.

I used all that saved space to add the rockbox executable and a single codec to the jffs.  The rest of the codecs are softlinks to the jffs addon pack (or the normal IZ2S rockbox package) on the SD card.  Yeah, I know... rockbox doesn't really make any sense on the jffs because you still need an SD card for the music files, but I'm smitten by the coolness factor of it all.  Actually, now that I'm hooked on multiple ttys I may need to build a new rockbox executable because the current one doesn't realize it's supposed to give up drawing things when I switch to tty1.

 

Stock zipit boots into gmenu2x and plays the zipit sound in rockbox with no SD card.

There's still more Americanizing to do.  The gmenu2x glinks app file sends the browser to the french portal by default.  I'm OK with that for now, because it points to lots of handy zipit friendly internet sites.  I also need to switch a few other things like the gmenu2x settings tab to english.  But I think I'd like to get a build out there now because I like the new boot sequence so much.

In the future I still want to try swapping MatrixSSL into links instead of OpenSSL.  And I'd like to switch to slug's gmenu2x sources, then hookup the wifi icon and paste in the IZ2S battery monitoring code that I used for rockbox.  Both of these efforts should save considerable jffs space.  I also want to add the new set timezone script to the initial boot sequence.  Then maybe I'll get back to bunjallo for a browser choice somewhere between links and retawq in size and functionality.  Or maybe I'll see if it's possible to dim the status LEDs (like the backlights) or just turn them completely off when the alarm clock is running.  They're way too bright for night time.

I also need to figure out a better way to organize the goodie bag.  Dronz has been busy adding everything, which is great, but now there's so much in there I can't remember what it all is.  I'm not sure what would help.  Short descriptions?  Dates?  Pointers back to the original blog posts?  Gotta think about it...


Here's the Americanized jffs.  iz2jffs-v4-en.tgz
The old install instructions should suffice.

Here's the new keymap files with src, plus the new gmenu, tinyirc, and Zcovery.  That should make it easy to update the French version.  gmenu-jffs-fixes.zip

I forgot to include the tinyirc source code with the fixes the so I'll pastebin tinyirc.c

Teeny TinyIRC

In the comments of the previous blog post you'll find a bunch of goodies from dronz.

 

His latest iz2jffs setup attempts to squeeze gmenu2x, gmu, glinks, rockbox, and some handy scripted dialogs for multiple wifi profiles and system configs.  I was able squeeze out a little more space by reconfiguring the libs and now I'm tinkering with the rest.

For starters, as seen above, dronz prefers tinyirc to pmirc because tinyirc keeps your keyboard input isolated on a separate line so you don't get mixed messages when someone else is posting at the same time.  Ok, I can see where that might be helpful when composing a long line of text.  But pmirc squishes down to only 2K on the jffs.  At nearly 40K, tinyirc never seemed all that tiny to me.  So I went to work.  First I weaned it off ncurses and switched to ANSI escape sequences for the few simple screen drawing tricks.  That got the executable down around 17K which is much closer to what I'd consider "tiny". 

Once that was out of the way I figured I should probably take the time to zipitize it to make it more useable.  First I fixed it to stop scrolling blank lines whenever it received a PING message.  That was driving me nuts, slowly scrolling the real messages up and off the top of the tiny zipit screen.  Then I added the home, end, pgup, pgdn, and arrow key support to complement the emacs style line editing keys and make composing messages easier on the zipit.  I also added a -t command line switch to turn on message timestamps, and a ctrl-t key to toggle them on or off at runtime.  Finally I added a splash of color; red for errors, magenta for JOIN messages, and green for my messages because all the cool IRC clients have color, even lowly pmirc.

Here you can see my colorful JOIN.  And if you look real carefully, you can also see that I toggled timestamps on just before the JOIN.  If the channel is quiet you can tell if timestamps are on by the uppercase Z after the TinyIRC release number on the status bar.  A lowercase z means timestamps are off.

 I still need to edit the boot scripts to register an IRCNICK environment variable (maybe in ~/.bashrc).  That way I won't keep getting a 30 second countdown to pick a new NICK whenever I startup tinyirc.  Actually I need to edit all the scripts anyhow since they're currently all in french...

Here's the modified source and the smaller tinyirc executable: tinyirc.zip

In the Zone

I decided to use my renewed focus on the jffs to try and see if I could squeeze gmenu2x onto the stock zipit jffs along with gmu. (I've already fielded a few not so subtle hints from my co-worker that the linux command line is perhaps not the easiest way to use the zipit.)  This wasn't gonna be easy though because gmenu2x is fairly bloated with C++, freetype, and lots of png files.

The first thing I did was to cut it back to a minimal installation with just the default skin, only one translation (french), and fewer icons and the smallest background image file I could find.  See above.  I also ran all the images through pngcrush for good measure.  This resulted in a gmenu2x installation that was almost small enough for the jffs.  Unfortunately it didn't quite work when run from the stock busybox shell.  I had to build a tiny killall executable to enable my previous uclibc workaround from the iz2s build.  Then I had to make sure to "exec gmenu2x" from my gmenu wrapper script or it would complain about various tty ailments whenever it finished running an app.  Weirdness.

Next I attempted to link gmenu2x without libstdc++ according to these instructions.   But gmenu2x uses STL strings, dynamic casts, and more from libstdc++ so the best I could do was skip exceptions and static link with libstdc++.a.  The shared lib is about 800k stripped, and would would use about 300K compressed on the jffs, so I managed to squeeze a little bit out of it.  I recently discovered the jffs seems to garbage collect on boot up, which means I may have a reliable way to compare the space usage.  So I'll probably try to install the full lib someday to see exactly how much I saved.  Actually, I suspect I'll hold off on that until I find another C++ program that I just gotta have...

I also tried static linking libfreetype, but that didn't save anything.  A stripped libfreetype is 400K, or about 200K compressed on the jffs, so I bit the bullet and stuck it on there.  This meant I could also toss in the dgclock program for only 20K if could trick it to use the same font as gmenu2x.  So I moved the /mnt/ffs/gmenu2x/skins/Default/font.ttf file to /mnt/share/fonts/font.ttf and replaced it in it's original location with a soft link.  Then I soft linked the mplus-2p-medium.ttf file used by dgclock to font.ttf and voila!  The dgclock works.  The gmenu2x font file is fairly compact but I can barely tell the difference in the dgclock program.  It might have slightly narrower glyphs.  Maybe it'll be good enough for a few more small SDL-ttf programs.

This fit onto the zipit, but just barely, so I swapped out the wpa-supplicant and wpa-passphrase for my cut down versions.  The ones from the V1 firmware (and IZ2S) are fairly large, and the ancient wpa-supplicant was having troubles connecting reliably to WPA2 routers anyhow.  The new smaller version actually seems to work better.  This got me to about 700K free on the jffs.  That's enough room for some more small goodies.

While working with dgclock, I noticed the zipit appeared to be stuck in a different timezone (somewhere in europe?) instead of EST5EDT.  I'm not sure what caused it, but eventually I deleted the /mnt/ffs/TZ file and rebooted.  The timezone setting script popped up.  I entered EST5EDT, and it recovered.  Then I realized I was off by an hour because the 2007 daylight savings rules weren't incorporated into the iz2s uclibc.  Fortunately Dom pointed out the uclib TimeZone fix for the US 2007 daylight savings change in one of the comments here.    Down at the bottom it mentions the magic EST5EDT,M3.2.0,M11.1.0 setting for the /mnt/ffs/TZ file.  EST5EDT,M3.2.0,M11.1.0 is US Eastern Time with Daylight Savings Time starting on the 3rd month (March), 2nd week, day 0 (Sunday) and continuing until the 11th month (November), 1st week, day 0 (Sunday).

Here's a combo jffs image containing the base, gmu and gmenu2x packages to make it an easier install for newbs.  Note:  I said "easier", not "easy".

gmu-gmenu2x-jffs.tgz   Here's the install instructions.

And apparently the Goodie Bag was offline for a while.  Sorry.  I think I'll try and mirror it...

Uncontrollable Urges

In the midst of all my utf8 sleuthing I got the urge to revisit my problem using bash (instead of the busybox shell) to type extended characters with the European keymap.  Running loadkeys eurokeymap.map says, "assuming iso-8859-15 euro".  Hmm, 8859...  I went back to Prototypeur, followed the french wikipedia link and finally realized my error...  Ah ha!  That's not utf8.  It's just a full 8bit codepage.  The french wikipedia page is actually clearer than the english version because the compact table layout makes it obvious at a glance that this is single byte encoding.  The english table is bloated and confusing with octal numbers and redundant hex values.  Who really cares about the octal these days?  Octal's about as useful as Roman numerals.  The future belongs to hex.

To make it work I want bash to run 8bit clean instead of 7bit only.  Maybe that'll help for for utf8 too.  Here's how.

Make a .inputrc file in the home directory and put this in it. Or try a global /etc/inputrc file.

# .inputrc controls how programs using the readline library behave.

# This includes bash.

### Make Bash 8bit clean ###

# Enable 8bit input

set meta-flag on

set input-meta on

# Turns off 8th bit stripping

set convert-meta off

# Keep the 8th bit for display

set output-meta on

As if that weren't enough, while all of this was going on I finally got around to packaging up the gmu music player for the jffs.  This came about because a co-worker suddenly decided he was ready for his zipit that I'd promised to deliver (as soon as it was done).  You know how that goes with software.  It's never really done...  Anyhow, I came up with 3 potential configurations for the jffs on this zipit:  rockbox for mp3s and games, gmu for mp3s and internet radio, or mplayer and some simple bash wrapper scripts like these for mp3s, internet radio, and possibly some video.   The gmu choice was selected so I finally put that together with all the required libs.  There's still about 1.2MB on the jffs for extra goodies, so I really need to identify some programs that make use of all those shared libs to get the most bang for the buck...

Meanwhile, in testing the gmu package, I discovered that my latest base jffs was horribly busted.  The timezone script was missing all the /dev/tty0 redirection that's required for scripts run before owntty in the boot sequence.  Oops, that little mistake left you hanging on a blank screen, waiting for you to select a timezone from an invisible list.  Not good.  Here's a replacement timezone script for the 2 people who downloaded the broken jffs base.

tz-iz2jffs.zip

Here's a gmu package suitable for the stock jffs.  I preloaded the playlist with a few stations.

gmu-0.8-iz2jffs.tar.bz2

Terminally Insane

This one is a long rambling mess.  Sorry in advance...

I found a simple program at the Linux Productivity Magazine to display the curses ACS special characters.  When I tried it I discovered that some looked wrong, and some were missing on the zipit.  All of the box drawing characters there but the arrows were garbled, the "lantern" or vertical tab char was missing, and all of the 1 3 5 7 9 single scan line glyphs were missing except for the ones that do double duty as the dash and the underline.

I took a peek at the unicode table from my console font and discovered the unicode mappings for the scan line glyphs were way up in the Chinese section of the giant unicode table.  So I moved them back down into the 0x2xxx range, rebuilt the font file and voila, the scan lines were there.  Turns out ACS_LANTERN was just missing from my mcurses code. The arrows were a different story.  They're not included in the 32 characters of the DEC special graphics set.  I need to print a unicode character in order to display them, so for now I went with the default standby ASCII substitutes of <>^v for the arrows and # for ACS_BOARD and ACS_BLOCK.

It drives me nuts that I've got all these nice glyphs in the font and yet have no way to display them.  So I went looking for some simple C code to print a unicode character.  This turns out to be all tangled up with a monster sized locale and nls system on my desktop linux box. 

There are about a dozen environment variables that control all sorts of settings.  So I tried setting these up for US english with UTF-8 according to the notes on the internet.  Not only did this have no effect, but when I try to set LC_CTYPE something (bash, I think) spits back an error message.  WTF?  It's just an environment variable!  Shut up and set it.  You might think its some sort of conspiracy to force a huge bloated locale database onto the zipit in /usr/lib/locale.  Ok, it's only 2.5M but that's too much for the jffs and I think the FAT filesystem of IZ2S will bloat that way up because it can't use soft or hard links to avoid duplication.  Plus I really don't need the zipit to know what order I want my socks sorted, or what time in the afternoon to serve me tea.  I just want to be able to print all of the characters I loaded into my font.  Is that too much to ask?

Well I did some soul searching, and some google searching and eventually unearthed the magic escape sequences to put the terminal into UTF-8 mode and back (ESC%G and ESC%@).  Armed with this knowledge I wrote a short C program to print the ACS_BLOCK character.  And it worked!

Well, it worked in my gnome term on the desktop linux, and it worked on the zipit linux console in both bash and the busybox ash shell.  But it didn't work in gnu screen or dvtm.  Fooey!.  Actually it turns out I can make it work in screen if I issue the ESC%G from a shell script first and then run "screen -U".  Ok.  I can live with that, but dvtm just eats the ESC% and spits out the G. (I can't remember, but I think this script may have finally let me type UTF-8 at the bash command prompt, instead of just in the busybox ash shell.)

Fortunately the dvtm code is pretty straightforward (unlike screen, which may have a secret built-in nethack mode?). I found the ESC handler code and added a little patch to eat the entire ESC%G sequence and toggle the internal is_utf8 flag.  But then dvtm just prints three nonsense characters for my 0xe2,0x86,0x88 sequence instead of converting to the proper unicode BLOCK glyph.  The man pages tell me mbrtowc and the reverse wcrtomb functions are under the influence of LC_CTYPE.  It's that darn conspiracy again! 

Back to the internet for a workaround.  This sorta spells out the problem and it gives a hint about the leader of the conspiracy: glibc.  I'd bet uclibc doesn't even know about those locale files.  Anyhow, I found some magic c code to convert utf8 to utf16 with no mention of the evil LC_CTYPE conspiracy.  It worked somewhat.  Debugging showed everything converted ok inside dvtm, but ncurses still eats the final result, no matter what form I try to push through.  Probably in league with the conspiracy.  So now what to do?

Maybe I should try to build a small ncurses example and get it working before moving back to dvtm. 

Or maybe I should do something about the nl_langinfo() function.  This function is used by both the dvtm vt.c init code and the ncurses ncurses/tinfo/lib_setup.c file to determine if the tty is in UTF-8 mode.  The nl_langinfo function is in the uClibc libc.so.0 library and I suspect it's just a stub, hardcoded to POSIX and C locales.  According to the uclibc FAQ you can compile in UTF-8 locales but that makes it significantly bigger, depending on the number of locales. (http://uclibc.org/FAQ.html)  The IZ2S libc is pretty small at just under 300K.  Plus you supposedly had to fetch uClibc-locale-030818.tgz manually to build the locale support, so I doubt it's in there.  Grep found the word POSIX, but no mention of UTF, LC, or LANG.  At least uClibc seems to be on my side, resisting the bloat, just not in a useful way that lets me use my font.

It looks like I could undefine HAVE_LANGINFO_CODESET and recompile ncurses so it uses an internal nc_get_locale() function instead.  But then I might have to undefine HAVE_LOCALE_H so nc_get_locale uses getenv instead of setlocal(LC_CTYPE, 0) which always returns "C" instead of "en_US.UTF-8" (or anything.UTF-8).  And what about the NCURSES_NO_UTF8_ACS environment variable hack?  I may need to set that once I'm in utf8 mode in ncurses.  There appear to be some special case hacks in the code to do this for gnu screen and when TERM=linux.

I ended up with a special version of nl_langinfo() that scans the environment vars for UTF-8.  I also bypassed setlocale() in the ncurses lib_setup.c file and now I see a UTF-8 locale.  But the meta and control conversions are taking precedence over the characters.  e2 94 a4 is printed as M-b ~T M-$.  And the block glyph e2 96 88 is printed as M-b ~V ~H.  Darn it!  Ncurses is a tough nut to crack!

Anyhow, dvtm is off the hook.  I can't even get a simple standalone ncursesw program to print utf8.  Worse, I can't even get the test programs that come with ncurses to print utf8!  I'm either building it wrong, or something in uclibc is broken.  Right now, I can't even tell if ncursesw is even using the wide char routines, though it is 20K larger than the non-wide ncurses.  Stupid speed optimization macros make it really hard to decypher the code.  Besides, it's more likely that some other fn like isprint or isascii from uclibc is steering ncurses the wrong way.  Apparently ncurses uses just about every single function that deals with text somewhere.  No wonder it's so fat.  And yes, it uses isprint() in multiple places, and the man page implies isprint() needs a working setlocale() to handle utf8.  However the uclibc implementation of isprint is a friggin ugly macro in ctype.h, so I can't easily replace it.  The macro doesn't look like it even considers utf-8.  That means multiple hacks will be needed in the obtuse ncurses code instead.  Ouch.

Meanwhile the ncurses source directory has a wcwidth.h file that looks suspiciously like the substitute wcwidth fn I dug up.  And there are tantalizing hints in the test directory that just maybe there's a configure option to use libutf8 instead of the libc defaults.  Is that just for the test programs?  Maybe I should try it.  Then if it works try it with my test program, and then dvtm if that works.  Unfortunately I think it's a hidden configure option.  configure --help=short gives no clue how to change it.

My list of hacks was getting sorta big, so I decided to try libutf8 to replace the whole pile of crap.  It's kinda big though at 160K, and the easier to use shared lib LD_PRELOAD plug version wouldn't link in my scratchbox toolchain.  So in the end, all I can say is that I'm still working on on it...

Someday when I get things together I'll post the updated fonts, and maybe an new dvtm-wide.

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.

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

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...