<It's not that hard to replace a non-standard data separator with a 9216 <or a homebrew design, or.... Or jumper the pins of the 9216 for the correct mode. Since the 9216 is only for the read side you still have to tweek the write and precomp logic. The 9229 does both sides (read and write). It's pretty trivial to do this even with SSI TTL. <But you can only do this if you have access to the signals you mentioned. <With the all-on-one-chip devices that are common on PC I/O cards you <don't. And since PCs always use double-density disks, a lot of these <chips were not properly tested in SD (FM) mode. True, you already have the resources. This is a matter I have experince with over 19 years, 19 of wich are with the 765 and heirs as I started as a product engineer with NEC before the 765 was rolled out. What I have for DOCs is, uhm, better than average. The last byte mashed in the UMC is also common to most 765s and is related to DMA read/write timing such that if you delay the DMA request by about 1-3uS (several FDD bit times) in FM mode it should work fine. In FM the internal clocks are slower and the transfers internally take longer. Some of the super parts compensate for this or there luck. It's part of the reason why when you write a command sequence or read status there can be a significant delay (12us for the 765A) as the clock runs the internal processors (one for parallel ops and one for the serial ops). OH in FM mode DTL byte in the command is significant (for MFM is filler). Allison