--- a/doc/FT232R-notes	Mon Sep 11 05:24:26 2023 +0000
+++ b/doc/FT232R-notes	Mon Sep 11 06:51:05 2023 +0000
@@ -1,42 +1,3 @@
-Unlike FT2232x devices with external EEPROMs, an FT232R device is not expected
-to ever have a blank EEPROM in normal usage: these chips have their EEPROM
-built in, and FTDI probably ships them with this internal EEPROM already
-programmed.  I said "probably" because I have not yet had an occasion to build
-my own FT232R-containing board where I would be getting completely pristine
-"bare" chips from Digi-Key, thus I have no first-hand verified knowledge.
-
-As an experiment, I have programmed "blank" (0xFFFF in every word) images into
-the two FT232R devices I have available for play at the moment (specifically
-devices which I could afford to brick if things went badly), and FT232R behaves
-the same way as FTDI's earlier chips with external EEPROMs: it runs with a fixed
-default config when the EEPROM is invalid.  But this configuration is NOT
-recommended for production use - you should always have a valid EEPROM config
-in your FT232R chip.
+This article has moved; the new location is:
 
-When our FreeCalypso fteeprom tools were first put together in 2019-04, I was
-getting erratic behaviour: when I tried to program my own EEPROM config
-generated with ftee-gen232r, the resulting EEPROM content became a bitwise AND
-between the previous image and the new one, as if the "EEPROM" is not really an
-erasable memory, but one of OTP kind where ones can be turned into zeros, but
-not the other way around.  I was doing this experiment on a no-name FT232RL
-adapter from ebay, thus my first thought was that the FT232RL chip was bad, a
-less-than-perfect clone rather than genuine FTDI.  But then I bought a UB232R
-module from Digi-Key (presumably containing a genuine FT232RQ chip), and it
-behaved the same way.
-
-Further investigation revealed that FT232R EEPROM write operations work
-correctly only if they are preceded by this magic sequence:
-
-	ftdi_usb_reset(&ftdi);
-	ftdi_poll_modem_status(&ftdi, &modem_status);
-	ftdi_set_latency_timer(&ftdi, 0x77);
-
-I can see how FTDI could have reasonably implemented a sort of safety lock on
-their EEPROM write operations, allowing them only if a special unlock sequence
-has been given - but it completely baffles me why they are doing some sort of
-OTP emulation in the absence of the right magic sequence, as opposed to
-disabling EEPROM writes altogether.  It is worth noting that this magic sequence
-is NOT needed for programming external EEPROMs behind FT2232x chips - were FTDI
-folks being deliberately malicious in designing their FT232R chip to simulate
-appearance of being bricked when it is programmed with older (or third-party)
-software tools that don't know the new magic sequence?  Who knows...
+https://www.freecalypso.org/hg/fc-usbser-tools/file/tip/doc/FT232R-notes