• Please review our updated Terms and Rules here

LPT to IDE interface

Ruud

Veteran Member
Joined
Nov 30, 2009
Messages
1,411
Location
Heerlen, NL
I just ran into this thread, mentioning a backpack hard drive. I know about external CD drives that can be connected to the LPT port but never heard of ones with HDDs. A quick search let me to a Moldavian site but I think they don't have it anymore: "Nu este in stock". I still emailed them, you never know. Not other results.

My question: is there anyone knowing about a LPT-to-IDE project with schematics, and most important, software? I could dream up a schematic myself, I could use the one of XT-IDE as a base. But without software the hardware would be a dead duck. And writing software just takes time. Even when using the Universal BIOS for XT-IDE as base.

Any pointers to a device like the Moldavian one are welcome as well.

Thank you very much in advance!
 
Before the rise of USB, these were very common. I remember using ones with big 3.5" HDDs inside back in the day. I should still have such an enclosure somewhere. I'm still using its power-brick to this day. :D

May I ask what you are after? If you just need to add storage to an old PC that has parallel only, a Zip100/250 does that for you.

But just for the record: the ones for CD drives work with hard disk drives as well. Not sure about "Backpack", as that brand is completely unknown to me, but you could buy empty enclosures that would take either a CD-ROM or a HDD. Both would work, as it's just IDE bridged to parallel. Software might be very hard to find these days, of course, as most of that stuff was no-name gear from Taiwan.
 
In fact I do have a Shuttle CDS-4X-P , have the software for it, :) , and I used it in the past to update my systems that hadn't XT-IDE yet. Those systems that have XT-IDE also have a CF connector that I use to copy files. But I and some friends also have some systems that don't, to remain original. And burning CDs every time I need to update such a system is a bit of waist. I also use UFO, a LapLink equivalent, but that needs two PCs.. Therefore this idea.

An update: I found this piece of software to handle various FAT types. That makes it easy to write my own driver. And a little cheater: I have a few LPT cards that are able to run in bi-directional mode. That will speed things up.

And just popped up: what about using an Arduino Mega + SD card? There is enough software around that handles the SD card. I only have to write a program that exchanges data with the Arduino. (FYI: why Arduino? It supports 5V interfaces, like LPT. The RasPi only does 3.3V.)
And this lead to another thought: how fast will the LPT-to-IDE interface be? I was thinking about one without a MPU/CPU, thus the LPT ports sets some registers and then reads the result. I'm afraid that will be even slower than UFO.

You see, things aren't as easy as they appear, still things to think about.
 
Most external hard drives were SCSI before USB, for good reason. Standard parallel port tops out around 150 KB/s.
 
ECP is almost as fast as SCSI-1 and twice the speed of USB1. The major problem with using the parallel port for storage is that it was very difficult to have multiple storage devices connected.
 
ECP/EPP weren't in the standard until 1994. If you wanted a fast external hard drive, it was SCSI.
 
My vague memory of the Backpack CD and hard drives is that there's a port replicator (I think that's the word) for an IDE/PATA interface and MS's own proprietary LPT protocol. Driven with an 8051 MCU, and some SRAM. Very similar to the BP floppy, but the floppy also includes an FDC as well.

You could certainly do the job with a STM32F4 MCU. I don't do Arduino, so I couldn't say. The F4 (and most of the F7/H7) line has 5V tolerant GPIO, so no problem there.
 
Before the rise of USB, these were very common. I remember using ones with big 3.5" HDDs inside back in the day. I should still have such an enclosure somewhere.
Do you need special software to run them in DOS? If yes, do you still have it / know where to find it?

May I ask what you are after? If you just need to add storage to an old PC that has parallel only, a Zip100/250 does that for you.
Some years ago, I've been looking for a generic LPT-to-IDE solution and couldn't find anything. I've got many IDE and ATAPI drives, but no ZIP drives. A solution would be interesting, especially if driver software is readily available.

Both would work, as it's just IDE bridged to parallel. Software might be very hard to find these days, of course, as most of that stuff was no-name gear from Taiwan.
Both (proper) IDE and ATAPI require a 16-bit wide interface and a few address bits, while the parallel port is only 8-bit wide. So some translation is necessary, and if it was common back in the days, following their approach may be much easier than cooking up something on my own.
 
Hence, my observation of "sufficient 5V GPIOs" on an MCU. 16+3 port+maybe 3 signaling just to talk to the drive.

But gosh, anything going through a parallel port--and legacy demands "nibble mode" if you don't have a later EPP/ECP model. So not fast in any case--you can't do DMA in legacy mode.

If what you're interested in is what's on the drive, why not an MCU driving a USB interface? USB MSC presents the drive as an LBA-addressed SCSI command device.

Get the drive data to a USB-equipped PC and move it where you'd like it.
 
May I ask what you are after? If you just need to add storage to an old PC that has parallel only, a Zip100/250 does that for you.
Oops, forgot to answer that one: I had two, both died. So confidence is zero. And there are enough HDD replacements around.
 
But gosh, anything going through a parallel port--and legacy demands "nibble mode" if you don't have a later EPP/ECP model.
My main targets are XT and AT (compatible) computers anyway. And then mainly laptops/portables like my Sharp and Ericson.

So not fast in any case--you can't do DMA in legacy mode.

If what you're interested in is what's on the drive, why not an MCU driving a USB interface? USB MSC presents the drive as an LBA-addressed SCSI command device.

Get the drive data to a USB-equipped PC and move it where you'd like it.
So if I understand correctly: LPT <-> MCU <-> USB. But why would you present it as an LBA-addressed SCSI command device? If you want to present the attached drive as a drive, I can understand. I myself was thinking of a Commander-like program where you can exchange files. Although I would prefer to see it as one or multiple drives as well. But still have no real idea how to program it.
 
So if I understand correctly: LPT <-> MCU <-> USB. But why would you present it as an LBA-addressed SCSI command device?
Because that's the default for USB Mass Storage Devices. If you want to define your own device type and protocol, go right ahead, but then be prepared to write host-side drivers in addition.
If you dig into the USB MSC/MSD details, you'll find that no matter what the physical device is, it's always presented as something obeying the SCSI command set. I do this, for instance when addressing SD cards via USB, even though they're pretty far from being SCSI.
Even USB floppy drives work this way.

 
So if I understand correctly: LPT <-> MCU <-> USB. But why would you present it as an LBA-addressed SCSI command device?
He did not mean that one should expose the thing as an LBA-addressed SCSI device, but that the USB-layer always does it that way.

Which makes me wonder... are there SCSI enclosures for parallel ports? And if so, did they come with ASPI drivers? Because that would allow the DOS side to rely on the generic ASPIDISK.SYS, ASPICD.SYS and ASPITAPE.SYS drivers, while the other end just needs to handle the LPT <-> USB communication layer without much translation.

Hence, my observation of "sufficient 5V GPIOs" on an MCU. 16+3 port+maybe 3 signaling just to talk to the drive.
My thoughts exactly, but is there a standard protocol for exposing IDE devices, or did every vendor do their own stuff?
 
Which makes me wonder... are there SCSI enclosures for parallel ports? And if so, did they come with ASPI drivers? Because that would allow the DOS side to rely on the generic ASPIDISK.SYS, ASPICD.SYS and ASPITAPE.SYS drivers, while the other end just needs to handle the LPT <-> USB communication layer without much translation.
Sure, at least sort-of. Consider the parallel-port interface removable-hard drives; Zip, Sparq, etc. Those certainly exposed an ASPI API.
 
SCSI might be better anyway, since there are devices that emulate scsi drives now.
 
Right, there are lots of SCSI to SD/CF/IDE adapters. Plug the two together. It'll be slow, but should work...
 
Back
Top