--- a/MCSI-apparent-bug	Wed Oct 23 00:11:37 2019 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,94 +0,0 @@
-NOTE: OUTDATED ARTICLE!!!
-
-The following article was written in 2018-10; it is now 2019-03 and we have got
-MCSI working - see the new Calypso-digital-voice article.  The original article
-below is only for history preservation.
-
-Original article with outdated info follows
-===========================================
-
-The Calypso chip provides a little-used auxiliary synchronous serial interface
-called MCSI.  It is an auxiliary interface to the DSP part of the Calypso
-(controlled solely by the DSP and not directly accessible to the ARM part); it
-is not clear what other uses TI may have had in mind for this interface, but
-one advertised feature of TI's TCS211 chipset+firmware solution is Bluetooth
-support in the form of using MCSI as a digital voice channel to be connected to
-TI's Bluetooth Island chip.  In FreeCalypso we are not interested in Bluetooth
-per se, but we are interested in getting a digital voice channel out of our
-modem for GSM voice calls in order to compete with the mainstream proprietary
-GSM modem modules which do provide such digital voice channels.
-
-Our current development board (FCDEV3B) has MCSI brought out on a header for
-experimentation, and we had high hopes that we could use TI's so-called
-"Bluetooth headset" mode (the mode in which the voice path is connected between
-GSM and "Bluetooth" on MCSI) to get a usable digital voice channel out of our
-modem.  However, experiments have revealed the following:
-
-1) The good part: when our TCS211-based fw is given a command to switch into
-the Bluetooth headset mode (auw 0 2 through fc-tmsh or our own added AT@VPATH=2
-command), MCSI comes alive: a 520 kHz bit clock appears on MCSI_CLK and an 8 kHz
-frame sync signal appears on MCSI_FSYNCH.
-
-2) The bad part: as soon as I dial a voice call after having enabled the
-Bluetooth headset mode as above, the MCSI clock and frame sync signals
-*disappear* at some point in the voice call setup process!  I can make them
-reappear by switching to AT@VPATH=0 (the regular GSM-to-ABB voice routing mode)
-and then back to AT@VPATH=2 (merely repeating AT@VPATH=2 or auw 0 2 is not
-sufficient, one has to switch to another mode and then back to Bluetooth
-headset), and then the MCSI clock & frame sync disappearance no longer happens
-on subsequent calls - they stay on.  I can similarly make these MCSI clock &
-frame sync signals come on and stay on if I issue the initial AT@VPATH=2 command
-*after* the first voice call has been connected - but it is not clear at all
-exactly which step in the call setup process one would need to wait for.
-
-To me (Mother Mychaela) it would make sense for the DSP to keep MCSI clocks off
-during idle and only turn them on during active voice calls (doing so would
-avoid erratic clock output as the modem goes into and out of deep sleep during
-idle), but the behaviour we are seeing seems like TI tried to do what I just
-said, but got the logic reversed.
-
-This erratic behaviour with MCSI clocks getting turned off when they should be
-getting turned on makes this interface unusable beyond lab experimentation in
-my maternal opinion - dunno about others, but I would not be able to market a
-commercial FreeCalypso modem product with a digital voice channel via MCSI if
-the behaviour of the interface is clearly buggy and requires hacky workarounds
-on the part of the end user.  For this reason no further work has been done to
-see if the MCSI_TXD line actually puts out sensible voice downlink bits and if
-the MCSI_RXD line accepts voice uplink bits in a sensible format when an active
-voice call is in progress and the clocks are on.
-
-As I see it, there are 3 ways we can solve this digital voice channel problem:
-
-1) The most ideal option would be to convince TI to dig up and release the
-source for the Calypso DSP ROM: getting that source and being able to study it
-would solve all of our problems at the root.  We would then understand exactly
-what the DSP does with regard to MCSI, and either change its behaviour to a
-more desirable one by way of a DSP patch, or adapt our ARM-side fw or even the
-external control interface definition to what will then be fully known DSP
-behaviour.
-
-2) If TI no longer have the source for the Calypso DSP ROM or are unable to
-find it because of the length of time that has passed (about 15 y), or if they
-have it but we are not able to convince them to release it, we could reverse-
-engineer this ROM by disassembling the ROM image that has been read out.
-However, reversing this ROM thoroughly enough to serve as a replacement for the
-lost original source would be an extremely costly undertaking: if I were to do
-it, I would need to be given a full year to work on it on a full-time basis, at
-the cost of about 150 kUSD, and I find it doubtful that any other professional
-reverser of sufficient qualification level would do it for less.  Needless to
-say, it is highly unlikely that anyone in our ultra-marginalized FreeCalypso
-community can spare 150 kUSD, and if someone does have that kind of money to
-spend toward the liberation of the Calypso DSP, the sensible course of action
-would be to first offer that money to TI in exchange for the DSP ROM source
-before giving it to a reverser.
-
-3) If someone has an actual (as opposed to hypothetical) money-backed business
-need for a Calypso-based modem with a digital voice interface, the fastest and
-cheapest solution would be to forego MCSI and tap into VSP instead, as described
-in the FCDEV3B-repackaging article in the section titled "Tapping VSP for the
-digital voice interface".  This option would require designing and building a
-new PCB, which would probably cost some 10 to 15 kUSD, but it is far less than
-the 150 kUSD that would be needed for DSP ROM RE, and the timeline would be
-much shorter too.  Unlike MCSI, VSP is used in the regular voice path going
-through the ABB, hence it is *known* to be good with no possibility of nasty
-surprises.