Like Clockwork

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

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

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

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

Putting Links on a Diet

I got a bit ahead of myself (skipping a few stops on the roadmap) and compiled a bunjalloo executable for IZ2S.  It doesn't do anything but segfault right now, probably hitting one of those pesky uclibc bugs.  I'll have to shake that out one of these days, but I should probably stick to the original plan before attempting it.

However, I did discover something very interesting.  The size of the executable.  It came out to right around 250K upxed.  That's really, really small compared to the 2+MB upxed links executables that I've been building.  This got me thinking again about how to put links on a diet.  I know OpenSSL is significantly heavier than MatrixSSL.  But the built in font contributes most of the links bloat.  Bunjalloo gets by with only one size (small) font containing only ASCII characters as far as I know.  On the tiny zipit screen that's probably good enough.  If you think about it, the text mode of links does exactly that.

Now, I already knew the enormous font_include.c file was just a bunch of png files shoveled into C code.  But after some digging around I finally realized the graphics subdirectory contains the actual png glyph files and source to the generate_font program which created font_include.c.  Jackpot!  I pruned the glyph files down to just the basic Latin15 codes and some extra punctuation glyphs and then ran generate-font.  Next I rebuilt links with the new slimmer font_include.c and voila!  The upxed executable is almost megabyte lighter.

I tested it on some ebooks and a few websites.  So far It seems to have all the glyphs I typically run into, except for some unusual arrow characters on slashdot that weren't in the original font anyhow.  It's definitely a step up from retawq on the jffs.

I'm now positive I can get a upxed build of links (with graphics) slimmed down to less than a megabyte.  Some of the options I might try are:

•     Only one font (no monospace text)
•     No bold characters
•     ASCII only (no Latin15)
•     MatrixSSL instead of OpenSSL
•     No SSL.

Here's my first attempt, weighing in at about 1.6MB:  links-sdl-latinonly.zip

That should free up a whole bunch of space on the rockbox/links iz2jffs distro variant...

For the gmenu2x/gmu iz2jffs I save 200K right off the bat by using the existing jpeg, png, and libz shared libs required by gmenu2x instead of the static libs.  I can get another 150K by retiring retawq.  And I think removing the bold characters buys 200-300K.  If I rebuild gmenu2x without libfreetype (using the code from slug's github?) I think it all might just fit.  For now I just went only ASCII only, no bold, and no SSL for a 750K quick and dirty retawq replacement on the gmenu2x/gmu iz2jffs system.

links-iz2jffs-gmenu2x.tar.bz2

I'll try to put SSL and such back in after I see how the new gmenu2x build goes...

The Return of Zpub

While comparing the screenshots of glinks and bunjalloo, I was reminded of my old zpub post.  At the time I hadn't really dug into the links code very much, so I just sorta settled for a so-so reading experience.  I'd thought the epub text in glinks was somewhat small and ugly compared to netsurf.  But since netsurf requires the "mouse" I was a bit aprehensive about using it for an ereader.  I also remembered that dronz had tweaked his glinks config for ereading, so I decided to do a little experimentation with zpub and glinks.

The first change I made was to bump up the text size to something closer to the fonts used in a typical paperback book.  I'm pretty happy with an html-user-font-size setting of 18, but 16 is also not too shabby.  With the larger font, it makes sense to reduce the html-margin setting to 1 character to waste a minimal amount of space on the sides.  To bad you can't set it to 1 or 2 pixels.

While I was working on the margins I decided to see what I could do about that big fat ugly scroll bar.  The default G_SCROLL_BAR_WIDTH setting in setup.h is 12 pixels, which is extremely wasteful on the zipit.  Simply reducing it by 4 pixels gives me another full line of text with a font size of 18.

The other thing that really bugs me about glinks is the ugly default battleship gray background color.  You can change the colors of the menus, status bars, and even the scroll bar, but the html page background color must be set with in the document with a <body bgcolor="#FFFFDD"> tag or else you get the hard coded default_bg_g color from the default.c file.  I may try to code up an html-default-bgcolor command line and config file option to set this at runtime, but for now I just compiled in a yellow tinged off white color #FFFFDD that reminds me an old paperback book.

Another thing I noticed was the occasional odd characters in the text. Turns out the books I fetched from Project Gutenberg are utf8 formatted. I wouldn't be surprised if all epub documents are utf8.  Gotta review the specs someday.  Anyhow, I simply added the html-assume-codepage utf8 setting to the zpub script and now all is right with the text.  Check it out.

Remember how it used to look?  The new look is sooo much more warm and inviting, and actually displays even better on the zipit itself because the hardware rotated screen orientation washes out some of the yellow and possibly better matches my glinks subpixel anti-aliasing orientation setting.  Compare to this.

Gotta see if I can add that links command line option, then get the goodies posted and resume work on the bunjalloo code.

Update:  That turned out to be pretty easy, just a few ifdefs in the default.c file.  But now I've got a few more ideas.  I read about a third of the "Little Fuzzy" novel last night, and when I put down the zipit I realized the links bookmark system is probably inadequate for ereading.  I'd really like to save the scroll bar position so I can resume where I left off.  I'm gonna see if I can use the M and R keys to Memorize and Recall a scroll bar bookmark.  I might also look into defining the L and D keys in links to Lighten and Darken the LCD backlight for an adjustable day or night reading experience.  Either that or I'll have to setup the keymap so I can switch to another virtual terminal to adjust the lights and maybe check the battery level.

Update 2:  I finally finished reading my first full e-novel on the zipit and I can honestly say the experience was actually better than a paperback book in one way because I was able to pocket the zipit and take it with me.  I did find and fix a bug in zpub during my test read that briefly prevented me from viewing the 2nd half of the novel.  The M and R key scrollmark patch was fairly simple, and really made it easy to put down the zipit and pick it up again later to continue reading.  I decided against patching dimmer keys into links because that should be done at a system level so all apps can benefit.  I just need to work out which key combos make sense for all apps.

Here's the updated IZ2S zpub and links executables:  zpub2-iz2s.zip

Here's the modified links sources:  links-sdl-iz2s-zpub.tar.bz2
Here's a comprehensive patch for links-2.3 on the zipit:  links-2.3-zipit.patch

And here's a patch with just the ereading modifications.  http://pastebin.com/weJbzHWT

A jffs version will come later.  I need to make a zpub-lite that works without bash, and bc.  And I'll either have to provide a mini unzip executable, or build zpub-lite as an executable so I can use zlib. Maybe another mcb...

I Don't Know What I Was Thinking.

Boy, that'll teach me to make promises on Friday the 13th, just before taxes are due.  The taxes got done, but not much else.  And now I'm really having trouble remembering where I stashed all the zipit goodies I promised to make available.  I swear I'll get them posted, real soon now...

In the meantime, whilst avoiding packaging up the old goodies, I somehow found myself on an old Nintendo DS homebrew site, which reminded me of the spiffy Bunjalloo web browser.  It runs quite well (with graphics even) in the limited 4MB and small screen real estate of the NDS.  Plus there's some notes about building it for linux with SDL, and it uses the tiny matrixssl library for shttp connections.  I've been looking for an excuse to use that one, but I'm far too lazy to graft it onto one of the other zipit browsers.  So off I went, merrily avoiding what I should be doing, and attempting to port bunjalloo instead.  Turns out it uses some (python based?) WAF build system that I've never heard of, and a bunch of stuff from the NDS devkitarm toolchain.  Well, python and WAF were quite unhappy with my scratchbox build environment, so I quickly ditched them and moved to script based compiling.  I had to resort to Windows to use the NDS oriented grit tool to convert some png files to .c and .h source code because I'm too lazy to pull down all it's requirements and build a linux version.

Then, just as I was reaching 100% of the sources compiled I ran up against a wall.  Oops, the linux build requires opengl.  Apparently some 2D opengl calls match up well against the native NDS hardware, so an opengl layer makes sense for portability.  But not really for my purposes.  Opengl is not so great for the zipit, with it's conspicuous lack of floating point hardware.  However on closer inspection, it looked like most of the opengl calls were using the integer versions of the functions.  Hmm, that got me thinking.  Apparently I still have a few brain cells left over from olden times, when DSLinux wasn't quite dead yet.  Just before the DSI came out and flatlined the last remaining DSLinux effort, I managed to sneak in a really lame port of the opengl version of the classic Elite space game.  I dug through the archives and sure enough, there was the integer only tiny-SDL-OpenGL lib I used for the port.  I think it needs a few tweaks to make it suitable for bunjalloo, and then there's the whole business of reconfiguring the screen and keyboard code, but the wall has been breached. 

Hopefully bunjalloo doesn't animate or use 100% of the CPU in a busy loop, because the opengl example programs are not exactly top performers.  Here's the well known gears program grinding out a whopping 2 frames per second on the zipit.

The shiny spinning triangle isn't a whole lot snappier.

Hopefully I can continue to restrain myself and not try to port any of my old opengl based CAD programs to the zipit.

 Although this does look almost useable in 320x240 pixels...

Must, resist, temptation...

For your  amusement, here's a zip with the tinygl sources.  The gears and triangle executables are also included in the examples directory. 
tinygl-iz2s.zip

And here's what bunjalloo currently looks like running in the debugger on ubuntu.

As you can see, I have plenty of work to do on the screen layout before I can even attempt to run it on the zipit.

Update:  I dug through the code, looking for all numbers near 256 and 192 (the NDS screen dimensions), and replaced all the 192s with 120 to use a half zipit screen instead of one of the NDS screens.  It sorta works but the scrollbar looks weird constrained to the bottom half of the display.  So I think I really want to make it use only one 240 pixel high screen instead.

I was able to confirm that I can use bunjalloo to access my gmail account (cool!), however hotmail seems to really want javascript.

Latin Lessons (and Other Things)

Wow, it's been over a month since I did any sort of real blog post.  This must be what writers block feels like.  I've been off tinkering with so many different things that it's difficult to put enough coherent thoughts together for a decent post.  After I put up my previous "Where's the Beef?" post, I went back and edited the dead links in all my old posts to redirect them to the "Where's the Beef?" message.  It's quite a relief to be done with that.  But that's just clean up.  Nothing new.

So why am I so scatterbrained?  Well, I'm currently lugging 5 zipits around, all with different stuff on the internal flash.  In addition, I've got a pocket full of micro/mini SD cards with various versions of IZ2S, Flashstock, openwrt, etc.  And the pocket is really rough on the labels I've made for them.  They keep fading or falling off, so I can no longer remember what's on what card.  At least some of the zipit's are still labelled, and I'm testing some of the official zipit skin stickers to see if they're more resiliant, or easier to remember.

Zipit 1.  I finally loaded Mozzwalds openwrt rescue onto a virgin zipit, as a prelude to loading slug's shiny looking gmenu/gmu rescue image.  But now this particular zipit no longer likes any of my SD cards, so I'm back to being disappointed with uboot again.  I could probably leave it at home in a drawer somewhere, but I keep hoping I'll come up with a brilliant plan to restore the blob bootloader and the stock kernel via the wifi.

Zipit 2.  After I gave up on zipit 1, I decided to update a zipit from Mozzwalds initramfs uboot rescue image to slugs gmenu/gmu image.  The initramfs was functional, but limited due to the high memory use of the filesystem in RAM.  This zipit seems to have less trouble with the SD cards, even though it has the exact same uboot image.  Weird.  Anyhow, aside from my general misgivings about uboot, this one looks quite promising.  However testing revealed a problem where some component of gmu (sdl, alsa, pthreads, nanosleep, or whatever) is causing it to use 70% of the CPU instead of the expected 17% or so.  I did a test build of rockbox for openwrt a while back which also performed poorly.  I wonder if it had the same problem...

Zipit 3.  I've been updating my gmenu/gmu image for the blob bootloader and the stock kernel.  It's not as pretty as slugs, but it's still fun to work on.  I'm currently fiddling with the wifi setup scripts in an effort to add options for multiple profiles.  I've also started poking through slugs gmenu2x updates to see how hard it would be to backport the wifi setup dialogs and other changes.  I've also done some work on running a 2nd tty so I can have gmu in the background and a clock on the screen, but running in another tty.  Both ttyclock and dgclock seem to function with gmu in the background.  However this required me to map the home key as F1 so I could enter the magic ctrl-alt-F1 sequence recognized by SDL programs to escape to tty1.  I created a t2 script to launch a new tty and a cls script to rotate the tty, turn on the cursor, and clear the screen, just in case it gets hosed somehow.  I also added a deallocvt utility to the lcdval mcb so I can clean up abandoned ttys.

Zipit 4.  I've been tinkering with the rockbox/glinks image that dronz whipped up.  I built a smaller partial static glinks for sdl and added latin1 keyboard support so now there's a little bit of room to grow.  Here it is with a totally fictional foreign URL. 

I also built a slightly smaller mpg123 in case I want to grow this jffs into something with internet radio support.  And I've been tinkering with the keymap because I really want to standardize on one sticky latin15 keymap and one non-stick keymap for all my IZ2S derivatives.  I still need to do something about the other Fn keys though.

Zipit 5.  This has my original jffs base image and plenty of free space for testing things while I attempt to shrink them down.  For example, I used this one to test a latin1 build of pspmaps.  I recycled the latin1 kbd routines from glinks and made pspmaps accept latin1 locations.  Then I discovered RFC 3986 which says you now need to convert URLs to utf-8 before percent encoding and assembling your http GET request.  So I finally got my foot in the door a utf-8 app (well half utf-8 anyhow).  My son just went overseas with his classmates so I offered the zipit, just in case he needed to use it for directions.  He took his ipod instead.  C'est la vie...

With the new pspmaps you can travel from Paris to Mâcon, without crossing the Atlantic to wind up in Macon, GA.

I also used htop on zipit 5 to do some baseline performance testing of gmu and mpg123 on IZ2S based systems.  Mpg123 seems to use about 13% to 18% of the CPU to play and gmu about 2% more.  While testing I discovered that I need a .bashrc file in the home directory on the jffs to set the terminfo path if I want to run curses programs like htop in an ssh session.  Gotta add that to the next revision of all the IZ2S based jffs systems.

Finally, I'm currently investigating toybox and it's oneit utility to see if it's more efficient than own-tty or this busybox sh trickery.  Toybox is a tiny busybox alternative with some interesting features for my jffs images.  It's fairly compact and comes with a nice set of utilities that complement the stock busybox without all the overhead of the full busybox replacement from IZ2S.  I could use it to replace nc, killall, tee, and a few other standalone programs that I've built and get quite a bit more for just a few K.  Since toybox comes with a mini bzcat, I figured I might as well look for mini versions of zip and gzip to round out the compression options.  I found some, but more testing is needed.

There will be goodies when I track down where I posted them on the #zipit IRC channel...

links-latin-sdl-iz2s.zip
Here's the source, finally:  lnks-sdl-iz2s-latin-src.tar.bz2
Here's a comprehensive patch for links-2.3 on the zipit:  links-2.3-zipit.patch

pspmaps-utf8latin-iz2s.zip
pspmaps-utf8latin-iz2s-src.zip

mpg123-iz2jffs.zip

Here's toybox, deallocvt, and related scripts for using multiple vts (as shown below).
toybox-iz2jffs.zip

Source for the new lcdval mcb with deallocvt:  ez2sutils-src.zip

For some reason I felt compelled to compile the lynx browser.  lynx-iz2s.zip

Remix

With the tiny mcurses build of ttyclock under my belt, I set my sights on some larger targets to mcursify.  First up was the alsamixer.  Even with the salsa rebuild it's still quite large due to the big fat lump of static ncurses embedded in the executable.  I added a few more stub functions to mcurses and made a new 60K (before upx) alsamixer for a savings of 100K.  Not bad, if only it worked.  Segfault!  Rather than wade through the voluminous verbiage of alsa goodness, searching for the offending mcurses function, I decided to look elsewhere for perhaps a smaller starter mixer.  Turns out there's not much out there and most of it predates ALSA, using the earlier OSS mixer controls. 

I like the simple compact look of rexima though.  So I built a 19K  mcurses version, hoping it might just work.  And it did.  Sorta.  It came up with only three controls displayed: PCM, PCM2, and IGAIN.  WTF?  I twiddled them anyhow.  PCM is what it says, the mostly useless master volume control.  PCM2 controled the headphone volume, and I think IGAIN handled the volume for weird zipit microphone input.  With no way to control the tiny zipit speaker, this wasn't gonna work.  Fortunately I went to the net and discovered these are just the default mappings from the emulated OSS mixer to ALSA mixer controls, and you can override them by writing the correct settings to /proc/asound/card0/oss_mixer in your boot up scripts.  On IZ2S and it's derivatives, that place would be at the end of the setup-alsa.sh script.  So I whipped up some changes and settled on the handful of controls I'm likely to use.  I also squeezed the rexima display down to zipit size, and added a splash of mcurses color.

Once I had the emulated OSS mixer under control I thought it might be fun to dig through the old curses music players.  Who knows what sort of nuggets might be in that pile.  I decided to try building the orpheus music player because it claimed make use of mpg123, which is included in IZ2S, and it mentioned internet radio support.  It's internationalized C++ so it's probably too bloated for the jffs.  Because of that I went with a regular ncurses build, after tweaking the screen layout and key bindings with the usual zipit fixes.  It looks ok, and it seems to work, but I don't think it's really what I want.  It did however prove that OSS mixer based programs can be viable on IZ2S.

That's orpheus up top working its way through a funky Eddie Hazel playlist, with rexima mixin it up down below in the bottom dxvt window.

Here's a 21K rexima executable with source (including mcurses) and a modified IZ2S setup-alsa.sh.  You can borrow the new oss settings from the bottom of the alsa script if you want to use this on the jffs.

Starting Over, Again.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here's the typematic keyboard goodies from dronz. 

typematic.zip

And the smaller (shared lib) nano editor.

nano-jffs.zip

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

loadkeys-kmap.zip

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

naim-iz2s.tar.bz2

The handy IZ2S busybox update is still available in here.

iz2jffs-extras.zip

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

One Font to Rule Them All

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

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

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

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

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

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

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

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

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

Small, but Spicy

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

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

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

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

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

New stuff:
mixer-irc.tar.bz2

A New Low

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

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

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

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

iz2jffs-e3.tar.bz2

New Years Resolution

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

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

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

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

iz2jffs-scripts.zip

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

Christmas Special

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

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

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

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

iz2jffs-base.tar.bz2

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

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

sdlbasic-iz2jffs.zip

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

More Small Thinking

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

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

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

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

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

cd /mnt/ffs

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

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

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

iz2jffs.tar.bz2

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

iz2jffs-extras.zip

A Better Basic?

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

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

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

Files are here for now.

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

Yet Another Calculator?

So it turns out Nano-X and FLTK 1.3 needed some extra lovin to get themselves working together real nice on IZ2S.  It took a while, but I finally got some freetype fonts loaded in the right place with the right config files.  Some small patches enabled kerning and anti-aliasing in nxlib and FLTK.

I also got the X11/rgb.txt color file installed so the Xlib example programs can use colors by name.  Unfortunately there's still some sort of clipping issue to work out when running nano-X -L to rotate the zipit screen to the proper orientation.  Images display fine when the screen is unrotated, but not when rotated.  Gotta fix that if I want to run Dillo on this thing. Anyhow this is what the mbasecalc calculator looks like, running with FLTK widgets on nxlib over nano-X.

It's got hex to decimal conversion (which I really like) and some nice shortcut keys for ease of use on the zipit.  I'm still thinking about tweaking the key bindings a bit though to minimize use of the ALT key.  And the calculator only uses part of the zipit screen, so it has room for more functions if I ever get really motivated.

Here's an FLTK font browser showing the list of fonts currently installed on my IZ2S setup.  Unfortunately there's currently a bug somewhere in either FLTK or nxlib that prevents all but the various sizes and shapes of the "helvetica" sans font family from loading. The good news is that font family looks pretty good, and fills most of  my needs.

I also fixed a few more issues with flwriter that were most likely caused by the jump to FLTK 1.3 from whatever old version it was last compiled with.  It works pretty well if you stick with the one working font family.  The default xhtml files load up just fine in the various browsers available on IZ2S, and the single rtf export file I created loaded up ok in word.  This is what flwriter looks like on the zipit with the anti-aliased fonts.

And here's the upgraded FLTK filebrowser with the shinier gtk+ theme and antialiased freetype fonts.  I'm not quite sure what to think of the microscopic  text in the preview pane.

Not too shabby though...

Layers and Layers (revisited)

Yet another of my long term goals for the zipit is to get FLTK working so I can build the Dillo browser, maybe murgaLua, and play with some light embedded GUI development.  FLTK applications have worked out quite well on some of the smaller linux distros like TinyCore and Puppy Linux.  So perhaps some of that good stuff could be squeezed onto the zipit.

Recently someone built FLTK 1.3 on Nano-X on DOS, so I figured if that was now possible, then a zipit port ought to be workable as well.  I followed some of the directions from the DOS port, and eventually figured out which options to select in the MicroWindows config file to convince Nano-X to build and run on the zipit.  The mouse was a bit tricky, but I eventually figured out the fake z2mouse was emulating a PS2 serial mouse, so all I had to do was softlink /dev/input/mice to the /dev/mouse device Nano-X was expecting, and it worked.  I still don't know exactly what to do about all the font options, but so far I haven't needed to sort that out just yet.

Now we all know by now that the framebuffer device on the zipit is actually a 240x320 pixel LCD oriented at a 90 degrees right rotation from the keyboard.  This must be accounted for whenever you want to display something on the screen.  Nano-X has a handy -L command line option to rotate the screen to the left for 320x240 pixels aligned with the keyboard.  But it also rotates the mouse coordinates, making the pointer 90 degrees off.  However, I found the spot in the Nano-X code where the mouse coords come in from all the various drivers.  So I added a 3 line zipit patch to rotate them 90 degrees to the right to match the real orientation of the screen.  And they remain matched up when the both the screen and the mouse are rotated by the -L command line option.  Nice!


I gotta revisit DirectFB and try to apply a similar mouse fix.  Especially now that I've got glinks running properly on SDL instead of DirectFB.  That leaves me completely free to discard the broken IZ2S DirectFB libs and start again from scratch.

I may also revisit the z2mouse driver itself.  The more I use it, the more I'm convinced that maybe the left mouse button should be on the play key instead of the center of the dpad.  It's nice for pointing and clicking to have all the functionality right on the dpad, with the lesser used center and right buttons off to the left on the play and stop keys.  But dragging anything takes 2 fingers, and it's really hard to get both of them in the confined space of the dpad.  So I'm thinking now that maybe the left and right buttons do most of the dragging work, so they should be moved off to the side of the dpad on the play and stop keys.  That leaves the center of the dpad for the center mouse button.  Easy to remember and it doesn't cross my fingers up dragging things around, or highlighting text.

Anyhow, FLTK seems to work.  Now I gotta just find me some FLTK apps to tinker with that work well in 320x240, or I suppose 240x320 if they don't need the keyboard.  These look pretty good, for example.  Perhaps eigenmath?  Or alsamixergui?

The Long Way Around the Top

I'm not exactly satisfied with the ebook contents page produced by zpub, so I thought maybe I could make zpub build the html using the same algorithm as the original script.  But that uses the bc utility to assemble it's javascript and xml contents, and bc isn't included with IZ2S, so I figured I'd build it and see if it helped. 

At around the same time, I somehow got to wandering around on the nanonote wiki where I happened upon a shiny picture of htop running on the nanonote.  Ooh, shiny... Had to have it!  So I compiled it and tweaked the screen and keys a bit to better fit the Z2.  I love the way it lets you scroll to the right to see the entire command line.  Way better than the usual run-of-the-mill top utility!

Also around the same time I got to thinking about how I still really wanted a C compiler for IZ2S.  What's wrong with me?  That's just stupid.  But sometimes the only way to get these crazy ideas out of my head is to just go ahead and do it.  So I did.  Well... Ok, it's not really a compiler per se, but the PicoC interpreter is probably a better fit for IZ2S anyhow.  Since I had some previous trouble with floating point math support on the zipit I built two versions: one without floating point support, and one with it.

Unfortunately, before I got to test it all that much, I stumbled upon an SDL patch for the links browser.  What?  How did I miss that before?  With this patch I should be able to make a version of links for IZ2S that works properly, with or without the mouse, and without requiring the messed up DirectFB libs.  If it works, I can finally toss out the broken IZ2S DirectFB libs and remake them correctly from scratch whenever I get back to working on fltk, xdialog, vnc, or any of my backburner projects that need a normal working version of DirectFB.

Anyhow, I tweaked the links-sdl patch a bit for the IZ2S screen size, and for the current version of links.  I also added link traversal via TAB and BackTAB, and horizontal scrolling with the <> keys to make it more workable with zipit keyboard and the fake "mouse".  Initial testing feels good.  Gotta get it finished soon so I can patch bc back into the zpub script and see if it helps before something else pops into my head...

See?  The "mouse" actually works.

Look in the Zipit Z2 Goodie Bag for links to all the stuff.

Thinking Small

Apparently the Zipit folks have obsoleted the original built-in app on the Zipit Z2.  This means the jffs on the internal 8MB flash contains about 5.5MB of useless applications and data.  Worse yet, it's supposedly possible to get the stock app stuck in some sort of infinite loop of update requests if it's never been connected to Zipit wireless for an initial firmware update.  Now I've never experienced this myself, but I also haven't booted a new Zipit into the stock app for quite a while now.  If you're really worried about it you should probably bypass IZ2S and run the latest FlashStock to replace the firmware with uboot and the spiffy rescue image.  Then you can run one of the many uboot userlands like z2lite.

However uboot is significantly slower to boot than the stock bootloader, and all of the uboot userlands seem to require reformatting your SD card to ext2, which may significantly shorten the lifespan of the SD.  So I got to thinking, maybe I should consider replacing the stock app on the internal jffs.  Now, what could I fit into 5.5MB?  A minimal Rockbox installation would be sweet.  I could also go for a minimal gmu install to turn the Zipit into a dedicated internet radio device requiring no SD card.  But both of these apps are just a wee bit bloated for the 5.5MB available on the internal flash.  So how do I make them fit? We could use an IZ2S version of UPX to cut the executables and libs down to about one third the size.  Then things just might fit.

The UPX source compiled without a hitch and seemed to work just fine on the IZ2S rockbox executable.  Supposedly the source version of UPX has somewhat lower performance than the pre-built UPX executables, but sometimes you just have to take what you can get.  It's probably good enough for my purposes.  Now I just need to sacrifice the stock app on one of my Zipits and then see what fits.  Meanwhile, here's the UPX executable for IZ2S.

upx-iz2s.zip

Loose Ends

I managed to build both an IZ2S and a z2lite rockbox 3.9 release over the weekend.  You can find them in the Zipit Z2 goodie bag (link on the right).  I also built a common plugin package that works on both.  Well... Ok, I tested the rockblox plugin on both userlands and it seemed to work.  I'm extrapolating that success onto the rest of the plugins.  Actual mileage may vary.

Meanwhile the new ldraw forum is still active, and so the bug reports keep rolling in.  Maybe it's just that the programs simply need more documentation.  I've wondered for a while now how to best handle lsynth parts in ldglite, and how best to push them through lpub.  Others have apparently been thinking the same thing.  Fortunately I just got a new Windows 7 PC.  Just in time to shake out some of these issues, and to try the new All In One Installer for ldraw.  The result is I've gotta put out a new ldglite release with some updated search path support, in addition to the new color support I did a little while ago.  Also, I think I finally see how to incorporate synthesized parts in lpub.  The result should look something like this.

What worked for me was to break out the synthesized part(s) into separate files and make sure to tag them as part files with this meta-command in the header:

  "0 !LDRAW_ORG Unofficial_Part".  

This technique also works in one big mpd file if you don't want a bunch of separate files.