Back on the Map

Last time around I did some updates to libmikmod and the sdl-mixer library.  Considering my previous lack of testing on them, I decided it'd probably be best to be a wee bit more thorough this time.  So I tracked down some oldschool galaga style games and gave them a zipit makeover.  I'd really prefer to get a nice version of centipede, joust, or one of the many zelda clones on the zipit, but didn't see anything that struck me as easy, so space shooters was it this time.

I started with dodgin' diamond and all went well.  Even the two player mode seen above appears to work, although it's difficult to get 2 different hands on the zipit keyboard at the same time.   Next I decided to give the fancier looking powermanga game a try.  I thought I maybe powermanga would be a more challenging port, given the code size and some floating point bits, but it was pretty smooth right out of the box on the medium sound quality setting.  So I'll take that as a win and move on.

I still wanted to leverage my success with the fixed point supertux patch into something more substantial, so I decided to see if I could do anything with protracker.  I'd like a few more tracker options on the zipit, and my little piggy tracker port was stuck on a blank screen for some reason.  Meanwhile protracker looked almost feasible.  I did a quick and dirty screen hack to remove the pixel doubling and chopped last 15 rows of the display to fit it onto the zipit screen.  It actually looks fairly decent, but appears to require the fake mouse controls on the dpad buttons, and all sorts of internal mixer and filter code needs a conversion to fixed point if I ever want to hear more than an occasional squeek out of it.

Unfortunately, about halfway through the float to fixed point conversion, we hit the Christmas holiday season and the zipit irc channel came alive with chatter.  Someone mentioned the pspmaps location lookup appeared to be broken.  My attention deficit disorder took control and off I went into fixit mode.  It didn't take long to discover that google had shut off the V2 googlemaps API a while back.  The V3 options were JSON or XML.  No sign of the CSV and KML options from V2.  Oh well.  I'd been meaning to tinker with JSON again someday.  And now that day had arrived.  I checked out a few small JSON libraries for C, but I'd seen cJSON before in the opentyrian code, and it looked simple enough, so I went with that.  After a modicum of testing, I had a working fix for both the location and driving direction lookups, so I bumped the version number.

Someday I'd like to add an option to use the OpenStreetMap lookup as well.  That way there's a backup solution, just in case google decides to obsolete their API again.  Also, I suspect openstreetmap might make it easier to add support for more permanent offline map sets.

I noticed the original pspmaps site was gone, but there was a github project with a few odd fixes from just before the google API change.  So I forked it, got back up to speed with git (after maybe two years of rust), and rebased the openwrt-zipit pspmaps project off my github fork instead of the dead link to the past.  I still haven't restored my openwrt-zipit build system after the recent hard disk crash, so hopefully somebody will notice and rebuild the openwrt pspmaps package.

Here's the goodies:

dd2-iz2s.zip

powermanga-iz2s.zip

I still need to package up pspmaps.  For now here's a new executable and urls.txt file for pspmaps on openwrt.  Just untar it in the pspmaps directory.

pspmaps-update_2_4_wrt.tgz

Do the same for the iz2s executable.

pspmaps-update-2_4-iz2s.zip

I'll have to do another blog post if ever get one of those trackers working.

In the meantime I should probably say something about the Navit GPS/map program since it came up in the same IRC conversation as pspmaps.

By following the TomTom build recipe I got it to compile for iz2s, as a possible offline map alternative to pspmaps.  Apparently it wants to be in Germany?  However it crashed when I attempted to bring up the internal gui, so it clearly still needs some work...

Update:

Ok, I fixed the crash and found the maemo build recipe, which had some more clues on how to configure it better for the zipit, like converting the svg icons to png, and discouraging floating point math.

I still have a few more icons to track down and convert, but most of the menus look all right now.  Perhaps it's time to fetch some more map data, other than that sample patch in Germany.

So I visited the Navit Planet Extractor website and fetched me a rectangle of OpenStreetMap data.  The smallest chunk it wanted to give was around 80 megabytes, so I went with that.  It sorta worked.  I could search for towns and streets contained within the map data, but the map itself was a mess.  It was very slow to update and missing (or simply not displaying) features that I know should be there.  Perhaps the 32 megabytes of RAM on the zipit is not enough?  I've read some notes that suggest Navit is not the most efficient app in the world.  I'll have to play with it some more and see it there's any way to make it feel like a useful tool on the zipit.  Or maybe I'll just grab the 700MB prepackaged blob of north east corridor USA map data from the Planet Extractor and see if I can make the zipit pop...

Or maybe I should try to use something like gmapcatcher to fetch map tiles for pspmaps.  I might have to reorganize the pspmaps cache to be compatible with the directory structure though.  It looks like it might be close.

Update 2:

It actually was pretty close.  Well, not really.  The pspmaps cache is a simple list of N numbered png files.  The meaning of those files is stored in a separate disk.dat file as a list of x,y,z coordinates (and a number for the specific map service), one entry for each numbered file in the cache.   It's these entries that match the directory and file structure of the gmapcatcher data, exactly.  They also match up with the OpenStreetMap Slippy map tilenames convention.  That meant it required just a few new lines of code in tile.c to convince pspmaps to check the offline gmapcatcher data before resorting to a network lookup.

Here you can see where pspmaps used some offline tiles saved by gmapcatcher.  I used two different map servers so I could be sure.  On the bottom left is a tile fetched from google by pspmaps.  The rest of the image is made up of tiles pulled from the offline files saved by gmapcatcher.  I forget which map service it was using, but you can easily see the difference.

Anyhow, I'll eventually put some sort of Navit package for iz2s here, and another revision of pspmaps too.

Update 3:

I've run out of vacation time so I zipped up a Navit package for iz2s.

navit-iz2s.zip

I haven't yet tried any of the large pre-made data sets, so I don't really know if it's actually useful.  I'll get back to it eventually.

Meanwhile, I think pspmaps has a lot of untapped potential.  I put the code in my github repository and added my offline map code to work with the OSM_tile data from gmapcatcher.  I also fixed it to remember a preferred default map service, and tweaked the code to allow you to skip map services that don't interest you.  

I've got a few other small changes that I'd like to make.  The simplistic linear searching disk cache implementation could use some work to allow it to scale up.  Maybe hash table lookups, or at the very least least make it do a binary tree search.  I'd also like to add some simple versions of the gmapcatcher functions.  A small radius local area capture with a few autozoom levels would be nice.  And an OSM_tile format offline map export function would make it possible to use the zipit instead of gmapcatcher in a pinch.  And of course I still want OpenStreetMap location and driving directions lookup as an alternative to google.

Some wilder ideas include better driving directions, with access to the text version of the route, and maybe markers for the turns.  Point of Interest data might also be fun to play with.  Maybe OpenPOIs or the OpenStreetMap Overpass_API would work?  I could probably use some of the 16x16 png icons from Navit as the markers...

Hopefully I'll have something worthy of a release soon...

Ok, this has the offline stuff and allows you to comment out map services that you don't want in urls.txt.  See the readme.txt file for details.  Once again it's just an updated executable with urls.txt and a readme file, not a full package.

pspmaps-update-2_4-1-iz2s.zip

Same for the wrt update...

pspmaps-update-2_4_1-wrt.tgz

Update 4:

As life would have it, I actually got a chance to try out pspmaps in a real world situation. I had to visit a company near Boston to get me some nifty software training for work.  Christmas flew by and I still don't have a smart phone with a data plan, so I loaded up the offline cache in pspmaps on the zipit.  I also generated some driving directions.  It worked, but just barely.  The screen is just a wee bit small to see enough of the map while driving, the thin blue directions line was barely visible at night on the road, and I really could have used the text directions.

I can't do much about the screen size, so I widened the blue line in the code and got to work on parsing the text out of the JSON driving directions.

 Wider is better

I'm using the SDL_rtf sample app as a mockup for the display.  It works reasonably well for my purposes (and I still dream of a minimal word processor app on the zipit someday) so I think I might stick with it when I fold the code back into pspmaps.

While I'm at it, maybe I should try to hook up the flite speech synthesis from the bard package to read the text out loud.  At the very least I should try and feed this sample text to flite and see if the pronunciation is intelligible.  That should be an interesting exercise.

Update 5:

Ok, I haven't tried to hook up flite, but I did fold the SDL_rtf driving directions code back into pspmaps.  I really like the way it autowraps the text for me because I wasn't looking forward to writing that part myself.  I had a bit of confusion with latin1 text until I realized the rtf unicode escape sequence \uN is apparently not yet supported in sdl_rtf.  However testing reveals I can simply convert the directions to extended ASCII from the 8 bit latin1 codepage and use that, as seen here.  

 Better watch out for the speed cameras!

The last release of SDL_rtf is more than 10 years old, but it's had a few unreleased updates on the SDL mercurial repository.  I fetched the most recent update for SDL-1.2, from 2012, but didn't see anything that looked like unicode escape sequence support.  So for now I'm sticking with the SDL_rtf v0.1 code.  I added SDL_rtf to the list of openwrt-zipit packages but I don't have a compiler set up to build an actual package for it.  Because of that, I decided to static link SDL_rtf into some pspmaps executables.  

Here's another round of executable updates (and the urls.txt config files).

pspmaps-2_4_2-iz2s.zip

pspmaps-2_4_2-wrt.tgz

The Backspace key gets you to the text directions screen on the zipit.

Faking it, Part 2

Last week I had some pretty good luck with a quick and easy build of the wetspot2 game that I discovered on the gcw zero recent news page.  So I thought maybe I'd go for a twofer and cherry pick another easy target off that list.  I measured things up and decided the last-mission game also looked ripe for the picking.  Naturally, things weren't nearly so simple.

Remember last month when I confessed to pushing a fake build of libmikmod in order to fascilitate a quickie build of SDL_mixer, which I needed to get sdlbasic running?  Well, it turns out libmikmod wasn't the only joker in the pack.  Apparently I also skimped on the SDL_mixer build itself.  I vaguely remember that was somewhat of a challenge to compile because I wanted it to use libmpg123 instead of libsmpeg.  But that involved a bunch of finicky hand patching.  When I finally got that going I failed to check out the other build options.  Turns out the default ogg support is the floating point version, not the fixed point libtremor code that works on the zipit.  Oops.

Which brings us back around to the last-mission story.  I was getting nowhere.  It would load a blank black screen, and then appeared to hang.  So I added some debug printfs and discovered it was actually running behind the black screen, loading a bunch of ogg sound files at something shy of a snails pace.  If I waited long enough, just short of an eternity, it would actually bring up the splash screen and allow me to attempt a game.  Sorta, kinda.  Press a button, then wait a minute for the the floating point ogg code to process the associated squeek or beep sound.   Repeat.  Not much fun at all, really.

I checked the SDL_mixer readme file and sure enough there was an option for libtremor that I hadn't selected.  That might work better than the fake floating point support on the zipit.  So I did a rebuild on the library and now the game loads and plays at reasonable speed on the zipit.  As an added bonus, the new SDL_Mixer lib also fixed up playmus to work on ogg files.  I wonder what else I might have missed.  Say, doesn't supertux use ogg?  Perhaps I should take another look at that.

Meanwhile I've got a new SDL_mixer and last-mission package to put up here...

libSDL_mixer-iz2s-tremor.zip
last-mission-iz2s.zip

Update:

So, I fetched supertux and applied the 4 patches from the openwrt-zipit project before compiling.  The resulting executable took a while to load, but it ran and the music played ok.  However the controls were sluggish and the frame refresh rate was pretty darn awful.  Digging into the code revealed floating point math all over the place.  Oh well.  But wait, I don't give up that easy.  I ran some internet searches and found a fixed-point patch for a slightly older version of supertux that was done for the zaurus.  I also found some tantalizing hints that someone might have updated them to the newer code, but could't locate the goods.  The outdated patch was pretty large, but I gave it a shot and then attempted to manually merge the rejected parts.

As far as I can tell so far it seems to work.  The controls are smooth and the game is much more playable.

So now I just gotta pack it up and make an updated version of the patch...

supertux-iz2s.zip
supertux-0.1.3-fp.patch

Two Steps Back...

Seems like only yesterday I installed a brand new 500GB harddisk in my tired old laptop so I'd have plenty of room to work on the zipit stuff.  But apparently it was in there for almost exactly two years last week when it suddenly decided that was enough.  Looking back I suppose it wasn't all that sudden.  It started humming a few hours before it froze, but at the time I thought it was the CPU fan.  Oh well, live and learn.  Shoulda done more frequent backups.

The most recent backup of my iz2s development VM was over 6 months old, and the openwrt backup was even older.  Ouch.  So I dug up a much smaller, slower drive from my junk pile and put the latest LMDE linux on it to get back up and running before the long holiday weekend.  Turns out the 500GB drive wasn't completely dead yet.  I could run it for a few minutes as an external usb drive before it would seize up, just long enough to pull off the iz2s dev stuff.  Phew!  Openwrt was another story though.  I tried a few times, but never got more than half of it.  I gotta think about it before I try again so I don't brick the drive first.  Maybe I can use rsync to resume where the last attempt gave up?  Then I need to come up with a better backup strategy for the long term that plays well with my inherent laziness.  

Meanwhile I had to test the restored iz2s VM and make sure all was well.  I was already running out of holiday so I chose an easy target.  I saw the wetspot2 game mentioned in the recent releases section of the gcw zero forums and thought it might be fun on the zipit.  Since it was developed in C and SDL it looked like a good fit.  The game compiled ok right out of the box, but I eventually tweaked the makefile a teensy bit for the zipit.  Then I changed the 2 player keyboard settings to get a little more separation on the cramped iz2s keyboard, but that was it.

Single player mode uses the dpad arrows to move the crab and the control key (...) to push the blocks.  For two players the tab (Zipit) key is used to move the blocks for player 1.  Player  2 gets the S, Control, Z, and X keys to move the crab, and the space bar to push the blocks.  I actually tried this with one of the kids and it's not too bad.  The player with the arrow keys has a slight advantage though.  I know this because I had the other keys and lost.  It had to be the keys.

wetspot2-iz2s.zip

Oh yeah, I almost forgot.  While the laptop was out of commission I found some time to dig into the iz2s wifi config scripts.  Every so often they'd connect, but fail to get a dhcp lease.  Subsequent retries never seemed to work, and so I was always forced to reboot whenever it happened.  But this time it occurred during my laptop downtime, so I had no excuse not to investigate.  Nothing better to do...

It didn't actually take very long to see what was going on.  The dhcp request failed but the wpa_supplicant demon was left running, and that's what interfered with my retries.  So I patched the script to kill any running wpa_supplicant before starting a new one.  Now a retry usually succeeds.

With that fix in the bag I decided to tackle another nagging wifi issue.  I finally ported the iz2s Easy Wifi Configurator script to work on the jffs.  Sometimes I prefer the dialog driven EWoC script to connect because there's less typing, making it easier to use in a dimly lit location.   The main issue was working out a suitable substitute for awk to fetch the selected line out of the list of SSIDs in one of the dialogs.  A one, two punch of head followed by tail did the trick.  Shoulda thought of that a long time ago...

ewoc-iz2jffs.sh

Can't Fake the Funk

I'm a bit of a sucker for puzzle games like sokoban, especially when they play the oldschool chiptunes for background music.  So a long time ago when my kids went through school and they had some fancy TI graphing calculators, I thought maybe I'd eventually inherit one and hack it to play some silly puzzle games like blockdude.  But, kids being kids, they either lost or broke the darn things and I forgot about it.

Time passed, and then a year or so ago I'd just finished patching up a zipitized build of the Funktracker Gold music tracker (and mod file player) when I spotted a gp2x version of blockdude.  I tweaked the keyboard settings and compiled it for the zipit but couldn't quite get the bleeping sound to work.  My blog post at the time had the title "Game Sounds" so providing blockdude without sound was never gonna fly.  Worse yet, I could not even solve the first level.  Embarrassing!

So I moved on and built some silent console games instead.  I don't think I've passed the first or second level on any of those either (I sense a trend here...) but at least everything seems to work.

Recently I was thinking about fixed point math again, which led me to discover the ancient gp2x version of SDL includes a really nice fixed point math module, with arm assembler code.  Nice.  That in turn led me to some opengl implementations which also incorporate the fixed point module.  I absolutely must explore that some day, but meanwhile it got me thinking again about chiptunes, mod trackers, and eventually my problems with blockdude.

This time I realized the first sound blockdude plays is from a mod file with the title soundtrack.  I remembered that I'd done a quick and dirty build of libmikmod, way, way back when I was trying to compile sdlbasic.  At the time, I only needed libmikmod because it was required to build the SDL_mixer library.  But I didn't have any mod files handy to test it, so I simply used the default config to fake it, and then promptly forgot about it.

So now I did some testing with blockdude and the SDL_mixer playmus utility and discovered that not only did my build of libmikmod refuse to make a peep, it also locked up the sound driver so that nothing else could use it either.  Not good.  So I fetched the latest libmikmod-3.1.18 bugfix release code and applied the config settings from the zipit openwrt makefile.  With the new libmikmod installed, playmus and blockdude could crank out the cheezy chiptunes in all their funky low-fi glory on my zipit.  I'm still stuck in level 1 though...

Here's the goodies.

libmikmod-3.1.18-iz2s.zip  (also includes the playmus utility from SDL_mixer)

blockdude-iz2s.zip

Update:

Made it to level 2.  I feel much smarter now.

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

This One Goes to Eleven

After nearly a year of service it seems the trusty iz2jffs-e10.tgz is showing some signs of age.  We had a burst of new zipit users recently.  A few of them loaded iz2jffs-e10 on their brand new zipits, booted up, and were left staring at the logo splash due to variations in the stock firmware.  Not good.  I need to fix that, so we're gonna have to push it to 11.  I also want to toss in a few fixes and goodies that have been somewhat lacking, like timezone setup and the passwd utility.  Imagine that!  Someone thinking the contents of their zipit might be important enough for a personalized password...

So I added a passwd program and attempted match more of the features in the French jffs.  I made a smaller build of the nano text editor, and made sure I got the color syntax highlighting working.  I also attempted to duplicate the new help system, and copied the French gmenu2x tab layout with a play tab and a program tab.  I'm not completely sold on sdlbasic for the jffs, so I added qemacs and a shell icon to the program section. I also added flipclock to the apps tab and some small console games on the play tab.  

Since I was abandoning the utilities tab, I tossed the media buttons into the settings tab.

With all this new stuff taking up valuable disk space, I felt I needed a smaller links executable so I used the one with less help languages built in.  I'm not quite done testing, so in the meantime here's the new nano.

nano-colors-iz2s.zip

I also finally built a working tmux executable for iz2s.  It's a bit large for the jffs, but you could fit it if you really wanted to.

tmux-iz2s.zip

While I was at it, I also finally did an iz2s build of the finch IM program that doesn't segfault right away.  It includes glib and libpurple so it's quite large, but some people insist it's great on the openwrt system, so here it is. 

finch-iz2s.zip -- But don't use it.  (Use the better version here.) 

And here's a build that I did recently of Quick2dPlot, a nice sdl based plotting program that I want to play some more with when I get a chance.  For example, I might possibly want to try and create an integer only (or fixed point) variation in order to speed it up a bit on the zipit.

q2d-iz2s.zip

Maybe I can turn the zipit into a graphing calculator after all.

Update:  Here's the new iz2jffs.

iz2jffs-e5.11.zip

Unfortunately the old manual install instructions are now obsolete, unless you can obtain the IZ2S 2.05 zip from the internet wayback machine.  So you'll have to install it the easy way with flashstock.  If you use flashstock you'll get a generic MAC address.  You should edit /mnt/ffs/etc/.macaddr if you want to use the proper the MAC address for your zipit, printed on the label under the battery.  There's an option for editing the MAC in the WIFI menu.

SDLvnc

It's been a long, long stretch with not much happening here.  What can I say?  I've been busy.  Yeah, yeah, I know...enough already with the excuses.  Onto the new stuff.

A few years ago (years?!) I mentioned sdlvnc as something to investigate "someday", and apparently never, ever got back to it.  Until now, that is.  There was a sudden flurry of activity on the zipit IRC leading into this weekend, and someone brought up vnc again.  Got me thinking...

So I tracked down the sdlvnc source code, and a slightly updated version of the sdlvnc sample client from WebOS with some screen panning code included.   I also discovered some libsdl_vnc fixes in the SVN repository that apparently have never been released.  In my opinion, either panning or scaling (or both) is absolutely required for vnc to be the least bit useful on the tiny 320x240 zipit screen.  Here's a picture so you can see what I mean.

I'm running a rather small 640x480 tightvnc session on my Debian Mint laptop.  With no panning, even this would be useless, but at least now I finally have a vnc client that's rotated properly for the zipit, thanks to the SDL backend.  However, the vnc mouse is jumpy and sluggish, ctrl-esc may not be the best key combo for quitting vnc, and my current choice of panning keys (ctrl-shift) is cumbersome on the zipit, but I can finally imagine someone actually, maybe attempting to use this in some sort of dire emergency situation.  So I'm gonna release the zipitized sources and an IZ2S executable, as soon as I clean up the code and test it just a wee bit more - especially the keyboard support for the unusual zipit keys. 

Really.  I mean it this time.  Well... except maybe first I want to check out the code for the WebOS junkvnc client, which claims to have taken sdlvnc even further and added a zoom function!

I wonder what else we can borrow from WebOS?

Update:

Ok, I fixed up the keys for the zipit.  Sorta.  It's been so long that I need to review how to do it for the Latin keys.  And I decided to go with ctrl-mousemotion for panning the vnc screen around.  For now.  I'm not sure how that fits in with slug's mouse setup on openwrt.

Here's the modified sources and an IZ2S executable of sdlvnc. 

sdlvnc105-iz2s.zip

I should probably repack it with a vnc wrapper script that sets the SDL environment vars first, but you can steal that from the rockbox, gmu, or glinks wrappers.  That'll have to wait for Rev 2 when I figure out how to fix all the other issues, and maybe add some zoom.

Here's an openwrt executable of sdlvnc.

sdlvnc-wrt.tgz

I'll have to add an option to swap left and center mouse buttons so the openwrt build is less awkward in the current gmenu2x userlands.

Update2:

I managed to get zoom working in 0.05% increments.  It's painfully slow, but it seems to work.  Good luck if you try it on a large framebuffer.  Here's an fbgrab screenshot of 65% zoom on an openwrt zipit.

The vnc zoom is on the ctrl-comma and ctrl-period keys.  I also added a -mb command line option to swap the mouse buttons, making drag-n-drop a bit less painful on openwrt.  I'll try to package it up in both iz2s and openwrt flavors tomorrow during the superbowl.

sdlvnc106-wrt.tgz

sdlvnc106-iz2s.zip

sdlvnc client code on github