Flappy Bee

The crummy "working title" from last week's post (that I ended up keeping for lack of a better idea) reminded me that about a month ago I'd started an iz2s build of hocoslamfy (aka. "flappy bee") for the zipit, but forgot to finish it for some reason or other.

So I decided to complete the build and give a try.  Back in a previous life, at a different job, I was the Christmas week Joust champion for several years running.  However my reflexes are not what they once were, so I have yet to make it past bamboo shoot number 3 with the flappy bee.  But I will.  Someday.

Unzip it onto the root of the uz2s SD card and see if you can beat me.

hocoslamfy-iz2s.zip

Update:  

WooHoo!  I made it to 12!  Really, I swear it's true.  See...

Unfortunately I also discovered it saves the high score file on the ramdisk instead of the SD card, so this too will pass -- the instant I reboot the zipit.  I'll have to fix the code and recompile when I get a chance.

Update2:

Actually I might not have to fix the code after all.  Apparently hocoslamfy, irssi, and other programs that I don't remember right now get the location of the home directory from the passwd file instead of the environment.  Currently the /mnt/sd0/etc/passwd file uses the default settings from the stock kernel ramdisk, which sets the home directory to /.  Editing that file and changing the / to /mnt/sd0/home makes the programs save their data and config files in the right place.  I'll fix that permanently for the next uz2s beta.

B3

Last week I did some work on the bard text to speech epub reader for iz2s.  It works fine, but I really want the better voices from the flite text to speech system.  So I followed some internet hints to the flite_hts_engine and tried that. It's quite small, and it sounds great, but again it's using floating point math, so it's too slow on the zipit.  The docs mention maybe someday adding fixed point math, but I'd guess it's unlikely.  Soon enough only the processor in your toaster will be without an FPU.  While it might be nice to talk to the little guy and tell it not to burn everything so much, I don't see that happening real soon.

Meanwhile I've also been adding icons for things to the gmenu2x layout in my ultra large iz2s build.  Here's the apps screen.  I'm getting to the point where I should probably move a few things off to another tab.

Here's the internet apps.  Still got some room there...

Even though some of the toys and games are command line apps, I still like to have icons for them.  Hmm, MilkyTracker looks like a dup from the apps screen.

And now the programming tab finally has some interesting stuff on it.

New for this release I've done a quickie hack of the load81 lua game building environment for the zipit screen.  I'm planning to switch the text to use the psf console fonts via psflib so I can get more on screen, and I'll probably have to do something about the enormous baby blue border.  I used the esc, prev, and next keys to exit, swap screens, and save the file, just in case you run it without a mouse.

I've kept the code that boots into rockbox first, because that's the way I use it.  If you don't, and would prefer not to press the smiley escape key to get to gmenu2x, you can simply comment out some or all of this section of the z2script.sh startup script on the root of the SD card.

##########################
# Boot right into rockbox for music in the car.
ln -s /mnt/sd0/music /audio
kbbrightness 511 63 50
#/mnt/sd0/bin/gmenu
/mnt/sd0/bin/rockthecar
#
# Done with rockbox.
##########################



Here's the stuff.

uz2s-beta3.zip

Return of the Bard

Recently, while prowling the net for GCW Zero goodies that might be willing to work for me on the zipit, I spotted some hints about a new release of Bard the Storyteller.  That got me thinking, maybe it was about time for an iz2s build of Bard.  I'm not sure why I never got around to it.  Perhaps I was worried the performance wouldn't be up to the level of the openwrt build, and I'd be stuck with the robotic 8KHz Kal voice instead of the surly 16KHz version.  I don't know.  Anyhow, I finally decided to give it a shot.

So I applied the old openwrt-zipit Bard patches, then tweaked the battery monitor and screen blanking code for iz2s.  I also adjusted the key bindings to move the page up and down functions onto the zipit Prev and Next keys, and added the increase and reduce functions (for volume/fontsize/speed) to the period and comma keys, as well as the volume +- rocker buttons.

It seemed to work ok, but the highlighted words seemed to jump ahead of the spoken voice quite a bit, so I dug a little deeper into the code.  I noticed some floating point code sprinkled about, here and there.  Seems like an odd choice to target small underpowered devices like the Nanonote, with no native floating point, and yet control the volume with a floating point multiply for each and every audio sample.   I switched that code to use an 8-bit fixed point volume multiplier.  I also converted the idle time check code to use integer milliseconds, like the rest of the SDL code instead of floating point seconds.  I did the same for the audio sample position timing code.  That might have made the "lip sync" a tiny bit better.  But it's hard to tell.

Here's the iz2s bard and flite executables, and a libzip that I needed to build it.

bard-iz2s.zip

I'll put together a patch file with the code changes ASAP.

But first I want to do some experiments with the rest of the voices.  I built the default set of flite voices, but aside from kal they all use floating point numbers for the data.  So they're an order of magnitude slower on the zipit.  That's ok if you want a higher quality voice, but you can't use them in bard because the text processing is too slow for realtime.  It might be nifty to fixup bard to "lip sync" the text on screen with a preprocessed .wav file, but I'd rather see about converting the voices to fixed point.  I examined some of the data and so far the largest number I've seen is around 220, and all the floats have 6 digits after the decimal point.  That range of values would probably fit quite nicely in a 12.20 fixed point format, which would speed things up enormously, and might even sound ok if the math doesn't overflow.  We'll see...

By the way, this might be a good time to mention that I finally remembered to add the missing speaker setting in the /mnt/sd0/bin/setup-alsa.sh script. 

  /mnt/ffs/bin/amixer -q sset "Right Speaker Playback Invert" on

I also toggled the identical setting in /mnt/sd0/etc/asound.state.  Without  that setting the speaker isn't really loud enough to hear.  But with it, I could almost picture myself listening to internet radio via the speaker, if I forgot my headphones.  It's certainly good enough to listen to the bard speak.


Next up, maybe a beta3 of the ultra iz2s SD card image.

Bad links (the fickle memory of the net)

Sometimes it seems the internet never forgets.  You know what I mean.  Post something you'd rather forget and it gets wedged in limbo on some far away anonymous internet cache.  Halfway between here and forgotten.  Forever.  But other times things can disappear down the infamous internet memory hole with seemingly no notice whatsoever.  A sudden transition from the crystal clarity of ones and zeros to a new state, existing only in our own feeble fuzzy memory.  Was it ever there?  Did it really happen?  I don't know, do you?

Today feels like one of those days.  IZ2S 2.05e is no more.  Just a bad link.  Sure, you can probably dig up some mention of it on the archive.org wayback machine, if you know what to look for, and when.  But good luck finding a zip file with the stuff you need.  Actually the older versions 2.04 and 2.05 are still currently available but I'm not  sure they have what I need.  Unfortunately for me, IZ2S 2.05e is an integral part of my install instructions for iz2jffs.  So now I have to come up with a new method, and then track down and fixup any links to the old way.  Yeah, I need to modify the internet memory of the past to better suit the crummy reality of the present.  Seems vaguely Orwellian when you think about it.  You can call me Winston...

Anyhow it's not an emergency procedure because flashstock is still available, and it installs an iz2jffs that's either the latest version, or the one just before it.  I can't really tell from the website.  In fact my new manual install procedure will probably end up using flashstock if it contains the right version of the tar command that I need.  Otherwise I may give up on the manual "install from tarball method" and instead create the backup files used by the flashstock script for any new releases of iz2jffs.  Only time will tell.  Or maybe it won't...

In the meantime I had already started working on my own version of IZ2S.  Sort of a super sized iz2jffs, except running off the SD card instead of the internal flash, and containing most of the goodies posted here over the years, already installed.  That's tons of stuff, so I had to trim it back a bit to bring it under 100MB or so. 

It's a lot of work, separating the experimental junk on my personal SD card from the good stuff, but I got far enough along to drop a beta release onto the internet.  It still needs tons of work, especially in the gmenu2x GUI since I tend to run things from the command line much of the time.  It boots into rockbox, because that's what I use it for most of the time -- an mp3 server for the car.  You can press the smiley face button to exit out of rockbox into gmenu2x to do other things.

I had to pull out gcc and gnu-emacs to keep the size down, so if you want them you'll have to get them from the goodie bag.  And you'll have to fixup g++ to make it work.  I tend to stay away from C++ for small things (like zipit code) so I never noticed the install was slightly broken.  A normal gcc setup uses softlinks to install the architecture dependent header files, but you can't do that on a FAT  filesystem.  For gcc I made copies and moved some files, but I forgot to do it for g++.  So to fix it you should do this:

  cd /mnt/sd0/share/gcc/include/c++/4.1.1/arm-linux-uclibc/bits
  mv * ../../bits

Then you can compile hello.cpp.  Well, at least it worked for me...

Here's the 70MB ultra large iz2s beta.  Just unzip it onto a FAT formatted SD card and it should boot up in a stock zipit.

uz2s-beta2.zip

If you'd like a working Doom, fceu NES emulator, and some other programs, you can follow the goodie bag link and install Dronz' sd0-f5.zip to get the addz directory onto your SD card.  There's a bunch of nice stuff in there.


Update:

Err... while I'm on the subject of loose screws and memory loss, I have to mention that I totally forgot about some new nethack builds that I worked on about a month ago.  

Here's a nethack ipk for openwrt that I'm 99% positive works.  Apparently I patched it for a uclibc strcasecmp bug.

nethack-openwrt.ipk

And here's an SDL nethack build for iz2s (screenshot from gp2x).

nethack-sdl-iz2s-beta1

I wonder what else I forgot...
 

Loose Change

Once again it's been a long time gone with nothing new here on the old blog.  Probably because I'm incapable of focusing on any one thing long enough to have something worth writing about.  However I have tinkered with a few small odds and ends.

For a short while I thought maybe I was gonna do something to improve the zipit text mode browsing options.  The ideal would be to get something going with both text and images and sharing the framebuffer nicely with tmux.  Yeah right, I know, keep dreaming.  But anyhow, I finally got motivated enough to build w3m, which supposedly can do just that, well, except for maybe the tmux part.  As expected the w3m executable came out rather bulky, which was disappointing.  And then I didn't quite come up with a workable solution for the pictures.  The w3m-img program responsible for putting the images on the framebuffer needed some work to make it capable of handling the evil rotated zipit framebuffer.   The solution may actually be out there already, if only I could convince google to translate some half English, half Japanese web pages properly.  Meanwhile this slowed me down just long enough that I eventually lost interest and moved on to something else.   Oh well.

But first I briefly considered hacking together something for displaying pictures superimposed on top of the links browser's text mode.  That'd require a straight up framebuffer driver, no sdl, so I built the fbv image viewer and even added a rotation option for the command line.  And that's about as far as I went, because I got distracted by iz2s build of zgv.  I was using it to compare with fbv and quickly realized that gif image support was broken in the iz2s executable.  A little debugging pointed to some routines used to read the gif structs containing some bad assumptions about sizeof() results for structs with odd byte counts.  So I fixed that and the gif display worked.  Mostly.  Naturally I wanted to try some animated gifs and the first file I tested used some (probably unnecessary) colormap manipulations that apparently aren't supported by the zgv gif code.  The animation played ok, but the colors were all over the place.  However, once again I got distracted before I'd worked out a satisfactory fix.

Around that time there were a few new users on the zipit IRC channel who took tinyirc out for a spin and came up with some fairly reasonable suggested improvements.  Before they vanished to some other IRC channel I dropped zgv and quickly added tab completion for NICKs, channel autojoin, automatic NickServe identification, and a few other options supported by changing the command line HOSTNAME arg into partial IRC URL support.  I also started on a busybox ash script to make configuration of the tinyirc command line options easier.  I'd probably be done with it already if I'd written it in C and ncurses, but for personal development reasons I really wanted to see what I could do with a minimal script for the built in busybox ash shell.  Here's what it looks like so far.

The script parses a small wrapper script containing a tinyirc command line and draws a little TUI with the tinyirc settings.  I still need to add something to edit the settings (inside the TUI if possible) and then save or run the resulting tinyirc command line.  I'm hoping to eventually be able to save new tinyirc configs as gmenu2x applets on the Network screen. 

Unfortunately before finishing that I ran into another issue with the image viewers.  I'd dumped some photos of the giant poison vines in my backyard from my camera onto the zipit, hoping to show them to some nonbelievers later.  But when I went to review them I got "out of memory" messages on every single image the viewer on the zipit.  Awkward.  Basic math says 10 megapixels at 4 bytes per pixel is a few megas too many for the zipit.  And sadly, I vaguely remembered assuming sometime in a past life that nobody in their right mind would ever try to view raw camera images on the zipit.  Oops.  Apparently I was wrong.  I hate when that happens.  So I got to work and patched up zgv (for starters) to do a cheesy power of 2 autoscale on any jpegs requiring more than 16 megabytes when uncompressed.  Seems to work so far...  I'd like to do something for imgv as well, but I suspect the simplified libsdl_image code layer may get in the way.

Hopefully I can at least wrap up the irc config script in the near future.  Meanwhile, I should be able to get my act together long enough to post some new iz2s executables of zgv, fbv, and tinyirc.

fbv-iz2s.zip

tinyirc-iz2s-tab-join-id.zip

zgv-gif-jpeg-fixes-iz2s.zip

Apparently I recently compiled zip and unzip executables for the iz2jffs.  Must've wanted them for something...

zip-unzip-iz2s.zip

Update:

My script is slowly shaping up.  You can follow the chain of pastebin links to see the progress.   However it's up to 15K already and still not quite finished.  I'd like to see it around 10K, with something that at least resembles real widget data structures that I could potentially reuse someday.  Not quite there yet...

Bird in the Hand

So... previously I managed to get the versatile finch instant messenger program running on IZ2S, but failed to connect to anything with it.  Recompiling and running it with --debug led me to an old uclibc 0.9.29 bug where it defines but does not support some getaddrinfo() hint flags like AI_NUMERICSERV and AI_ADDRCONFIG.  Using them locks up the program (or the thread in the case of finch) on the dns lookup.  I patched the uclibc netdb.h header file to not define the unsupported flags, then hacked the glib resolver function to skip over those flags and instead use IPV4 only on the zipit.  This fixed my glib resolver test program, and got me a working nslookup applet, but failed to fix the finch.  I gave up -- again -- and did some work on the Links browser instead.

Eventually I got the idea to search for the "DNS query queued" debug message inside the finch libpurple code.  Sure enough, despite the fact that finch requires the enormous glib to build, it goes straight to the libc getaddrinfo() function instead of wading through the extra bloat of the glib resolver wrapper.  If only the finch devs would see the light and bypass all of glib then maybe I could build a cut down finch with a subset of plugins that actually fits on the internal zipit flash.  Anyhow, I patched libpurple just like glib, rebuilt everything and the new finch was able to connect to IRC from my IZ2S zipit.  You can see my test session running on the half hidden right side window in this screenshot.

When I configured finch it gave me a warning that some IM protocols would have reduced functionality without gnutls, so I decided to build that while I was still working on the finch executable.  Sadly, I don't remember which IM protocols wanted it so the libgnutls remains untested, but included for completeness.

While building, I also found pkgconfig, which is a nifty slim replacement for the bloated pkg-config program, and will surely make compiling certain large packages with the native IZ2S and openwrt compilers much easier.  It's a clear win over my previous cheesy pkg-config shell script.

Here's the new finch with the patched glib and libpurple shared libraries along with a few other libs that should be enough to get it going on a basic IZ2S zipit.  I included a wrapper script that should also work if you want to boot iz2jffs and run finch from the SD card.

finch-iz2s-resolve.zip

Here's the gnutls libs.

gnutls-iz2s.zip

And the nslookup applet.


nslookup-iz2s.zip

And finally, I've included the unstripped glib along with the pkgconfig utility as an add on for the native IZ2S compiler.  This stuff should go in the usr/local directory on your SD card if you want to compile with it.

glib-iz2s.zip

I still need to build an openwrt pkgconfig executable...

The Latin Crush

I discovered my iz2s build of finch runs just fine -- no segfaults -- but it never seems to make a connection to the IRC server.  Running it with --debug pointed me towards the threaded DNS resolver function, which never seemed to finish.  So, suspecting glib, I built a small test function and it didn't work either.  Then I noticed the nslookup busybox applet wasn't working either, which put the problem in uclibc.  The internet said there were some unsupported (but reported) flags in the getaddrinfo function in the ancient uclibc used by iz2s.  I patched around it and managed to fix my test program, which could substitute for the broken nslookup applet, but the threaded versions of the function used in finch and glib still don't weem to work.  Oh well.  I'll figure it out someday.

Meanwhile over on the zipit IRC channel, slug_ was busy reworking the ssl functionality in the openwrt build of the links browser, attempting to reduce the jffs disk space required for links by backing the ssl code out to a shared lib and then pointing links at some other random shared lib already on the jffs.  I like the idea, but not so much the implementation because it's totally broken on iz2s.  I'd rather try and fix the openssl compatibility layer in polarssl and/or patch the links https.c file to use it.  Unfortunately that idea is still on the back burner.  But meanwhile, all this somehow got me thinking about shrinking the png files used by the links font system.  I got motivated and ran my cut down latin15 links font set through pngcrush --brute, then rebuilt links to see what would happen.  Turns out, it saved me 40K bytes on the jffs, so I'll take it.

But I didn't stop there.  I got to thinking again about using TTF fonts for links, so I bit the bullet and compiled the links code on the zipit itself in preparation for a heavy gdb session to track down the source of the segfault that stopped me cold the last time I tried this.  Turns out I never got into the gdb session.  I ran links via ssh and noticed the error message, looked it up in the code, and found a self induced segfault due to my shoddy character width calculations on the TTF mono-spaced font.  Oops.

So I fixed that and now it runs.  The good news is the executable comes out to a very reasonable 534K with ssl included via static linking.  Nice.  And as expected, the tiny fonts required by the zipit are much cleaner and far more readable than the original scaled down png fonts. 

I think I can approximate the coverage of the original built-in png fonts on the jffs with just two dejavu fonts (mono and proportional spaced) for only 80K bytes over the current TTF font included on the jffs, possibly more if I need bold and italics.  That gives a savings of maybe 200-250K over the pngcrushed links build, and it might just save my eyes.  Plus I'll have a decent set of fonts on the jffs to work with for other apps like the flipclock.  Even pspmaps might work on the jffs if I keep the map images in /tmp when the SD card is absent.

As you can see in the picture, I still need to do plenty of adjustments to make the TTF glyph metrics match what links was doing with the png files.  That'll take some time because I probably also need to measure the RAM footprint of multiple preloaded TTF font sizes vs the runtime resizing of the png fonts to get something optimal for the 32MB RAM in the zipit.

Update:  Getting closer..  I got multiple fonts and sizes going and I fixed some problems with the spacing and non-printable control characters.  Judging by the link highlight rectangle in the picture below, spacing could possibly use a bit more work.  And if I can figure out why some text isn't printing in the title bar, status bar, and dialog boxes I can probably release an executable package.

Update 2: I fixed the bug with the text in the title bar status bar and dialogs.

I also restored the bold font support and did some comparisons to the original links.  The ttf and png versions used a similar amount of memory with the same mix of bold, normal, and monospace fonts when rendering this test page.

I find the original png fonts (below) a bit fuzzy, especially at the smaller sizes best suited for the zipit screen.

Anyhow, here's the pngcrushed Links executable.  I might try to make it smaller with some more advanced pngcrush settings mentioned on the zipit IRC channel.

links-iz2s-latincrush.zip

I'm hoping to add the font-include-latin-crushed.h file to the openwrt-zipit links package on github, real soon now.

Here's a links-ttf executable.  Probably riddled with bugs, but at least it proves the concept is viable.

links-ttf-iz2s-beta1.zip

And here's a tiny Latin1 ttf font viewer program with source code that might be handy someday if I ever decide to scour the internet for smaller font files.

ttfview-iz2s.zip

Update 3:  I fixed the segfault in Links when selecting languages.  Here you can see it not crashing in that section of the menu.  You can also see the Bepa Roman ttf fonts support more glyphs than I did with my Latin1 built-in-font executables.  If I could figure out what all those characters were, maybe I could restore some more of the original 33 languages on the menu...  Actually, it really demonstrates that I need to move the menu language support into runtime loaded optional shared libs so you can install your own language(s) to go with your own ttf fonts.  If only the standard solution for that wasn't such bloatware.

This screenshot also showcases some new mini scrollbars and a new menu color scheme that I've been testing in the ttf package with more contrast for better readability with the tiny font.  You can't see it here but I also added a blue block cursor in the ttf package for the menu text entry fields.  The original underline cursor was always difficult for me to locate with my bad eyes.

Anyhow, I repackaged some new executables with the segfault fix.

links-iz2s-latincrush2.zip
links-ttf-iz2s-beta2.zip

Update 4:

I added slug's title and statusbar hiding code from the openwrt build for a little extra screen space in the links ttf executable.  Every little bit helps.  So here's the new executable and the modified links source code.

links-ttf-iz2s-beta3.zip
links-ttf-src3.tgz