Recording flux transitions (just like a real disk drive) takes about 25Kb/track for a 300rpm drive. No attempt is made to decode the data. Otherwise, you'd have to make assumptions about how the controller encoded the data, bit order, etc.
I guess what I was envisioning wasn't actually a flux transition device, more along the lines of a conventional "higher level" floppy emulator. So strictly speaking it'd only have to store the actual sector data. (Looking in the Northstar manual a double density sector is 32 bytes of zeros, a sync character, 512 bytes of data, and a check character. Everything but the data itself looks not too hard to synthesize on the fly.)
Floppy drives with a 3ms step rate were available as early as the days of the North Star DD controller, so 3ms needs to be the design target. Adding heat settle time of 15ms after a step, by which time you should be spitting out the correct data, is a reasonable design target. No other read delays can be assumed.
I guess I can't find anything in the disk controller hardware manual that says anything about stepping time. Maybe that's up to the CP/M driver? I did find some assembly code for the boot PROM, and just scanning it... I find a part that says "Step out once, and delay (for 2 sector times) while it steps". Two sector times would be roughly (200ms/10) * 2, aka 40ms? My North Star has SA400s in it which would need that much time, was it normal for people to hack faster times into the CP/M driver?
Most hard sector controllers have a sector register that is incremented by the hard sector pulses and is sync'd by the index pulse. Sync is not lost due to a stepping operation. Data would need to be retrieved starting at the next expected sector and then wrap back around.
So that appears to be true. The controller has a special status bit that's lit up when it passes the "Index" mark so it does care where the "start" of the disk is, but it would certainly be possible, in theory, for CP/M to request a sector on the next track within the same rotation after the stepping pulse.
The really critical thing it seems to care about it, yes, it can *never* miss a sector pulse or have it delayed. If I'm reading the manual correctly it starts an aggressive timeout after the index pulse waiting for the first sector pulse and you'll get a hardware error if it doesn't get it and subsequent pulses on schedule. Whatever else a simulator for this does it has to keep spitting out pulses constantly.
The kicker in all of this is writes. With a USB stick or SD card, the application has to tolerate random latency periods of 200ms by spec, easily over 500ms in reality. If a read is needed at one of these times, you're stuck. Even with a background thread doing writes, the high-priority read would still have to wait on the hardware to finish its write operation and the read has then failed.
In the "GreaseWeazle" application the Blue Pill acts like a USB Full Speed *peripheral* to a host, that's what I was thinking with this idea. IE, the disk image(s) in use would be resident in RAM on whatever PC (it could be a raspberry Pi or whatever) that's driving the Blue Pill. So as long as whatever OS you're running there has adequate timeslice resolution latency should be possible to keep down to a few milliseconds. Or that's the thought, anyway.
I definitely agree with you that the timing constraints imposed by the inability to "fake" sector boundaries on a hard sector disk make directly running from flash (whether USB or SD) *really hard* and would probably pretty much necessitate onboard RAM in a stand-alone device.
Maybe the reverse-greaseweazle idea isn't worth pursuing given how easy it is to find ARM-based devices with a few MB of RAM onboard for a few bucks. (Bare-metal Raspberry Pi Zero would be an obvious possibility.) I just happened to have a couple Blue Pills lying around that I bought for a different project I haven't gotten to yet.