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.  But 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.

Update Jan 21, 2019

I also did some work on the tiny zipit bleeding edge openwrt starter filesystem that gets installed by the latest flashstock.  I updated the certs and installed libustream-openssl to fix up links and wget, and a tossed in few other goodies while I was at it.  And very quickly ran out of space. 

No room for emacs.

Now the filesystem for this is comprised of a read-only squashfs and a 1MB overlay jffs.  All the new stuff goes onto the jffs and that's where we ran outta room.  But I sorta remembered checking the squashfs a while ago and discovered that it didn't quite fill up the entire mtdblock3 partition.   So I dumped it to a file with dd and copied it over to my laptop where I used unsquashfs to examine the contents.  Sure enough there was about 400K unaccounted for.  So I figured I could squeeze (squash?) mpg123 and the libustream-openssl package in there.  The certificates are likely to change in the future so they'll have to stay with the jffs.  I had to simplify to a plain blue background, lose the zz-zipit sound file, and change a few duplicate files into softlinks, but eventually it all fit.

Plenty of room for emacs.

Hopefully I can fit the certs and both ziptuner and emacs onto the now roomier jffs partition.

Here's the fully packed ultra-bleeding-squashfs.sfs file.  I managed to fit everything else I wanted onto the jffs with over 700k to spare.   If you boot your zipit from an SD card and your kernel is configured with the right mtd partition sizes you can use dd to upgrade the squashfs installed by flashstock.

root@zipitz2:/tmp#  cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "uboot"
mtd1: 00010000 00010000 "ubootenv"
mtd2: 00190000 00010000 "kernel"
mtd3: 004d0000 00010000 "squashfs"
mtd4: 00150000 00010000 "jffs2"


root@zipitz2:/tmp# dd if=ultra-bleeding-squashfs.sfs of=/dev/mtdblock3
9856+0 records in
9856+0 records out


And don't forget to upgrade /dev/mtdblock2 with the latest openwrt kernel while you're at it.

One more tip.  If you're like me and get really annoyed by bright or blinking LEDs, especially at night, you might want to edit /etc/init.d/z2leds.  Set all three LED triggers to "none" to wrest control away from the kernel and give it to you.  Also comment out or delete the bit where it checks the battery and turns on the "charged" LED. 


root@zipitz2:~# cat /etc/init.d/z2leds
#!/bin/sh /etc/rc.common
#
# Setup Zipit Z2 LED's
#

START=11

start() {
    echo "Setting up Zipit LED's (gimme full control)"
    echo "none" > /sys/class/leds/z2\:green\:wifi/trigger
    echo "none" > /sys/class/leds/z2\:green\:charged/trigger
    echo "none" > /sys/class/leds/z2\:amber\:charging/trigger
#    STAT=`cat /sys/class/power_supply/Z2/status)`
#    if [ "$STAT" == "Full" ]; then
#        echo "255" > /sys/class/leds/z2\:green\:charged/brightness
#    fi
}


That didn't completely cure the epic seizures the kernel was having over the "charged" LED on my zipit, so mozzwald made this new seizure free kernel.

Update Feb 3, 2019

In order to stay out of trouble, the seizure free kernel avoids reading the flaky charge controller status, and so it can't provide a charge full status to gmenu2x.  This is a minor annoyance so I thought maybe some small updates to ebindkeys and or gmenu2x could work around it.  But the squashfs partition is completely full, right down to the last 4K block.   So I've had second thoughts about including the 150K dialog package in there, just to support the sleep timer applet.  Especially so, since I had to substitute a slightly smaller non-wide character version of dialog -- It makes a mess of ziptuner on the international internet radio channels.

With this in mind I finally did something useful with my piles of ANSI escape sequence junk code, and made a 6K standalone menu script as a fallback if the sleeptimer applet finds no dialog package installed.  Here's what it looks like.



The current code avoids using stty since it's not available in the squashfs, and at 50K I'm not planning to put it there.  Eventually I'll redo the squashfs again without dialog, but with more updates and other goodies instead.  Perhaps picocom and tinyirc.

...And I ended up replacing the dialog package with qemacs and tinyirc, in addition to the sleepmenu since that was an exact fit sizewise in the squashfs partition.

ultra-bleeding-squashfs-2.0.sfs