Nothing to see here, again.

Not much happening here.   I'm working very slowly on an upgrade to the flipclock that makes use of the sfont image from the openwrt gmenu2x to display something useful in the large blank space at the bottom of the screen, without resorting to ttf.

I need to patch sfont to handle all the extra characters in the gmenu2x font.png file.  There is already an sfont extension for unicode out there, and also nfontc from nfont which does latin1.  I may try to use one of those, or code it myself.  I'm not sure at this point.  I also need to work on fading the font so it's not so bright in the clock app.  Here's a picture of the work in progress.  Pretty exciting, eh?

Update:

Naturally I got sidetracked from this endeavor almost as soon as I posted the picture above.  I discovered how to build upx with the magic lzma code for 20% smaller executables on the jffs.  I estimate I can possibly save up to half a megabyte on the jffs by recompressing the 10 largest executables.  Here's the new upx executable.

upx_iz2s_lzma.zip

And here are some recompressed links browser executables to show the improvement.  I also removed libtiff from all but the largest one, since I've been using links without it for a while now on my openwrt zipit and haven't missed it yet.

links_iz2s_lzma.zip

Now that's exciting.

And finally, here's the dronz super special links, recompressed along with a few other big programs.

big-programs-lzma.zip

Oops, that was not the super special links, but maybe this one is?

links-latin-ebook-lzma.zip

And here are a few small links executables for openwrt.

links-wrt-lzma.tar

Junk in the Trunk

It's getting near time to roll out another release of the iz2jffs.  Over the past 6 months or so I've put together a handful of small incremental improvements, that taken together, add up to a significantly better system.  Well, I like it better anyhow.

However before I get to that, I think I need to clean out the attic, so to speak.  I've got a bit of a backlog of minor goodies that never quite seemed worthy of a full blog post.  Some are hardly even worth a mention, but I need to push them out to clear my conscience.  It may take a few days to find them all and clean them up, so I'll start this out as something of a todo list and flesh it out as I go.

Most of this stuff runs on IZ2S (or iz2jffs if you can fit it).


There's the 10K imgv image viewer, and the larger zgv image viewer (already blogged).

I have a new IZ2S build of the rexima mixer that scales down better for use with a screen multiplexer.  (I might try to squeeze dvtm onto the jffs).

rexima-resize-iz2s.tgz

I built the 70K Frequency (fz) IRC client for IZ2S so I could have a scrollback buffer.

fz-irc-iz2s.zip

But then I figured out how to fix the keymap file to use the scrollback buffer already built into the fbcon console.  This puts the scrollback on the shifted volume keys:

    shift keycode 74 = Scroll_Backward
    shift keycode 78 = Scroll_Forward

I wanted a smaller dialog program for the jffs so I built a 70k lxdialog.

lxdialog-iz2s.zip

But I needed more options so I configured a lite 100K dialog executable instead.

dialog-iz2s-slim.zip

Then I built a smaller libncurses.so using the configure options from openwrt.  I recompiled dialog (again) to 40k, and dvtm to 22K, with both using ncurses as a shared lib.  This should fit about the same space on the jffs as the old dialog executable.   Now I need to find some more tiny ncurses programs to really make the shared ncurses lib worth it.

dvtm-dialog-curses-jffs.tgz

I've got some settings for the links browser for sampling internet radio with mpg123 that I blogged about a while back.   So I built a lite 50K mpg123 for use on the iz2jffs.  It uses the same libmpg123 shared lib as gmu to save space.

mpg123-iz2jffs-shared

There's a new version of bc, but I already blogged that one.  However I built sdlcalc before I figured out how to fix bc.

sdlcalc-iz2s.zip

I'm working on the nanoglk interactive fiction viewer.  Here's a screenshot.

I  still need to work out the font settings, which should fix the status line and make it readable.  I compiled a 10K SDL ttf font viewer program (sfontview) from puppy linux to help me with this.  I suppose it could fit on the jffs if you wanted to put it there.

sfontview-iz2s.zip

Here's another screenshot of nanoglk using the liberation fonts that I already had on my openwrt zipit.  Except for the status line, I like the DejaVu font much better, so this still needs a little work.  I probably have to bite the bullet and install the whole list of DejaVu fonts from the openwrt zipit package repository.

Here are some test builds of nanoglk.  Turns out my IZ2S zipit had a pile of DejaVu fonts in the /mnt/sd0/share/fonts/dejavu directory (probably installed there when I was testing netsurf, and/or fltk) so I went with that for the IZ2S build.

nanoglk-zipit-wrt-liberation-fonts.tgz
nanoglk-iz2s.zip

I feel really guilty about withholding the bunjallo browser executable, but its still more of a proof of concept than even a work in progress.  

I need to stash the openwrt Makefile for pspmaps somewhere, and maybe post the openwrt pspmaps package if I haven't done that already.  Hmm, looks like mozzwald already made a pspmaps package on github so I added the missing sdl_gtk lib to the DEPENDS line in that Makefile to get it compiling again in the nightly builds.  Unfortunately the nightly builds appear to have stopped sometime mid-November.  I'll have to try and get them started again.

And I gotta put the IZ2S sources for the naim chat client somewhere safe as well.

naim-src-iz2s.tgz

Last but not least, there's an IZ2S port of slug's gmenu2x that I posted a screenshot of a while back and then forgot to finish.  I'm still hoping it'll save me a little bit of disk space on the jffs once I get an  executable package finalized.

Heh, I couldn't even get a single goodie posted before I got distracted by the movgrab youtube downloader.  It integrates reasonably well with the openwrt links browser and mozzwald's youtube search portal.  For now, the details are in the zipit IRC logs.  I have not yet tested the IZ2S version.

movgrab-wrt-176x144.tgz
movgrab-iz2s.zip

Oh, and I almost forgot to mention the linenoise library.  I'd like to investigate the various incarnations of this tiny readline replacement lib.  I suspect it'll make for a nice, but still tiny, improvement to the interactive mode of picoc and a much smaller interactive build of bc, with linenoise instead of the rather large readline lib.

And another thing I almost forgot.  I compiled a full build of the flite text to speech program just in case anyone wants to use the nicer voices, even though they're too slow for the real-time conversion required for bard.  The first tarball is the full executable, with all the voices together.  It's pretty big.  The other tarball contains everything else from the build, including all the individual executables for the voices.

flitetest.tgz
flitebin.tgz

Pimp my JFFS

A few days ago someone on the zipit IRC channel expressed some dissatisfaction with the default IRC and web browser apps on slug's gmenu2x jffs.  "The web browser that was loaded on the sd image version BLOWS same with the IRC chat client".  Some pretty harsh critisism that, but fairly accurate.  The retawq browser and the pmirc script are the absolute smallest apps available that still provide enough functionality to get by in a pinch.  But now slug has pruned the jffs and put out an RC12 release with well over a megabyte of free space.  That's plenty of room to hold some fancier options.

On my iz2jffs system I use tinyirc.  It compiles to under 20K and provides better command line separation and editing than the pmirc script.  I added some optional timestamps to the code, but that's about it.  I wish it had a scrollback buffer option, but that'd be a fairly large patch job, so it's probably never gonna happen.  Armed with the native compiler on my openwrt zipit, I built a tinyirc executable and the somewhat larger Rhapsody IRC client with it's ncurses GUI.  I also compiled in the frequency (fz) client which looks like tinyirc, except with more colors and a working scrollback buffer.   See below.

On my zipit I simply renamed tinyirc to irc and used that to replace the existing /usr/local/sbin/irc executable.  That way I didn't even have to mess with any gmenu2x icons or settings.  I can be pretty lazy sometimes.

Not so long ago I updated the patches for the openwrt zipit build of the links browser to include most of my fixes from IZ2S.  But I left the rather large built in font alone, vowing to get back to that someday.  That day is today.  I fetched the various pruned font_include.c files from the IZ2S sources did some test builds with the ASCII only font set to see how small I could go.  First I added --without-tiff and --without-bz2 to the build options.  The results were encouraging but the executable still required some large openssl shared libs which aren't on slug's jffs.  So I tweaked the makefile to link in the static ssl libs and upxed the executable down to around 1.2 megabytes.  (I did some testing and large executables do seem to use less space on the jffs when upxed first).  You should be able to squeeze this onto the jffs if you really, really want it.  Just remove the retawq executable first.  You can probably also move libfreetype and libSDL_ttf from /usr/lib on the jffs to somewhere on the SD card to save even more space.  I don't think there's anything on the jffs that actually uses truetype fonts. It should look something like this.

Now I don't actually plan on doing all that much online shopping with the zipit so I decided to do another links build with the --without-ssl setting.  This one weighs in at just under 800K, which leaves room for other options.  Nice!  That's the one that's going into the jffs on my zipit (after removing retawq of course).  I'll try to do two more links builds soon with the slightly larger latin1 font_include.c file and see how that goes.

As I put the pimped up RC12 jffs to work I quickly found some more changes I wanted to make.  First I grabbed slugs updated gmenu2x executable so I could multitask on the extra virtual terminal without worrying about having the screen spammed with graphics from the other tty.  Then I loaded the simpler rexima mixer program so I can tweak the headphone or speaker settings while gmu is running on the other tty.  Rexima also squishes up really tiny if you want to use a screen multiplexer.   See all the empty screen real estate?

It gets even smaller if you split the screen vertically, as you can see in this screenshot from IZ2S.   In fact, if your terminal multiplexer can go that small, you should be able to access all of the controls on a single line 13 character window. 

By the way, I did see on the other tty that GMU does indeed use 70% of the cpu, probably due to the SDL audio buffering.  Gotta fix that like rockbox someday.  I also finally got around to adjusting the timezone setting on the jffs and copied over my gmu internet radio playlist and my browser home page with the shoutcast and other internet radio search sites.

Things were looking pretty good, but I really wanted to see if I could do anything about the default gmenu2x background image.  I figured with a little work I could free up most of the 70K used by that and still have something visually appealing.  The current build of gmenu2x has been pruned to use only png files, which makes this trickier than it otherwise would be.  However it turns out png supports color mapped images in addition to full RGB.  So I went internet searching for some shiny images with a mostly blue pallet that appealed to me.  I reduced these to 320x240 and saved them as png files using  mtpaint on my puppy linux netbook.  Then I converted them from full color to indexed, experimenting with 256, 16, and even 8 colors along with various resampling algorithms until I got a decent image with a file size I could live with.  Pngcrush provides the finishing touch.

The jffs still has over 340 megabytes free, but I'm pretty happy with it as it provides a realy decent fallback system for whenever my SD card eventually fails.  And it probably will fail someday because I've been beating on it pretty hard lately with the native compiler.  There was some additional whining on IRC about the nightly openwrt builds breaking things, like bard, quake, and supertux.  Bard is busted because the openwrt version of flite overrules the zipit build in the packages.  We fixed this before, but it happened again.  My old packages are probably still around, and I did some new flite builds recently to test the delux voices to see if they could do realtime tts for bard at higher cpu freq settings.  They cannot, but you can still use them to pre-convert a text book to audio and play it in GMU later.

Supertux can be made to work if you update your libstdcpp package to the latest version in the nightly build ipk repository, The new one is actually a few K bytes smaller anyhow.   I'm not sure what was wrong with quake.  I didn't actually try the ipk, but my test build seems work well enough so far as I can tell.

Goodies:

tinyirc-wrt.tgz
rhapsody-irc-wrt.tgz
fz-irc.tgz

links-ascii-nossl 
links-ascii-ssl 
links-config

gmenu2x with fix
rexima-wrt.tgz

sdlquake_0.1.1_pxa.ipk
sdlquake-shareware-data_1.0.6-1_pxa.ipk

I also created some latin1 links builds that might fit on the openwrt jffs.

links.latin.nossl.upx
links.latin.ssl.upx

And apparently despite documenting the links font reduction process a long time ago, I've never actually posted any of the modified links font-include.c files.  So I think it's time to remedy that.  However, rather than zip them up here, I've placed the font files on the openwrt zipit github instead.

Dividends

At some point during all the various updates to the previous post I noticed that dronz posted an update to his calculator package in the goodie bag.  I haven't really had time to test it yet, but I spotted the note about my crappy build of bc.  Way back when I compiled bc I got stuck, unable to fix a segfault with the builtin mathlib, so it was limited to only the most basic functions.  Good enough for the rudimentary math required for zpub, but not much else.

Well, now I have a native compiler and a debugger so I took another look.  Turns out the segfault was due to gcc 4.1 optimizing out some important initialization functions required for the builtin mathlib.  I turned off the optimizations, and now it all seems to work.   Ok, my "extensive" testing showed the sine of zero is zero, and four times the arc tangent of 1 is pi according to the bc mathlib.  That's miles better than a segfault.

I have the compiler running on an SD card loaded with IZ2S 2.04, and the keyboard drivers on 2.04 are a bit flakey, so I decided to build another bc executable with the readline command line editing enabled.  That adds quite a bit of bloat, so it's not really suitable for the jffs, but it did help me with my testing on the jumpy keyboard.  So I guess I'd recommend the readline version if you're gonna put it on an SD card.   Otherwise I'd upx the smaller bc and go with that.

bc-with-mathlib-iz2s.zip

Here's a site with tons of goodies for bc.

Another site with code for making animated graphs from bc.  Perhaps it could be combined with zgv or imgv to make a graphing calculator?

Update:

I spent a few minutes with dronz' latest iz2jffs calc script and tweaked it up a tiny bit.  The resulting calc script runs bc with -l to load the mathlib, lets me change the scale, and can apply subsequent operations to a previous result.  That covers about 99% of my calculator usage, except maybe when I want to do hexadecimal math.

Try, Try, Again

Previously I mentioned the premature demise of my openwrt and IZ2S development laptops.   I have backups for both, but they're on far from optimal machines.  So I've been itching to get something going with native compilers on the zipit.  Lately I've been having some luck with the aboriginal linux native compiler on my openwrt zipit, so I thought I'd give the other aboriginal native compiler some attention on the IZ2S zipit.

Running gcc -v tells me the native compiler I've been trying to use in IZ2S was built with --disable-multilib and --with-float=soft, which is incompatible with the hard float settings in all the IZ2S shared libs built with the scratchbox VM.  That's too bad because the xscale processor in the zipit has no FP hardware, so the soft-float setting makes more sense than forcing the kernel to trap whenever a function call attempts to pass an arg via nonexistant FP registers.  But even more disappointing, it means the aboriginal gcc is pretty much limited to producing static executables for IZ2S.  Someday I should try to use it to build a static version of nightsky and see if soft-float really is 10 times faster than trapping all the FP calls.

The scratchbox instructions on the wiki mention arm-gcc4.1-uclibc20061004 so I fetched gcc 4.1.1 and attempted to build it with the scratchbox cross-compiler.  I think the last time I built a compiler was way back before C++ even existed, so I was more than a bit intimidated by the complexity of a more modern compiler.  My first attempt to build gcc in VM didn't go so well, so i thought maybe I could build it right on the zipit with the aboriginal compiler.  I very quickly thought better of that plan.  Unzipping gcc on the zipit used way too much disk space.  In fact, I panicked watching it unzip all that stuff and hit the hard reset button, which naturally hosed the FAT filesystem on the SD card.  Poking around in the wreakage reminded me that the FAT filesystem doesn't support softlinks, probably a deathblow to building gcc.  Not to mention the zipit is too slow, has no memory, and the SD card would take a serious beating.

I came to my senses and decided to try again in scratchbox.  This time I did some homework.  Running gcc -v reveals the config settings used to build the scratchbox compiler.  Running ld -V tells what config settings were used to build the scratchbox binutils.  I took some notes and read (ok skimmed) the gcc build instructions.  So this time I built binutils first, configured to install in the /usr/local/share/gcc directory so I could keep it segregated on the zipit SD card.  That went fairly well, so I duplicated most of the config settings from the cross-compiler and attempted to build a native gcc.  It went somewhat better this time.  Near the end of the build it tried to use xgcc (a limited build of gcc) to build something - maybe libgcc and/or the final gcc executable.  But xgcc was an arm executable built in an earlier stage, so it segfaulted when run in the scratchbox environment.  I patched the gcc/Makefile to replace ./xgcc with gcc so it would use the scratchbox cross-compiler to finish the job.  This actually seemed to work and make install put what looked like a native compiler in /usr/local/share/gcc.

I gave it a whirl on the zipit and discovered a few problems compiling a basic hello.c program.  First of all, it couldn't find stdio.h.  I'm not sure how to get make install to put everything in the /usr/local/share/gcc directory.  So meanwhile I had to fetch the /usr/include and /usr/lib directories from scratchbox.  I used zip to pack these up for transfer to the zipit so it would make file copies instead of softlinks for the FAT filesystem used by IZ2S.  I also had to track down libc.so.0 because apparently libc.so is just a script that points to the real libc.so.0 somewhere in bowels of scratchbox.  I edited the libc.so script to remove the scratchbox paths so libc.so.0 could reside in the same directory as libc.so on the zipit.  I also made a compiler.sh script add the /usr/local/share/gcc/bin to the PATH and softlink the various lib and include directories into the proper places in the /usr and /usr/local sections of the filesystem.

This let me build the executable, but it wouldn't run.  It was looking for the /lib/ld-linux.so.2 dynamic linker instead of the /lib/ld-uClibc.so.0 I had on the zipit.  I fixed this temporarily with a softlink, which got the hello program running, but was quite unsatisfying.  After a bit of internet research I went back to the gcc build and edited gcc-4.4.1/gcc/config/arm/linux-elf.h to make LINUX_TARGET_INTERPRETER use the uClibc dynamic linker.  Reconfigure, rebuild, again.

Now hello.c compiles and runs.  Yeah!  So I moved on and I tried to build an IZ2S version of imgv.  It compiles and links against the IZ2S SDL libs.  Yes!  Couldn't do that with the aboriginal compiler.  But it segfaults when I run it.  Drat!  Actually, some of it runs because when I forgot to set the SDL env vars it rotated the screen before segfaulting.  I think that means it was actually doing some of the SDL stuff.  I ran imgv through strace, and it appears to blame gettimeofday?  Weird, but getting closer.  I ccould almost feel it.  I've had mysterious segfaults due to bugs in the ancient IZ2S uclibc so I also compiled imgv with the scratchbox compiler to compare.  It also segfaults on getimeofday so the compiler is off the hook on that one.

I went to my backup SDL test program - fgui.  This also segfaulted, but with a little debugging I tracked it down to the SDL_init call.  It was set to initialize SDL_EVERYTHING including the SDL_CDROM code.  I probably built SDL without cdrom support, so I reduced the init to SDL_VIDEO only and voila, it runs on the zipit.Looking back at imgv I see it inits SDL_VIDEO and the SDL_TIMER.  I bet the timer code is triggering the segfault when it trys to use the buggy uclibc gettimeofday function.  I might just have to rebuild SDL with some new fixes, or see if I can link in the gettimeofday function from libiberty.a instead.  And I should probably review the SDL_Init calls in some of the SDL programs I'd previously abandoned due to mysterious segfaults (like bunjallo and zgv).

So the good news is the native IZ2S compiler appears to work.  Yes!  Here's a screenshot of the freshly compiled fgui SDL test app in action on the zipit.

Now I just need to figure out how best to trim it down and package it up.  Can I get rid of the enormous pre-compiled c++ headers?  Apparently --enable-libstdcxx-pch is on by default.  This is actually a bit of a tough call.  The precompiled headers use 36MB of the precious SD space, but I suspect if I ever do any C++ they'll save gobs of time on the super slow zipit, by appending --include bits/stdc++.h to CXXFLAGS?  Maybe I should run some time tests.

Here's the native compiler (23MB).  iz2s-gcc.zip
The C++ precompiled headers (7MB).  iz2s-gcc-pch.zip
And a snapshot of my usr/local/lib and include dirs (40MB).  iz2s-gcc-usrlocal.zip

The native compiler contains a script (/bin/compiler) that you should source in order to setup some softlinks and environment variables.  You may want to edit he bin/compiler script if you want to enable a swapfile for compiling bigger things.

Update:

I moved the SDL sources to the zipit and did some debugging on the segfault.  Turns out it was pthreads that was causing the segfault in the sdl_timer code, not gettimeofday.  So I did some searching on the internet and discovered some references to problems running pthreads from shared libs (like say SDL).  The fix is in the linking.  I linked with -pthread before -lSDL and -pthread again (for good luck) after the -lSDL and the other SDL libs and now imgv runs just fine.  So does zgv.  Maybe uclibc has some fake pthread functions that get in the way if you don't explicitly link in the real thing?  I don't know, and I also have no idea right now what's the difference between -pthread and -lpthread, so I have some more reading to do...

Here's an imgv package for IZ2S: imgv-iz2s.zip
And here's a zgv executable for IZ2S: zgv-iz2s.zip

And finally, this is what bunjalloo looks like on the zipit.

Sorry for the poor lighting.  It's sorta ironic considering the headline article in the magazine I used for background.

Finch

Shortly after my last post, walrus43 mentioned on the zipit IRC channel that he'd like to get the Finch instant messenger client working on his openwrt zipit.  And he was hoping to accomplish that with the native compiler.  Wow, that's quite a challenge.  I remember that Finch beastie from the trials and tribulations of my IRC client porting days with IZ2S.  At the time I dismissed Finch as far too bloated to even attempt.  It's only C code, but it uses glib, which has a huge list of tricky prerequisites for a uclibc environment.  After several days of fiddling I actually managed to build a finch executable with the native compiler, but I haven't quite got it working with the protocol plugins.  So it's not all that useful in it's current state.  I'll try to finish that up shortly and publish the results, including my fake pkg-config script.

But in the meantime, I switched over to the cross-compiler and a built full working finch package to go along with the libpurple protocol plugin package already available in the zipit openwrt repository.  It's all in git already, but I'm not sure if I have to do any extra steps to force the nightly build system  to recognize the new finch package.  On my local PC I had to do this:

  make package/symlinks
  make menuconfig

Then select the finch package so my next make would build it.

Finch actually runs pretty well, but some of the dialogs are designed for screens taller than a standard  24 or 25 by 80 character terminal.  The default font on slug's openwrt only gives you 20 lines so this can be a bit of a problem.  However it looks like the smaller fonts I created for IZ2S make this workable.  Here's the 30 line preferences dialog with the 5x8iz2s.psf font file.

It might be a good idea to create a wrapper script for finch setup that does this before running finch.

  loadfont < 5x8iz2s.psf

Here's the goodies.  This is my first try.  It works but you may prefer the real ipk file below.

finch-wrt-with-libs.tgz

Unfortunately that finch executable had a bug which caused it to segfault on exit.  I found a defect report on this (#13739) which made it fairly easy to patch, so I rebuilt the finch executable and threw in the smaller IZ2S fonts here.  You still need the libs from the other tarball above.

finch-with-fonts.tgz

The package has arrived, but it doesn't have the smaller fonts or the gmenu2x icon yet.

finch_2.7.11-1_pxa.ipk

Workaround

In the waning summer days since my last blog update I suffered two crushing laptop failures.  Although neither laptop is completely dead, both are pretty much useless to me in their current state.  First, my ancient PIII thinkpad decided it would only run for 3 minutes before an abrupt shutdown.  Very frustrating.  I can just barely open all the windows needed for openwrt coding and then, bam, it's done.  A mere 2 days later the NVIDIA graphics chip fritzed out on my old Dell 620 (the one with the IZ2S development VM).  The poor thing still boots and runs, but I can't see what it's doing.  I'm gonna try to  dismantle it someday and reflow the solder to the graphics chip.  But that won't likely happen for a long time, if ever...

So now I'm down to an early EeePC netbook and a bunch of zipits.  That's just barely enough to workaround my laptop problem, but it'll have to do.  Since I was fresh off a successful rockbox build on the openwrt zipit, I figured that I might as well soldier on with that compiler and see what else it could do.  Unfortunately I tend to work much faster with a real keyboard.  The EeePC keyboard is extremely cramped but I can still sorta touch type without too much pain.  So the first thing I did was to build all the SDL libs on the netbook.   Now I can tinker on the EeePC first, before committing to work on the zipit.

Around the time of the laptop meltdown I managed to convince slug to rebuild the SDL library on his jffs and drop DirectFB to save a whole bunch of space.  I'm thinking a small build of the links browser would be a much better use of the precious jffs space.  But anyhow, he got it working only to discover he needed a way to do the splash screen without DirectFB.  So I poked around and found imgv, already in the openwrt packages.  It uses SDL for the graphics and has some nice features, but was lacking a command line interface that would allow it to run a timed splash screen.  I couldn't imagine an easier project to practice with the native compiler on the zipit.  In almost no time we had a working SDL splash screen and slideshow program, and slug made us a new rc12 jffs with plenty of room to grow.

Then walrus45 followed up on my imgv work and pointed out there was also a zgv openwrt package that could use some lovin.  Once upon a time I took a stab at building zgv for IZ2S because of the spiffy thumbnail image selector, but never got it to do much of anything.  For some reason, this time it was easy.  I just configged it to use SDL instead of svgalib, tweaked the fileselector to fit better in 320x240, and miraculously it all seems to work.  I still gotta get my changes worked up into an openwrt patch for github and the official packages.  Then maybe I'll try and build it with the native compiler on an IZ2S zipit.

You can fit up to 8 thumbnails on screen with the current set of hacks.  Originally it was limited to 2 thumbnails at 320x240, which (as you could imagine) was not terribly useful.  Here it is, zoomed to fullscreen on an old cell phone picture of the dog.  I haven't yet played with the slideshow feature to see how it compares to imgv.

Speaking of beagles...   Also around this time beaglebreath resurfaced and got me going again on the gpio code.  We eventually worked out that the kernel needed a small patch to enable the CIF camera gpios for use in sysfs.  Mozzwald supplied the patch, Slug whipped up a new kernel and voila, the gpios were working.  I managed to build some gpio testing hardware (no solder required ;) and beaglebreath got his weather sensor working on his openwrt zipit.  I'd still like to see if picoc can handle the timing requirements, because I think it'd be cool to have a full gpio prototyping setup on a zipit with no SD card.

 Here's my solder-free gpio test rig.  It's a bit unwieldy but I needed a way to include the pull up resistor to make the open collector gpio pins work.  The three clips on teeny tiny pins of the zipit connector had a habit of falling off whenever I tried to type a gpio sysfs command on the zipit.

Next up, maybe I'll get back to work on the flipclock.  I noticed that dronz recently added a fancy new timezone script to the the goodie bag.  Perhaps I'll try and fold the clock into gmu, with an internet radio scanner based on a shoutcast website that walrus45 pointed out.  Apparently this page works in the links browser, without javascript, although I don't have it working yet.  I tried to set it up via the links menu.  I went to setup>associations, selected "Add" to create a new association for the audio, and then created a new association with these settings:

  "Label":  shoutcast-pls
  "Content-Types(s)":  audio/x-scpls
  "program":  mpg123 -C@ %

I also unchecked something about X-Windows.  It didn't work at first, so I went back to the setup menu and picked "Save Options".  That seemed to do the trick.  Now I need to figure out how to control it better.  For example, Alsa Mixer lets me change the volume, but its a challenge to get there.


Here's the goodies (not much, really):

A zgv executable for openwrt (I still need to update the patches on github)
An imgv ipk for openwrt.

Bedtime Stories

Thanks to some nice folks at CMU, the zipit can now read aloud to me at night.  Apparently things have come a long ways since the eighties when I toiled away in a lab down the hall from the speech guys.  I sorta remember the speech recognition software at that time had some difficulty with my central New England speech patterns.  Or maybe that was a scene from a movie... I can hardly remember it was so long ago.

Anyhow, the flite text to speech system and the accompanying Bard Storyteller epub reader appear to be a perfect fit for the zipit.  If you don't like the "kal16" voice you can set Bard to scroll lazily through the document (still hands free) instead of reading aloud.  That's a step up from my cheesy links2 based ereader.  The only issue I've run into so far is the poor rendering quality of the pictures at the 320x240 resolution of the zipit.  I might take a stab at fixing that someday.

Here it is reading a relaxing bedtime story acquired from the archives at Project Gutenberg.  I feel sleepy already...

For some reason the name and the sound quality of the kal16 voice made me think of "Karel the Robot", the intro to programming book used at CMU way back in the early eighties.  Or maybe it was just that story.  I don't know.

I put the zipit patches for this on github, so pretty soon now the nightly build should generate some official ipk files.  I really wish git would make that easier, instead of giving me trouble every single time I try use it...  Meanwhile, here are some openwrt ipk packages that work for me.

bard_0.7-1_pxa.ipk
flite_1.5.5-1_pxa.ipk 
libzip_0.10.1-1_pxa.ipk

More of the Same

Yet another month of very light blogging.  And once again, I did actually accomplish a few things that I just simply haven't yet managed to write about.

I was lurking around on the zipit IRC channel lamenting the apparent demise of some zipit sites (and locating the backups on google and in the wayback archives) when beaglebreath mentioned he was looking to move some of his weather monitoring gpio code over to openwrt from z2sid.  Now z2sid comes with a native compiler, but openwrt is where most of the action is these days.  So I thought, hey! openwrt has a package with the PicoC small C interpreter.  Maybe that could handle it.  You only need to read and write some files in sysfs to work the gpios for the weather sensor. Based on my experience with PicoC on IZ2S I figured that'd be easy.  Of course reality gets in the way.  Openwrt had PicoC, but it was on an old version of PicoC, just before the file IO support was added.  Figures. I bumped it up to the latest version on the zipit openwrt github, and then added a tiny patch to convince openwrt to build it.  I had to switch some of beaglebreath's file IO routines to use stdio instead of fcntl.  But with that small change it seems to work for me.  However it's still unclear if it can actually handle the IO for the sensor.

At this point I decided to try a real native compiler instead of the C interpreter in PicoC.  I started with tcc because it's tiny.  It seems to work, sort of.  But I got stuck trying to link anything against uclibc.  Without a libc, file IO would probably be a challenge.  So I revisited the self contained aboriginal linux gcc that worked so well on IZ2S.  Because openwrt is eabi I was able to use the arm5l compiler which is quite reasonable for the arm5tel processor on the zipit.  I built a few hello.c progams, which worked, but the weather sensor program gave the same results as PicoC.  Hmm, maybe we're using the wrong source, or perhaps the sysfs works differently on the openwrt kernel than it does on z2sid.  Since I don't have my own weather sensor I'll have to dig up a logic analyzer someday and watch the IO lines to verify once and for all if PicoC can do it.  I still believe...

Meanwhile, I opted for a real challenging test of the native compiler.  Rockbox!  I got it to build way back in February with the buildroot cross compiler setup from openwrt, but it ran like crap so I gave up on it.

This time I compiled it on the zipit with the native compiler, but wouldn't link against the openwrt SDL shared lib.  Possibly because the libs are stripped?  I don't know.  I gotta swap in the unstripped libs someday and see what happens.  Anyhow, I still had nagging doubts that maybe the previous performance problems could've been fixed with my buffer patched SDL from IZ2S.  So I compiled the IZ2S SDL and salsa code on the openwrt zipit and static linked rockbox against it.  That was a bit of a chore, and the rockbox executable is now about 300K bigger, but it runs nice and smooth.  I had to fetch perl, some perl modules, and coreutils-install packages from the openwrt package repository to work through the rockbox build and install process.  I also created a 32MB swapfile needed to compile a few of the codecs.  Otherwise the build was fairly straightforward, if somewhat tedious.  I even compiled a pile of plugins.  Rockblox, anyone?

I still wonder if the performance problems with the cross-compiled rockbox could be fixed by installing a replacement SDL like I did on IZ2S.  Someday, maybe...

The apps on my openwrt zipit are now looking a whole lot more like my IZ2S zipit apps. 

Here's the goodies.  I updated these from the betas so now all the codecs are included, as well as a gmenu2x icon, and the key bindings on the rockblox and bubbles plugins have been fixed up.
rockbox-wrt-r3.9.1.tgz
rocks-wrt-r3.9.1.tgz

I finally managed to link against the shared libSDL using the unstripped libs from my openwrt staging-area.  So I upxed the smaller rockbox.bin down to just under 280K if you want to try and fit it on the jffs.  But it does sometimes skip when it first starts up.
rockbox-wrt-shared-upxed-r9.1.1.tgz

I also created a rockbox wrapper script with dronz' bass and treble setting settings.

RockboxWrtJffsInst.sh will set you up to use it when you boot from the jffs. This may not be required if you're using the overlay scripts.  I haven't tried them yet.


The updated PicoC is available from the openwrt package repository.

Here are some interesting PicoC links:
PicoC enhanced for a commercial PLC
PicoC robot code documentation

There might be something wrong with the openwrt gdb package so I compiled it on the zipit just in case.

gdb-wrt.tgz

Like Clockwork

Heh, not really like clockwork.  I've actually been somewhat remiss with the blogging lately.  What can I say?  It's summer.  Oh wait, I already said that, didn't I...  Anyhow, last time I made a teensy tiny bit of progress on my zipit clock radio dream project.  Well, it's now been another 4 weeks and once again I haven't really got much to show.  But a little something is still better than nothing, so here it is:  My first attempt at porting that maemo flipclock app I've been lusting after.

As you can see, after resizing it for the zipit I've got plenty of room on the bottom for other goodies like the date, alarm settings, or even the weather from the internet via the http://www.google.com/ig/api?weather=zipcode API, or somesuch.  I'll probably try to  steal some ideas from this nifty weather clock for z2sidX.  There's not actually whole lotta code in the flipclock, so I also just might attempt to paste this into GMU as an additional screen with maybe a truncated playlist in the empty space down below.  Although, I'm kinda sorta waiting to see what's in the mysterious GMU update release hinted at here before digging into that code again.

Oh well, I'm really not sure where I go from here, but I'm sure I'll get there eventually.

Here's a zip with the sources and an IZ2S executable.  flipclock0-3-iz2s.zip

Blinky Lights

Not so long ago I mentioned that the dronz alarm clock in the jffs was nice but... even with the lid closed the LEDs on the zipit are too darn bright and keep me awake.  At least they're only green and amber, and not those evil blue ones that seem to be popping up on just about everything these days.  I swear the blue ones can trigger migraines and burn holes in the backs of your eyes, but that's a story for another day.

Anyhow, the LEDs have gotta go if I'm gonna get any sleep.  I already had a utility for controlling the right LED, so I just dug up the GPIO numbers for the other two LEDs from the wiki, and patched it into the existing IZ2S powerbutton and lid checking MCB program.  The only tricky bit was the GPIO for the  middle LED defaults to an input for some strange reason, so I had to borrow some more code to set the direction register.  That seems to work, so now you can softlink the new "lid" executable on the jffs (or copy it on IZ2S) to a bunch of new utilities for the left and middle LEDs.  I also added commands to query the current state of each of the LEDs, so they can be saved when the clock starts up, and restored when the alarm goes off.

Here's a zip file with the new "lid" executable, the source code, a script to make all the softlinks, and another script that prints all of the current LED states.  Nothing really exciting, but hey, I need my sleep.

ledctrl-iz2s.zip

Summer Vacation.

Wow, July is half over and I haven't posted anything for weeks.  I've done a little bit behind the scenes, but every time I settle down to tackle something on my todo list the dog gets the urge to go outside and play.  And somebody has to go with him.  It's not so bad though...

It's actually kinda tranquil now that the bridge replacement is finally finished.

So what have I got to show for all this lack of effort?  Well, not much, really.  I did update a few previous posts with new qemacs executables for IZ2S, z2sid, and openwrt.  I really like qemacs now that I've added the missing features.  I still have to try and make a real openwrt project for it, but I'm slowly inching closer to that particular goal. 

Projectgus opened up the openwrt-zipit project on github, so I've been trying to learn more about github and the openwrt build system.  To do this I decided to update nupdf from a mipsel-only openwrt package to one that builds against the same (more current) mupdf shared libs as the fbpdf package.  The nupdf source archive appears to be inactive, so I cloned it onto github to do the update, and then added the zipit keyboard patches.  I then borrowed openwrt Makefile settings from the gmenu2x package to fetch the nupdf package via git from github instead of svn from google code.  Seems to work. 

Apparently the old static IZ2S nupdf package also works on openwrt if you simply unzip it into /usr/local, so maybe someday I'll try and run it on z2sid as well.  I'm pretty sure it's already available on z2lite.

Oh yeah, I also finally posted the gcc/gdb package for IZ2S in this old post.

A Little Less Failure This Time?

This week started out much like the last.  More adventures in failure.  The guys on Zipit IRC seemed to be struggling with an improperly rotated links -g running on DirectFB in openwrt.  I pointed out Ray Haque's secret sauce for that problem, but failed to get it done.  So I got the bright idea to try and build it myself, with SDL and all my favorite patches from the IZ2S world.  Sound familiar?  Yeah, and it started out exactly the same way.  One failure after another. 

To start with, I had an old failed rockbox for openwrt that I never quite got working right.  It runs, but horribly, and eventually I lost interest and moved on.  Shoulda took that as a warning.  Stay away.  But no, I fired up the old P3 with my openwrt setup on it and updated all the git archives following Anarsoul's instructions.  At least I thought that's what I was doing.  Apparently the browser still had a cached version of the instructions from last February when I was working on the rockbox build.  And the cached instructions contained a typo.  A dash character in one of the feed names prevented me from building the qi repositories with the links package that I wanted.  For several hours!  The guys on IRC were quite helpful, and we eventually worked out the problem only to discover the instructions on the internet were already fixed, and probably had been for months.

See.  There's the typo, right there.  Can you spot the difference?

Oh well, moving on.  So I started the P3 building the goodies and watched for a few minutes before... guess what?  Hard disk failure!  Aargh!  Stupid old 80GB external drive developed a bad superblock.  I sorta remembered this drive gave me trouble before so I decided to abandon it and get a newer one rather than try to fix it.  Someday maybe I'll try to recover the bad rockbox build with one of the backup superblocks.

The next day I nabbed a 500GB drive from one of the kids and started over.  I refetched all the openwrt archives, followed the correct instructions to setup the feeds and started the build again.  Then I went to sleep, exhausted but hopeful.  The build failed a few times on supertux, the kbd package, and libmpg123 so I had a few restarts to do the next day.  But eventually it built everything else I'd selected.  Gotta see what's up with kbd and libmpg123 since I may want them someday.  But for now I'm gonna build with IGNORE_ERRORS=m to keep it going after failures.

Anyhow, the links package compiled so I just needed to apply my patch from IZ2S and rebuild.  Or so I thought.  I tested the patch in the directory with the links sources and it applied cleanly.  Cool.  However when openwrt compiles, it wants to wipe out the directory with the package sources, start fresh, and apply it's own patches.  But it took a while to figure out how to remake my patch the way openwrt wants it.  You need to make it run with patch -p0 so the destination directory name in the patch must match exactly with the directory name in the package tarball used by openwrt.  At least I think that's the case.  It's hard to see exactly what the byzantine openwrt build system is doing, even with the V=99 command line option.

I got some more hints from the IRC guys on how to reproduce the openwrt build environment so I could manually step through the patching and configuring and try and fix the broken parts.  I don't think I ever completely reproduced the environment but got close enough to figure out some of the trouble spots.  Apparently for openwrt you need to make a makefile for each package that runs configure to create a makefile for the package.  Hmmm.  I examined the existing meta-makefile and attempted to convert the tricks used to configure directfb into tricks that would configure links for SDL.  It didn't exactly work.  The openwrt build process was successfully applying my patch, but failing during the configure stage because it couldn't find SDL.  I tried looking at some other packages like nupdf and sdlwidgets for SDL config hints, but to no avail.  As many things do, the answer crystalized in my sleep, and when I woke up I found the sdl-config program I needed in the openwrt-zipit/staging_dir/target-arm_v5te_uClibc-0.9.33_eabi/usr/bin directory.  I fixed up the meta-makefile with that path.  Now the configure stage managed to find SDL and moved on... only to fail writing the new makefile.  Syntax error in the patched configure script!  Did I already say arrgh!?

Now, the original SDL patch from the internet required me to rerun autoconf to create a shiny new configure script (and Makefile.in) with SDL options.  I did that for my IZ2S build, but I have no idea how to do that in the openwrt environment.  Also, different versions of autoconf tend to generate a completely different output files.  And configure is over 600MB!  So I'd attempted to make a small patch for the configure script that would paste in only the changes involving SDL and skip all the gratuitous changes caused by the different version of autoconf. That got me all the way to the syntax error.  I took another look at my patch, and the modified configure script, but that's not work meant for humans.  Hand editing 600MB of butt ugly machine generated script file is not my cup of tea.  Even the mighty emacs with it's color syntax highlighting and electric parenthesis matching wasn't helping me deal with the horrendous tab formatting.  So instead I gave up and changed the openwrt meta-makefile to replace the whole 600MB configure script with the one I'd regenerated earlier with a different autoconf on a different PC.  Oh well.  It's kludgy, but it works.   

Not Fail!  Yeah!

The new openwrt Makefile, patches, some zipit friendly config files, and key docs are on github.

I put up the links-sdl_2.3pre1_pxa.ipk package for openwrt zipits, with config files and a kbd cheatsheet.

Here's my wrt-env.sh script (modified from slugs).

Update:   Anarsoul added PKG_FIXUP:=autoreconf to the Makefile to auto-magically regenerate the correct configure script as part of the openwrt build process.  And projectgus pulled it all into the master github project, so you should be able to get the links package from the usual place.  Cool!

Meanwhile, here's a qemacs executable for openwrt.  I still need to learn how make it into a real openwrt-zipit package...

Adventures in Failure

A few days ago I mentioned my desire to try compiling right on the Zipit.  It ought to be possible.  It seems like just yesterday I had Linux with X Windows, emacs, gcc and all sorts of goodies running just fine on a junky Cyrix "486" CPU with only 16 MB of RAM.  What happened?

Anyhow, just as I was lamenting my failure to debug Bunjalloo in IZ2S the subject of rockbox on z2sid came up once again on the zipit IRC channel.  Ah Ha!  That's been on my todo list for quite a while now.  I knew z2sid came with a working gcc right from the get go.  I could start with that project and work my way back to the IZ2S compiler.  To make it easier for me I tarred up my pre-patched rockbox 3.9 sources instead of updating the zipit patch to the current release version.  Gotta do that someday...

I dumped the sources on a 2GB z2sid SD card I had lying around in my collection and booted it up in my one working uboot zipit.  I started up the rockbox configure script, picked the zipit target, and failed because it couldn't find the SDL dev package.  Ok.  That makes sense.  I should be able to get that with apt-get install libsdl-dev.  Unfortunately that took a lot longer than I wanted because I forgot you needed to be root to use ewok or wifi-config to get connected.  Also the wifi-config scripts all need to be edited to replace eth1with wlan0 in order to work in a uboot zipit.  I'm not sure why a zipit needs a user account in addition to root.  Everything I want to do on it seems to need root permission, and really!  Who cares if somebody hacks into my $10 toy via the free wifi at MacDonalds?

Eventually I got connected and ran apt-get update (twice for good luck) and then apt-get install libsdl-dev.  This was taking a while so I set it aside to finish while I went out for some old man hockey and beer time.  When I got back it was done, and successfully too!  But apparently apt pulled down dependencies for just about every SDL backend out there, including Xlib!  WTF!  The poor SD card was full up to the limit with only a few measly megabytes leftover for me.

So for giggles I ran make on the rockbox sources and let it go overnight.  As expected, it ran out of disk space and failed.  Oh well.  Maybe I'll try again, with a fresh install of z2sid, compiling my own lean mean SDL with only the framebuffer and salsa backends.  That might just leave enough space on the SD card for a rockbox build.  If only the zipit uboot was stable enough to work with larger SD cards.  I have a bunch, but no luck with anything over 2GB.

But really, I think I need to put zipit compiling on the backburner for a while.  If anyone has a bigger SD card and wants to try this, I put up the rockbox sources here.

  rockbox-zipit-src.tgz

You'll need to build SDL or get a libsdl-dev package.  Then do this.

cd rockboxtrunk/tools
rm bmp2rb
rm convbdf
rm codepages
cd ../build-zipit
cp autoconf.h autoconf.h.save
../tools/configure

Type 205 to select the zipit target.  This will configure an IZ2S build target.  You don't want that because the battery monitoring code is for the older kernel.  So open up the Makefile with nano or vi and remove the -DIZ2S from the EXTRA_DEFINES line.  Hopefully the battery monitoring code for the z2lite kernel is good for z2sid.  Also, I made the zipit config target use the SIGALTSTACK_THREADS option, but never got it to work so you have to restore the autoconf.h.save with the SDL_THREADS option instead.  Then maybe it'll build.

cp autoconf.h.save autoconf.h
make

Cross your fingers.  If it succeeds, strip the rockbox.bin file then:

make install.

Maybe strip the codecs in the /usr/local/lib/rockbox dirctory and borrow the /usr/local/bin/rockbox script from z2lite.

Update:  I discovered I was using the z2sid version with the enormous j (junk?) file on the root directory so I deleted that and tried again.  Still no luck.  Turns out it was the /tmp directory running out of space.  The /tmp directory has only 1MB, so maybe I'll make a /usr/tmp and export TMPDIR=/usr/tmp to see it that moves things along.

Update 2:  That actually got me most of the way through the build.  It appears as if only the initial tool building stage needs the extra TMPDIR space to reproduce the bmp2rb, convbdf, and codepages utilities deleted above.  Subsequent rockbox builds don't need it.  However I hit a snag on the assembler code.  I was forced to add -mcpu=xscale to the makefile get any arm assembly instructions above armv4 to build.  That got me all the way through the "make install" step.  Still didn't work though.  The main rockbox executable brings up the GUI and everything looks good until I pick some music to play.  Then...  "Codec Failure".  Oh well.  At least that's familiar territory.  The SDL codec loading section of the rockbox source code is overly convoluted, and I've had to tweak it a bit before for earlier IZ2S and z2lite builds. I'm not looking forward to repeating that work though...

Meanwhile, since the z2sid compiler seems to work well enough, I decided to build a qemacs for z2sid to make it easier for me to edit and debug the code on the zipit. 

  qe-z2sid.tgz

Maybe You *Can* Teach an Old Dog New Tricks

The other day while floundering around on the net I noticed qemacs 0.3.2 was out, with some compiler fixes.  Because of it's size and feature set (split windows and a shell) I tend to use qemacs on all sorts of embedded platforms, and on the zipit.  However its got a few quirks that constantly drive me nuts.  The one that really gets me is the missing repeat feature on the C-k key.  It kills me that I can't use consecutive C-k keystrokes to add multiple lines into the current kill buffer.  I use that all the time to cut and paste multiple lines of text between emacs windows.  To make matters worse, I never managed to get alternate the C-@ and C-w (mark and cut method) to work on the zipit because of the unusual keyboard layout.  So I finally decided to dig into the code and add the missing functionality.  It wasn't actually all that difficult to fix.  Shoulda done it years and years ago...

While I was in there I figured I might as well add the missing scroll keys too.  I've been using C-z and M-z to scroll my editor windows up and down since the days of the dinosaurs, way before there were scroll wheel mice, or for that matter mice, or scroll bars even.  I got hooked on those keys many years ago in school when I switched my preferred DOS editor from MINCE to Epsilon.  I no longer use Epsilon (I probably still have the floppies somewhere) but I always add those key bindings to my .emacs config file.  However I could never convince the ~/.qe/config file to do much of anything for me.  So now I've simply patched the source and compiled them in.  Yay!  If I get really deep into the code, perhaps I'll try to add bourne shell syntax highlighting, which I tend to run into more than html or C syntax on the zipit, and the embedded stuff.

Another thing I noticed on the net was a github archive with the qemacs 0.3.1 sources.  I decided this was my chance to finally learn how to git.  I'd already established a github account and forked a few projects, but never really got around to doing anything with it.  For starters, my scratchbox development VM is on debian lenny so I had to jump through a few hoops to install a current version of git.  The key to that was adding a line to the /etc/apt/sources.list file pointing to the recently archived lenny backports. I found the answers at "Git on Lenny, a love story", except for the new archived location of the lenny backports:

deb http://archive.debian.org/debian-backports lenny-backports main

Then this command got me a recent version of git.

sudo aptitude -t lenny-backports install git

So now that I'd got git, I had to get git skills.  For practice I forked the qemacs 0.3.1 repository on github, cloned it to the local disk on my zipit development VM, bumped the code to version 0.3.2, applied my patches, and pushed them back up to my github repo.  Piece of cake.

Next I need to learn to make a new repository from scratch on github so I can track my changes to the bunjalloo code. And then I've gotta practice git branching with my IZ2S fork of slugs gmenu2x code.  I'm pretty excited about that one since it appears to use a 7K png font file instead of an enormous ttf font.  If I change the jffs to use slug's gmenu2x I can get rid of the ttf libs, the ttf font, and (unfortunately) dgclock will have to go too unless I rewrite it.  But I'll still have two clock apps and will save at least 300K on the jffs for more interesting goodies.  Here's a screenshot.  The png font uses more pixels, so not as many apps fit on the screen.  But the scroll bar makes it pretty obvious that there are more down below, so that's ok, I guess.

The qemacs patches are on github, but I've also included them here with an IZ2S executable.
qemacs-0.3.2-iz2s.zip

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