Monday, December 31, 2018

Reindeer Games

Hey, it's the holidays again, and Right now the RS97 crowd is buzzing like a jolly bunch of busy bees on dingoonity  with daily updates on their progress creating fresh new goodies for their cute little game consoles.  Some of the stuff is in the sweet spot for the zipit, so I've raided their github archives and compiled a few new games for IZ2S.  Here's what I've tried so far.

Prince of Persia
Abbaye des Morts
Cave Story

Of the three, I've found Cave Story the most compelling.  Maybe it's the music?  Or maybe because Cave Story seems to work properly whereas Prince segfaults occasionally and Abbaye is too slow.


The third poison plant gets me every time.  But I swear I'll get past it before years end.

The sluggishness in Abbaye is due to the expectation of a 60Hz refresh rate, which ain't never gonna happen on the zipit.  There's a nice spot in the SDL2 shim code where it adds adds a delay after the buffer flip whenever the refresh rate exceeds 60Hz.  I can tweak that for the zipit to skip frames instead when it needs to catch up.  Then I've gotta tinker a bit more, perhaps try and remove any gratuitous floating point math and fix up any bad keybindings.  After which I'll zip up some packages.

nxengine-iz2s.zip
abbaye-iz2s.zip
 
I tweaked the keybindings for a better zipit experience on both of these.  There's no Fn keys on the zipit, so just use the Q, W, and E keys for F1, F2, and F3 if you find yourself in the Cave Story options menu.  I also changed jump and fire from Z and X to ctrl and Z to line up better with the other keys on the left edge of the screen.  Here's the basics.

    Movement - ← ↑ ↓ → (down opens doors)
    Jump - Ctrl
    Fire - Z
    Previous weapon - A
    The next weapon is S
    Inventory - Q
    Map - W
    Exit - ESC (the options menu is also accessible via ESC)

For Abbaye you can use ctrl,Z for jump,crawl and comma,period for left,right instead of the dpad if you find the center nub on the dpad gets in your way.
This Abbaye screenshot actually came from github, because I'm feeling lazy...

Update 12/31/2018

Oddly, as the holidays progressed I was overcome with a desire to complete a project long ago given up as somewhat of a failure.  You see, a relative (who wishes to remain anonymous) has a tablet and was spending an inordinate amount of time attempting to develop professional level FreeCell skills before returning to work in the new year.  Witnessing this was a constant grating reminder of my long ago failure to finish while attemping to bring some high quality console card games to the zipit.  I got pretty close, but never really went the distance.  This was mostly due to the limited utf-8 support in IZ2S.  You can do some unicode manually, but library support is simply not there due to the small size options selected when uclibc was built. So libncursesw on IZ2S is just a bloated version of the regular libncurses, with no functioning unicode features.

However I realized that I actually had some new ideas to try.  The iz2slat font provides latin-15 support in addition to a full set of line drawing characters for ncurses.  So life is not so bad.  But the font wastes space with a few duplicate characters, and also has some unicode glyphs that can't be used by ncurses, making them very limited in value.

I's been a while since I fiddled with the font, so to get started I grabbed the psftools (not this psftools although it may also work) required for editing glyphs in ASCII mode.   And to help visualize how the glyphs in progress would look on the zipit, I created a small showpsf program from libpsf.  Here it is displaying the iz2slat.psf font on my laptop.

If you squint you might just see some duplicate glyphs in positions 2,3, and 128.

There's already a diamond in position 4.  I originally had a plan to replace the 3 duplicate glyphs in positions 2,3, and 128 with the glyphs required to show all 4 suit symbols in some console card games instead of the feeble ASCII substitutes.  So I created a variation of the iz2slat font with the changes and assigned the suit glyphs unicode numbers U2660, U2663, U2665, and U2666 in the psf unicode table.  Unfortunately the only way to display them on the zipit console is to avoid ncurses and instead use ANSI escape sequences.  I can do that, but it makes porting existing code difficult.

The new suit glyphs show up just fine on the zipit in the showpsf program.

So I came up some cheesy work around ideas.  At first I thought maybe making a whole new font designed around codepage 437 might work.  But further reading discouraged me from that idea.  As far as I can tell, all the codepage 437 linux solutions are based on utf-8 support.  I need to get significantly cheesier for something that works in IZ2S.  It occurred to me that the difference between the latin-1 and latin-15 charsets involved only a small number of fairly obscure glyphs.  Other than the Euro symbol, the other new characters probably won't be missed all that much.  (I've never used them...)  So I made another variation on the iz2slat font where I substuted the card glyphs in latin-15 zone.   I almost used the accent characters, but instead went with some actual letters that might just work as recognizable suit identifiers if I accidentally forgot to switch from the normal iz2slat font.

Here you can see the new location of the suit glyphs.

To tie things all together I dug up csol (a new console solitaire suite on github), created a new pint-sized zipit theme for it, and tweaked the code ever so slightly to eliminate the dependence on utf-8 for the zipit theme.

And here they are making csol look pretty.

The following picture represents a victory lap from my one and only game of freecell on the zipit.  I feel pretty good about it, but I don't think I have what it takes to go pro...

 I got a really bad case of video game thumb rescuing that 4 of diamonds from the bottom of the stack.


Here's the goodies (once I zip things up):

iz2splay.psf
csol-iz2s-with-font.zip
showpsf-iz2s.zip



Wednesday, December 19, 2018

Cryptonecronom

Anyone remember way back when the internet was simple?  You could telnet to directly to certain TCP/IP ports and type your email or web requests in pure and natural ASCII text, and it would work.  Well those days are gone, replaced by an endless rotation of crypto protocols that seem to rapidly degenerate into obsolescence or expiration.  Or maybe time moves faster as you age?  I don't know.  Anyhow, I expect this post be be all about the dead crypto eating away at my aging computers (and zipits) and my attempts to get things working once again.  The well known technical term for this rot is crypto necro nom-nom-nomicus in meme-latin.

We'll have to see where this eventually takes us. For now I'll start it off by re-posting a recent update to an old blog entry about the QEMU compiler setup for IZ2S, because dead crypto is what instigated my renewed efforts there.

After a few years of neglect I decided to put the qemu compiler to work once again, and make myself a new IZ2S build of the dropbear embedded ssh suite.  The old cyphers are deprecated and the workaround command line args to ssh into the zipit are painful.  I could handle something like -1, but -oKexAlgorithms=+diffie-hellman-group1-sha1 is about 40 letters too many to commit to memory.  So I resurrected the qemu chroot and went to work compiling the latest dropbear.  It took a few tries to remember some of the tricky techniques required to produce "optimal" executables for both the internal flash jffs and for the SD card.  For the jffs, small size is critical, so I built the dropbearmulti target with minimal features and compressed it with the lzma version of upx.  An IZ2S SD card uses the FAT filesystem, so individual apps work better than dropbearmulti, because softlinks are not available on FAT.

I've uploaded a zip file to the usual place, with dropbearmulti for the jffs and the individual apps for the SD.

Meanwhile, I discovered some gaps in the tool set on the IZ2S qemu image.  The upx and sstrip programs were absent, and libcrypt.a was unavailable.  I believe libcrypt is actually in the qemu image with the older v4.1 compiler, and simply needs to be copied from the older gcc libs in /usr/local/share/gcc/lib to the usr/lib directory.  But it's not in the v4.4.7 compiler zip or the zips for for the IZ2S libs and includes.  So I think I need to put together a small "toolchain_extras" zip file with the missing bits.

Also, since I can't seem to remember, I'll point out here that CFLAGS="-march=armv5te -mtune=xscale" is nice for the zipit processor.  And do NOT use soft-float on IZ2S.  The stock kernel is OABI and the libs are compiled with default float settings.  Back in olden times that meant hard float instructions with kernel emulation of the FPA via exceptions, which is why floating point code is so dreadfully slow on IZ2S.  If you run readelf -h libgcc.a you'll see lots of zeros in the flags and ABI bits, indicating the defaults were used.  So if you get hard/soft float mismatches from the linker (like I did when I accidentally grabbed the soft-float libcrypt.a from openwrt) then you should compare readelf header output of the mismatched files to see what's up.

Here's a readelf -h header sample from the IZ2S libgcc.a for reference:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          700 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         9
  Section header string table index: 6

Another tip to remember... If you're making an SDL program for IZ2S, don't forget to link with -pthread before -lSDL and -pthread again after.  This prevents a nasty segfault in the startup code -- before it even gets into main().


Meanwhile, almost as soon as I made the new dropbear, I realized that i needed more.  At the time I was using putty on Windows PC and for some reason putty requires an sftp-server on the linux side to transfer files, even if you use pscp.  Dropbear lets you know that's not gonna work by mentioning it can't find /usr/libexec/sftp-server and then disconnecting.  Fortunately bleeding edge openwrt has an sftp-server package that works just fine for this.  So I dug up the bleeding edge recipe that builds a minimal sftp-server executable from openssh and compiled it for IZ2S.  To activate it you should install the sftp-server executable in the libexec directory on the root of the IZ2S sd card, and then edit z2start.sh to make a softlink from /mnt/sd0/libexec to /usr/libexec, similar to the one for /usr/lib.

Unfortunately when I tried to install the sftp-server package on my bleeding edge openwrt zipit, I ran into trouble with opkg.  It no longer worked.  Some investigation revealed that opkg was using wget to fetch the packages from mozzwald.com via http.  Running the wget command by hand showed the http command got redirected to an https link which failed with an error about libustream-openssl gone missing.  Turns out wget on openwrt is actually a softlink to uclient-fetch, and I needed to install the libustream-openssl package if I wanted it to do https.  So I fetched the package manually from mozzwald.com on my laptop, then transferred it to the zipit and installed it from there.  At that point I could run opkg update and see that it now functioned properly.  So I used opkg install to fetch and install the sftp-server and ca-certificates packages.  Crypto death rot was put off for just a little while longer.

The rot isn't specific to the zipits.  My eeepc 900A netbook has also got it bad.  It's currently running an old puppy linux flavor (puppeee) specially tailored for the hardware.  But it's about a decade old now and the crypto stuff is so outdated that nothing on the internet will even try to talk to the web browser.  Git can't fetch code from github.   Ssh is crippled.  Everything that made this machine fun is now busted and I'd really like to bring it back from the dead.  So the search is on for a more recent netbook sized linux that could meet my needs.

Goodby puppeee, you served me well back in the day.

Update Jan 5, 2019

I wound up taking the path of least resistance and installed a newer version of puppy linux -- specifically the Ubuntu based 32-bit XenialPup 7.5.  It went onto a usb stick with relative ease via this command.

  sudo dd bs=4M if=xenialpup-7.5-uefi.iso of=/dev/sdb conv=fdatasync

Booting it was a bit more challenging.  The eeepc boot screen mentions F2 for setup and Tab to see messages, but it's the Esc key that actually gets you to the runtime boot media selector.  I only just stumbled onto the Esc key functionality with a happy accident when I tried Tab and got bored watching the memory test count up.


The XenialPup looks pretty darn similar to puppeee, and I like that.

I booted xenial from the usb stick a few times to try it out and quickly decided it was familiar enough with ssh, picocom, and git all pre-installed, just like on puppeee.  The only obvious issue was the wifi drivers.  Running lspci -v showed the kernel detected the atheros wifi, but no modules were loaded.  Someone left out the atheros drivers from the xenial iso image.  Oops.  But this was already known and an atheros_kernel_modules-4.4.95noPAE-xenial32.pet package was already created to patch the hole.  So I borrowed the ethernet cable from the TV and fetched the package.  I also tried the Pale Moon browser and found it sluggish, but it gets me onto github so I'm satisfied there.

Unfortunately double clicking on the atheros .pet package stubbornly refused to install anything, darn it!  However I untarred it manually and had no problems copying the additional driver directories into the lib directory tree.  Then I ran depmod -a and insmod ath5k and voila the "Connect" gui could now see the wifi.

This was good enough for me so I manually copied the files from the xenial USB stick to the eeepc flash drive for a homemade frugal install.  I also added the devx_xenialpup_7.5.sfs developer tools squashfs for gcc.  Then I edited my existing grub menu.lst file to remove some obsolete browserlinux and pup431 options and added xenial instead, keeping puppeee as the default in the menu for now.  At this point I ditched the USB stick, and booted into xenial from grub.  It takes longer than puppeee, but what can you do, it's got some ubuntu stuff in there.  The next step was to get me some emacs.  So I ran the pet installer, did an ubuntu package update, and installed the ubuntu emacs package.  I'm not sure I'm gonna keep that since it hogs a whopping 80MB whereas an emacs sfs is only about 40MB.  I'm not sure if I can use the emacs-24.5-i486.sfs from the puppy forums because it's not specifically for xenial.  So perhaps it's time to howto roll my own sfs.

So far the noticeable differences boil down to a larger font in the urxvt terminal -- I probably need that at my age -- and I don't know if I can set the titles in the urxvt tabs.  They don't respond to the old xterm ANSI control sequences, but hopefully I can figure something out.  Anyhow, life is good once again with the eeepc netbook.


Update Jan 12, 2019

After using it for a while I noticed another issue.  Closing the lid on the eeepc is not detected, so the screen stays lit and the netbook continues to run hot and heavy.   I suspect xenial runs a bit hotter than puppeee since I sorta remember tinkering with some special eeepc settings available in puppeee, so this is a bit of an annoyance.  I've currently "solved" the problem by creating a small script to echo "freeze" into /sys/power/state and then placing a convenient icon for it on the desktop.  That works ok, but it got me thinking maybe I should keep looking for alternatives.  So I'm gonna try AtomicPupXIX when I get a chance.  It's supposed to be a slackware based puppy linux tailored to atom processors in the early eeepc lineup, so it could be a good fit.


Tuesday, October 16, 2018

Where do we go from here?

This blog seems to be running out of steam, or maybe it's just me.  Anyhow, I guess it's time for an update of some sort.  So I'll have to cobble something together to fluff up the word count...

Some ideas to write about include:

Compiling code for the zipit on my chromebook.  That was fun.
Tinkering with voidz linux on the zipit.  Also sorta fun.

My original plan for the chromebook was to use the compiler from chromebrew to make a smallish static dietlibc build of the current movgrab source code to work around a problem with the musl builds.  The chromebook has an arm processor, so many static zipit executables actually run on it, allowing me to test things without having to transfer to the zipit.  More on that here:

https://mozzwald.com/irclog/zipit/2018/05/28

My hopes for dietlibc were many.  It builds smaller static executables than other libc implementations.  It might not have the socket reuse issue I was getting with musl.  And it had a recipe for building a static openssl, something that had eluded me last go around when I made the static uclibc build of movgrab.

I got dietlibc working, and made a static qemacs with it, but the movgrab build never came to fruition.  I suspect it really only works with glibc, and glibc now actively resists static builds.  So I gave up.  But then the voidz linux distro got created for the zaurus and and seemed like it could be a really nice fit on the zipit, with musl and no systemd.  I didn't have a compiler for it, but wanted to give it a test drive.  So I went back to the chromebook and built a set of static executables to let me run the ziptuner.  This tarball has ziptuner, dialog, mpg123, with some config files and scripts.

ziptuner_static_with_dialog_and_mpg123.tgz 

The executables are all static builds that I compiled and tested a bit on the chromebook.  The ncurses setup on the chromebook has issues with terminfo and I remember mpg123 was a bit of a challenge, but I eventually managed to coax some sound out of it. Unzip it into /usr/local on voidz and run ziptune to give it a try.  It might also work on other zipit distros due to the static executables.  For all the trouble it gave me in the build, the mpg123 executable actually runs pretty well on the chromebook.

Here's a shot of the ziptuner compiled and running on voidz.

I'm hoping to try and learn how to turn ziptuner into an actual xpbs package for voidz.  We'll see how it goes. 

Saturday, April 21, 2018

Return of the Toys

I'm not sure where I'm going with this, but I'm gonna take some notes here and just see what happens.

Not long ago I was doing my semi-annual browsing at ldraw.org, just poking around to see what's new there.  Coincidentally on that very same day, someone happened to submit a small enhancement request for lsynth, an ldraw program that I took on maintenance duties for many years ago when the original author ran out of steam.  It was a simple request for an addition to the config file, no coding required, so I thought why not?

Naturally things got more difficult and I ended up moving both ldraw projects that I pretend to maintain from the sourceforge over to github.  The sourceforge has been troublesome lately, and I'm now more familiar with github anyways.  And besides, there always the hope on github that someone else will fork it, pick up the slack, and add new features.

It didn't quite work out that way.  Shortly after I moved the two programs, I started getting bug reports and feature requests.  Who knew there was still any demand for the old stuff?  And why do I still have to do all the coding?  Oh well, at least these were high quality, interesting topics. Like how to get a synthesized rubberband part to fit properly on the pins of these wheel holders, when the pin is not aligned with a convenient axis and the parts are rotated in different directions.  I eventually remembered enough math to get it fixed.



I should probably put together a new lsynth release with that fix, but no sooner had I completed it when the ldglite requests started rolling in.

The idea behind one of the ldglite enhancement requests was to change the transparency rendering for some "faded" parts so the rear faces and edge lines don't show.  It wasn't to difficult to whip up some test code that does it with an extra run through the render, updating only the depth buffer, before a final render pass to draw the edge lines.  It should be reasonably fast if I only do it for certain transparent parts.  At least that's the plan, I think...

Here's a picture.  More later.


Another aspect of that feature request was to support more than one level of transparency in ldglite.  Ok, ldglite uses an ancient deprecated polygon stipple technique for transparency.  And back in old school days, when there were 16 or at most 256 colors available, we had some commonly used 25% and 75% stipple patterns to mix up some more colors.  So I added those to the 50% pattern already in ldglite to get to three levels of transparency for fade effects.  That should be enough.  Hopefully downsampling the new patterns won't produce any painfully hideous aliasing effects.

Here's a shot with the 75%.


And here's the 25%.


Another of the requests was to come up with a simple way to provide a glowing silhouette in some selected color for certain parts.  I've started work on that, but so far I only have this really unimpressive picture.  For some reason the opengl driver is ignoring line widths (and antialiasing) so the glow is reduced to that feeble yellow outline that you can barely make out on the black technic pin.


Heh, it turned out to be a bug by me that made the yellow glow lines so thin and feeble.  But no matter, it also happened that my clever plan to use only type 5 ldraw lines was not so good.  That doesn't actually provide the entire silhouette.  So it was back to the drawing board for this one.  I gave up on cleverness and implemented the well known stencil buffer silhouette technique.   Unfortunately the stencil buffer commands always seem to confuse me, but eventually I connected the right bits in the graphics pipeline and got a decent halo.
 

I just wish I could convince myself I knew what I was doing.  But the sad truth is I don't.  You see, I'd really like to have the yellow silhouette showing slightly through the 50% transparent part.  But the stencil setting that I thought would do it had no effect.  Oh well.  Maybe I'll get it eventually by trial and error...

Or maybe not.  It just occurred to me that it's not the stencil function blocking the glow inside the faded part, it's the depth buffer blocking all edges inside the faded part.  I'll have to try moving the drawing of the glow lines to before the depth buffer writes are done for the faded parts.  That just might work.

Anyhow, the final request (so far) was to allow a wider range of color codes that will make these new features more compatible with the calling program LPub3D.  I've added some code for that already, but it's not something that provides a spiffy picture.

Tuesday, January 16, 2018

Long Time No Talk

I haven't done much worth writing about lately.  Or maybe I've just simply been too busy doing other things.  I don't know...  So I'm just gonna jot down a few brief notes for now to keep this zombie blog twitching.

On the zipit IRC we recently started tinkering with Devuan.  So far, it feels pretty similar to the old Arch distro from two years ago, except you have to mount the SD card on your PC in a qemu chroot to fetch packages.  That's not as difficult as it sounds, so it's not huge burden.  I noticed that several of the executables I built for Arch, like qemacs and gmu, actually work on Devuan as is.  Probably because they're both based on glibc.  Anyhow, that's handy.  But I'm still getting up to speed compiling things in the Devuan chroot.  So far I've built a working version of the ziptuner, but not much else.

Meanwhile there's a few new tidbits for the bleeding edge openwrt.  Here's a picture of the new wavemon package running on the zipit with the 5x8 font. 


The Fn keys shown on the botton don't exist on the zipit, but you can still get to the other screens by pressing the first letter of the screen name.  So the keyboard support seems good enough for me on the zipit.  However, a few strings in the messages could possibly be shortened to make it all fit.  Maybe I'll whip up a patch for that.  I'd also like to make a patch to build it with libnl-tiny to make it smaller, but that's not really a priority

What else is there?  About the only bits I remember are a small update to the ebindkeys package to make the stop button work with the default gmu shift-esc key combo.  Maybe I did some more work on the unfinished stppc puzzles package?


Part 2.  The Long Lost Holiday Special.

As you can see above, somehow despite a personal record, due to procrastination, of 2.5 weeks off for Christmas and another full week for Thanksgiving, I managed to accomplish next to nothing during the holiday season of 2017.  Well, maybe I got caught up on some classic science fiction reading from the 50's, 60's, and 70's.  But nothing worth mentioning here.  So instead I decided to relive some former glory and attempt to recollect the events that transpired near the end of 2016.  Around that time I had a really nice burst of energy and enthusiasm that has gone undocumented here for far too long.  I need to sort it out and finally start tidying up some of the loose ends before I forget it all completely.

 At the very least I'd like to rediscover my recipe for building an iwmmxt enhanced mplayer executable for openwrt.  I'm almost 99% certain that a zipit running bleeding edge openwrt was publicly demonstrated to play video streams (with proper lipsync) that were located with the links browser through mozzwalds zipit friendly youtube search portal, then fetched with movegrab and piped into an iwmmxt enhanced mplayer for a seamless streaming experience.  For now I might be happy if I could simply recover enough notes to make an iwmmxt howtobuild.txt file and check it into the files directory of the openwrt mplayer github project.  Unfortunately it turns out the whole sequence that culminated in that public demo involved more cheating and hackery than I care to remember.  The bleeding edge movgrab package was even more challenging to put together than the iwmmxt enhanced mplayer, but we'll get to that later.

Anyhow, I'd also like figure out what sort of loose ends I left when I created the openwrt rockbox package around the same time, so can pick up the slack and clean it up.  Right now I'm thinking the battery monitor code was unfinished and maybe I need to borrow some eq files from the iz2s build?  This could turn out to be really important to me.  Here's why.  After 10 years in the same old car I finally gave up and got a new one.  Apparently the new car can play music off a usb stick, or an iphone, or whatever else you might have via the aux input jack.  But the software is a total mess.  The USB interface only recognizes mp3 files and presents them on screen in a confusing mishmash of unrecognizable numbered folders.  I mean who in the world thought that listing random numbers for folder names instead of the *actual* folder names from the USB stick was a good idea?  At least the auto maker Honda was nice enough to include an aux port, so the zipit is still golden if I can keep it running for another 10 years or so.  By then I expect to have a robot valet to drive my flying car and manage my music collection.

So, here's the story.  It started in the run up to Christmas 2016, when I managed to put out a few updates to various zipit goodies, mostly for the bleeding edge openwrt.  For example, at some point I made a bleeding edge tinyirc executable.  It's handy for a zipit internal flash installation, if for some reason you can't get an SD card going.  There's better IRC clients in the bleeding edge package repo if you're running from an SD card. Than in May 2016 I finally fixed a rather annoying "feature" of qemacs that had been driving me nuts for some time.  Normally, in full up gnu emacs, whenever you type a close bracket (be it round, squiggly, or square) the electric parenthesis matching function flashes the cursor briefly over the matching opening bracket and then returns to your current position.  I love that feature when developing code.  But the qemacs version of this was failing miserably on the return.  You can probably imagine the confusion that causes when you're feverishly coding, only to realize the text you're typing is inserting itself into the wrong place, and has been for quite a while -- ever since you closed your last parenthesis.  It was especially horrifying pasting a large block of code only to see it crumple in upon itself in slow motion, creating a total jumbled mess of nonsense to clean up.  I finally had enough and patched the code and uploaded a bleeding edge executable.  Eventually I remembered to update the github repositories too, so the current bleeding edge openwrt package should also contain the fix.  I probably ought to upload a new iz2s executable, or maybe even make an update the old uz2s image from 2015, when I find some time.

In October I picked up speed heading into the holiday season and compiled a zgps executable for bleeding edge, and also updated the pspmaps and navit executables for iz2s. Toward the end of October we got a request for opus codec support, so I built libopus and gmu10 to make use of it for the bleeding edge  openwrt.  These might be real packages at this point, but I can't remember.

As the holidays approached I determined to get the video player integrated into bleeding edge openwrt, just like it was in IZ2S and the older openwrt system based on uClibc.  I wanted to browse for music videos on mozzwald's youtube search portal and have them play in realtime, right from the links browser.  We had a working mplayer package, right?  So I figured we just needed to fix up some musl compile issues in the movgrab package and add some configuration glue to the links package.  How naive...

After fixing some minor compile issues with musl header files, I discovered movgrab had a problem with the musl implementation of select or poll.  Been there, done that with gpsd and such.  So I rewrote a FDselect wrapper function in the movgrab libUseful code to add a timeout. otherwise it would block for something like forever when printing out the available video formats, and when fetching the actual video stream url.  Or so I thought... Eventually I got to thinking it was a socket reuse problem in musl, and not actually another problem with select.

Unfortunately I never solved it.  Instead I compiled a cheezy static version movgrab on a zipit with the old openwrt.  That got it built with uclibc instead of musl.  But I didn't have the ssl or crypto libs and include files on the zipit where I did the compiling, so instead I built a really bare bones movgrab.  What a mess, but it seemed to work, even on the bleeding edge zipit. If you look real close at the bleeding edge movegrab package files on github you might notice the static movgrab executable in the files directory.  When you build the package, it goes to all the trouble to compile a musl executable and then slips in the old static executable instead.  :)  Wow.  I am a total cheater.

Sadly it longer seems to work with youtube, probably due to the missing ssl or whatever restrictions fell out of the recent Amazon Google spat over access rights.  But maybe I can finally spend some quality time now and fix up the musl build the right way.  Or else try to compile an up to date static build in the devuan chroot we've been using lately.  Hmm...possibilities.

Anyhow next up was the links config glue.  However while testing various implementations it was revealed that the lipsync was off.  The sound would play at normal speed, but the video would gradually fall further and further behind.  Apparently it was like this in the iz2s and the old openwrt.  We were so close, so we twiddled with all the obscure mplayer mplayer runtime config settings, but it could NOT be convinced to coax it into sync.  So we had to go for some compile
optimization, the tricky iwmmxt code buried deep in the guts of mplayer.

At first I thought, naively again, that it was simply a matter of fixing the openwrt mplayer package makefile to add the mplayer iwmmxt config setting.  But no...  nothing is ever so simple with the zipit.  Openwrt insisted on adding -march=armv5te and -mcpu=armv5te to the compiler switches, overriding my iwmmxt setting.

So I made a script to do a swap in the makefile and then a rebuild.  That almost worked.  But -- and this is where my memory is failing me -- I could swear that I also had some compile problems somewhere in that mess that forced me to turn off iwmmxt for a couple of files.  But I don't remember if I did that by editing the source code, or by recompiling them individually with the armv5te settings.  I also vaguely remember getting it to build and then having to debug some segfaults caused by the iwmmxt code.  Maybe that's what triggered me to rebuild some of it with the armv5te settings.  I need to dig this up from the IRC logs and from my openwrt build area so I can reproduce it.  Anyhow at some point I got it to build.  The lipsync worked, so I stashed the executable and finished up the glue code.

And here's the proof.

High on success, I buried all memory of my sins and moved onto rockbox in an insane attempt to turn that into a viable bleeding edge openwrt package.  Apparently rockbox also had a problem with the musl select function.  I wish I could remember the details of that fix.  I couldn't even remember if I built the plugins.  Anyhow, I got rockbox to work, and got it to build as an openwrt package from a much more recent rockbox source snapshot.  I also managed somehow to include all the plugins in that package.  But I believe the keymaps for those plugins were just some quick and dirty hacks to make them compile, and so they probably still need some serious work.  And there were some changes to the rockbox battery handler code that prevented the zipit battery detection from working. However I abandoned rockbox at this point, and moved on.  A year later, I couldn't remember why.  But most likely the reason I stopped was that openwrt was fighting me whenever I tried to recompile it with the standard openwrt trick:

  make package/rockbox/compile V=99

Normally that would build only the rockbox package, and give me some nice verbose compiler output for it.  But instead of the detailed compiler messages I needed, it was feeding me some useless error message that told me absolutely nothing.  This got to be very frustrating, so I moved on in March (without polishing up the loose ends) when I got a request to help integrate my ancient ldglite project with into LPub3D.


Part 3: Moving Forward


I now suspect my woes with the openwrt build system might've been caused by some extra directories like junk and gitfiles that I'd created inside the rockbox package feed directory to hold some temporary backups and test files.  Weird!  In retrospect, I'm thinking maybe gitfiles was a bad choice on my part. I gotta remember from now on to hide any backup or working directories in the files directory.  That seems to be a safe place to stash temporary junk without breaking the build.

Once the build system was working, I finally felt like I could make some progress again with rockbox.  So examined the android battery support code and fixed up the zipit battery code in a similar way to make it work once again.  Only a year or so late...  Anyhow, the rockbox package has finally been updated with a working battery monitor.  There are some hints in the android code that rockbox could be made to work off the system volume control and also possibly use the system headphone detection, so I may tinker with that.

I also want take another look at movgrab to try and match up socket closes with each and every open.  See if that makes it allocate new sockets properly in musl...  I might also add more calls to fflush(stdout) so musl doesn't block it on printf calls with no linefeed, kinda like I did once upon a time with tinyfiledialogs.

Meanwhile, there's also a few other odds and ends that I'd like to remember here if I can find the time.

I made handy setclock utility for times when I want to edit files with proper timestamps, but the network is down.

I compiled drumtoy but did not make it a full package yet.

I also compiled a very simple game, ativayeben as sort of a turkey day special.

Saturday, June 10, 2017

sdlvnc redux

This time I was really planning to make something useful out of the fgui code and prove to myself that it was good enough for whatever.  But... once again something else came up that captured my attention and I lost focus.  Someday I swear I'll finish.  Just not today.

So what happened was this.  I was minding my own business, lurking on the zipit IRC channel, when someone mentioned how he wanted X11 on the zipit to serve as the remote display for some other gizmo.  And that got me thinking...  Sounds familiar?  Yeah I know, it's the same story every time.  Oh well.  I just roll with it and see where it takes me.  This time it took me back to sdlvnc -- another project I never quite finished.  But maybe things would be different this time.

Anyhow since a modern X server is a bit heavy for the poor little zipit I figured let the remote gizmo do the rendering to a local headless X11vnc server.  Then you can run the less resource hungry sdlvnc client on the zipit if you want to see it and interact with it.  After all, if that other gizmo has the horsepower to run X clients, the it can probably run an instance of the X11vnc server too.   That's a much better use of the available resources.  Of course I've visited this particular problem before, but I never quite finished, and left some serious quick-N-dirty hackery in the sdlvnc zoom code.  Also I never made it  into a real openwrt package.  It was finally time to get serious about it.

First I got the old sdlvnc code working again by compiling it right on the bleeding edge openwrt zipit. In the process I fixed a few bugs with the connection setup code that I'd known about previously, but never bothered to fix.  It felt real good to finally get those out of the way.  Next I created an openwrt project for it and got a real sdlvnc openwrt package built.  That was also quite rewarding. In the process I also fixed the ebindkeys mouse emulation code to make the zipit mouse tracking less jumpy, so there's a new package for that as well. And, since everything was moving right along, I thought I'd step it up and tackle the zoom code.

The problem here was that I'd done a quick paste of the sdl_gfx zoomSurface function into the sdlvnc code the first time around.  That function is really intended for rescaling small sprites and images, and not so much for working with the entire screen.  It worked, but the performance was awful.  That's  mostly because the linear interpolation code is only written for 32 bits per pixel surfaces, so the 16 bpp vnc screen surface had to be converted, zoomed, and then converted back for every refresh.  All of those surface copies were created and destroyed on the fly by zoomSurface, for every screen refresh.  Yikes!  That's a lot of memory, and a lot of copying. It was wasting a third of a second per refresh for a 640x480 screen on the vnc server, and was even more excruciating for bigger screens, when it didn't crash for lack of memory.  So, I decided to add a 16 bpp path through the sdl_gfx zoomSurface function to eliminate all those wasteful copies.

I scribbled lots of notes and pieced it together a tiny bit at a time in the evenings, starting from a copy of the 32 bpp zoomSurfaceRGBA subfunction in sdl_gfx. Surprisingly, two or three weeks later when I tried it on a whim, it actually worked.   That never happens.  So for the next few days I cleaned it up and ran some timing tests.  The 16bit path was running in about one third the time of the 32 bit path -- a tenth of a second or so to zoom the 640x480 screen.  Much better, but I was hoping for more.  What to do next?  I was pretty sure small constant array offsets were essentially free in modern instruction sets, whereas maintaining an extra set of nearly identical pointers was not.  So I worked up some inner loop optimizations and squeezed another 12% speed gain out of it.  I also discovered that the code runs much faster the more you zoom out because it skips over more of the inner loops.  That's a nice bonus.  So converting 640x480 to 320x240 only takes about 0.03 seconds.  I can live with that, so I think I'll call this one finished.  Here's what it looks like.

I love the way the mouse pointer also gets scaled in zoom mode.

It's almost useful at that scale.  But now you can zoom in and out pretty much at will, so that's not such a problem.

Now I just need to find some new project that'd be great to have on the zipit, if only the display fit in the 320x240 pixel zipit screen.  I'm sure I passed up a few of those over the years...

Saturday, April 1, 2017

April Fooling

It's April 1st, and the weather gods have once again played a nasty little joke, dumping a chilly mix of snow and ice onto the lawn.  So I decided to make the best of it, staying inside and tinkering with some zipit software that's just barely past the idea phase.

One such idea that I keep revisiting is how to make the gmenu2x GUI more versatile.  So this time I thought, perhaps I can do it from outside the box.  Maybe I can make some scripted modal dialogs that could launch from gmenu2x, but run outside of gmenu2x and simply display over it temporarily.  Or maybe we could find a use for popup notifications that post themselves over gmenu2x temporarily.


So I grabbed a few small example programs that open /dev/fb0 and write directly to the screen.  And that's where I am right now.  I can save the gmenu2x screen, write over part of it, and then restore it when I'm done.  Not too exciting, but lotsa potential, especially if I pull in the fgui code for some nice looking widgets.  Fgui makes for a nice fit because it's only requirements are a pair of get and put_pixel functions, so it's easy to graft onto any sort of graphical backend.

With any luck, I'll have an actual dialog screenshot before the snow melts.

Update April 2

And there it is...
Check out that shiny new icon for the ziptuner.  Pretty sweet eh?

Ok, it's not an actual dialog, but it is a small chunk of the fgui demo program -- reworked with /dev/fb0 as the backend instead of the original sdl backend.   The new backend  lets me pop it up over the gmenu2x display and tinker with the controls.  There may still be a few patches of snow left in the shadows beneath the trees, so I think I'll call this a success.

It'd be even better if it used the /dev/fb1 overlay screen so I could display the popup with no worries about contention with gmenu2x screen updates.  Unfortunately there appears to be some bugs in the PXA video driver that make the overlay less than optimal for my purposes.    Perhaps I can do a workaround someday for the overlay, but first I want to try and make what I've got do something useful.