SDLvnc

It's been a long, long stretch with not much happening here.  What can I say?  I've been busy.  Yeah, yeah, I know...enough already with the excuses.  Onto the new stuff.

A few years ago (years?!) I mentioned sdlvnc as something to investigate "someday", and apparently never, ever got back to it.  Until now, that is.  There was a sudden flurry of activity on the zipit IRC leading into this weekend, and someone brought up vnc again.  Got me thinking...

So I tracked down the sdlvnc source code, and a slightly updated version of the sdlvnc sample client from WebOS with some screen panning code included.   I also discovered some libsdl_vnc fixes in the SVN repository that apparently have never been released.  In my opinion, either panning or scaling (or both) is absolutely required for vnc to be the least bit useful on the tiny 320x240 zipit screen.  Here's a picture so you can see what I mean.

I'm running a rather small 640x480 tightvnc session on my Debian Mint laptop.  With no panning, even this would be useless, but at least now I finally have a vnc client that's rotated properly for the zipit, thanks to the SDL backend.  However, the vnc mouse is jumpy and sluggish, ctrl-esc may not be the best key combo for quitting vnc, and my current choice of panning keys (ctrl-shift) is cumbersome on the zipit, but I can finally imagine someone actually, maybe attempting to use this in some sort of dire emergency situation.  So I'm gonna release the zipitized sources and an IZ2S executable, as soon as I clean up the code and test it just a wee bit more - especially the keyboard support for the unusual zipit keys. 

Really.  I mean it this time.  Well... except maybe first I want to check out the code for the WebOS junkvnc client, which claims to have taken sdlvnc even further and added a zoom function!

I wonder what else we can borrow from WebOS?

Update:

Ok, I fixed up the keys for the zipit.  Sorta.  It's been so long that I need to review how to do it for the Latin keys.  And I decided to go with ctrl-mousemotion for panning the vnc screen around.  For now.  I'm not sure how that fits in with slug's mouse setup on openwrt.

Here's the modified sources and an IZ2S executable of sdlvnc. 

sdlvnc105-iz2s.zip

I should probably repack it with a vnc wrapper script that sets the SDL environment vars first, but you can steal that from the rockbox, gmu, or glinks wrappers.  That'll have to wait for Rev 2 when I figure out how to fix all the other issues, and maybe add some zoom.

Here's an openwrt executable of sdlvnc.

sdlvnc-wrt.tgz

I'll have to add an option to swap left and center mouse buttons so the openwrt build is less awkward in the current gmenu2x userlands.

Update2:

I managed to get zoom working in 0.05% increments.  It's painfully slow, but it seems to work.  Good luck if you try it on a large framebuffer.  Here's an fbgrab screenshot of 65% zoom on an openwrt zipit.

The vnc zoom is on the ctrl-comma and ctrl-period keys.  I also added a -mb command line option to swap the mouse buttons, making drag-n-drop a bit less painful on openwrt.  I'll try to package it up in both iz2s and openwrt flavors tomorrow during the superbowl.

sdlvnc106-wrt.tgz

sdlvnc106-iz2s.zip

sdlvnc client code on github

Fun with qemu

As it turns out, I might get to use that setlogcons applet in IZ2S after all - on emulated zipit hardware.  Somehow the light chatter on the zipit IRC channel recently turned to qemu.  We dug up anarsoul's old post on it and he worked out a slightly different patch for the blob bootloader to allow it to run the stock kernel and a hacked version of the iz2jffs (with the wifi modules removed from the Zcovery startup script).  Although nearly incapacitated by Thanksgiving turkey and stuffing sleepy syndrome (not to mention all the visiting relatives and pets) I did manage to find a few brief moments to tinker with this. 

So far I've tweaked the qemu startup script to make use of all 3 zipit serial ports.  After the boot messages display on the qemu console window, you can run a shell there by launching own-tty on the /dev/ttyS2 serial port to access the zipit from the host pc.  I imagine setlogcons could be handy here if the kernel messages start to bother me.  However the qemu launch scipt lets me access the other two zipit serial ports via telnet to ports 4000 and 4001 on the localhost.  That should be all I need for an editor and compiler window for development.  To access the other serial devices you have to create them first with mknod.  It's all laid out here.

launch-iz2s-qemu.sh  

I tried a few things to test the serial telnet windows.  Emacs, ttyclock, and text mode Links ran ok, so ncurses and the vt100 emulation is good.  I also launched the graphics mode Links from the serial telnet and flipped through the vttys to make sure it was running along with gmenu2x.  All looks good so far for development and testing on a virtual zipit.  I'm planning to tinker some more with the jffs startup scripts to automatically create the serial devices on bootup.  It's actually rather tricky to do it in the emulator window because it faithfully emulates the odd zipit keyboard layout.

You can see the extra shells running on the qemu zipit in this screenshot.

Meanwhile, anarsoul also came up with a small qemu patch to allow the zipit to run the kernel directly from qemu (without blob) and have it run in qemu with much more than zipit's paltry 32MB of RAM.  I haven't tried this yet, but it might be handy for compiling.  However, at this point the IRC discussion turned to qemu-user mode for a faster, bigger, better IZ2S development platform and tychoreg was off and running.  He's already working on some serious miracles.  At his current pace he should have some truly wonderous stuff by xmas.  I can't wait.

Update:

I made some scripts to mount and unmount the jffs image in a loop so I could examine and modify it on my linux laptop.  It all seemed to work, but when I ran it in qemu I discovered the laptop was using LZO compression whereas the zipit kernel only supports zlib compression for the jffs.  Now, according to the internet there are some patches that allow you to specify "compr=zlib" in the mount command, but it's not available on my laptop.  Darn it!

If I want to tinker with the jffs I'll probably have to modify it on a real zipit, dump it to the SD card with dd, and then transfer it the the laptop via sneakernet or scp.  That's a whole lot more work, unless I figure out how to dump it from the fake zipit running in qemu directly to the laptop running the qemu session.  I suppose it might be feasible to dump the jffs mtdblock to /tmp and then transfer it via zmodem, but alas, there's no zmodem on the jffs.  Time to read some more of the qemu manual and see if there's a simple file transfer option that I might have missed...

Update 2:


Looks like I was wrong.  The jffs zlib mount option does seem to work on my laptop.  I just forgot the -o in "-o compr=zlib" to set it up.  So now I can boot with qemu into a jffs with 3 shells immediately available, one on the qemu console window, and two more via telnet to localhost at ports 4000 and 4001.  It's totally insecure, but could be really handy for rapid compile and test sessions.  Now I just need to get an SD card image working in qemu so I have access to the compiler.

Update 3:

At first I followed some really crazy looking instructions for making an SD image for qemu.  I don't know what that stuff is for - maybe if you need to  emulate it down to the spi layer?   Who knows.  Turns out it's much easier to simply dd a pile of zeros into a file, make a vfat filesystem on that, loop mount it, and unzip IZ2S to get a working SD image suitable for qemu.  Actually, I also had to dig back in the IRC archives before I remembered to comment out the zipit lid check in the z2start.sh script.  I also added the serial tty setup from the jffs startup script.  And now I can boot qemu into either the jffs or sd version of IZ2S.

I'll post all of the new qemu scripts real soon now...

Back on Track

Well it took a while, but the 32GB SD card in my dedicated mp3 player zipit for the car is finally almost full to capacity with golden musical nuggets from the 70's and early 80's, ripped from my ancient collection of vinyl - scratches and all.  I've also installed a zipit in the bedroom as an internet radio player, and tossed in another 32GB SD card with a different set of mp3s from my record collection that I consider good sleeping music.  Well, it's too sleepy for the car anyhow.

Meanwhile the holidays are fast approaching, so I should have enough free time soon to resume some of the projects I'd started on before the music break.  I've got a few small things that might be worth posting already, so I'll start with that stuff.

I have plans to shrink up the links browser some more, perhaps significantly, but in the meantime here's the one I built a while back with most of the help messages stripped out for the languages I'll never use.  Saves about 100K on the jffs for stuff I might actually want.

links-100k-less-help-iz2s.zip

I also spent some time trying to decide which of the goodies on the french jffs I wanted to include in mine.  Dronz has a slightly different mix of stuff.  At one point his blog had some pretty pictures of his jffs, but that all seems to have disappeared into the vast internet memory hole.  Oh well, I can still look at the files.  There's a few programming languages and a serial terminal on the french jffs that I suppose could make a zipit with no SD card into a servicable test tool in an emergency.  Hmmm.  I only have the serial port mod on one zipit, but it's got uboot on it and I'm unlikely to convert it back to the stock blob bootloader just to play with the serial port in iz2jffs.  However it did get me curious about the ssterm program.

I looked at ssterm before, but not for long because it's written in python so I figured it was too big for the jffs.  But it has some features not available in picocom so I went back for another look.  Turns out the source is in a git repository, and with a little poking around I found my way back to a previous version written in C.  I grabbed the last version of code before it was rewritten in python.  It's somewhat newer than the one rkdavis provided many years ago, so I compiled it with small code complier options and here it is.  Someday maybe I'll put a serial port on a stock zipit and try it out.

ssterm1.2-iz2s.zip

I also added a setlogcons applet to my lcdval multi-call-binary utility.  It was a pretty good fit with the other console utilities in there, and it should be handy for redirecting pesky kernel log messages away from the serial port if you're stuck using the minimal ramdisk busybox available on the jffs.  The bigger full iz2s busybox build already has a setlogcons applet.

lcdval-setlogcons-iz2s.zip

Intermission

Wow.  It's been over 3 months since my last blog post.  Time really flies sometimes.  But I've been busy.  I finally committed to the Zipit as my car MP3 player of choice, retiring the old Mattel JuiceBox to the junk bin.  That meant I had nearly 32 gigabytes of space on the SD card to fill up with my favorite music. And that's where all the time went.

You see, most of my music collection is still trapped on Vinyl, so I got busy converting the good stuff (mostly obscure funk from the 70s) to digital.  Sadly this is an extremely time intensive process.  I have to monitor it most of the time in order to catch and prevent skips, and to pause the recording and flip the records at the appropriate times.  It's even more of a hassle with 45s and singles.  And that's just half the process.  Once it's digital there's still a whole lotta work to be done.

I can't get this on CD, but I might have to see if the youtube audio is better than my scratchy record.

I've been using Audacity to do most of the conversion.  It's a bit quirky, but I've got a procedure now on paper that walks me through the basic steps.  Once the music is digital, I have to scan for gaps to break up the songs, usually with the song times from the record as a guide.  As you can imagine, this takes significantly longer when there's no gap because I have to listen (several times) and select a spot that makes me happy.  After that I'm still not finished.  I like my MP3 files with a reasonable set of tags describing the music, maybe even an album cover to make it pretty in rockbox.  However the MP3 tag creation function in Audacity must've been created by idiots.  I've tried to use it several times, but there's no way that I can find to streamline the process.  There's way too much mouse clicking on various data fields and redundant typing for me, so I just let it create numbered files that I post process later with a different program.  It all works, but it's really time consuming.

Interestingly, a google search for "emacs audacity mode" turns up some actual meaty looking links, but I don't think any of them are the streamlined, keyboard accelerator driven interface I want.  Oh well, I guess you can't do everything in emacs.

I have to admit that with a decent bit rate, the sound is better than it was in my collection of cassettes, even before they spent way too many summers baking in the hot car.  I really like recreating my old personalized "greatest hits" cassettes via rockbox playlists, which takes even more of my time.  I originally tried to make the playlists using rockbox itself, but it turns out to be easier for me to just use some shell scripts and a text editor on the computer, then move the playlists to the SD card where rockbox can find them.  They're simple .m3u files so it's not too difficult, just (you guessed it) time consuming.


Anyhow, in the meantime I've actually built a few more small Zipit goodies and posted links to them on the Zipit IRC channel.  I'll try and dig them up from the IRC logs and list them here before the links expire and I completely lose track.

I updated fceu with a fix for battery backed RAM saves.  Here's an ipk, just in case the "nightly build" package doesn't work:  fceu r67-1 pxa.ipk

Here's a dvtm executable for openwrt.  dvtm-zipit-wrt.tgz


I also recently attempted to close some old bug reports on ldglite, which stirred up some more comments in the bug tracker that I'll have to do something about, eventually.  Who knew anybody besides me was still using that old stuff?

The Silence of the Games

I've examined quite a few gp2x type games lately and I've noticed a trend.  They tend to take games that you traditionally think of as silent and add sound, usually via some rather large .wav files played through the somewhat bloated SDL_mixer library.  I swear they've probably got a chess game with a soundtrack.  Now, that might be nice on the zipit too, but it won't ever fit on the jffs.

However, I'd really like to fit a few games on there, just for emergency entertainment purposes, so I searched around for some card and puzzle games for the console.  I happen to enjoy sokoban style games so I built some of those.  Other folks like solitaire, or minesweeper.  I've got a few of them built now too.  I just need to spend some more time with them for - err - "testing" purposes.  Yeah, that's it.

Here's a teaser shot of my zipitized port of consolitaire from a recent "test run".

I'd like to pretty up freecell with a similar look, if possible.  Eventually I should have a nice bundle of tiny games for the goodie bag, real soon now...

In the meantime, here's a shot of nsudoku.  It fits just fine on the zipit with only 2 new lines of code.

This nc-fighter game almost fits, but it moves too fast for me.

XorCurses actually fits, but only with the 4x6 font.  Better get a microscope if you plan on reading the help screen.  It's quite playable though, once you learn the basics.  And since it's a puzzle game it's a good one for me.

Yeah, this game is fun.  It actually got me motivated to get a better 4x6 font in order to read the help text.  So I grabbed the Tom Thumb bdf font and converted it to a psf console font, adding the ncurses line drawing characters while I was at it.  It came fully stocked with a set of tiny unreadable latin15 characters, so that was a nice bonus.

It gives me a migraine, but I can read it if I have to.  Hmm, perhaps this could also be used for those bloated finch config screens.

Meanwhile I managed to  fit the Enigma puzzle game into the standard iz2s font.  So far I've only managed to get about 20 moves into the game before I realize I'm stuck.  Either this game is really, really hard, or I must be getting senile faster than I thought.

The start up menu screen needed some adjustments to squeeze it onto the zipit, but it works.

I also built the Chroma puzzle game which supposedly supports Enigma and Xor levels as well.

And finally, to remind myself that SDL based games can also be small and silent, I built the embedded version of vectoroids.

It's only about 20K altogether, including the redspot image file.

For reference, here are some handy sites with loads of links to console apps.

http://inconsolation.wordpress.com/
http://kmandla.wordpress.com/
http://ttygames.wordpress.com/
http://jaredandcoralee.com/CLIapps.html

And now I really need to stop "testing" and get to work, packing all this up for the goodie bag...

But first I should mention the recent bugfix for fceu.  It was pointed out that the previous build did not allow saving the Battery backed RAM state, which made some games such as Zelda much more difficult than intended.  This build fixes that.  Here's an openwrt ipk, just in case there's problems with the nightly builds.
fceu r67-1 pxa

I have a new IZ2S executable too.  Get the package from the goodie bag (if you don't already have it) and replace the fceu executable with this one if you want to use the save feature.

fceu-iz2s-save-fix.zip

Here's the 4x6 console font.  Walrus45 was asking for it, so I expect he'll let me know if it helps any with the finch config screens...

thumb4x6.psf

Moving at a glacial pace...  Here's the iz2s enigma executable and modified source code.

enigma-iz2s.zip

And here's the iz2s consolitaire executable and modified source file.

consolitaire-iz2s.zip

I've packed up the csokoban, cmines, and cblocks executables for iz2s but I still need to zip up a package with the modified sources.

cgames-iz2s.zip

Here's xorcurses for iz2s, including the tomthumb console font.

xorcurses-iz2s.zip

Nsudoku, vectoroids, and freecell executables for iz2s.

nsudoku-iz2s.zip

vectoroids-iz2s.zip

freecell-iz2s.zip

Here's an iz2s chroma package.

chroma-iz2s.zip

Back to Reality

The original design of the zipit envisioned it as a communications toy for kids.  However, when I first saw it I pictured it as more of a learning toy, at least for me.  It's got all the basics for software development built into a teensy toy form factor.  And over the past few years I've learned quite a bit, porting various pieces of software to fit on the slow processor and gizmo shape of the zipit.  In fact it's been almost 2 years now since I attempted to relearn some shell scripting techniques that I'd nearly forgotten with the passage of time.  I always thought that stuff might come in handy some day, possibly even at work.  And sure enough, it's finally paid off.

At work I'm occasionally called to help support the field engineers by phone as they deploy the software parts of the systems we build.  Some of these are built on TinyCore linux and installed in a little black box with no local user interface.  This can be challenging when someone wants to transfer files to and from the devices with say a usb stick at the site.  Now, TinyCore comes with a really nice simple gui for identifying and mounting usb sticks, but if you don't happen to have a monitor or mouse you wind up trying to do it all via an ssh window from a laptop nearby.  Just try talking someone over the phone through the linux commands for identifying, and mounting a usb stick on the command line.  Let me tell you, it's a challenge. 

So to make my life somewhat easier, I decided to devote some of my spare time to make a shell script that emulates the TinyCore disk mounter tool.  You can see here the original FLTK gui tool and the scripty tool below it running in an xterm.

Not too bad, eh?  Now what, you say, does this have to do with the zipit?  Well, it turns out TinyCore runs on a busybox ash shell, just like the zipit.  And it doesn't come with the dialog program so I had to build the scripty disk mounter out of /bin/sh, sed, and grep (with a sprinkling of ANSI escape codes) just like I did with the zipit almost 2 years ago.  I suppose it might even be handy on the zipit if the homemade usb adapters were ever to become commonplace.

Here's the code.  The mnttool.sh script uses 3 helper scripts that are also included.  Two of them come from TinyCore and are also used by the GUI tool.  The cfajfuncs helper script comes from http://cfaj.freeshell.org (I bought and recommended his book previously) and is slightly modified to work with the variations of the echo and read commands in the TinyCore busybox shell. 

mnttool-sh.tgz

Game Sounds

In the midst of my last post I noticed that dronz had rearranged his blog and posted some screenshots of his latest french version of the iz2jffs.  They look quite pretty with that shiny blue background.  I'm somewhat jealous, gotta get me some of that.  I wonder what happened to the older blog posts though.  They don't seem to be available via his archives link.  I know I referenced some of them from this blog way back when I was working on the keyboard, so now I have to go back and review all my old posts for dead links.  Maintaining things on the internet can be quite a drag sometimes.

And speaking of change, I also saw the gmenu2x tabs were reworked, perhaps to sync up better with the gmenu2x from slugs openwrt jffs.  It looks like the utilities and terminal tabs have been dropped in favor of games and programming.  While I'm not sure programming requires it's own tab, I do have to admit I've been somewhat delinquent with the games.  After all, the zipit shares quite a bit in the form-factor department with other portable game systems.  So it should naturally be fully stocked with games.

But what've we got so far?  Doom, nethack, some rockbox games, and an fceu port without sound.  I'm sure there are some others, but nowhere near enough to fill up the games tab.  So I got busy, prowling through the sdl game list links, searching for anything appealing that might scale down to the zipit.

The first thing I spotted was opentyrian.  That seemed to be available on just about everything.  I grabbed the latest sources and built it with the dingux settings but it was painfully slow.  Huh?  Turns out the current sound code is full of floating point ops used to emulate the ancient opl sound hardware.  Now why would they do that?  This was originally a DOS game.  So I dug back in time and found an earlier port for the gp2x that was apparently done before someone went crazy with the floating point.  I built 2 more versions of the executable with that source --- one with sloppy 8bit sound for speed, and one with higher quality 16 bit sound.  I prefer the one with the better sound, but it runs slow when music is enabled and things are really happening in the game.  So I disabled music by default, but you can turn it on if you want via the esc menu.

Next I tried mozzwald's port of ohboy from openwrt.  I was hoping it'd have better keyboard support than the rockbox gnuboy plugin.  I'm not sure why the openwrt build doesn't include the splash screen image, but I guess it isn't really required.  Unfortunately, I'm still stuck on this one.  The menu runs, but not the games, so I put it on the backburner for now.

I have about half a dozen prospects from the sdl game list.  My reflexes are shot, so I need to find some puzzle games like sokoban for me.  Slug also mentioned cards, so I'm on the lookout for a card game that doesn't require a mouse to manipulate the cards.  Of course, wouldn't you know, the first thing I got working was another space shooter game, InsanerzShooter.

It works, despite the use of floats in the particle system.  That actually looks like an easy fix if I decide it's needed.   But for some reason the SDL_mixer lib doesn't like the oss audio driver, and the alsa driver on iz2jffs is my hacked build with extra buffering to reduce the skippies in rockbox.  This means all the laser and explosion sounds arrive about a second late.  Or is that the way it's supposed to be because of the speed of sound in a vacuum?  Heh.  I need to go way back in time and review my documentation on the SDL alsa environment variables that I added to let me tweak the hacked buffer settings.

Goodies will be posted soon.

Update:

Looks like I'm falling behind with the goodies.  Oh well.  Soon, I promise.  I had a refreshingly challenging week at work, and I also got distracted by some other games like blockdude and several different flavors of solitaire for the zipit console and SDL.  I'll get it all sorted out someday...

And here's a little note-to-self:  Walrus45 reminded me --- yet again --- to see what's up with the save function in fceu.   So I'll have figure out how to get past level 1 in something.

opentyrian-iz2s.zip

insanerz-iz2s.zip