I've considered this before, and I think we've discussed it at length.
Personally I'm not interested in doing the project unless I can come up
with a way to access the disk at the nibblized level to handle copy
protection, and it remains to be seen whether or not this is feasible
over USB, where the timing is far from being deterministic. The
question of whether it is deterministic enough is probably only
answerable through experimentation - something I'm not keen on.
The answer is to not rely on USB timing to be accurate and buffer the
data. Not necessarily a full 140kb, but maybe enough for a couple of
sectors of data so there's always a sector in the buffer.
The usb device portion would feed a command buffer and allow you to
monitor the command queue, so to speak, as well as pop off any output
from the drive itself (read sectors, errors). At that point it's up to
a controller to communicate with the disk, pop commands off the command
stack, and push output to the output stack. This would be feasible,
imho, because you're usually only working with full disk images. So
there's no need to communicate back to the host all the time, you get
the right timing, and reduce the level of error. The only killer would
be if you encountered an I/O error, for which an error should be dumped
into the output stack and halt.
PC <--> [USB Host] --> [Command Stack ] --> Controller <--> Disk II
<-- [ Output Stack ] <--/
Of course, it sounds all nice and fluffy -- but I have no idea how to
implement a USB Host or a controller in hardware. I suppose that's why
the developer in me prefers to use a real apple. :-)