It's hokey and may not even exist, but one thought is if there's such thing as a *reverse* USB-IDE adapter... Then @mincepi 's USB-gadget idea (mentioned in the first log) could work in systems like these.

That's a tall order... Search-fu returns nada. The IDE-converter would essentially have to be a USB host, which generally means it needs a computer behind it... but that wouldn't be the computer with the IDE connection, since IDE doesn't speak USB. And that wouldn't be the USB-attached SBC-gadget, either, because it's not the host, it's a device.

So, such a device, IDE <- USB, would be unusual, and essentially require an onboard computer inbetween.

I thought maybe such thing exists... e.g. there's a floppy-drive emulator that can use USB thumb drives... Essentially the same thing but with a floppy-drive connector rather'n IDE... But, that has a comparatively large market of vintage (real vintage) comouter-enthusiasts. 

Though, this device, the converter, anyhow, could've seen a similar market in, e.g. test equipment. Though, there, I think it relatively-common to replace hard-disks with Compact-Flash cards which already speak IDE.

(And makes me wonder why the floppy-emulator speaks the rather-complicated USB-host, when IDE/CF-host is doable via an 8bit uC! PROPs to its designer for such an undertaking!)

OK, so now we're back to an FPGA as the IDE-device interface, forgoing USB entirely. Props to @AlanH for #NetPi-IDE in achieving that! 

Actually, maybe that is *the* solution. Not too fond of FPGAs... "black boxes"... I should maybe get over that.

Alternatives in the IDE<-USB realm...?

I think I recall a PIC32 with a "Parallel Master Port" that could be put into slave mode... Also, I think I recall there being a USB-Host peripheral... Yet another "black box",  but, if acheivable, would make IDE<-USB possible for other things, as well, like the aforementioned test-equipment.

Dual-port memory was also a thought, this would go along the lines of an FPGA, no USB involved... And, frankly, only slightly less black-boxy, as it's not particularly common.

The IDE interface is quite a bit like a typical memory-interface... 16 bidir data bits, a few "address" bits, Chip-select, Read/Write... It could *almost* be directly-interfaced to an SRAM. There are a few other signals, some logic required. And without dual-port, there'd need to be arbitration circuitry (latches, buffers...) to allow the device to read/write that SRAM only when the host isn't... and to stop immediately when the host does... A lotta logic, back to an FPGA.