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.
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...
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...
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
Here's toybox, deallocvt, and related scripts for using multiple vts (as shown below).
For some reason I felt compelled to compile the lynx browser. lynx-iz2s.zip