Stuck on Segfault

This time I really and truly wanted to get a links browser build running on the zipit with ttf fonts instead of the fuzzy built-in fonts.  Unfortunately a nasty segfault halted my forward progress like a brick wall.  I swear I'm almost there.  Really.  But apparently not in the mood for a serious debugging  effort.

Before I hit the bricks I made a little bit of progress.  I discovered links apparently has 33 language translations for the menus baked right into the executable, just like the font system.  I removed all but English and French for a 500K RAM savings at runtime and a 100K savings on the jffs.  Not too shabby.  I also devised a simple way of loading one or more of the excised translations at runtime from a shared lib using dlopen, but didn't code it up yet,

Anyhow, this put my free space on the jffs right up around a megabyte.  Sweet!  So I pressed ahead and cut ties with the internal font, roughed in a ttf system based on the plan9 varfont patch, and found myself with a "tiny" 500K upxed links executable that promptly segfaulted.  Aargh!  So close.  I bet if I swapped out the openssl bloat for the tiny matrix ssl library I could get it down around 300K.  Of course, it doesn't work right now.  There's probably some residual piece of the old font system poking at random memory through a bad pointer that I forgot to prune out.  I'll get it, but i need to step away for a moment.

Maybe some relaxing music might get me back into the swing of things?  Well, actually this has been bugging me since the sound system in my fceu build didn't quite work.  I decided to try and port the SDL Drum Toy to get a better idea of how game sound is accomplished.  So I shrunk up the interface from 640x480 to 320x240 for the zipit and gave it a spin.

Heh.  It sounded even crappier than the Super Mario sound running in fceu on the zipit.  But I stuck with it and learned a few things.  Notably, the first 4 sounds in all of the sample music tracks appear to be loaded from .wav files, and work just fine.  The other 12 sounds are typically synthesized at runtime to create an octave of notes, or a few chords.  These FM synthesized notes are generated on the fly at runtime, but about 10 times too slowly for actual use due to the lack of a floating point unit in the zipit processor.   I think this is basically the problem with the fceu sound code.  It can't create sounds fast enough to use them in a timely manner on the zipit hardware.

When I commented out the DrumToy FM synth code, the tracks played at full speed, albeit with only the 4 digital drum sounds.  So I thought maybe if I converted the FM synthesized voices to digital samples on startup then I could play the full musical track.  I allocated a generous 2 seconds worth of samples to each synth voice and suddenly it was taking 3 minutes to bring up the main screen.  That's not so good.  I also botched the formula because the sampled FM synth notes were pure noise.   But at least the tracks were now playing at full speed.  So instead of synthesizing I borrowed the samples from the NDS bliptracker and used them to replace six of the synthesized voices in the demo1 track.  It sounded weird, but it worked.  It looks like you can probably make full use of all 16 voices in the DrumToy if you can find 12 more decent mono .wav files.

This music stuff is kinda fun so I may tinker with it some more, until I feel like taking on the segfault.  There must be some simple integer only synth code out there somewhere, right?  Didn't we have different notes on the PC speaker way back when DOS ran off a flippy floppy?  I may even have a 5 inch floppy in the attic with that sort of code on it.  Too bad I got nothing to read it.

I see there's quite a bit of sample code here.  And this has some fast integer sine functions, with arm assembler code!  Just what the doctor ordered.  The DrumToy FM synth boils down to a few floating point multiplies and two sine calls per sample.  If I can just convert it all to fixed point, that function might just do the trick.

There's also an interesting thread on MilkyTracker at the dingoo forum.  Hmm...

Yeah, so that turned out to be a relatively easy build for the zipit.  It takes almost 30 seconds to load, but seems to work ok.  However it requires the z2mouse which makes it somewhat cumbersome to use.  I might take a look at the keybinding code someday to make it easier to control.  Although I'm not sure how much I can do.  It seems to have a function for every single key on a full PC keyboard.  So any sort of "fix" would just be a trade off for a slightly more usable set of keys.

Since I don't particularly like the dpad "mouse", I thought it might be a good idea to try and dig up something mouseless.  I ran a search for ncurses trackers, but most of that stuff appeared to be rather old.  I built the ancient funktrackerGOLD and managed to play it's example songs, but it reqires an 80 character wide terminal, which forced me to load this nearly unreadable Atari font.

It also sounds like the music is being played underwater.  Is that really the way 8bits used to sound?  No, it's not.  Turns out the mixer code in funktracker uses doubles.  The individual instruments actually sound just fine when played manually via the the single octave on the z row of the keyboard.  I did some experiments reshaping the display for a bigger font, and fixed some nasty stack overrun bugs caused by string overflows.  I'd say this has promise, if I can convert the mixer code to integers.


Update: 

I've spent some time in the DrumToy code and made a little bit of progress.  The integer sine functions seem to work ok.  It can now synthesize the 12 FM notes on the fly, which is pretty cool.  The small errors introduced by the integer math may be changing the tone of the notes somewhat, but it's hard to tell because I've found a bigger problem.  The tempo isn't working right on the zipit.  At some point I noticed the 4 wav sounds seemed to stutter and hang around too long, which got me looking at the code for maintaining the tempo.  It's starting to look like the DrumToy was programmed with a fairly powerful PC in mind.

I'm not sure exactly where the tempo problem originates, but I suspect there's too much wasteful math happening in some of the inner code loops where it should just be moving data out to the audio device.  I did some experiments with reducing the graphics overhead and that quickened the tempo quite a bit, but still not quite up to full speed.  I also did an experiment with no notes playing, not even the wav notes, and it still failed to keep up with the expected 120 beats per minute.  That should never happen.  So I've gotta fix this before I go back and  attempt to smooth out the FM sounds by tweaking the location of the decimal point in the integer math.

Update 2: 

 Heh.  Apparently there was some more sneaky floating point math (that I completely missed) in the saturation_process function.  I commented that out and now it runs at the correct speed.  So it's back to tweaking the integer math in the FM synthesis code.  Gotta find me a few more bits of precision for those low, low notes in the demo1 track.

Actually all of the integer math notes were sounding a bit flat, even to my tin ear.  What's up with that?  I dug up a cheap guitar tuner gizmo and verified it.  They are indeed flat.  Whereas the tuner says the floating point math is generating the true notes.  Hmm, maybe I should go back to double precision floats for the initial frequency calculations, and save the integer math for the runtime sample generation?  Or maybe the integer sine function loses precision as the number of cycles increases?  I don't know, so I think I'll go back and retest it with some additional (more realistic) sample points.

Update 3:

I solved the problem with the flat notes.  It was accumulating errors in the integer math, which pushed all the frequencies off by a few cycles per second.  Now it sounds halfway decent, and the guitar tuner gives it the thumbs up too.  It still needs lotsa work with the location of the decimal point in all of the integer multiplies.  I think there are parts of the code where I'm down to a single bit of precision -- the sign bit -- but it's only supposed to be a "toy", right?  So it'll have to do for now.

Here's a nice blurry video.  Enjoy.

Here's some DrumToy executables for IZ2S and OpenWRT, with the integer FM synthesis source code included.

drumtoy-fm-iz2s.zip
drumtoy-fm-wrt.tgz

And here's a milkytracker package for IZ2S.

milkytracker-iz2s.zip

The openwrt package should have shown up in the nightly builds by now.  It's in mozzwald's repo but not yet in the chainxor repo, which probably calculates "nightly" in Australian.

A File Manager for SDL?

I'd really like to stay focused on converting the flipclock and the links browser from png to ttf fonts, but sometimes the distractions just sorta pop up outta nowhere.  Way, way down on my todo list is a requirement for some sort of file manager for iz2jffs.  Now I don't need it myself because I'm old and the command line was the only game in town when I started using computers.  But I've seen plenty of folks struggling to find their way around when presented with a command prompt.  So when I stumbled on a file manager written in C and SDL on a raspberry pi forum, I figured I had to stop and take a look.   I tweaked a few lines of code to shrink up the display into something a bit more zipit sized, and ended up with this.

It still needs work to make it usable on the zipit, but it shows promise.  Plus it's only about 25k after upxing so it could easily fit on the jffs.  However, first I should decide if it makes more sense to add some basic file manager functions to gmenu2x instead.  Based on the grey function buttons in the image above, there really isn't all that much missing from the gmenu2x base code.

So I took another look at Dingux Commander which has a more polished look, shown here browsing the iz2jffs home directory in the left panel, and the mounted filesystems on the right.

But it's C++, and at 115K it's not such a great candidate to put on the jffs.  However, I thought maybe I could simply fold the code for the split panel view and the file manager functions into the gmenu2x C++ code base without increasing the bloat by all that much.  And as it turns out, folding the Dingux Commander code into gmenu2x (with minimal changes to make it build) only adds about 14K to the total after upxing.  So I guess I should probably provide an executable, and think about rolling another release of the jffs.

Here's a tar file with a new gmenu2x executable and that nice striped background image.  To keep it simple I used the ttf font and icon images from the gmenu2x default skin instead of the ones from Dingux Commander.   If you try it, you should see a shiny new File Manager icon in the applications folder, right next to the Explorer icon.

gmenu2x-cmdr.tgz

After getting the basics working I did some more work on the code to make it fit in better on the jffs.  I altered a few of the key bindings and turned on blended text for a smoother, more readable look.  You can see here its using the smoothed gmenu2x font and the icons from the default gmenu2x theme.  Looks nice.

 

 I also patched the Dingux Commander text file viewer to reuse the gmenu2x code that I created for viewing Latin15 text files.

Finally, I merged the Commander text input code with the gmenu2x input code to enable Latin 15 input via the zipit keyboard instead of the on screen keyboard for the mkdir and rename functions.  Altogether it seemed like a fairly useful addition to the jffs, so I rolled out yet another iz2jffs5 release.


And now I can get back to the ttf stuff.  I took a quick peek the plan9 links-varfont hack and it looks like 90 percent of the conversion from png font to ttf can be done by replacing 3 functions in dip.c:  g_print_text(), g_text_width(), and g_char_width() with the equivalent SDL_ttf functions.  I still need grep for "ifdef PLAN9" and evaluate the rest of the diffs for subtle issues, but it doesn't look too painful...

Time for a Change

I've been rolling out new iz2jffs5 updates at a fairly rapid pace for two weeks now, so I figured maybe it was time for a change of pace.

So I checked the todo list, double checked it, and decided to finally do something about that flipclock app that's been languishing there for quite a while now.  The first thing I had to do was track down the problem with the display.  It was way too flickery to leave on all night.  I tried it once and it drove me nuts.  So I reorganized the code a bit to give the SDL software double buffering a chance to do it's thing.  Now I can leave it running without fearing for my sanity.

After spending all that quality time in the code I finally felt more confident adding some command line options to do various messaging functions in the blank space below the actual clock.

It's now got 4 lines of text using the png font file that I borrowed from slug's gmenu2x a while back.  I could've fit 5 lines, but it seemed kinda tight.  So far I've got code to put up simple static messages, strftime formatted time and date messages, and messages that can be updated on the fly by polling a file.  I'm planning to use that one someday to feed it a real live weather report.  It integrates pretty well with the iz2jffs alarm script so I included a sample implementation of that too.  Here's the usage message to give you some idea how I intend to use it.


Usage:  fc [-1|-2|-3|-4][D|f][w|d] [message|file|timeformat]

Displays a flipclock and up to 4 lines of text messages underneath.

  f = Display message from a file.  Updates whenever the file does.
  D = Display the date/time by passing timeformat through strftime().
      Line 3 defaults to a date using "%b %d, %Y  -  %l:%M %p".
  w = white text (default = grey)
  d = darker grey text.

eg:  fc -1d "Nice weather." -2D "%b %d, %Y" -3 "" -4 "Wake at 7 AM"

This should work on either IZ2S or the iz2jffs, although I haven't yet tested the alarm script in the bash shell on IZ2S.
fc-iz2jffs.zip

Source code:
fc-iz2s-src.zip

I'd still like to see if I can get it to use the gmu font files in addition to sfont files and the modified gmenu2x sfont file.  I suspect gmu uses only fixed width fonts because the fonts lack the "magic pink" spacers on the top image line.

Update:

I added a -t option for 24hr time in the main clock display, and -p for padding the upper hour digit with a zero for folks who need to see 4 digits all the time.  I also experimented with various options for the  date string to see what could be done with that.  Here I tried it with a bigger message font and this command for an ISO 8601 date with 24 Hour time.

   fc -tp -3w "%F - %R %p"

I forgot sfont files can come in colors, so I think I probably need to change the w option to b for bold and remove all mention of grey from the usage message.  I'll package up a new executable and the code real soon now, depending on how far I get with the gmu font file.  Here's what that looks like so far.  I added a -w<size> option just in case it can't figure out the font width from the png image size.

I have to say, I definitely prefer the layout of the GMU font file to the gmenu2x "sfontplus" file.  The GMU font files are quite small because they use fixed width characters.  The magic pink spacers don't seem to compress so well in the sfont files.  But what I really like about the GMU file is that it's a simple 256 character latin1 font, which works quite well with the latin15 setup of the iz2jffs.  The gmenu2x sfontplus file has the glyph order scrambled all willy-nilly.  Who came up with that?  If I ever do get back to working with the openwrt-zipit version of the gmenu2x code, the first thing I'm gonna do is re-order the glyphs in the font file.  It's unicode so I'll just put them in unicode standard order with the gaps for missing characters compressed.

Now if only I could convince gimp or mtpaint to generate a decent png font file, I'd be all set with the flipclock app.

Maybe this microfontmaker thing will do it for me?  I just gotta find me a PC that still has java on it.

Or maybe I can hack the code from that tiny sdl font previewer to save a png file.

Or use one of the many Windows texture font makers like bmfont.  Something's gotta work.

Or maybe I should just come to terms with the fact that libfreetype and libSDL_ttf actually fit on the jffs with plenty of room to spare.  I really should be using ttf fonts for everything.  In fact, the best change I could make to the jffs would be to chop the huge png font outta links and replace it with some nice ttf fonts that all the apps can use.  I really need to take another look at that plan9 ttf version of links...

Update 2:

I managed to modify the dingux gmenu2x font generator program gen_sfont_image.py to create a latin1 png font instead with gen_sfont_latin.py.  I used it to create an sfont file with the same latin1 glyph order as the gmu font file, except this one uses a proportional spaced 15 point DejaVuSansCondensed font. The file is a bit larger than I'd like so maybe the gmu font makes more sense for the jffs.  I might do some more experiments generating fonts, but more likely I'll start converting the flipclock to use a ttf font.  Heck, even the tiny imgv program uses the ttf font.

I did a quick latin test on puppy linux and it seems to work, maybe.

Here's the new flipclock release.
fc3-iz2jffs.zip

Source code:
fc3-iz2jffs-src.zip


Meanwhile, since I'm still waffling over then benefits and drawbacks of libfreetype I should probably mention stb_truetype.h over at http://nothings.org.  It replaces libfreetype with a small C header file.  You give up some quality (hinting) and performance for the tiny size but you also lose the dependency on the huge shared lib.  I probably can't use it on the zipit because I really want the hints for the smaller fonts.  But I'm gonna have to try it.  And some of the other code there too.

iz2jffs v5

Note, there's a bunch of releases here.  The most recent is down at the bottom.

It took a while, but I finally came to my senses and realized I was never gonna get around to everything on my todo list.  So I decided to patch together whatever good stuff I could find from the last 9 months and roll a new iz2jffs release.  It still looks a whole lot like like the v4 release, but there are actually quite a few changes under the hood.  Thanks to the new upx many of the executables are smaller, and quite a few have also been updated or improved in some small way.  I used up a little bit of the extra space so I could include dvtm and my sel file selector based "album" script for handy command line mp3 playing.  There's currently about 640K free on the jffs, which is plenty big enough to experiment with some more new goodies.

Here's a quick picture.  Hey look, is that 30GB free on the SD card?  Nice!  The 32GB class 10 Sandisk card I recently acquired seems to work just fine so far...

Here's my first try:
iz2jffs-e5.tgz

Heh.  That one didn't last very long.  I updated a few more programs for about 800K free:
iz2jffs-e5.1.tgz

And then I fixed the gmenu2x battery monitor, changed the input.conf file to include key bindings from slug's jffs, and made it a wee bit smaller so I now have 820K free:
iz2jffs-e5.2.tgz

And if anyone else actually tries it out, feedback can only make it better.  Based on Dronz's feedback I made yet another build with my forgotten LED fix, even more upxed executables, and a smaller (DejaVuSans) font file that I also found to be more readable.  The jffs now has over 900K free!
iz2jffs-e5.3.tgz

I replaced the useless gmenu2x touchscreen code with a semi functional wifi indicator and switched to the smaller Bepa-Roman.ttf font file for 920K free.
iz2jffs-e5.4.tgz

Uh oh.  I think I may have left out the font from that last one.  Yikes!  Hopefully I got it into this next one.  I also added an updated imgv viewer and patched the gmenu2x file explorer to let me select a directory with the spacebar and pass that to imgv.  Then I can quickly cycle through all the pictures in that directory with imgv using the n and p keys, or s for a slideshow.  And while I was working on the explorer code, I also removed the restriction that would only let you run programs with certain gp2x executable file extensions.  So now you can launch anything.  Be careful with that.
iz2jffs-e5.5.tgz

For the next build I made some overdue cosmetic changes.  I replaced the ugly SD card and Speaker icons on the bottom bar, and tweaked the wifi script so the wifi bars will show up right after you connect.  I also added slightly modified versions of Dronz's new alarm script and micro SD refresh app.  I'd still like to fix the Ctrl-c handler in the alarm app and figure out how to make it use the space-bar to quit in addition to the q key.
iz2jffs-e5.6.tgz

After testing the alarm script this overnight I decided to tinker with the display.  Now it's centered, with the current time up top where it's easy to find since that's what I want to check in the middle of the night.  I also figured out how to use the space and esc keys to quit.  Afterward I experimented with flipclock for the display.  It works, but I need to tweak it to display and possibly control the alarm setting.  Altogether it's not yet enough to warrent another release, but here's the current incarnation of the alarm script if you want to try it.

All the nice internet radio options got me wanting an easy way to change the volume without leaving gmenu2, so I finally decided to fix it up right for the zipit.  I replaced the broken volume and cpu speed settings with separate working headphone and speaker controls using the zipit volume buttons (ctrl-volume for the speaker).  I also replaced the start and select button images so the help messages almost match the zipit key bindings.  Check out the cute little zipit key in the Radio selector.  I added an AudioCheck selection that you can use to turn off the radio, or test the alarm beep volume.

iz2jffs-e5.7.tgz

I was on a bit of a roll there for a while, but all good things must come to an end.  I made a few more changes and then got distracted by the flipclock app and an SDL file manager program, so this next one may be it for a while.

I noticed the gmenu2x volume controls were starting up at -1, and all of the audio scripts contained "alsa started" tests.  So I decided to waste another second during startup and launch setup-alsa-sh from the Zcovery script.  I also added some commented out gmu and rockbox launchers in Zcovery to show how to tweak the jffs for a dedicated internet radio device that starts playing right away, or a car audio player that's easier to get going while you're behind the wheel.  I have one of each myself.

While I was in the Zcovery script I decided to pre-rotate all 4 of the consoles during startup.  This got me thinking about the mpg1234tty4 script and the way it works in gmenu2x.  The radio app launches mpg123 into a background process (on tty4) so I thought it might be better to use the gmenu2x dontleave option.  I tried it, and it came out looking much cleaner, but I noticed I could no longer change the channel.  It turned out the gmenu2x dontleave code had a bug that would add params (the new channel) to the end of the existing command line instead of starting over from scratch.  Thus mpg123 would always start up working on the first channel selected and not the new channel.  I fixed the bug and now the radio app is better than ever.

However rockbox and gmu were now more difficult to use because they use internal software volume controls and expect the main volume (or Headphone volume) to be set high.   So I edited their startup scripts to temporarily set the Headphone volume to 95% so they can maintain their own internal volume settings from session to session.  The scripts restore the gmenu2x headphone settings when the apps exit.

In addition, I made a few more cosmetic changes.  Dronz supplied the Black Gloss theme, and I read the mtpaint documentation on layers and transparency so I could clean up the button images I made earlier.  I also decided to reuse the old about icon for the new help app since it was a bit cleaner and they were quite similar otherwise.

iz2jffs-e5.8.tgz

Did I just say 5.8 would be the last one for a while?  Oops.   Apparently I was mistaken.  I was reviewing all the new help text when I suddenly remembered that gmenu2x has it's own set of help functions that might also have some utility.  So the first thing I did was pipe the mpg123 messages from the radio app through a tee and into a log file.  I hooked the log file up to the help info function on the radio app, so now I can check the recently played song list without ever leaving gmenu2x.   Since the help icon that appears on the bottom bar has an i (for info?) I added the i key to the input.conf file.  And while I was in there I also added the missing inc and dec keys so I can twiddle the color numbers in the skin settings dialog.

The next thing I tried to do was to hook up the rockbox help file to the rockbox app, but that file is html and all the tags made it nearly unreadable in the readme dialog.  So I patched gmenu2x to pass .html help files through a sed filter and strip out most of the html tags before opening up the readme dialog.  Hmm, maybe someday I'll replace the odd gmenu2x manual file support with some limited html support instead...

Anyhow, once that was working I attempted to use the full help.html file.  But that file uses latin15 character coding and gmenu2x only likes utf8, so I whipped up a simple on the fly converter and also fixed it to expand tab characters into  multiple spaces.  It's not perfect.  The html sed filter mangles the euro character (it looks ok in a .txt file).  The help text for the < and > keys also gets mangled by the html sed filter.  Plus the expanded tabs will never look quite right with a proportional space font (maybe I'll implement a pseudo fixed width font mode for the readme files).  But overall I'd say it's readable, and possibly even somewhat helpful.

I also replaced the clunky gmenu2x onscreen keyboard code with slug's patch supporting the real zipit keys, and then enhanced that with the pspmaps code for the Latin15 keymap.

I'll post the new stuff soon.  Gotta play with it a bit more and then wrap it all up.

Then maybe I'll start digging into links again.  I couldn't find the back button in text mode.  So I'd like to match up the text mode and graphics mode keys better, maybe pull in slug's zoom patch, and see if I can possibly replace the built in png font with ttf.

iz2jffs-e5.9.tgz

I made a few small changes to make sampling internet radio work better with the links browser.  Then I merged Dingux Commander into gmenu2x and decided it was enough of an enhancement to roll one more release.  You can read that story in a more recent post above.  Meanwhile, here's the goods.

iz2jffs-e5.10.tgz

The really old install instructions should still suffice for the jffs.

Fun and Games

Sometimes it seems like the one thing everyone wants to do on the zipit is recreate their cherished childhood memories playing various ancient video games.  I suppose I did that myself for a while when I finally got the rockblox plugin working in rockbox.  I still remember passing the entirety of a particularly long airport layover ages ago in New Oreleans, playing Breakout on the purchasing power of a single quarter.  I was actually saddened when the time finally came to board the plane because I still had 5 or 6 free game credits racked up.

While it's not exactly from my childhood, I do have some cherished memories of playing Super Mario and Link on the NES.  Link was a particular favorite because I never really finished it until the kids were old enough to try it, and they pushed me to complete the mission.  I think we still have the old NES box and a pile of cartridges tucked away in a closet somewhere...

Anyhow, the topic came up for like the millionth time on the zipit IRC channel and this time I made up my mind to try and build an NES emulator.  After reviewing the multitudinous choices, I eventually settled on the FCEU Rerecording emulator.  It's been built for the zipit before, but not yet for IZ2S or openwrt, the two zipit distros I seem to be using these days.

I got it working on IZ2S, but just like everyone before me I failed to get decent working sound out of it.  Plus the key binding configuration requires me to launch it from an ssh session so I can see the config instructions.  That's just weird.   So I thought I might try this gpfce variant of fceu.  It's got some ARM assembler optimations and a nifty SDL menu system borrowed from the picodrive emulator.

I got that working too, and the menus do look nice, but the emulation runs even slower.  Oh well.

After building both of these for IZ2S I decided to try and attempt an openwrt build.  This was more of a challenge.  I didn't feel up to wrestling with the weird openwrt Makefile and patches build system so I opted to compile it on the zipit itself.  This took longer that I'd have liked and probably wore a groove into my SD card, but eventually resulted in an fceu executable.  I launched it from ssh and configured the keys only to discover it had some sort of graphics bug, perhaps due to some quirk in the particular gcc version used by the native compiler.  Drat!  That forced me back into the openwrt Makefile that I was hoping to avoid.  

I eventually wrangled the Makefile into a working build, but it wasn't exactly easy.  The openwrt configure junk wouldn't even run until I figured out how to make it reduce the fceu folder depth by one level.  And autoconf absolutely refused to find the lua lib no matter what weird openwrt hack I threw at it, so I had to make a cheesy patch to trick the autoconf files into skipping the liblua check.

Goodies were posted to the zipit IRC channel.  I'll track them down and post them here when I get a chance.

Here's the iz2s build of fceu;
fceu-iz2s.zip

The fceu Makefile and patches are on the openwrt-zipit github now.
https://github.com/openwrt-zipit/openwrt-zipit-packages/tree/master/fceu

Here's my openwrt build of fceu:
fceu r67-1 pxa.ipk

Just in case the one from the nightly build has problems:
http://mozzwald.homelinux.net/zipit/openwrt/pxa/packages/fceu_r67-1_pxa.ipk

I also spent some more time on tinyirc.  The MirOS variant has a working SIGWINCH  handler which I've tested by resizing it in dvtm.  The executable it 1K bigger because they   added all sorts of improved random number generator code for the private messaging.  Whatever.  I do like the resize code.

I also built the recent Finch release for openwrt and compiled a notification plugin at Slug's request.  We'll have to wait and see just exactly what that does for the zipit.

Here's the libpurple ipk, the new finch ipk to go with it, and  the ultra generic command-execute.so plugin. It does a system call on whatever command string you want so you can make your own special notification.

A New Gmu

So once again I was settling down, just letting the todo list grow, when out of the blue wej announces a new release of his gmu music player on the zipit IRC channel.  Gotta try it.

The new large font is big improvement.  And the png file with the new font is actually smaller than the original.   Go figure...

Gmu now comes with an ncurses GUI which can be run from a remote PC.

I couldn't figure out if it has any volume control, and I miss the o and * markers from the SDL frontend.  Also the help messages on the bottom don't all fit on the zipit screen.  But overall, it seems to work.

Update:  Our nitpicking on the zipit IRC channel resulted in a quick update to the new gmu release addressing most of the bug reports and enhancement requests.

I've made a patch to build it with regular non-wide-char ncurses.   Now I just have to package up a full IZ2S build.  For now, I've packed it up without the libs.  If you don't already have them you can get the shared libs for the codecs from one of the older gmu packages and put them in the libs directory on the root of the sd card.

gmu-0.9.1-iz2s-nolibs.zip

Also, here are some tinyirc updates for IZ2S and openwrt that address problems with the command line display for long lines, and some other screen refresh issues in the openwrt build.  The upxed executables are around 13K.  Both tarballs contain the updated source code in addition to the executable.  Someday I'll get it into a github repository.

Note: The IZ2S executable uses the shared ncurses lib posted a while back.

tinyirc-iz2s-cmdfix.tgz
tinirc-wrt-cmdfix-src-bin.tgz

And I might have created a functioning nethack build for openwrt if anyone wants it.  Rumor has it the official packages don't work right now.

And finally, although I was unable to conquer the high CPU usage issue in the openwrt build of gmu, I did build an openwrt version of my IZ2S libSDL with the ALSA buffering patch.  It also has slug's patches for gmenu2x. It smooths out some of the glitches when playing music from slow SD cards and may fix other minor sound issues with SDL programs.  It also allows me to use a shared lib version of rockbox so maybe someday I'll be able to squeeze that onto an openwrt jffs.

libSDL-wrt-alsa-buffered.gz

Here's the patch I used to build it in openwrt.

005-sdl-alsa-buffer.patch

A Fine Selection of... Something?

While on break from my previous break from ever finishing anything I mentioned the Blacklight mp3 player on the zipit IRC channel.  I knew slug was looking for a minimal front end to mpg123 and he seems to like C++ a whole lot more than I do.  We played with some g++ compile/link options and slug managed to get it down to a fairly tiny 16K build for his openwrt jffs.

Unfortunately C++ doesn't reduce nearly as well with the IZ2S compiler.  I only got it down around 34K using uClibc++, a shared lib version of ncurses, the lzma upx, and the magic compiler options.  I can't seem to lose the exception handler code, despite my best efforts.  It also seems to make mpg123 sound a bit worse.

However, Blacklight is really just a file selector at heart, which reminded me of the sel file selector program I tinkered with a while ago, but never really got around to finishing.  The sel program is a capable ncurses based complement to the dialog program  for shell scripted text GUIs.

The original web site is long dead, so I retrieved sel from the wayback machine.  Stripped, upxed, and linked against the shared ncurses lib from the Junk in the Trunk post it comes out around 14K, which makes it small enough to toss onto the jffs.  I added support for some more handy navigation keys on the zipit, made it always quote the filenames, and fixed up the globbing code to tack the glob string (eg. *.mp3) onto selected directories.  This works pretty well to let me select and play whole directories of mp3s, as well as select files to play individually.

    sel -b "Play MP3s" -m "*.mp3" -c "mpg123 -C %" -d /mnt/sd0/music

Here's an updated zip file with the modified sel sources and two executables for IZ2S, one with ncurses static linked, and one shared.

sel-0-08-4-iz2s.zip

Update:  I couldn't leave it alone so I went and tested it in DVTM along with a mini rexima window for the volume control.  I couldn't decide what to put in the 3rd window, so I just ran another copy of sel.  That lets me start one window playing a makeshift playlist and then use the other window to select some more music for later.  I suppose that could be handy, although what I really ought to do is make a sel command that inserts the selected items into an mpg123 command fifo and then simply run mpg123 on the fifo in the 3rd window.

I tweaked the sources a little bit more to get sel working in the tiny window, and I still need to patch the code to handle a window resize.  I'll post a new zip when it all works again.

sel-0-08-04zz-iz2s.zip