Project Logs

Collapse

• USB-gadget -> IDE?

  Eric Hertz • 11/25/2018 at 18:30 • 0 comments

  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.

• Wifi, of course...

  Eric Hertz • 11/25/2018 at 17:36 • 0 comments

  I still prefer the IDE approach, since most of the systems I'd want to do this to are far too old for built-in WiFi... Also, the original/host system would have to have a boot-drive and hardware drivers... and an OS with GUI properly configured, and so-forth... (and have you ever tried to get a random wifi card working in a "universal boot"? Oh yeah, and most wifi cards I've run into can't be hotspots, but I'm old)... and now we're far from the drop-in-and-go system-upgrade I've been visualizing.

  BUT, did I mention I'm old? (and so are my systems).

  This one, #Pi in my laptop uses WiFi... And, frankly, that does the job nicely in newer systems. VNC, so-forth. I hadn't caught that the Pi and laptop were actually talkin', since there were no wires. How obvious could it be?

  Nicely-done.

  And, realistically, we are nearing (or even within?) the era where a small SBC might be more powerful than a lappy with WiFi, or bootable USB, and so-forth.

  (BTW, I think there's a link in the first log where a Pi was put in USB-gadget-mode as a bootable hard-disk.)

• SATA, SPI, and other ramblings

  Eric Hertz • 11/24/2018 at 18:29 • 0 comments

  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...

  Read more »

• "Project Ideas"

  Eric Hertz • 11/24/2018 at 17:28 • 0 comments

  As of today, this is the related (and soon to be relocated) portion originally from https://hackaday.io/page/1036-project-ideas

  This is written latest-to-oldest... oy.

  [SMARTER] IDE Drive-replacement(Revisited, see below) (2-5-17)

  @Starhawk has informed me of EOMA-68... a PCMCIA-form-factor for SBC's... might be something in there... hmmm... (10-20-17)

  Ooooh: Check out @AlanH's #NetPi-IDE! (3-30-17)

  And noted on the HaD blog (4-14-17)

  AlanH uses a RasPi as an IDE hard drive and other hardware (was networking one?), interfaced via IDE, to a PCjr, no less. Using an FPGA to convert from the Pi's SPI to IDE, and some custom DOS-based drivers, not much different from the ideas laid-out below...

  @mincepi is at it again with the inspiration for IDE-Drive replacement (see his#laptop2pi).

  (See also my earlier ramblings on the matter, below, "RAM-On-IDE" (9-1-15)).

  So, say you've got an old [486-era] laptop with an IDE hard disk. Not much to do with a 486, these days... And, some of those devices had some pretty hefty limitations, being that they weren't *intended* to be upgraded (e.g. my Toshiba T200's BIOS only supported hard disks up to ~128MB, and RAM upgrades are Small and Rare... Maybe 16MB.).

  An earlier idea was to install "RAM" (actual real RAM) on a device which looks like an IDE drive. This real RAM could, essentially, look like a swap-partition to the computer, but without the drawbacks of slow physical access-time of hard disks of the era, nor limited-writes of e.g. today's Compact-Flash cards which can [almost easily] be dropped-in as hard-disks in IDE-based systems.

  The problem isn't so much to *use* the 486, but to use the *machine*... the display, battery, UI, etc. (Or for e.g. my Pentium150 laptop, the keyboard, sound-card, etc.)

  So, why not take the custom IDE "device" a step-further... Install a friggin' Single-Board Computer in its place. Use *that* as the brains, and use the rest of the system for what it's still useful for, its hardware.

  (Ironic, maybe, that this goal is somewhat similar in intent, but approached from a different direction, to #Improbable AVR -> 8088 substitution for PC/XT)

  Not sure, exactly, how to do this...

  Mincepi's method is to use a Raspberry Pi as the brains in a system which can boot from (and has) USB. The Pi looks like a USB-attached hard-disk, which the system boots from, into what I imagine is a pretty limited OS that basically doesn't have to have anything more than some drivers and some sort of remote-desktop to the much more powerful single-board-computer. (Via USB this is somewhat more straightforward, SBC's can run in "gadget" mode, which can make them appear as USB hard-disks, USB ethernet-adapters, and more).

  So, how could this be done via IDE (on a system that doesn't have USB)?

  Essentially the "Master" drive (since many laptop-systems of the era either A: don't support a slave, or B: have a CD-drive attached) would have to handle *everything*... We're talking:

  It has to be bootable by the original system (486, pentium... maybe 386? What about really old Macs? Hmmm...), provide the necessary software to communicate with the SBC, and provide the necessary drivers to interact with its real hardware.

  It might have to provide BIOS-overlay support to the system, to support this imaginary hard-disk that will likely appear larger than 128MB.

  It has to provide some means of communicating U/I info to that 486 (over IDE!).

  It may even need to have support for things like communicating sound-events and other interrupt/timing-specific stuff...?

  (again, all over IDE, which wasn't designed with this sort of thing in mind).

  (Unlike my earlier ramblings on the matter, this system probably wouldn't have to provide a "swap" partition to physical-RAM attached via IDE. Though could if necessary implement such a thing via the SBC's RAM).

  So, I'm imagining a few different 'partitions'. One might be only as large as a frame-buffer,...

  Read more »

View all 4 project logs