Edinburgh pictures from TI

[Mychaela Falconia]

Hello FreeCalypso community,

I am trudging along on our FC Tourmaline handset firmware:

https://www.freecalypso.org/hg/fc-tourmaline/

This firmware runs in its full glory (176x220 pixel color UI) only on
our Luna development platform, which consists of an LCD of the needed
large size connected either to a historical iWOW DSK board or to our
own Caramel2.  Right now Das Signal and I are the only two people in
the world who have the necessary hardware to run this fw (DS has an
iWOW DSK board plus my Luna LCD add-on, I have run both iWOW-DSK and
Caramel2 versions), so it is rather unfortunate that no one else can
see this firmware in action...

This handset UI firmware work I am doing in the Tourmaline source tree,
it is intended to be the fw component of my still-dearly-desired
FreeCalypso Libre Dumbphone handset.  Of course I will still need to
build the physical handset hw, but I am focusing on the firmware first
because hw without fw is nothing but a very expensive paperweight,
whereas most of the needed fw can be developed on my current Luna
platform.

One of the areas I am working on right now is looking for ways to
speed up the drawing of the idle screen, one component of which is the
background wallpaper.  As I was studying this code in need of speeding
up (it currently runs too slow, does too many inefficient computation
operations), I took a closer look at the wallpaper images included in
TI's demo/prototype/PoC handset UI going back to early 2000s.  A
selection of 5 possible idle screen wallpapers is included: the default
is a big TI logo, and the other 4 are pictures of various locations in
Edinburgh.  Why Edinburgh?  The handset UI layer of TI's firmware suite
was developed by the group that started out as Condat UK and then
became TI-UK when TI bought out Condat, and that UK office was in
Edinburgh.

Here are the wallpaper images extracted out of TI's demo/prototype/PoC
UI code, converted by me to classic Netppm format for viewing with
standard tools like xv:

https://www.freecalypso.org/members/falcon/TI-wallpapers/

Each of the 4 Edinburgh wallpapers is actually embedded into TI's code
as a 175x220 pixel image, one pixel short of the 176x220 pix display
size, so whenever one of these wallpapers is selected for display, the
rightmost pixel on the LCD remains white in the entire column.  The
PPM images with 'w' suffix in the filenames have had a white pixel
added on the right to bring their size up to 176x220.

I would like some help from the community with identifying these
Edinburgh images.  What are the locations depicted in them?  What is
the significance of these 4 particular locations in that city?  And
the monument depicted in the Edinburgh4 image, whose statue is it?

squares.ppm is an abstract art image which appears in TI's source
(IcnBgdSquares.c, same source file as the Edinburgh images), but it
isn't included in the firmware build - it is excluded from compilation
by preprocessor conditionals.

For our own FreeCalypso handset firmware, I am thinking about removing
the entire system of compiled-in wallpaper images and replacing it with
a mechanism where the firmware would read the wallpaper image from FFS,
with the expectation that the user will use fc-fsio to upload whatever
wallpaper image she likes.  In the case of traditional locked-down
phones where both the firmware source and the development tools are
withheld, the traditional handset manufacturers' approach has been to
include some manufacturer-defined fixed selection of wallpaper images
in the firmware, and let the user choose among this fixed limited set
via the menu.  Letting the user upload her own images via a Unix/Linux
command line tool like our fc-fsio was of course an utterly blasphemous
idea to those traditional locked-down phone manufs.  But we are
different, we are FreeCalypso, and I have no interest in marketing my
phones to command-line-phobic sheeple - instead my desired FC Libre
Dumbphone will be made specifically for Unix/Linux command line lovers.
So why bloat the firmware (and thus slow down compilation and flashing
operations) with a bunch of fixed-choice wallpaper images - instead
let the flash contains just one wallpaper image, the one installed by
the user, and let this one active wallpaper image reside in the FFS
portion of the flash, rather than the firmware code.  The selection of
possible wallpaper images for the end user to choose from then becomes
the entire repetoire of images to be found on the Internet, not just
some arbitrary set chosen by the manufacturer for inclusion into fw.

Hasta la Victoria, Siempre,
Mychaela aka The Mother