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

Cable Guy

One thing I dislike about the zipit is the power adapter.  The connector seems flimsy, and in fact the tiny plastic end sometimes comes off the connector and lodges inside the zipit.  I happen to have one zipit in that sad state right now, unable to get a charge.  This got me thinking again about the Dell Axim x50 and it's expansion cable with the zipit compatible 36 pin connector.  Now I've got a reasonable excuse to make a purchase and see it the Axim cable can be modified for use with the zipit, like for instance as USB charge cable.  So I picked one up online and took it apart.

The connector hood is held together by two screws and some fairly weak clips so it's easy to disassemble.  Here you can see the two screw holes on the left, and the 4 red, black, white, and green USB wires, (is that a standard?) along with 2 jumper wires connecting ground and power to multiple pins.

Here it is from another angle.  And one more shot with the hood removed.  Sorry about the sloppy photography.  I might try to get some better shots.

The interesting thing about this connector is that although it looks very similar to the one from Hirose that's popular with the zipit folks, it's not the same.  The top and bottom rows of pins inside the connector are physically swapped.  Odd numbered pins are routed to the bottom of the Hirose connector, but are sent to the top of the Axim connector.  This threw me for a loop when I tried to match up the colored wires to various online documents describing the Axim pinout.

Next up, I gotta move the wires to different pins so it can charge the zipit.  Wish me luck...

Integrated Media

Last weekend I did some traveling, and spent some quality time with the zipit at the airport and on the plane.  During this time I realized that I really wanted an mp3 player integrated into gmenu2x in much the same way as the internet radio player.  Rockbox and gmu have their place, but it's sorta nice having the music playing in the background on tty4, while still maintaining some control over it in gmenu2x.

The first thing I did was modify the mpg1234 script that's the heart of the radio app to handle mp3 file names with spaces.  This made it possible to create an mpg123 app for gmenu2x that works pretty much the same way as the radio app.  You can select a whole directory of mp3s with the space bar and view the "now playing" info without ever leaving gmenu2x.  However it was still a bit of a pain switching over to tty4 if I wanted to skip a song or pause it briefly to listen to the plane departure announcements.  I needed a way to send an f or a space character to the mpg123 process running on tty4 from within gmenu2x.  Fortunately we have the internet and it provided the basics for this tiny sendtty program, which I used to create 4 handy new media control utility apps in gmenu2x.

The Pause and Stop buttons should also work just fine with the internet radio app.  Eventually I plan on making yet another gmenu2x release with hot keys for the media control functions, as well as a w hot key for the wifi.  But I haven't decided yet whether to make the minor release numbers for iz2jffs V5 go to 11, or if I'm ready to start calling it V6.

Anyhow, here's the mpg123 app, including a sendtty executable for iz2s.

mpg123-iz2jffs-app.tgz

I might have to rework that a bit because the shiny new french version of iz2jffs seems to have replaced the underused terminals and utilities tabs with some more interesting stuff.  So the media buttons will have to go in settings instead.  I can live with that.


Before hitting the road, I did some work on the funkgold tracker program, fixing bugs and making it fit better on the the tiny zipit screen.  Here's a zip file with an IZ2S executable and modified sources.

funkgold-iz2s.zip

If you compare this screenshot to the one in the previous blog post you'll get some idea of what I did to make it workable with the default iz2s console font size.  For example, on this screen the Length field is hidden until you move the cursor off the Sample Name field.  Then it appears and obscures the right half of the sample name.  Some of the other fields use shorter abbreviations, so the whole thing just barely fits.

Enjoy.

Stuck on Segfault

This time I really and truly wanted to get a links browser build running on the zipit with ttf fonts instead of the fuzzy built-in fonts.  Unfortunately a nasty segfault halted my forward progress like a brick wall.  I swear I'm almost there.  Really.  But apparently not in the mood for a serious debugging  effort.

Before I hit the bricks I made a little bit of progress.  I discovered links apparently has 33 language translations for the menus baked right into the executable, just like the font system.  I removed all but English and French for a 500K RAM savings at runtime and a 100K savings on the jffs.  Not too shabby.  I also devised a simple way of loading one or more of the excised translations at runtime from a shared lib using dlopen, but didn't code it up yet,

Anyhow, this put my free space on the jffs right up around a megabyte.  Sweet!  So I pressed ahead and cut ties with the internal font, roughed in a ttf system based on the plan9 varfont patch, and found myself with a "tiny" 500K upxed links executable that promptly segfaulted.  Aargh!  So close.  I bet if I swapped out the openssl bloat for the tiny matrix ssl library I could get it down around 300K.  Of course, it doesn't work right now.  There's probably some residual piece of the old font system poking at random memory through a bad pointer that I forgot to prune out.  I'll get it, but i need to step away for a moment.

Maybe some relaxing music might get me back into the swing of things?  Well, actually this has been bugging me since the sound system in my fceu build didn't quite work.  I decided to try and port the SDL Drum Toy to get a better idea of how game sound is accomplished.  So I shrunk up the interface from 640x480 to 320x240 for the zipit and gave it a spin.

Heh.  It sounded even crappier than the Super Mario sound running in fceu on the zipit.  But I stuck with it and learned a few things.  Notably, the first 4 sounds in all of the sample music tracks appear to be loaded from .wav files, and work just fine.  The other 12 sounds are typically synthesized at runtime to create an octave of notes, or a few chords.  These FM synthesized notes are generated on the fly at runtime, but about 10 times too slowly for actual use due to the lack of a floating point unit in the zipit processor.   I think this is basically the problem with the fceu sound code.  It can't create sounds fast enough to use them in a timely manner on the zipit hardware.

When I commented out the DrumToy FM synth code, the tracks played at full speed, albeit with only the 4 digital drum sounds.  So I thought maybe if I converted the FM synthesized voices to digital samples on startup then I could play the full musical track.  I allocated a generous 2 seconds worth of samples to each synth voice and suddenly it was taking 3 minutes to bring up the main screen.  That's not so good.  I also botched the formula because the sampled FM synth notes were pure noise.   But at least the tracks were now playing at full speed.  So instead of synthesizing I borrowed the samples from the NDS bliptracker and used them to replace six of the synthesized voices in the demo1 track.  It sounded weird, but it worked.  It looks like you can probably make full use of all 16 voices in the DrumToy if you can find 12 more decent mono .wav files.

This music stuff is kinda fun so I may tinker with it some more, until I feel like taking on the segfault.  There must be some simple integer only synth code out there somewhere, right?  Didn't we have different notes on the PC speaker way back when DOS ran off a flippy floppy?  I may even have a 5 inch floppy in the attic with that sort of code on it.  Too bad I got nothing to read it.

I see there's quite a bit of sample code here.  And this has some fast integer sine functions, with arm assembler code!  Just what the doctor ordered.  The DrumToy FM synth boils down to a few floating point multiplies and two sine calls per sample.  If I can just convert it all to fixed point, that function might just do the trick.

There's also an interesting thread on MilkyTracker at the dingoo forum.  Hmm...

Yeah, so that turned out to be a relatively easy build for the zipit.  It takes almost 30 seconds to load, but seems to work ok.  However it requires the z2mouse which makes it somewhat cumbersome to use.  I might take a look at the keybinding code someday to make it easier to control.  Although I'm not sure how much I can do.  It seems to have a function for every single key on a full PC keyboard.  So any sort of "fix" would just be a trade off for a slightly more usable set of keys.

Since I don't particularly like the dpad "mouse", I thought it might be a good idea to try and dig up something mouseless.  I ran a search for ncurses trackers, but most of that stuff appeared to be rather old.  I built the ancient funktrackerGOLD and managed to play it's example songs, but it reqires an 80 character wide terminal, which forced me to load this nearly unreadable Atari font.

It also sounds like the music is being played underwater.  Is that really the way 8bits used to sound?  No, it's not.  Turns out the mixer code in funktracker uses doubles.  The individual instruments actually sound just fine when played manually via the the single octave on the z row of the keyboard.  I did some experiments reshaping the display for a bigger font, and fixed some nasty stack overrun bugs caused by string overflows.  I'd say this has promise, if I can convert the mixer code to integers.


Update: 

I've spent some time in the DrumToy code and made a little bit of progress.  The integer sine functions seem to work ok.  It can now synthesize the 12 FM notes on the fly, which is pretty cool.  The small errors introduced by the integer math may be changing the tone of the notes somewhat, but it's hard to tell because I've found a bigger problem.  The tempo isn't working right on the zipit.  At some point I noticed the 4 wav sounds seemed to stutter and hang around too long, which got me looking at the code for maintaining the tempo.  It's starting to look like the DrumToy was programmed with a fairly powerful PC in mind.

I'm not sure exactly where the tempo problem originates, but I suspect there's too much wasteful math happening in some of the inner code loops where it should just be moving data out to the audio device.  I did some experiments with reducing the graphics overhead and that quickened the tempo quite a bit, but still not quite up to full speed.  I also did an experiment with no notes playing, not even the wav notes, and it still failed to keep up with the expected 120 beats per minute.  That should never happen.  So I've gotta fix this before I go back and  attempt to smooth out the FM sounds by tweaking the location of the decimal point in the integer math.

Update 2: 

 Heh.  Apparently there was some more sneaky floating point math (that I completely missed) in the saturation_process function.  I commented that out and now it runs at the correct speed.  So it's back to tweaking the integer math in the FM synthesis code.  Gotta find me a few more bits of precision for those low, low notes in the demo1 track.

Actually all of the integer math notes were sounding a bit flat, even to my tin ear.  What's up with that?  I dug up a cheap guitar tuner gizmo and verified it.  They are indeed flat.  Whereas the tuner says the floating point math is generating the true notes.  Hmm, maybe I should go back to double precision floats for the initial frequency calculations, and save the integer math for the runtime sample generation?  Or maybe the integer sine function loses precision as the number of cycles increases?  I don't know, so I think I'll go back and retest it with some additional (more realistic) sample points.

Update 3:

I solved the problem with the flat notes.  It was accumulating errors in the integer math, which pushed all the frequencies off by a few cycles per second.  Now it sounds halfway decent, and the guitar tuner gives it the thumbs up too.  It still needs lotsa work with the location of the decimal point in all of the integer multiplies.  I think there are parts of the code where I'm down to a single bit of precision -- the sign bit -- but it's only supposed to be a "toy", right?  So it'll have to do for now.

Here's a nice blurry video.  Enjoy.

Here's some DrumToy executables for IZ2S and OpenWRT, with the integer FM synthesis source code included.

drumtoy-fm-iz2s.zip
drumtoy-fm-wrt.tgz
drumtoy-fm-wrt-bleeding-edge.tgz

And here's a milkytracker package for IZ2S.

milkytracker-iz2s.zip

The openwrt package should have shown up in the nightly builds by now.  It's in mozzwald's repo but not yet in the chainxor repo, which probably calculates "nightly" in Australian.

A File Manager for SDL?

I'd really like to stay focused on converting the flipclock and the links browser from png to ttf fonts, but sometimes the distractions just sorta pop up outta nowhere.  Way, way down on my todo list is a requirement for some sort of file manager for iz2jffs.  Now I don't need it myself because I'm old and the command line was the only game in town when I started using computers.  But I've seen plenty of folks struggling to find their way around when presented with a command prompt.  So when I stumbled on a file manager written in C and SDL on a raspberry pi forum, I figured I had to stop and take a look.   I tweaked a few lines of code to shrink up the display into something a bit more zipit sized, and ended up with this.

It still needs work to make it usable on the zipit, but it shows promise.  Plus it's only about 25k after upxing so it could easily fit on the jffs.  However, first I should decide if it makes more sense to add some basic file manager functions to gmenu2x instead.  Based on the grey function buttons in the image above, there really isn't all that much missing from the gmenu2x base code.

So I took another look at Dingux Commander which has a more polished look, shown here browsing the iz2jffs home directory in the left panel, and the mounted filesystems on the right.

But it's C++, and at 115K it's not such a great candidate to put on the jffs.  However, I thought maybe I could simply fold the code for the split panel view and the file manager functions into the gmenu2x C++ code base without increasing the bloat by all that much.  And as it turns out, folding the Dingux Commander code into gmenu2x (with minimal changes to make it build) only adds about 14K to the total after upxing.  So I guess I should probably provide an executable, and think about rolling another release of the jffs.

Here's a tar file with a new gmenu2x executable and that nice striped background image.  To keep it simple I used the ttf font and icon images from the gmenu2x default skin instead of the ones from Dingux Commander.   If you try it, you should see a shiny new File Manager icon in the applications folder, right next to the Explorer icon.

gmenu2x-cmdr.tgz

After getting the basics working I did some more work on the code to make it fit in better on the jffs.  I altered a few of the key bindings and turned on blended text for a smoother, more readable look.  You can see here its using the smoothed gmenu2x font and the icons from the default gmenu2x theme.  Looks nice.

 

 I also patched the Dingux Commander text file viewer to reuse the gmenu2x code that I created for viewing Latin15 text files.

Finally, I merged the Commander text input code with the gmenu2x input code to enable Latin 15 input via the zipit keyboard instead of the on screen keyboard for the mkdir and rename functions.  Altogether it seemed like a fairly useful addition to the jffs, so I rolled out yet another iz2jffs5 release.


And now I can get back to the ttf stuff.  I took a quick peek the plan9 links-varfont hack and it looks like 90 percent of the conversion from png font to ttf can be done by replacing 3 functions in dip.c:  g_print_text(), g_text_width(), and g_char_width() with the equivalent SDL_ttf functions.  I still need grep for "ifdef PLAN9" and evaluate the rest of the diffs for subtle issues, but it doesn't look too painful...

Time for a Change

I've been rolling out new iz2jffs5 updates at a fairly rapid pace for two weeks now, so I figured maybe it was time for a change of pace.

So I checked the todo list, double checked it, and decided to finally do something about that flipclock app that's been languishing there for quite a while now.  The first thing I had to do was track down the problem with the display.  It was way too flickery to leave on all night.  I tried it once and it drove me nuts.  So I reorganized the code a bit to give the SDL software double buffering a chance to do it's thing.  Now I can leave it running without fearing for my sanity.

After spending all that quality time in the code I finally felt more confident adding some command line options to do various messaging functions in the blank space below the actual clock.

It's now got 4 lines of text using the png font file that I borrowed from slug's gmenu2x a while back.  I could've fit 5 lines, but it seemed kinda tight.  So far I've got code to put up simple static messages, strftime formatted time and date messages, and messages that can be updated on the fly by polling a file.  I'm planning to use that one someday to feed it a real live weather report.  It integrates pretty well with the iz2jffs alarm script so I included a sample implementation of that too.  Here's the usage message to give you some idea how I intend to use it.


Usage:  fc [-1|-2|-3|-4][D|f][w|d] [message|file|timeformat]

Displays a flipclock and up to 4 lines of text messages underneath.

  f = Display message from a file.  Updates whenever the file does.
  D = Display the date/time by passing timeformat through strftime().
      Line 3 defaults to a date using "%b %d, %Y  -  %l:%M %p".
  w = white text (default = grey)
  d = darker grey text.

eg:  fc -1d "Nice weather." -2D "%b %d, %Y" -3 "" -4 "Wake at 7 AM"

This should work on either IZ2S or the iz2jffs, although I haven't yet tested the alarm script in the bash shell on IZ2S.
fc-iz2jffs.zip

Source code:
fc-iz2s-src.zip

I'd still like to see if I can get it to use the gmu font files in addition to sfont files and the modified gmenu2x sfont file.  I suspect gmu uses only fixed width fonts because the fonts lack the "magic pink" spacers on the top image line.

Update:

I added a -t option for 24hr time in the main clock display, and -p for padding the upper hour digit with a zero for folks who need to see 4 digits all the time.  I also experimented with various options for the  date string to see what could be done with that.  Here I tried it with a bigger message font and this command for an ISO 8601 date with 24 Hour time.

   fc -tp -3w "%F - %R %p"

I forgot sfont files can come in colors, so I think I probably need to change the w option to b for bold and remove all mention of grey from the usage message.  I'll package up a new executable and the code real soon now, depending on how far I get with the gmu font file.  Here's what that looks like so far.  I added a -w<size> option just in case it can't figure out the font width from the png image size.

I have to say, I definitely prefer the layout of the GMU font file to the gmenu2x "sfontplus" file.  The GMU font files are quite small because they use fixed width characters.  The magic pink spacers don't seem to compress so well in the sfont files.  But what I really like about the GMU file is that it's a simple 256 character latin1 font, which works quite well with the latin15 setup of the iz2jffs.  The gmenu2x sfontplus file has the glyph order scrambled all willy-nilly.  Who came up with that?  If I ever do get back to working with the openwrt-zipit version of the gmenu2x code, the first thing I'm gonna do is re-order the glyphs in the font file.  It's unicode so I'll just put them in unicode standard order with the gaps for missing characters compressed.

Now if only I could convince gimp or mtpaint to generate a decent png font file, I'd be all set with the flipclock app.

Maybe this microfontmaker thing will do it for me?  I just gotta find me a PC that still has java on it.

Or maybe I can hack the code from that tiny sdl font previewer to save a png file.

Or use one of the many Windows texture font makers like bmfont.  Something's gotta work.

Or maybe I should just come to terms with the fact that libfreetype and libSDL_ttf actually fit on the jffs with plenty of room to spare.  I really should be using ttf fonts for everything.  In fact, the best change I could make to the jffs would be to chop the huge png font outta links and replace it with some nice ttf fonts that all the apps can use.  I really need to take another look at that plan9 ttf version of links...

Update 2:

I managed to modify the dingux gmenu2x font generator program gen_sfont_image.py to create a latin1 png font instead with gen_sfont_latin.py.  I used it to create an sfont file with the same latin1 glyph order as the gmu font file, except this one uses a proportional spaced 15 point DejaVuSansCondensed font. The file is a bit larger than I'd like so maybe the gmu font makes more sense for the jffs.  I might do some more experiments generating fonts, but more likely I'll start converting the flipclock to use a ttf font.  Heck, even the tiny imgv program uses the ttf font.

I did a quick latin test on puppy linux and it seems to work, maybe.

Here's the new flipclock release.
fc3-iz2jffs.zip

Source code:
fc3-iz2jffs-src.zip


Meanwhile, since I'm still waffling over then benefits and drawbacks of libfreetype I should probably mention stb_truetype.h over at http://nothings.org.  It replaces libfreetype with a small C header file.  You give up some quality (hinting) and performance for the tiny size but you also lose the dependency on the huge shared lib.  I probably can't use it on the zipit because I really want the hints for the smaller fonts.  But I'm gonna have to try it.  And some of the other code there too.

iz2jffs v5

Note, there's a bunch of releases here.  The most recent is down at the bottom.

It took a while, but I finally came to my senses and realized I was never gonna get around to everything on my todo list.  So I decided to patch together whatever good stuff I could find from the last 9 months and roll a new iz2jffs release.  It still looks a whole lot like like the v4 release, but there are actually quite a few changes under the hood.  Thanks to the new upx many of the executables are smaller, and quite a few have also been updated or improved in some small way.  I used up a little bit of the extra space so I could include dvtm and my sel file selector based "album" script for handy command line mp3 playing.  There's currently about 640K free on the jffs, which is plenty big enough to experiment with some more new goodies.

Here's a quick picture.  Hey look, is that 30GB free on the SD card?  Nice!  The 32GB class 10 Sandisk card I recently acquired seems to work just fine so far...

Here's my first try:
iz2jffs-e5.tgz

Heh.  That one didn't last very long.  I updated a few more programs for about 800K free:
iz2jffs-e5.1.tgz

And then I fixed the gmenu2x battery monitor, changed the input.conf file to include key bindings from slug's jffs, and made it a wee bit smaller so I now have 820K free:
iz2jffs-e5.2.tgz

And if anyone else actually tries it out, feedback can only make it better.  Based on Dronz's feedback I made yet another build with my forgotten LED fix, even more upxed executables, and a smaller (DejaVuSans) font file that I also found to be more readable.  The jffs now has over 900K free!
iz2jffs-e5.3.tgz

I replaced the useless gmenu2x touchscreen code with a semi functional wifi indicator and switched to the smaller Bepa-Roman.ttf font file for 920K free.
iz2jffs-e5.4.tgz

Uh oh.  I think I may have left out the font from that last one.  Yikes!  Hopefully I got it into this next one.  I also added an updated imgv viewer and patched the gmenu2x file explorer to let me select a directory with the spacebar and pass that to imgv.  Then I can quickly cycle through all the pictures in that directory with imgv using the n and p keys, or s for a slideshow.  And while I was working on the explorer code, I also removed the restriction that would only let you run programs with certain gp2x executable file extensions.  So now you can launch anything.  Be careful with that.
iz2jffs-e5.5.tgz

For the next build I made some overdue cosmetic changes.  I replaced the ugly SD card and Speaker icons on the bottom bar, and tweaked the wifi script so the wifi bars will show up right after you connect.  I also added slightly modified versions of Dronz's new alarm script and micro SD refresh app.  I'd still like to fix the Ctrl-c handler in the alarm app and figure out how to make it use the space-bar to quit in addition to the q key.
iz2jffs-e5.6.tgz

After testing the alarm script this overnight I decided to tinker with the display.  Now it's centered, with the current time up top where it's easy to find since that's what I want to check in the middle of the night.  I also figured out how to use the space and esc keys to quit.  Afterward I experimented with flipclock for the display.  It works, but I need to tweak it to display and possibly control the alarm setting.  Altogether it's not yet enough to warrent another release, but here's the current incarnation of the alarm script if you want to try it.

All the nice internet radio options got me wanting an easy way to change the volume without leaving gmenu2, so I finally decided to fix it up right for the zipit.  I replaced the broken volume and cpu speed settings with separate working headphone and speaker controls using the zipit volume buttons (ctrl-volume for the speaker).  I also replaced the start and select button images so the help messages almost match the zipit key bindings.  Check out the cute little zipit key in the Radio selector.  I added an AudioCheck selection that you can use to turn off the radio, or test the alarm beep volume.

iz2jffs-e5.7.tgz

I was on a bit of a roll there for a while, but all good things must come to an end.  I made a few more changes and then got distracted by the flipclock app and an SDL file manager program, so this next one may be it for a while.

I noticed the gmenu2x volume controls were starting up at -1, and all of the audio scripts contained "alsa started" tests.  So I decided to waste another second during startup and launch setup-alsa-sh from the Zcovery script.  I also added some commented out gmu and rockbox launchers in Zcovery to show how to tweak the jffs for a dedicated internet radio device that starts playing right away, or a car audio player that's easier to get going while you're behind the wheel.  I have one of each myself.

While I was in the Zcovery script I decided to pre-rotate all 4 of the consoles during startup.  This got me thinking about the mpg1234tty4 script and the way it works in gmenu2x.  The radio app launches mpg123 into a background process (on tty4) so I thought it might be better to use the gmenu2x dontleave option.  I tried it, and it came out looking much cleaner, but I noticed I could no longer change the channel.  It turned out the gmenu2x dontleave code had a bug that would add params (the new channel) to the end of the existing command line instead of starting over from scratch.  Thus mpg123 would always start up working on the first channel selected and not the new channel.  I fixed the bug and now the radio app is better than ever.

However rockbox and gmu were now more difficult to use because they use internal software volume controls and expect the main volume (or Headphone volume) to be set high.   So I edited their startup scripts to temporarily set the Headphone volume to 95% so they can maintain their own internal volume settings from session to session.  The scripts restore the gmenu2x headphone settings when the apps exit.

In addition, I made a few more cosmetic changes.  Dronz supplied the Black Gloss theme, and I read the mtpaint documentation on layers and transparency so I could clean up the button images I made earlier.  I also decided to reuse the old about icon for the new help app since it was a bit cleaner and they were quite similar otherwise.

iz2jffs-e5.8.tgz

Did I just say 5.8 would be the last one for a while?  Oops.   Apparently I was mistaken.  I was reviewing all the new help text when I suddenly remembered that gmenu2x has it's own set of help functions that might also have some utility.  So the first thing I did was pipe the mpg123 messages from the radio app through a tee and into a log file.  I hooked the log file up to the help info function on the radio app, so now I can check the recently played song list without ever leaving gmenu2x.   Since the help icon that appears on the bottom bar has an i (for info?) I added the i key to the input.conf file.  And while I was in there I also added the missing inc and dec keys so I can twiddle the color numbers in the skin settings dialog.

The next thing I tried to do was to hook up the rockbox help file to the rockbox app, but that file is html and all the tags made it nearly unreadable in the readme dialog.  So I patched gmenu2x to pass .html help files through a sed filter and strip out most of the html tags before opening up the readme dialog.  Hmm, maybe someday I'll replace the odd gmenu2x manual file support with some limited html support instead...

Anyhow, once that was working I attempted to use the full help.html file.  But that file uses latin15 character coding and gmenu2x only likes utf8, so I whipped up a simple on the fly converter and also fixed it to expand tab characters into  multiple spaces.  It's not perfect.  The html sed filter mangles the euro character (it looks ok in a .txt file).  The help text for the < and > keys also gets mangled by the html sed filter.  Plus the expanded tabs will never look quite right with a proportional space font (maybe I'll implement a pseudo fixed width font mode for the readme files).  But overall I'd say it's readable, and possibly even somewhat helpful.

I also replaced the clunky gmenu2x onscreen keyboard code with slug's patch supporting the real zipit keys, and then enhanced that with the pspmaps code for the Latin15 keymap.

I'll post the new stuff soon.  Gotta play with it a bit more and then wrap it all up.

Then maybe I'll start digging into links again.  I couldn't find the back button in text mode.  So I'd like to match up the text mode and graphics mode keys better, maybe pull in slug's zoom patch, and see if I can possibly replace the built in png font with ttf.

iz2jffs-e5.9.tgz

I made a few small changes to make sampling internet radio work better with the links browser.  Then I merged Dingux Commander into gmenu2x and decided it was enough of an enhancement to roll one more release.  You can read that story in a more recent post above.  Meanwhile, here's the goods.

iz2jffs-e5.10.tgz

Unfortunately the old manual install instructions are now obsolete, unless you can obtain the IZ2S 2.05 zip from the internet wayback machine.  However you can install this on a stock zipit the easy way with flashstock.

If you're looking to install this from a uboot zipit, or one with the openzipit kernel, check out the readme file in the flashback package for instructions.  You can find flashback in Dronz's stuff near the bottom of the goodie bag.

Update:

After some time away, I couldn't resist and made another release:

iz2jffs-e5.11.tgz

Fun and Games

Sometimes it seems like the one thing everyone wants to do on the zipit is recreate their cherished childhood memories playing various ancient video games.  I suppose I did that myself for a while when I finally got the rockblox plugin working in rockbox.  I still remember passing the entirety of a particularly long airport layover ages ago in New Oreleans, playing Breakout on the purchasing power of a single quarter.  I was actually saddened when the time finally came to board the plane because I still had 5 or 6 free game credits racked up.

While it's not exactly from my childhood, I do have some cherished memories of playing Super Mario and Link on the NES.  Link was a particular favorite because I never really finished it until the kids were old enough to try it, and they pushed me to complete the mission.  I think we still have the old NES box and a pile of cartridges tucked away in a closet somewhere...

Anyhow, the topic came up for like the millionth time on the zipit IRC channel and this time I made up my mind to try and build an NES emulator.  After reviewing the multitudinous choices, I eventually settled on the FCEU Rerecording emulator.  It's been built for the zipit before, but not yet for IZ2S or openwrt, the two zipit distros I seem to be using these days.

I got it working on IZ2S, but just like everyone before me I failed to get decent working sound out of it.  Plus the key binding configuration requires me to launch it from an ssh session so I can see the config instructions.  That's just weird.   So I thought I might try this gpfce variant of fceu.  It's got some ARM assembler optimations and a nifty SDL menu system borrowed from the picodrive emulator.

I got that working too, and the menus do look nice, but the emulation runs even slower.  Oh well.

After building both of these for IZ2S I decided to try and attempt an openwrt build.  This was more of a challenge.  I didn't feel up to wrestling with the weird openwrt Makefile and patches build system so I opted to compile it on the zipit itself.  This took longer that I'd have liked and probably wore a groove into my SD card, but eventually resulted in an fceu executable.  I launched it from ssh and configured the keys only to discover it had some sort of graphics bug, perhaps due to some quirk in the particular gcc version used by the native compiler.  Drat!  That forced me back into the openwrt Makefile that I was hoping to avoid.  

I eventually wrangled the Makefile into a working build, but it wasn't exactly easy.  The openwrt configure junk wouldn't even run until I figured out how to make it reduce the fceu folder depth by one level.  And autoconf absolutely refused to find the lua lib no matter what weird openwrt hack I threw at it, so I had to make a cheesy patch to trick the autoconf files into skipping the liblua check.

Goodies were posted to the zipit IRC channel.  I'll track them down and post them here when I get a chance.

Here's the iz2s build of fceu;
fceu-iz2s.zip

The fceu Makefile and patches are on the openwrt-zipit github now.
https://github.com/openwrt-zipit/openwrt-zipit-packages/tree/master/fceu

Here's my openwrt build of fceu:
fceu r67-1 pxa.ipk

Just in case the one from the nightly build has problems:
http://mozzwald.homelinux.net/zipit/openwrt/pxa/packages/fceu_r67-1_pxa.ipk

I also spent some more time on tinyirc.  The MirOS variant has a working SIGWINCH  handler which I've tested by resizing it in dvtm.  The executable it 1K bigger because they   added all sorts of improved random number generator code for the private messaging.  Whatever.  I do like the resize code.

I also built the recent Finch release for openwrt and compiled a notification plugin at Slug's request.  We'll have to wait and see just exactly what that does for the zipit.

Here's the libpurple ipk, the new finch ipk to go with it, and  the ultra generic command-execute.so plugin. It does a system call on whatever command string you want so you can make your own special notification.