--- a/README	Sun Mar 18 21:30:10 2018 +0000
+++ b/README	Sun Dec 29 23:01:26 2019 +0000
@@ -73,16 +73,17 @@
 in a few different ways:
 
 * We have a real TI-made D-Sample board and we can run our Magnetite firmware
-  on it, but lacking the tpudrv10 driver code for Clara RF, we are running with
-  a non-functional placeholder stub for the TPU driver.  The D-Sample board thus
-  has no GSM radio functionality when running our fw, and the firmware can only
-  do what any regular phone would do in an area with zero coverage: limited to
-  stepping through menus and examining SIM phonebook entries and stored
-  messages.  The physical LCD output works, but is often garbled due to what
-  appears to be a hardware problem.  Running fc-lcdpoll|fc-lcdemu against this
-  setup results in the virtual LCD mirroring the physical one, albeit with some
-  lag, and the virtual LCD shows what the physical one *should* display if it
-  weren't garbled.
+  on it, but lacking the real tpudrv10.c driver code for Clara RF, we are
+  running with a disassembly-based reconstruction attempt which is unfortunately
+  still broken and non-functional.  The D-Sample board thus has no GSM radio
+  functionality when running our fw, and the firmware can only do what any
+  regular phone would do in an area with zero coverage: limited to stepping
+  through menus and examining SIM phonebook entries and stored messages.  The
+  physical LCD output works, but is often garbled due to what appears to be a
+  hardware problem.  Running fc-lcdpoll|fc-lcdemu against this setup results in
+  the virtual LCD mirroring the physical one, albeit with seconds of lag, and
+  the virtual LCD shows what the physical one *should* display if it weren't
+  garbled.
 
 * One can run a UI-enabled Magnetite build on our FCDEV3B modem board and use
   the fc-lcdpoll|fc-lcdemu pipe to display what the fw puts in the framebuffer.
@@ -98,25 +99,20 @@
   the new key command for sending such simulated keypresses to the target, and
   by combining this key entry mechanism with the present fc-lcdpoll|fc-lcdemu
   display viewing mechanism, we've been able to exercise the UI a little
-  further.  This approach definitely shows some promise.
+  further.
 
-* The Pirelli DP-L10 target has also been tried.  I was hoping that it would
-  make a good platform by virtue of having a working GSM radio (unlike the
-  D-Sample sans tpudrv10 code) and a physical keypad that is just like the
-  one on the D-Sample, but no joy.  When running FreeCalypso on Pirelli's alien
-  hardware, among many other issues that kill any possibility of turning this
-  alien hw into a libre phone, we get this one highly bizarre misbehaviour for
-  which we have absolutely no explanation: the radio works OK *only if* the
-  firmware is built with deep sleep enabled in CST (i.e., enabled by default on
-  boot), and the Calypso gets to do some deep sleeps prior to the operator
-  manually bringing it up with AT commands.  If deep sleep is disabled, as soon
-  as you try to bring the radio up, the Calypso DSP falls over with errors
-  which we naturally have no way of debugging.  The most recent experiment has
-  revealed that this same DSP death behaviour (resulting in no working GSM
-  radio) occurs even when deep sleep is enabled if the firmware is built in the
-  MFW configuration (UI layers included) - as the UI layers command the radio
-  bring-up immediately on boot, the DSP falls over.  Thus we are rudely reminded
-  once more than the Pirelli target is a dead end.
+* One can also use a Pirelli DP-L10 phone instead of FCDEV3B.  The long-time
+  bug that caused GSM radio functionality to break if it was brought up without
+  getting some deep sleep first was fixed in 2019-03, and all GSM radio
+  functionality now works just as well on this Pirelli target as it does on our
+  native FCDEV3B.  The native 128x128 pixel LCD on this phone remains dark and
+  unused for now because it is too small to display TI's 176x220 pixel UI, but
+  the present fc-lcdpoll|fc-lcdemu mechanism works just as well on the Pirelli
+  as it does on FCDEV3B.  However, the Pirelli phone has a physical keypad that
+  has the same repertoire of buttons as D-Sample, and our fw knows and supports
+  Pirelli's keypad wiring.  Thus if you run a UI-enabled Magnetite build on the
+  Pirelli, you can use the phone's native keypad to drive this UI, but you have
+  to use the fc-lcdpoll|fc-lcdemu mechanism to see the display output.
 
 One currently outstanding defect with this fc-lcdpoll mechanism is that rvinterf
 currently prints all ETM packets as full hex dumps, and the flood of all that
@@ -124,9 +120,11 @@
 purpose of seeing other debug output from the fw.  This voluminous rvinterf
 output also slows down the rate at which the LCD framebuffer is polled.  One
 can run rvinterf with the -n option to suppress its output, but then all other
-debug trace output will be lost too.  I plan on fixing rvinterf at some point
-in the future to make its output less voluminous by default: keep the human-
-readable traces, but omit the rarely-useful hex dumps from the default output.
+debug trace output will be lost too.  Back in 2018-03 I was thinking about
+fixing rvinterf at some point to make its output less voluminous by default,
+keeping the human-readable traces, but omitting the rarely-useful hex dumps
+from the default output - but now I am thinking of different approaches as
+outlined below.
 
 Baud rate considerations
 ========================
@@ -142,3 +140,77 @@
 TR_BAUD_CONFIG=TR_BAUD_812500 argument to your ./configure.sh line,
 and remember to pass the -B812500 option to rvinterf when talking to such
 trace-speed-increased firmware.
+
+New thoughts as of 2019-12
+==========================
+
+While the fc-lcdpoll approach implemented in 2018-03 is much cleaner and much
+more workable than the original 2015-09 approach, the update rate of the virtual
+LCD is painfully slow, which is why no actual UI development work has been done
+yet via this approach.  It needs to be remembered that a 176x220 pixel
+framebuffer image with 16 bits per pixel weighs 77440 bytes, while the
+theoretical maximum throughput of a Calypso UART at the maximum 812500 baud rate
+is 81250 bytes per second - thus even under ideal conditions it will still take
+almost a full second to push out a single frame update.  The original 2015-09
+approach tried to get close to this theoretical maximum update rate by having
+the firmware stream out framebuffer updates continuously, but embedding this
+stream within RVTMUX resulted in overwhelming the trace mechanism beyond what
+it was meant to handle.
+
+The newer 2018-03 approach avoids overstressing the trace mechanism, but the new
+drawback is that the update rate of the virtual LCD got even slower: it now
+takes about 4 s to update the virtual LCD window by reading out the firmware's
+framebuffer via ETM, thus any UI features (animations, temporary message
+pop-ups) that last less than 4 s become lost.  This unacceptable lag in visible
+display updates is the main reason why I did not pursue further UI development
+work back in 2018 using this mechanism.
+
+If we were to continue down the virtual LCD route as opposed to looking for a
+new Calypso platform with a suitable hardware LCD, one possible approach would
+be to make use of two fully accessible UARTs on our FCDEV3B as opposed to just
+one UART accessible on our previous OM GTA02 and Pirelli DP-L10 platforms.  One
+idea would be to keep the IrDA UART for RVTMUX and keep it free from virtual LCD
+blit traffic, remove the ASCII AT command channel from the MODEM UART (not
+needed for basic handset UI work) and repurpose the MODEM UART for a new ad hoc
+interface that would carry just virtual LCD blits and nothing else.  It would be
+similar to going back to the original 2015-09 approach, but using a dedicated
+UART and thus not loading the RiViera Trace mechanism at all.
+
+However, as of right now (final days of 2019) I (Mother Mychaela) am not looking
+at any more virtual LCD approaches because as explained above, even under ideal
+conditions we would still have a lag of almost a full second per frame update -
+and no real LCD on any real phone or proper development board is that slow.
+
+Instead my view is that the proper solution is to acquire or create a UI
+development platform whose LCD subsystem would be no worse than D-Sample.  The
+exact arrangement implemented on the DS board is unknown because we have no
+schematics or any other hw docs, but the R2D driver in TI's firmware implements
+both LCD module configuration writes and actual pixel output by writing 16-bit
+words into certain magic addresses in the nCS3 address space, meaning that a
+16-bit parallel microprocessor bus write interface is implemented in some
+manner.  The 128x128 pixel LCD (also 16-bit color) on the Pirelli DP-L10 is
+similarly memory-mapped, with both commands and pixel data written as 16-bit
+words into magic addresses on another chip select (nCS4 in Pirelli's case) -
+although they have the additional complication of going through that SPCA552E
+camera chip which we would much rather not have.
+
+Smaller LCDs on lower-end phones are attached serially, using either uWire or
+I2C, but note that the largest serial LCD we have ever seen on a real-life
+Calypso phone is the 96x64 pixel 16-bit color LCD on the C139.  Pirelli's
+128x128 pixel LCD is already 2.6 times larger in terms of bits per frame, and
+it is parallel memory-mapped, not serially interfaced any more.  TI's 176x220
+pixel LCD on the D-Sample (also 16-bit color) is another 2.3 times larger than
+Pirelli's 128x128, and it is also parallel memory-mapped.  I desire a 176x220
+pixel LCD for UI development so I can see TI's original UI in its full glory,
+and I feel that interfacing it to the Calypso in any other way than 16-bit
+parallel memory-mapped would be substandard: the update rate would be slower
+than it was on the original D-Sample, and the user experience with the UI would
+no longer be the same as what TI's original developers experienced when they
+implemented this UI.
+
+The current situation as of the last days of 2019 is that we are looking to put
+together our own FC Luna UI development platform with a memory-mapped parallel-
+interfaced 176x220 pixel LCD using a certain historical development board as our
+starting point.  Our current hope is to be able to work on this project in the
+first half of 2020 once the starting-point hw arrives at the Mother's shop in
+California.