Update at the bottom...

------

While this particular project is mostly focussed on *really* old systems, e.g. 386-486, maybe pentium, there may be other uses in in-the-now-ish systems such as those with SATA drives...

If nothing else, it got me thinking about the SBC->IDE connection circuitry.

SATA drives can be connected to IDE hosts, and vice-versa, through converter boards which are pretty cheap.

Connecting e.g. an RPi, as a "drive," directly to an SATA host would be... improbable... via its GPIOs. (differential signalling, timing, etc.)

OTOH, later-model IDE controllers were made to be backwards-compatible with *really old* and thus *really slow* drives. An ATA-66 controller could still communicate with a 120MB drive from a decade prior, communicating at something more like ATA-5(MHz).

That means, the newer controller had to be able to slow down its handshaking signals *dramatically* to even detect such a drive.

Now, I can't vouch for SATA converters, but I've not seen them *specify* only working with ATA-66, ATA-133, etc. So, despite the *extremely fast* bit-rate of SATA, there's probably quite a bit of room for a really slow transaction-rate. As I recall, IDE limits that stuff with strobes and acknowledgements... And... besides the actual communication-rate, I think I also recall that e.g. a data-read request is actually not expected to be responded-to until that data is ready, which can take quite some time, what with spinning and seeking.

What am I getting at?

RPis have a lot of GPIOs, but IDE would use most of them, and they're hard to precisely time... ATA-66 might be asking a lot. Besides that, it's nice to have GPIO for other things...

So, maybe, it might be plausible to communicate with an IDE host (or SATA converter) via a handful of GPIO pins and a bunch of latches. (Maybe even via SPI and shiftregs?)

----

Thoughts inspired by:

https://hackaday.com/2018/11/24/the-best-laptop-gets-even-better

... A pretty sweet CD-drive-bay repurposing with an SBC-inside.

-----

Update:

Some randomish delving into the concept:

First: Long-ago, as I recall, it was determined that Pi GPIOs can be toggled up to 50MHz... with a lot of work.

That may sound fast, especially considering early IDE drives' transactions maxed-out at only 5MHz. 

But think about all that has to happen in a simple register-read via IDE. I'll simplify: 

1) First the host sends an address-request. 

2) The device must then acknowledge.

3) The device must access that register.

4) The host pulls the read or write pin active

5) The device must either output the data or read it.

6) The host deactivates the read/write pin.

7) The device must remove data from the bus (if reading)

So, a read-procedure takes something like 10 GPIO transactions... and now the 50MHz GPIO toggling has dropped to 5MHz transactions.

Doable, maybe.

Now... This also applies to our SPI idea...

I mistakenly recalled IDE having some sort of indicator from the drive stating that it was ready to respond. In fact, the only such indicator is IOCS16-, which indicates that the request was received. And, according to my source, that *must* come through within a maximum of 90ns.

Meanwhile, I also looked up the SPI rate, which tops out at 150MHz... 16 bits (and, actually, I count 26 inputs, 21 outputs) would bring that down to 10M-'bus'-changes... and now we're far slower than even an early IDE drive, and 90ns is seriously pushing it. 

Nevermind, of course, those kinda speeds in discrete shift-regs would be hard to find, and would have to start pondering things like transmission-lines.

This wasn't about speed... it's about meeting the timing-specs a host might require... using as few pins as possible... And it looks dubious.

There was a link, I think in the last log, where someone threw an FPGA inbetween. And now I see why!

An alternative, maybe, would be an SRAM (dual-port?). Might be doable.

Hmmm.... back to the drawing board!

Here's what I came up with before... dun think it'll do. Except maybe to interface that SRAM.