--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/D-Sample	Mon Mar 19 18:45:16 2018 +0000
@@ -0,0 +1,118 @@
+Back In The Day TI had an official and well-supported platform for Calypso
+software development; this platform was called D-Sample.  It consisted of a
+development board with the Calypso+Iota chipset on it (as well as a GSM RF
+section based on their older Clara RF transceiver chip) plus an attached test
+handset.  Here are some pictures:
+
+https://www.freecalypso.org/members/falcon/pictures/D-Sample/
+
+I (Mychaela) have managed to obtain one of these historical D-Sample kits (the
+one pictured) back in 2015.  Given that this D-Sample board was the original
+and most native hw target for the TCS211 firmware program, and given that our
+FreeCalypso Magnetite firmware project is essentially a resurrection and
+continuation of that TCS211 fw program, I naturally have a strong desire to
+have our firmware run on this board in its full glory like it once ran in the
+offices or cubicles of TI's own software engineers who worked on various parts
+of TCS211 fw for the Calypso.
+
+The current state of support is that we have everything other than the GSM radio
+working.  We are currently unable to bring up the radio tract on the D-Sample
+board with our own Magnetite fw because of Clara RF: we only got a stripped
+semi-src version of TCS211 in which the *.c files for L1 were censored out and
+only *.obj blobs were supplied instead; the latter blobs target Rita RF and not
+Clara.  We have now successfully reconstructed the lost C sources for the RF-
+independent and Rita-specific L1 modules, and we have l1_rf10.c for Clara RF
+from the MV100 source fragments, but we are still missing the tpudrv10.c module
+which is also required for Clara RF.  Right now if one builds our current
+Magnetite fw for target dsample, a placeholder stub version of tpudrv10.c is
+used - it allows the firmware to link, but does not do any actual RF control,
+thus any attempts to bring up the radio immediately fail.
+
+Despite having no working radio, everything else works: we can flash our own
+Magnetite fw images into the board with our fc-loadtool (fc-host-tools-r8 or
+later; earlier versions did not support the 28F640W30B flash chip correctly),
+the SIM interface works, the audio subsystem driven by the Calypso DSP driven
+by our reconstructed TCS211 L1 works (can make beeps through the loudspeaker in
+the handset part of the kit), the handset keypad works, and when we run a
+firmware image built with the UI layers enabled, the 176x220 pixel color UI
+shows up on the big LCD.  Because the SIM interface works, one can play with
+this UI a fair bit despite having no working GSM radio: the UI behaves the same
+way as any regular phone would in the absence of coverage, so one can step
+through the menus, read SIM phonebook entries and stored messages.
+
+Apparent hardware defect in our D-Sample LCD
+============================================
+
+The one specific D-Sample board we have managed to score (might be the last one
+left in the world, who knows) appears to be an early board: it is PCB rev 3,
+but it has an early C05 version of the Calypso chip (F741979B), and it was made
+some time in 2002.  It came flashed with a firmware image built on 20020917,
+and this original image it came with did not light up the LCD at all - it only
+responded to AT commands.  (Examination of that fw image suggests that it has
+SMI instead of BMI+MFW, but I am not familiar with SMI at all - all I can tell
+is that it behaves functionally as if it were an ACI build.)  Thus the LCD part
+of this D-Sample hardware only got exercised for the first time when I ran our
+own Magnetite fw on it, and it exhibits some strange behaviour which I can only
+attribute to a hardware problem.
+
+The symptom is that the picture on the LCD sometimes appears garbled, and
+whether or not this LCD garbling happens (and if it does happen, how severely)
+appears to depend on the picture content.  Furthermore, the dependency is not
+only on the picture content, but seemingly also on some law of chance, as the
+same picture can get garbled more or less severely at different times.  Closer
+examination of exactly how the picture is garbled reveals that the misbehaviour
+appears to be some kind of double latching of write data inside the LCD module.
+
+The R2D driver maintains a software framebuffer in the r2d_lcd_memory_words[]
+array, and the r2d_refresh() function transfers the picture in this software
+FB to the hardware FB inside the LCD module by sequentially writing 176*220
+16-bit words into a fixed ARM7 memory address in the nCS3 range, causing a
+write cycle to be issued to the LCD module for each pixel.  When a garbled
+picture appears on the physical LCD, the picture maintained by the software in
+the r2d_lcd_memory_words[] array is correct (not garbled) as revealed by
+reading that array memory out via ETM memory read commands (see the tools in
+the freecalypso-ui-dev repository), and the picture on the physical LCD is
+garbled in such a way that it appears that at some point when the firmware sent
+a single pixel to it, the LCD module erroneously registered a double write,
+incrementing the internal FB RAM pointer by two pixels instead of one, with all
+subsequent pixels shifted accordingly.  The picture can be garbled more or less
+severely depending on how many pixels in the picture trigger this apparent
+double write effect.
+
+The end result is that even though we have a real TI-made D-Sample hardware kit,
+its usefulness to us for FreeCalypso UI development is rather limited because
+of both the lack of tpudrv10.c code resulting in no working GSM radio and the
+apparent hardware problem with the LCD module in the handset part of the kit.
+
+The Mother's plan is to design and build our own UI development board to take
+the place of TI's D-Sample, combining the good version of the Calypso+Iota+Rita
+chipset for which we have good fw support with a 176x220 pix color LCD of our
+own - it is one of the industry standard sizes, so it should only be a matter
+of getting a semi-custom one with the right interface (16-bit parallel) and the
+right polarizer orientation (6 o'clock viewing direction).  The proposed board
+would be a derivative of our current FCDEV3B, keeping the core Calypso+RF block
+(originally from Openmoko) completely unchanged, but adding the LCD, the keypad
+buttons and other handset peripherals, resulting in a Handset Motherboard
+Prototype - HSMBP.
+
+Different Calypso silicon versions
+==================================
+
+Because the D-Sample was a development board rather than a commercial end user
+product, different D-Sample boards at different points in time had different
+versions of the Calypso chip populated on them as the Calypso silicon itself
+evolved.  The board we got appears to be an early one, as it has Calypso chip
+version F741979B on it (C05 rev B, DSP ROM version 3311), but I can only reason
+that later D-Sample boards must have had Calypso C035 chips on them, either the
+original Calypso C035 with DSP ROM version 3416 or the final silicon with DSP
+ROM version 3606.
+
+Because we only have one D-Sample board and we have no idea whether or not there
+are any other DS boards out there in the world (ours may well be the world's
+last remaining unit), our current build system is set up to target only one
+D-Sample version, the one we've got: CHIPSET=8, DSP=33 for Calypso C05 rev B
+silicon.  If anyone else in the world has another D-Sample board and it has a
+different Calypso chip version on it, if you would like to run our FC Magnetite
+firmware on it, you will need to edit the targets/dsample.conf source file
+(it's a Bourne shell script fragment sourced by configure.sh) and set the
+CHIPSET and DSP settings correctly for your Calypso chip version.