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