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

Where's the Beef?

The goodies you seek are here. and/or here.  Read on if you want to know why.

But first, a note about the goodies.  Much of it is intended for either iz2s or iz2jffs.  They're basically the same thing except iz2jffs is much smaller and resides on the internal   flash, whereas iz2s is installed on an SD card.  Both are hacked up systems that make use of the stock kernel that comes pre-installed on the zipit.  It's an ancient kernel, but I like it for my purposes.  Now since the entire thing is hacked together there's no real package management system for beginners.  Sorry about that.  You might just have to learn your way around the linux file system if you want to get a lot out of this.

Anyhow, if you want to use lots of this stuff, then your best bet is to  boot from an iz2s SD card.  Otherwise, if you know what you're doing, you can use all of the goodies with an iz2jffs setup, but it takes a little extra work to get it to recognize the libraries and paths used by the stuff.  The addz goodie pack does this for you for some of the older goodies that can't possibly fit on the jffs.  You'd have to do something similar to the addz pack to adapt the newer goodies to work with the jffs.  I may do it someday, but right now I'm booting from the SD card most of the time.

And now for the story of the goodie bag...

It's been said that the internet giveth and the internet taketh away.  And sometimes that's true.  It's also been said that the internet never forgets, but that's another story.  This one is about give and take.  Previously my cable provider of 10 years decided to eliminate their crappy (but free!) web hosting service because absolutely nobody was using it, except me.  So the Zipit Goodie Bag had to pack up and move.  Rkdavis graciously provided a new home for it, but it's fallen into a bit of disrepair lately.  I suspect he's taken in too much raspberry pi vapor, and will be back when the buzz wears off.

In the meantime I've been keeping things patched together by hosting new goodies at datafilehost.com.  But already some of the links have gone dead due to lack of interest.  Imagine that!  My 40MB IZ2S emacs package has gone missing due to lack of downloads.  Don't you people realize the awsome power of a fully operational emacs?  Even my own son has turned against me, recently declaring allegiance to vi instead of emacs.  I've seen this movie before and let me just say, it doesn't end well for the zipit.

But now Dronz has provided the Zipit Goodie Bag with a new summer home in France.  So it's time for some spring cleaning.  I'm planning to prune all the dead links in the blog and redirect them to this post, where I still have the editing power to keep things up to date.  From now on, this post will tell you to where all the goodies actually reside.

Here's the Zipit Goodie Bag Summer Home, including the new jffs goodies.
And here's the old tried and true (but in need of an update) Zipit Goodie Bag.

Curses!

My plans for a cheesy SDL_ttf console font hack are now officially on the backburner.  Too many distractions.  I'll get back to it real soon though, I swear!

The #zipit IRC channel is abuzz with all sort of openwrt chatter.  It's too hard to ignore so I finally got off my butt, took inventory of my messy stack of Micro SD cards, and found one that worked well enough with uboot to load openwrt.  Actually the uboot that came with the flashstock rescue system seems much more robust with the SD cards than I remember.  Maybe it's fixed now.  I'll have to triple check that inventory and see how many, if any, SD cards still fail to boot.

Anyhow, the recent openwrt system from projectgus had a busted wifi setup, so mozzwald posted his test tarball with working wifi and a few extra goodies like gmenu2x and gmu.  It's quite shiny and seems to work pretty well, so I'm gonna have to play with it.  I'm just not sure what to do next.  My git foo is kinda week, so when I got confused trying to clone the code from the projectgus github I switched over to anarsouls instructions and finished the job based on that.  I hope the resulting odd mix of git clone archives is ok.  It's building right now on a slow USB drive hanging off my old PIII laptop, so it should be done cooking by sometime next week.  Then I'll try to build an openwrt version of rockbox and see how that goes.

So what did I accomplish last week?  Err, not much. 

I was a bit bothered that the smallest a static ncurses program will get down to is about 120K.  But the shared lib is over 400K, so I need to find at least 4 ncurses programs that I've just gotta have to make installing the shared lib worth it on the jffs.  A 120k static executable for ttyclock seems excessive.  So I went looking for a mini ncurses alternative to make a smaller clock.  There are actually quite a few out there.  I settled on mcurses because it came with a nice demo program and didn't need too much work to build the ttyclock.  I added a fake "immediate" (as in unbuffered) mode version of the windowed curses functions and it.  I shuffled the ttyclock code a teensy bit to make it work.  Then I added a bunch of patches to add some features and fix the date format bug, plus make it default to ISO 8601 dates instead of whatever weird euro-format it was stuck on.  The resulting executable is around 16K, which puts the static mcurses overhead at about 1/10th of the size you get with ncurses.  I'd call that a win.

Here it is in borderless ISO-date mode, preparing to replace the old standby clock radio.

ttyclock-mcurses.zip

I also finished off the 5x8 font and repackaged dvtm along with the rxvt terminfo files it seems to want.

The rest of the goodies will be posted real soon...

Off Track

I was planning to hack up a cheesy console font version of SDL_ttf this week so I could build some bloat free versions of dgClock, the jlime fileselector, and possibly gmenu2x suitable for squeezing onto the stock zipit jffs.  And then I was gonna attempt to build a skinny version of the retro the maemo flipclock.  But that woulda involved lots of planning and testing, and whatnot.  Instead I got distracted by some shiny new things.
 
I don't remember how, but I was reading something that led me to the dtach utility which led me to the dvtm virtual terminal manager.  Or maybe it was the other way around.  Perhaps I was reading about twin and that led me there.  I don't know.  Anyhow, if you can't give up the jffs space to run gnu screen, then maybe these two lighter utilites are a better fit. 

To get a better idea of what dvtm was capable of I added the line characters to a few fonts that are smaller than the one true 6x10 font I've been using.  Here's a shot of dvtm running with a 5x8 font from the ben nanonote mailing list archive.  I also patched the lines into the atari4x8 font so at least I did something related to fonts...

As if this wasn't enough distraction from my planned activites...  These days everyone and their dog seems to have some version of openwrt running on their zipit.  I got hooked into their discussion on IRC because there's now a version of gmu for openwrt that fits on the openwrt rescue jffs.  It's not as nice as mine because you have to crank it up to 412MHz to beat the skippies.  But still, I should'a been done with my jffs version by now.  Maybe I can still be first with a cool alarmclock radio gmu package.

Meanwhile, due to all the chatter on the zipit IRC channel about openwrt and it's mini versions of everything, I got motivated to try and build a WPA-only version of wpa_supplicant for the jffs.  I didn't quite get there because that's rumored to come out around 50K, and I only got mine down to just over 100K.  It prints a few ioctl warning messages but seems to work so far with the WPA settings on my cheepo home wifi router.  I also got onto an open access point without a hitch, but that's probably cheating. 

If you're daring and need the room on the jffs you can realize quite a savings over the 640k stock wpa_supplicant.  I also built a smaller version of wpa_passphrase but I still don't know exactly what that does, so mine might just do nothing.  In a pinch you can always boot off the SD card and use the full wpa_* utilities from EZ2S to connect to one of those "enterprise" wifi routers that you might see at work.

dvtm-dtach-iz2s.zip
wpa-jffs.zip

Bad Dates

So the new jffs base is barely out for a day and the bug reports are already rolling in.  I included a tiny cal program as a freebie, mostly so I could tinker with the ansi escape menu code on the jffs.  But apparently it prints out bogus calendars, and doesn't even support the vital -m switch to start the metric week off properly on a Monday!  We can't have that.

Actually I was just starting to pull together the various bits needed for the alarm clock portions of my planned internet clock radio package when dronz filed his bug report.  So I suppose I should probably attempt to fix the calendar first. Darn it!  I took a longer look at the code and discovered some obvious problems.  I'm pretty sure January usually has 31 days, not 21.  Even after that fix all the days were still off by 1.  Was time counted differently way back before y2k when this code was probably written?  I can't remember, so maybe it was.

Anyhow, I hacked in the -m setting and fixed enough math errors to get past the end of 2012.  According to the Mayans, the world's supposed to end in 2012 so that's probably good enough.  Right?

Meanwhile I'd really like to get a nice alarm clock running on the zipit before then.  I built a smaller shared lib version of the tty-clock executable from IZ2S.  It's ok for a start, but I'd prefer something really sharp like the retro flipclock they've got on the maemo.  The source is mostly SDL, with a tiny helping of gtk for the alarm sound file selector dialog.  Fortunately the ben nanonote has a tiny fileselector program from the jlime distro that's written in SDL and could work as a replacement for the gtk.  It took a while to get it working because of the uclibc dirclose() segfault that I worked around for sdlbasic, and then promptly forgot about.  It's still there in the IZ2S uclibc though, so I'm sure it'll get me again.  

 The jlime fileselector works pretty well now in IZ2S, but it's a bit large for the jffs because it requires a truetype font and all the bloatware that goes along with that.  I did some searching and discovered the SamyGo folks may have written an SDL_ttf replacement that uses a tiny linux console font instead of truetype fonts.  I couldn't locate the code but I may make a go of that myself, especially with all my recent console font file experience.  I also noticed gnurobbo has a compiler setting to use pixmap fonts instead of SDL_tty, so I might just take a peek at that as well.

If I do manage to produce a substitute lib using the console font I'll probably try to build a mini version of the dgClock program from a previous blog post.  It weighs in at only 18K if I can ditch the 1MB required for SDL_ttf and libfreetype.  It's also quite a bit prettier than the cal program, but I don't know if it has a setting to display the metric version of the calendar.

Here's an updated cal program, with source code so you can fix the math yourself in 2013, if that ever happens.
iz2jffs-cal.zip

Here's the smaller shared lib ttyclock executable and a few alarm scripts to cull for ideas.
ttyclock-jffs.zip

Starting Over, Again.

In my previous blog entry I mentioned a bunch of goodies and ideas provided by dronz just as I was going to press with the blog post.  It took a lot longer than I expected, but I think I've finally got most of it incorporated into a new jffs base.  Originally I expected to break it into a bunch of additions, but as I rummaged through the goodies I realized much of it really belonged in the base jffs package.  So it had to be small.  The first thing I noticed was a proliferation of upxed executables from the original IZ2S and EZ2S systems that simply access a GPIO line to the zipit LEDs and buttons and such.  I figured these presented a perfect opportunity to roll them all into a single multi-call binary (mbc) executable and really save some space.  I was even hoping to toss in the IZ2S power button and screenblanker demons since they access the same GPIOs.

It actually turned out to make the most sense to create 2 mcb executables and leave the demons alone.  The static linked demons were the most efficient with memory at runtime, and don't take up all that much disk space.  Especially considering all the other savings I was getting from the two mcbs.   You can see the two static linked daemons in this htop screenshot, using a mere 16K of resident (RES) memory each while running.

The shared versions use significantly more RES memory, although there is the possibility that some of that will be recovered by sharing (SHR) with more programs running.  Here you can see the shared version of the screenblanker on the blue line with the two original static daemons on the two lines below.

I'm also starting to rethink upx.  It imposes a 4k runtime memory penalty, which is not so bad, but it also starts it's disk compression 4k or so behind the builtin (gzip?) compression on the jffs.  Now upx seemed to win somewhat in my minimal testing on the fairly large busybox and rockbox executables, but it's really hard to be sure when working on a live jffs because you never know when the jffs garbage collection will kick in and throw off all the numbers.  I really prefer to just make the executables tiny and let the jffs compress them.  Here's a shot of the original IZ2S daemons using 4k more memory after being upxed.

To make matters more difficult for me, the original IZ2S daemons were built in an earlier scratchbox environment that's a bit more frugal than the one I'm using.  I've experimented with dietlibc and musl libc to see if I could duplicate some of that frugality with the mcb executables, but the gcc wrapper used by my scratchbox environment conflicts with the gcc wrappers used by dietlibc and musl, to that's gonna take some serious work to get any sort of results.  Oh well.

Anyhow, the new additions from dronz also included some upxed helper utilities such as tee, clear, and date to pull in more functionality such as timezone, and hex passphrase management from the EZ2S network setup scripts.  I set about recompiling tiny shared lib versions of those, as well as replacing the large static sed, grep, and ntpdate programs from IZ2S with dynamic builds of minised, ugrep, and ntpclient for a rather large savings of several hundred K on the jffs.  I also threw in a new setup-tz.sh script to help get a /etc/TZ file generated after a fresh jffs install.

Now if you're off the wifi grid with your zipit, you can still set the time and date either interactively or on the command line with the new date utility.  Simply type date MMDDhhmmYYYY with the appropriate Month, Day, hours, minutes, and Year on the command line, or run /mnt/ffs/bin/date -i to do it interactively.

Also amongst the new goodies were some additions for better sound out of rockbox, however since I'd already ditched the massive alsactl utility in favor of the smaller amixer program these required some changes to the rockbox script to make them work.  I modified things to use amixer and it seems ok now, saving and restoring sound settings in the rockbox script.  I also renamed the original  /mnt/ffs/share/rockbox/eqs/Default.cfg file to Rockbox.cfg and switched to the dronz "hifi" Default.cfg file.  This apparently gets you better sound than the original default eq settings.  However I'm not positive how to activate the eq settings.  If I had to guess, I'd say go into the Settings/Sound/Equalizer menu and select Enable, then Browse to pick the Default config file.

By the way, dronz points out that you can save gobs of space on the jffs by deleting codecs you don't use from the /mnt/ffs/lib/rockbox/codecs directory.  He's got better ears than I, so he deletes the MP3 codec file mpa.codec.  I'd probably go the other way and delete most of the others...

Since I was now committed to remaking the base system I decided to throw in some more font support for the Western European characters.  The /mnt/ffs/share/fonts/erusfont.psf console font has slightly larger glyphs and is thus a bit more legible than the default font.  It may also have more unicode glyphs than the default font.  Feel free to edit the font loading line of the Zcovery script to suit your preference.   You can also load the /mnt/ffs/etc/eurokeymap.kmap instead of the default keymap.kmap.  This keymap provided by dronz allows you to use special key combos to type uincode text with the zipit keyboard.  I had trouble with this in the bash shell on IZ2S (maybe I'm missing some language setting environment variables) but it works pretty well in the busybox sh shell on the jffs.  I also couldn't get the eurokeymap to work in the e3 editor.  However the nano editor handle the unicode typing so I'm providing a separate package for that with a slightly smaller build than the statically linked IZ2S nano executable.

If you wish, you can add more fonts.  I recommend installing non .gz versions of the fonts on the jffs because the base system won't load .gz fonts and the jffs uses gzip compression anyhow, so the file size is effectively the same.

Finally, there's also a set of replacement kernel modules from dronz that you can use to enable auto-repeating keys, so you don't wear out your thumbs quite as fast.

Whew!  That's a big post.  Here's the goods, starting with the new base.  Follow the instructions from the earlier post to install it.
iz2jffs-base-v2.tar.bz2
Oops.  Apparently the new timezone script leaves you at a blank screen.  Here's the fix: tz-iz2s.zip.

The mini Rockbox is now a separate install after the base.

rockbox-391-jffs.tar.bz2
Dronz says:  You can save some space by replacing the default cabview theme with this 4k theme and the 14-Terminus-Bold.fnt font from the rockbox font pack (or this slimmer version of the font Lat15-TerminusBold14.zip).

Here's the typematic keyboard goodies from dronz. 

typematic.zip

And the smaller (shared lib) nano editor.

nano-jffs.zip

This loadkeys program can be used in IZ2S to convert keymaps to the binary .kmap format used on by the jffs base.

loadkeys-kmap.zip

Oh yeah, here's the updated naim IM client that uses the still functioning OSCAR protocol.  I still couldn't tell if it works though...

naim-iz2s.tar.bz2

The handy IZ2S busybox update is still available in here.

iz2jffs-extras.zip

And I still need to wrap up the final version of the source code for the IZ2S mcbs...
Here's the nearly final version of iz2s-pwr-src.tgz just in case i lose track of this...

One Font to Rule Them All

Way back in the olden times (9 months ago?) I tried to use weechat on z2lite.  I lasted about a minute before my eyes squealed in agony.  It was setup by default to use a microscopic font in order to squeeze as much information onto the tiny zipit screen as possible.  Now I understand.  I've been fiddling with various IRC and IM text apps for a week or so now, trying to see which, if any, I can cram into the jffs.  In order to provide more utility than the basic pmirc script they all seem to need the box drawing characters and plenty of screen real estate.

IZ2S 2.05 (enhanced) comes with a really nice 6x10 font that gives you 24 lines and 53 columns on the zipit screen.  It's not quite a full xterm, but it's a nice readable compromise.  Unfortunately it only comes with the basic ASCII char set.  No frills.  All the rest of the glyphs in the 256 char font are hideous useless squiggles.  A while ago fellow IZ2S zipit user dronz dug up some nice 8 wide fonts complete with box drawing characters and a full set of Western European glyphs to go along with his European keymap for the zipit keyboard.  I've used these a bit (mostly for the box chars) and they work well enough for the alsamixer, but 8 wide glyphs only give you 40 columns across the zipit screen.  Not quite enough room for chatting and a buddy list.

The microscopic font has the box drawing characters, but again, my eyes!  I searched the internet, far and wide, for the perfect linux console font.  And I found some candidates, but nothing that truely satisfied.  Ok, in the dark and distant past, I've been known to roll my own homebrew font to squeeze as much as possible onto the tiny screens of yesteryear.  So I dug around for some sort of console font editor.  What I found was also a blast from the past.  The nafe font editor dumps the font to a text file with the glyphs drawn in Xs and spaces.  Then you edit the glyphs with a text editor (emacs) and a lot of squinting.  I also discovered the cse font editor (which I haven't tried yet, but I did try his nethack font) and gbdfed, which I used to import my partially finished psf font file and display the glyphs at actual size.  I could've used it to edit the glyphs, but I'm pretty comfortable with emacs.  However, I did also use gbdfed to display the 8x10 font from dronz as something of a guide for my new 6x10 glyphs.  When the new glyphs were complete I used psfgettable to fetch the unicode mapping table from the Western European font and psfaddtable to paste it onto my new font.  So it should support all the same unicode chars, including the box bits.  The results are simply fabulous!

I finally got the rhapsody IRC client to fit ok on the zipit screen.  It's about 140K, which is not too shabby for the additional features it gives you over the no frills pmirc script.  The new font should also do wonders for the naim IM and IRC client, if it works.  I built the new experimental code with lua scripting and OSCAR protocol support, but I still have some config details to work out.

Meanwhile on the #zipit IRC channel dronz pointed out some online gateways for IM and email that appear to work with retawq.  Good idea.  I dug up my old mobile links homepage that I created for netsurf and reworked it as the default homepage for retawq on the jffs, including a link the the retawq help pages.  Reading the help documentation made me realize that retawq can be scripted to substitute for wget or curl.   So I quickly dashed off a one line "wget" script that seems to work well enough for simple downloads.  You still need the busybox upgrade to download and unzip things.  Gotta remember to make better use of the goodies I've already loaded onto the jffs.

It may take a day or two to release all the goodies for this post.  Just as I finished the photography portion of this post, dronz sent me a bunch of new scripts, fonts, and config files that I need to sort out and merge into my stuff.  To get the ball rolling, here's nethack, rhapsody IRC, and the new font for IZ2S.

nethack-iz2s.zip
rhapsody-irc-iz2s.zip
iz2slat-font.zip

And here's a pic of nethack with the new IZ2S font loaded and the DEC character set selected from the nethack option menu.  Check out those nice smooth walls...

 I'm still working on the code for the really fancy nethack font.

Diminishing Returns

After eliminating the ALSA bloatware I'd set my sights on the big fat static loadkeys program from IZ2S.  I was originally forced to keep it on the jffs because the keyboard is pretty much useless without a keymap, but a 300K executable is a bit excessive for that.  Now the IZ2S busybox upgrade comes with the loadkmap utility, which is much smaller because it only loads a binary version of the keymap file.  This seemed to work well enough so I compiled a tiny 4K standalone version for the base jffs system.  Unfortunately you need a recent version of the loadkeys program to convert any new keymaps you might make to the binary kmap file format, and the IZ2S loadkeys is a bit too old, so I has to use my Mint linux box to convert the keymaps.  Eventually I guess I'll build an updated loadkeys for IZ2S.  For now I just included a bunch of premade kmap files.

That took care of most of the remaining bloat on the base jffs.  None of the other executables in the /mnt/jffs/bin directory were significantly over 100K, so any further savings generated by replacing them would be relatively small. So, armed with the space saved by eliminating loadkeys I decided to try and replicate some more of the core IZ2S functionality on the jffs.  Two obvious gaps were the 600K Screen utility and the 4.5 Meg Centerim instant messenger client included in IZ2S.

Apparently source code development on the screen utility has ground to a halt lately, so I took a quick peek at the newer tmux screen multiplexor.  Unfortunately my build of tmux segfaults, so that'll have to wait a bit.  Instead, I recompiled the current release of screen to make a smaller executable, and while I was at it I threw in the vertical screen split patch.  As with emacs, I remain unconvinced as to how useful that'll ultimately be on the tiny zipit screen.  But it certainly can't hurt.  Well, actually the new upxed screen program is still almost 200K so I suppose it still hurts a little.

Thats my cheesy ANSI escape wifitest program in the right split, and the retawq browser on the left.

Centerim is huge so that's a no go for the jffs.  I examined quite a few alternatives and most of them seem to pull in openssl, or glib, or some other bloatware that pushes the exe size up over 2 Megs.  Too big for the jffs.  I had really high hopes for bitlbee because it's just a daemon that lets you use your IRC client (think pmirc) as a front end to various instant messanger services.  But it was also huge.  Oh well.

I decided to try the divide and conquer strategy.  Instead of one monster "do it all" program, I started looking for a group of smaller single protocol programs.  Even so, many of these were also bloatware.  So far I've got naim (pictured above) at 250K, bsflite (seen below) at 28K, and a shell script for jabber that (like pmirc) uses sed, grep, and ncat with ssl.  Apparently naim really wants to run with screen. It spews garbage unless I run screen first.  Weird, but ok I guess.  Unfortunately I don't IM myself, so I don't really know if it works.  Actually I think the TOC protocol used by the official naim release has been retired, so I may have to build an experimental version with the OSCAR protocol.  I did however manage to have someone to try bsflite on the zipit and confirmed that it was able to access an AIM account.

IZ2S version 2.04 comes with ncat, but I think it's built without ssl support.  The openssl program itself is about 1 Meg, so I had pretty low expectations when I built an new ncat.  Yep its huge.  But a search led me to snetcat aka.spipe with the embedded matrixssl library. At about 100K snetcat is a strong contender for the jffs.  I just need to redo the jabber script like I did with pmirc.  Then I need to figure out how to test it...

BTW, this post was actually composed on the road using e3em, which I ran on top of the screen utility so I could check the zipit battery level every so often with the EZ2S batlvl command line utility.

Here's the stuff.

bitlbee-iz2s.zip
loadkmap-iz2jffs.zip
screen-im-ssl-iz2jffs.zip

Small, but Spicy

To save space on the zipit jffs, I made some small (but spicy) SALSA builds of amixer and alsamixer to replace the bloated static full ALSA build of alsactl from IZ2S.  That change freed up 200K on the jffs and eliminated a second or 2 from the ALSA setup part of the boot process.  Apparently the lean and nimble amixer program enables the sound much quicker than the fat old alsactl beastie.  The salsa version of alsamixer forces you scroll off to the right through the controls for quite a few screens before you get to the good stuff, but other than that it works pretty well.  As you can see in this screenshot of me, preparing to turn down the zipit speaker from it's ear blasting default of 100%.

While I was at it, I also compiled a shared lib version of the own-tty program for a 150K savings over the static IZ2S build.   The new one is only 4K.  Nice!

Meanwhile, upon further testing I discovered the pmirc script from last week had quite a few runtime requirements for utility programs only available in the busybox upgrade from the IZ2S.  Oops.  So I set about hacking the script to eliminate some unneeded utilities, and building the others.  After some time relearning sed and regular expressions, I managed to replace tr, cut, and clear with sed and ANSI escape codes.  I built a much smaller 11K shared lib version of nc to replace the big static build from IZ2S.  To make things easier for me I adjusted the help messages to fit the zipit screen, and tossed in a tiny telnet wrapper script.  (I also built a small 7K copy of NetKitty but haven't done anything with it yet.)  I've been searching for a while, and finally found a tiny 5K non-busybox version of the date program on the internet.  I modified it a teeny bit to add /etc/TZ file handling for local timezone formatting.  This lets pmirc timestamp it's log files with the local time.  I still gotta make a setup script with well known city name hints so it's easier to get the right setting into the /mnt/ffs/etc/TZ file.  Here you can see annonymous zipit_user_20645 using the 5K new pmirc utility on the jffs to join the #zipit chat group.  Probably just gonna lurk for a while...

While I was working on the date program I also built a tiny 5K cal program so I can now run the entire wifitest demo dialog script off the stock busybox.  Plus, someday when I get the gmu sqeezed into the jffs I hope to be able to set aside a zipit to be used as a dedicated alarm clock (internet) radio gizmo.

Anyhow, with both rockbox and the IZ2S busybox upgrade installed, I now have nearly 600K free on the jffs for other goodies.  I'd really like to have the zipit16.mp3 file I rescued from the resources.arl file play the "ZZZZipit!" sound on boot up.  But it's 80K and I've only been able to prune mpg123 down to about 230K, so that's unlikely for the time being.  I'm considering upxing the 600K wpa_supplicant program from the stock jffs to see if I can squeeze 100K out of it.  And the loadkeys program is also a heavy load.  Wejp went with the much leaner loadkmap on his zipit userland.  It only loads binary keymap files that must be created with loadkeys on a full linux system, but hey, that's another tradeoff I'm willing to make for 200K or so.

New stuff:
mixer-irc.tar.bz2

A New Low

The original point of cramming tiny things into the jffs on the zipit was to replace the obsolete (and possibly broken) stock firmware with something useful.  I recently broke out of my "shrinking things" mindset for a while and had a few useful thoughts on this.  It turns out I haven't done much of anything with the tiny /mnt/ffs/Zipit2 script.  I only made that script to fool the init system in the ram disk so it wouldn't initiate the infinite "update of doom" loop.  However, I realized it's actually a nice safe place to add some customization to the boot process because it's the very last bit of script that gets run on boot up.  Currently it just prints a short message and drops into a shell.  But it could just as well launch right into rockbox, or gmu, or check if the SD card has some extra goodies to beef up the system via softlinks.

In order to customize the Zipit2 script without an SD card I felt a simple (but tiny) text editor was required for the jffs.  Now I admit the stock busybox comes with vi, which I can usually remember enough about to get the job done (barely).  But think of the children!  And so I was back to "shrinking things".  To fit on the jffs the programs must be tiny.  At only 14K the e3 editor weighs in at just about the right size.  Plus, depending on the name you run it as, it can emulate the basic commands of wordstar, nedit, pico/nano, vi, or emacs.  Wooo, emacs FTW!  Here's a picture of me using e3 in emacs mode, editing the Zipit2 script to run Rockbox on boot up.

 While I was searching for tiny editors, I just happened to stumble upon the pmirc script (for the busybox ash shell no less) in the puppy linux forums.  I'd already built a 37K version of tinyirc, but at about 2K compressed pmirc was simply too small to pass up.  Plus its got lots of good ideas I can borrow to pimp up the other scripts I've been whipping up.  I modified it a bit to work better with the stock zipit busybox, and tweaked the key input make things a bit easier on the tiny zipit keyboard.  I might have to scour the old software archives to see in there's any similar scripty gems in the floppy linux distributions.  So far most of the potential goodies I've seen are riddled with bashisms, but if I dig deep enough I know I'll find some nuggets.  I'm pretty sure I've got a box of 5 inch floppies somewhere with the ancient simtel archives...

Here's an e3 package with all the softlinks and wrapper scripts.  I also threw in the modified pmirc and Zipit2 script.  You can also use e3 with iz2s, but you'll have to create the softlinks at runtime like in the iz2s busybox.sh script.

iz2jffs-e3.tar.bz2

New Years Resolution

I often find myself booting the zipit off in a dark corner somewhere, so I thought maybe I should let the iz2jffs startup script dimly light the keyboard LEDs, just before the wifi setup, and then turn them off again after. That way I can see the keys well enough to type a password when I need to.  So I made a tiny script called kbledsdim to run the kbbrightness utility from EZ2S.  I also converted kbledson and kbledsoff to similar scripts instead of full executables, so the jffs disk space useage remains about the same.

Now you can't see the keyboard in that picture, but perhaps you can see that I've started making some progress with the ANSI escape sequences.  I polished up the wifi startup scripts with some more color and better default hints.  Combined with the dim keyboard lighting, the wifi config is now bearable.  Maybe I don't need the ANSI escape based dialog boxes after all.

However I also finally got the ANSI escape based dialogs working at a reasonable speed by substituting the echo command for all of the printf calls in the demo script.  Since echo is a builtin function in the busybox sh, it runs about 10 times faster than external printf commands.  This was quite a challenge though since printf has way more formatting capabilities, and the builtin echo command doesn't accept the "no linefeed" switch so moving the cursor gets tricky.  Also the scripts are now tied to the specific busybox sh in the stock zipit initramfs.  Bash and the newer iz2s busybox sh require the -e command for echo to process the escape sequences.  Maybe I can fix that with a test and an alias for echo at the top of the script.  Yeah, maybe someday...

Of course now that I've got the desired speed, I need still to convert the demo into a reasonable set of working dialogs.  So far I've just added a little bit of code to manipulate a highlighted selection bar with the arrow keys, and then launch the currently selected option with the enter button.  I find that handy because even with the keyboard lit up like a Christmas tree it's still hard to find the number buttons, as they're printed in tiny red letters that don't light up.  If anyone wants to play, here's the work in progress on the scripts pictured above.  Some parts still require the iz2s busybox, so be careful with these scripts if you haven't loaded that on your jffs.

iz2jffs-scripts.zip

Turns out stty is crucial to the arrow key parsing and it's not available in the base system, only in the iz2s busybox which I currently have upxed on the jffs of my zipit.  That makes it way too slow to capture the multi-character arrow (and function) key sequences reliably.  I can make it better by only calling stty once, but it's still not an optimal solution, especially since the base jffs has no stty command.  I think I may have to try building a stripped down standalone version of stty...

Christmas Special

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

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

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

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

iz2jffs-base.tar.bz2

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

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

sdlbasic-iz2jffs.zip

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

More Small Thinking

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

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

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

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

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

cd /mnt/ffs

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

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

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

iz2jffs.tar.bz2

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

iz2jffs-extras.zip

Blank Slate

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

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

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

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

A Better Basic?

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

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

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

Files are here for now.

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

I Blame the Trees

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

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

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

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

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

Update:

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

And here it is with the -L orientation.

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