A Better Basic?

Remember way back in August, when I patched up an sdlBasic interpreter for the zipit and mentioned that there was more than one sdlBasic.  Well, there's been some lamenting lately on the zipit IRC that I shoulda picked a different one.  A better basic.  SdlBasic.  It's more shinier, and it comes with sound!  Ok, whatever.

Anyhow, I split the difference between the gp2x and linux makefile settings and compiled a version of the runtime for the zipit.  I still need to package it all up with some better zipitized example programs because it wants to run at 640x480, but the zipit is only 320x240.  The gp2x runtime package came with some patched .sdlbas files for 320x240, but they also had the keyboard controls modified to use the joystick instead.  Once again I split the difference and took the keyboard code from the original beast.sdlbas file and the screen size fixes from the gp2x code.  This is what it looks like with me fumbling around, trying to hold a camera and press the zipit alt-number keys to load the various .mod music samples. 

I think it shows a whopping 25 FPS!  35 if I run it without the music.  Shiny!

Files are here for now.

sdlbasic-iz2s.zip
sdlbasic-iz2s-src.tar.bz2

I Blame the Trees

Still not much happening in the software world.  The real world gets in the way.  We have electricity again, but we also have dozens of downed trees to cut up and remove, which leaves far too little time and energy at the end of the day for a whole lot of this stuff.  Gotta get me a chainsaw.

Anyhow, I did somehow manage to spend a few minutes testing things, trying to identify which lib causes the image display bug in the fltk example programs when the screen is rotated.  The pure microwindows nxview program is able to display pngs, jpegs, and bmps in any orientation so libnano-X is probably ok.  The next layer under fltk is the libNX11 X Windows compatibility layer.  So I took a ride in the wayback machine and dug up the ancient xv sources. 

Ah ha!  This program does all sorts of X11 trickery and only shows a blank splash screen when the nano-X server is running rotated. 

But it looks just fine in the native orientation.  So the problem is somewhere in libNX11.  Quite possibly in the cliping functions used by both FLTK and xv.

At this rate I should have it solved by Christmas.  I just hope it doesn't snow again for a while...

Update:

Apparently nxview has trouble with alpha blending.  Here it is in the native screen orientation.  The edges of the dice in the alphademo.png image blend nicely with the background color of the window.

And here it is with the -L orientation.

No blending!  I don't believe nxview uses libNX11 so that places at least some of the problems in libnano-X.

2nd Rate Utilities

This has not been a particularly fun week.  Winter arrived a wee bit early this year with a foot of sticky wet snow that plastered our third world electric grid, just recently recovered from the previous hurricane destruction.  Once again the local utilities proved to be not quite up to the task of restoration.  It's been a long, long 9 days so far without power and with temperatures most nights well below freezing.  Needless to say, all software projects are currently on hold. 

I did manage to get online (for a couple of minutes) only to find an email from my ISP announcing their nefarious plan to delete all my web files within a few short weeks.  Nice.  The Zipit Z2 Goodie Bag is now homeless.  Oh well.  The current location wasn't all that convenient with it's relatively tiny 20MB partitions.  It looks like I can get 100MB for files and a wiki for free on google sites, so it'll probably be moving there once the power company gets me some electricity.  And maybe I'll cancel cable TV to teach that ISP a lesson.  I haven't really missed it.  I just wish I could do the same with the local power monopoly...

Yet Another Calculator?

So it turns out Nano-X and FLTK 1.3 needed some extra lovin to get themselves working together real nice on IZ2S.  It took a while, but I finally got some freetype fonts loaded in the right place with the right config files.  Some small patches enabled kerning and anti-aliasing in nxlib and FLTK.

I also got the X11/rgb.txt color file installed so the Xlib example programs can use colors by name.  Unfortunately there's still some sort of clipping issue to work out when running nano-X -L to rotate the zipit screen to the proper orientation.  Images display fine when the screen is unrotated, but not when rotated.  Gotta fix that if I want to run Dillo on this thing. Anyhow this is what the mbasecalc calculator looks like, running with FLTK widgets on nxlib over nano-X.

It's got hex to decimal conversion (which I really like) and some nice shortcut keys for ease of use on the zipit.  I'm still thinking about tweaking the key bindings a bit though to minimize use of the ALT key.  And the calculator only uses part of the zipit screen, so it has room for more functions if I ever get really motivated.

Here's an FLTK font browser showing the list of fonts currently installed on my IZ2S setup.  Unfortunately there's currently a bug somewhere in either FLTK or nxlib that prevents all but the various sizes and shapes of the "helvetica" sans font family from loading. The good news is that font family looks pretty good, and fills most of  my needs.

I also fixed a few more issues with flwriter that were most likely caused by the jump to FLTK 1.3 from whatever old version it was last compiled with.  It works pretty well if you stick with the one working font family.  The default xhtml files load up just fine in the various browsers available on IZ2S, and the single rtf export file I created loaded up ok in word.  This is what flwriter looks like on the zipit with the anti-aliased fonts.

And here's the upgraded FLTK filebrowser with the shinier gtk+ theme and antialiased freetype fonts.  I'm not quite sure what to think of the microscopic  text in the preview pane.

Not too shabby though...

Refining the Layers

Just a quick update for now.  After playing with the FLTK demos for a while on the zipit I began to realize they could do with a bit of refining.  For example, the keymap still wasn't quite right, and nothing was really tuned to fit on the 320x240 screen.  I did a bit of tweaking in the microwin layer and got the alt key recognized as altgr so the keymap would work as loaded in all the microwin demos.  But then the nxlib layer needed another similar tweak before the fltk demos would work right.  I got that done, and moved onto the FLTK editor demo. 

I figure the editor demo might actually be useful as a simple text editor when launched from say gmenu2x, so I decided to take a look at that one first.  Most FLTK apps seem to have a few hardcoded window coordinates located in or near the main() function.  This turned out to be the case with the editor demo.  I adjusted the coordinates to fit nice and tight on the 320x240 screen and all seemed well and good until I hit the file save dialog.  Apparently the builtin FLTK dialogs are just a wee bit chubby for the zipit screen.  So I adjusted them a bit as well.  Here's the tweaked FLTK file dialog. 

I think it looks pretty nice on the zipit.

And since the simple editor worked out so well, I thought maybe I'd take it one step further.  So I poked around the internet and found some references to an abandoned old fltk word processor program that works with xhtml files and can export to rtf.  Hmm, that's almost borderline useful.  Maybe with some helper utilities to convert things...

So I compiled flwriter and tweaked it a bit for the zipit screen.  So far, so good, but it revealed a problem.  I still need to figure out how to install the fonts for nano-X.  I suppose that's next.  It'd be really nice If I could work out how to share the dejavu fonts in the netsurf package.

Layers and Layers (revisited)

Yet another of my long term goals for the zipit is to get FLTK working so I can build the Dillo browser, maybe murgaLua, and play with some light embedded GUI development.  FLTK applications have worked out quite well on some of the smaller linux distros like TinyCore and Puppy Linux.  So perhaps some of that good stuff could be squeezed onto the zipit.

Recently someone built FLTK 1.3 on Nano-X on DOS, so I figured if that was now possible, then a zipit port ought to be workable as well.  I followed some of the directions from the DOS port, and eventually figured out which options to select in the MicroWindows config file to convince Nano-X to build and run on the zipit.  The mouse was a bit tricky, but I eventually figured out the fake z2mouse was emulating a PS2 serial mouse, so all I had to do was softlink /dev/input/mice to the /dev/mouse device Nano-X was expecting, and it worked.  I still don't know exactly what to do about all the font options, but so far I haven't needed to sort that out just yet.

Now we all know by now that the framebuffer device on the zipit is actually a 240x320 pixel LCD oriented at a 90 degrees right rotation from the keyboard.  This must be accounted for whenever you want to display something on the screen.  Nano-X has a handy -L command line option to rotate the screen to the left for 320x240 pixels aligned with the keyboard.  But it also rotates the mouse coordinates, making the pointer 90 degrees off.  However, I found the spot in the Nano-X code where the mouse coords come in from all the various drivers.  So I added a 3 line zipit patch to rotate them 90 degrees to the right to match the real orientation of the screen.  And they remain matched up when the both the screen and the mouse are rotated by the -L command line option.  Nice!


I gotta revisit DirectFB and try to apply a similar mouse fix.  Especially now that I've got glinks running properly on SDL instead of DirectFB.  That leaves me completely free to discard the broken IZ2S DirectFB libs and start again from scratch.

I may also revisit the z2mouse driver itself.  The more I use it, the more I'm convinced that maybe the left mouse button should be on the play key instead of the center of the dpad.  It's nice for pointing and clicking to have all the functionality right on the dpad, with the lesser used center and right buttons off to the left on the play and stop keys.  But dragging anything takes 2 fingers, and it's really hard to get both of them in the confined space of the dpad.  So I'm thinking now that maybe the left and right buttons do most of the dragging work, so they should be moved off to the side of the dpad on the play and stop keys.  That leaves the center of the dpad for the center mouse button.  Easy to remember and it doesn't cross my fingers up dragging things around, or highlighting text.

Anyhow, FLTK seems to work.  Now I gotta just find me some FLTK apps to tinker with that work well in 320x240, or I suppose 240x320 if they don't need the keyboard.  These look pretty good, for example.  Perhaps eigenmath?  Or alsamixergui?

My Kingdom for a Calculator

Building the bc utility reminded me (yet again) that given it's form factor, the zipit really ought to have a decent calculator program.  Bc is ok I guess, but I can't remember more than the most basic syntax, and besides, it segfaults when I run it with the -l switch to pull in the math functions like sin() and cos().  I gotta see if I can fix that.  Maybe the IZ2S mathlib  is busted.  I sorta remember removing all references to doubles from  nightsky to get it to run right.  Maybe I need to rebuild a new libm.so with different floating point settings...

Anyhow, what I'd really like is to get bc working well and get a nice GUI wrapper for it like x-bc so I don't have to remember the syntax. I've already got something *almost* like that with the emacs calculator mode.

The emacs calculator has it's own command line math system like bc that works pretty well, and comes with a GUI that's ok with a real mouse, but quite a chore to navigate with the zipit dpad or via emacs key commands.  Besides, it's Reverse Polish Notation (RPN).  Yuck!  That's just not natural.  And finally, all the digits are still ALT key combinations on the zipit keypad which makes them difficult to type.  I suppose it could handy though if I want to calculate some numbers and paste them into a document, or vice versa.  I might look into tweaking the emacs lisp code to let me type digits into the calculator pane without the ALT key, but I'm not sure where my ancient lisp skills stand aftar all these years.

I did find a fairly simple SDLcalc program for the caanoo that might meet my needs someday.  It looks nice, but it has no keyboard input yet. Apparently the caanoo has a touchscreen?  Plus it's got some screen refresh issues, possibly due to the rotated screen on the zipit.  I think I'm gonna try to keep the GUI but add keyboard support and maybe switch to a bc backend when (if?) I get the bc mathlib problem fixed.

I'm not sure if it uses SDL, but the cal2x calculator for the gp2x looks pretty decent.  It even does some grahping if you're into that.  Me, I really want that hex button.  Unfortunately the source web site is korean and full of dead links.  Oh well.

Meanwhile, I thought to myself, there's gotta be an ncurses calculator out there somewhere that'll do the trick.  However the only ones I could find were all RPN style, like dcalc.  Err, yuck?

Then I stumbled onto tcalc, the mighty console calculator.  It's nothing more than a simple bash script, with ANSI escape sequences to draw the boxy graphics characters.  Wow!  Talk about retro, low-tech chic.  I had to dig up a console font with the box chars small enough to display the entire calculator.  And I had to adjust the ANSI sequences to move the whole display to the top left of the screen so it would show up on the zipit.  I'd like to add some color, but even so, I think it looks ok as is.

The last tweak I did was to adjust the key parsing routines to let me enter all the digits and the basic math keys without touching the dreaded ALT button.  That's a huge win for me!  It could do with a few function buttons, and once again, maybe a bc backend.  Someday, maybe...

tcalc-iz2s.zip