--- a/FC-handset-spec	Sat Jun 12 02:58:47 2021 +0000
+++ b/FC-handset-spec	Sat Jun 12 05:32:38 2021 +0000
@@ -123,11 +123,13 @@
 1) older phones with black&white LCDs: on all phones of this type which I've
    ever used, the display is perfectly readable without the backlight given
    ordinary ambient lighting, be it natural daylight or room lighting.  Such
-   LCDs are called reflective.  With these B&W displays, you only need to turn
-   on the backlight if you need to operate the phone in darkness, such as
-   outdoors at night or inside with all lights off.  The firmware in such phones
-   is typically designed to leave the actual display functional and updated at
-   all times, with only the backlight subject to on/off control.
+   LCDs are called transflective: primarily reflective, but can also operate in
+   transmissive mode when the optional backlight is turned on.  With these B&W
+   displays, you only need to turn on the backlight if you need to operate the
+   phone in darkness, such as outdoors at night or inside with all lights off.
+   The firmware in such phones is typically designed to leave the actual display
+   functional and updated at all times, with only the backlight subject to
+   on/off control.
 
 2) most newer phones with color displays, of which Pirelli DP-L10 is a
    representative case, have transmissive LCDs that are not designed to be
@@ -978,3 +980,106 @@
 nTESTRESET, but it is a bigger hammer (reset of RTC can be unwanted), hence
 -Prts will be recommended as the gentler option, leaving -Pdtr for times when
 recovery from runaway code is needed.
+
+2. FC handset firmware functional scope specification
+
+FreeCalypso handset firmware will always run (perhaps with subset functionality)
+on more hardware targets than just our main-goal FC Libre Dumbphone handset.  It
+already does: our firmware currently runs on our Luna development platform, and
+prior to FC it ran on TI's original D-Sample platform.  A very restricted
+functional subset also runs on Motorola C139 hardware.
+
+If we consider only the main goal of FC Libre Dumbphone handset, then our
+firmware evolution can be seen as strictly linear: we start with what we got
+from TI, and we morph it toward what will be needed to operate our handset,
+adding functionality and peripheral support which we need for our FC handset,
+but which is not present in the starting point code from TI.  However, we also
+have side-branch functionality: at times when the code from TI supports
+something which we don't need for our own FC handset, but which may be useful
+for alien hardware targets, a moral imperative can be made for keeping and at
+least minimally maintaining that functionality as a kind of side-branch feature,
+a permitted configuration that is not needed for our own FC handset but needed
+for others.  Similarly, when we add support for entirely new peripherals that
+are planned for our FC handset (such as the loudspeaker), we should make the
+firmware change in such a way that targets without the extra feature can still
+be supported.  Finally, when we are changing the firmware in ways that
+significantly depart from TI's original, it may sometimes be prudent to preserve
+TI's original way as a lorekeeping option.
+
+The following sections will spell out what we support and what we don't support
+in FreeCalypso handset firmware, and how these scoping decisions relate to our
+starting point from TI, to our main goal of FC Libre Dumbphone handset, and to
+secondary objectives of alien target support and lorekeeping.
+
+2.1. Display support
+
+2.1.1. Support for different display sizes
+
+By the very nature of the problem, any phone handset UI design will always be
+quite specific to a particular display size in pixels, and also to the display
+type as in color or black&white.  The starting point code we got from TI
+supports 3 different UI configurations in terms of size and coloration:
+
+* 176x220 pixel, 16-bit color;
+* 176x220 pixel B&W;
+* 84x48 pixel B&W.
+
+In FreeCalypso we have made two changes to this set of possible UI
+configurations:
+
+1) The large (176x220 pixel) B&W option has been removed.  In TI's delivery this
+   option was nothing more than a quick&dirty hack to extend their small (84x48
+   pixel) B&W UI to the large D-Sample screen, and this configuration offers
+   nothing useful - any real display of such large size will always be color.
+
+2) The small B&W configuration has been extended from 84x48 to 96x64 pixels.
+   Why 96x64?  Because it is the size in pixels of Motorola C139 LCD, and it is
+   the smallest LCD size found among those alien Calypso phones whose existence
+   is known to us and for which we have at least minimal support.  Extending
+   this UI configuration from 84x48 to 96x64 pixels was an easy change because
+   it is an increase in screen real estate (not a decrease), and it is a fairly
+   small increment, such that UI design choices which were sensible for an 84x48
+   pixel display are still sensible for 96x64.
+
+The main principal difference between our approach in FreeCalypso and what a
+conventional commercial phone manufacturer would have done is that we are
+retaining TI's smallbw configuration and keeping it supported, as opposed to
+disregarding it and working only on the bigcolor UI config for our own planned
+hardware product.  We keep this smallbw UI configuration around, in the extended
+96x64 pixel size, for two reasons:
+
+1) Lorekeeping: unlike TI's 176x220 pixel B&W config that was totally
+   uninteresting, TI's old smallbw UI (from the days of C-Sample) is
+   sufficiently interesting and unique (and naturally quite different from the
+   bigcolor version) to be worth preserving.
+
+2) By keeping this configuration around (not discarding it and not allowing it
+   to bitrot beyond repair), we keep the door open for the possibility of a
+   minimally usable FreeCalypso Lite aftermarket firmware for Motorola C139.
+
+Both UI configurations can be built for our current Luna platform, and both of
+them display on our Luna LCD.  The virtual framebuffer of 96x64 pix B&W in the
+smallbw config is displayed in the center of our physical 176x220 pixel color
+LCD, surrounded by a pale magenta border.  The same ability to run both configs
+will continue on our next development board (Venus).
+
+2.1.2. Backlight readability paradigm
+
+(See theoretical background in section 1.4.3.)
+
+Our actively maintained FC handset firmware has been paradigmatically redesigned
+to assume a display which is NOT readable without the backlight.  Our logical
+primitives with respect to display control are display on/off, rather than
+backlight on/off, and we swallow the initial keypress that turns on the display.
+
+This change is a significant departure from TI's original.  The LCD on TI's
+D-Sample is transflective, and when the backlight is off, the display remains
+readable in ambient light.  It is certainly better in this regard than Motorola
+C139 LCD.  And if we go back further in TI's history to C-Sample and earlier,
+those 84x48 pixel B&W LCDs were the traditional mostly-reflective type,
+perfectly readable without the backlight.
+
+This area is one where we are NOT retaining TI's original way as an option in
+our actively maintained firmware.  The difference between the two principal
+paradigms is too great, and we don't have any active-demand prospective targets
+with B&W displays of the old traditional kind.