Hehe, it still took some dozens of hours of debugging all the minor requirements of the flags and behavior of the WD1772
Sure - the details are always what keeps you from that magical 100%-mark of compatibility. I didn't expect the ST to be any different from the Commodore computers that we've done so far.
The file format which holds the MFM stuff ("flux") is the SCP - do you know it's average size is 20-30MB? Doesn't fit into the SDRAM, and I'm not sure if streaming from the SD Card can give adequate latency for copy-protections.
I am not looking for the flux level, as that really produces too much data (Catweasel produces about 50k of data for every track of a DD-disk, so around 8MBytes per DD-disk). Instead, I am thinking of storing the actual MFM bits, which is about twice as much as the decoded bits. In addition to that, I'd divide the track into 400 (or maybe 512 for ease of addressing) zones for which you can store the bit rate of the block in question.
This should be sufficient for most (if not all) copy protections, as you can create the "weak bits" for any sequence of "too many 0s in a row" with some additional code. You can of course go complicated and store 5 different reads of every track in order to record what the actual floppy made out of those weak bits, but that's depending on the floppy itself and will vary from real machine to real machine. So why bother? Just add a probability of inserting a 1, and increase that with every 0 in the stream (and of course reset that probability to 0 for every "1" in the source stream). Let a noise generator add some jitter to that inserted-1, and you should have sufficiently-different data on every read.
Let's say we're on 500kBits/s for DD disks, this means you have 100kBits of raw MFM data per track and side (given 5 rotations per second=300 RPM), resulting in a very managable 12.5k/track or 2MBytes per image. Adding 512 bytes of timing information per track only adds 80k, which is absolutely within the limits of what both Chameleon and MiST can handle. Not sure how big your 1772 core is ATM, but it may be worth integrating that if you create a microcode engine, so the total size comes down.