Recommendations for Drive Docks

[atakioki]

I'm struggling with a menagerie of inexpensive but unreliable SATA/PATA combination docks. Attaching KGBs to them only gives me a usable drive about 50% of the time, and I'm worried about binning a good drive because the dock can't deal with the drive for whatever reason. I would prefer to use something external so I'm not constantly opening fragile old machines to get at their built-in controllers, or leaving them operating with their cases open for my children to commit some accidental tragedy to their exposed guts.

I remember the purple wiebetechs being the gold standard two lifetimes ago when I was a tech. I'm inclined to pick one up used off the hellsite at this point, but was curious if anyone here had a good experience with any of the more modern docks.

Would also be interested in any software recommendations for pulling data from disks on the brink.

 

[GiGaBiTe]

What's a KGB? Komitet gosudarstvennoy bezopasnosti?

External drive docks are always going to be flaky because they're not really full disk controllers. IDE USB solutions are even worse, the controllers are really dumb and tend to have problems with old drives, and may not see CHS drives at all. If you want to use a real SATA controller externally, you can just get a motherboard with eSATA and use an external power brick. This will allow you to keep your systems closed.

The OS used also has a large say in how well these devices work. Windows disk subsystem is VERY stupid and it causes a lot of problems with these devices. Older versions of Windows (like XP, 2000 or 98SE) behave a bit better and tend to work with older formats better, assuming drivers are available for them. Linux will give the best compatibility, as it can read most any disk format. And even if it can't, you can just use DD to do a block copy of the device to a file, and DD the file back to another drive.

If you're doing critical data recovery, I'd recommend something like a PC-3000. Expensive, but it will give you the best success of recovering data with the small amount of time the drive may continue working.

 

[atakioki]

KGB = Known Good Board

Thanks for the affirmation, I'll probably do as you say and pursue the PCIe cards with external power on Linux using ddrescue.

While I was researching I stumbled across greaseweazle, which looks like a really cool tool for floppy recovery. Just need something for SCSI and Optical media and I'll have a complete toolkit: )

 

[MiaM]

Another potential problem with testing disks:
My tiny experience re this is an old external PATA disk enclosure that seems to have a marginal/weak PSU, that might have resulted in me binning a disk at least once. I put a large label on it that the PSU isn't great, and since then I'm always using a separate PSU.

I agree with GiGaBiTe that anything made after disks reached a certain size has a high risk of not supporting CHS.

The IDE/ATA interface is technically really easy to implement a controller for. You just need a bunch of I/O pins on a microcontroller. Unfortunately the perhaps most readily available ready made PCB with a microcontorller, the Arduino Uno, seems to not have enough pins and would need some additional chip(s) to interface an IDE/ATA device directly. And of course it would likely be slower than any dedicated hardware, but might be fast enough for those disks that a newer USB adapter / external disk enclosure won't work with.

SCSI isn't that hard either, but it needs even more pins even though the transfers are 8 bit rather than the 16 bit of IDE/ATA.

 

[the3dfxdude]

I got one from star tech a long time ago, USB adapter, and it has worked flawlessly except on one, 35 year old western digital IDE drive.

I found another dock at a yard sale, probably no name USB from amazon for $2. Eventually tried it and it didn't work.

 

[GiGaBiTe]

ust need something for SCSI and Optical media and I'll have a complete toolkit: )

If you don't care about speed, I'd recommend something like an AHA-2940UW. It can do both single ended and wide SCSI at the same time. With adapters, you can use most any SCSI drive up to Ultra320 spec. If you can get the correct SCSI cable, you can do external drives. You'd just need something to adapt from that cable to whatever your drive uses.

SCSI isn't that hard either, but it needs even more pins even though the transfers are 8 bit rather than the 16 bit of IDE/ATA.

Depends on the SCSI standard. Old SE (Single End) devices are 8 bit, but the later wide and ultra wide SCSI standards are 16 bits. Thankfully SCSI is mostly forward and backwards compatible, so you can do silly things like have an Ultra320 SCA-80 drive on a pile of adapters and have it work on an ancient 8 bit SE bus at much reduced speeds. I've done silly things like have a 15k RPM Seagate barracuda Ultra320 drive on a Quadra 605. It has to be externally powered though, those drives draw too much current for the PSU inside those pizza box macs.

These can be used externally, but it's getting hard to find the cables and enclosures these days for them. I picked up a pile of SCSI stuff in the early 2000s when it was being dumped for pennies when everyone was migrating to SATA and SAS drives.

 

[MiaM]

Yeah, I've been toying with the idea of connecting an 18GB latest-what-ever-ultra-wide-differential-whatnot SCSI disk to one of my Amigas with the old regular 8-bit 50-pin IDC SCSI interface.

I don't know what value disks like this have, but worst case if they aren't worth much and if cables/adapters are expensive you could solder directly to the PCB of the drive.

 

[GiGaBiTe]

Just remember that you most likely won't be able to utilize the full capacity of the drive. I'd also recommend powering the drive externally, because the later higher spindle speed SCSI drives can draw a few amps of current across both +5v and +12v rails.

In Mac land, anything prior to Mac OS 8.1 use HFS and have a 2 GB partition limit. HFS+ in 8.1 allowed up to 4 GB partitions, but I don't think they are bootable on 68k Macs. Not that I'd recommend having partitions that large regardless due to the extremely fragile nature of the operating system. All it takes is one misbehaving application to crash the system to cause massive data corruption.

I found a guaranteed way to force it to happen some years back. Get a 68000 based Macintosh, like a Mac SE and install System 7.1. Then proceed to try and run the game Beyond Dark Castle. It will cause immediate stack smashing, overwrite the system heap, start writing garbage to the screen frame buffer (resulting in the screen going corrupt) and then eventually start writing garbage over the hard drive partition table. Eventually the system will reboot to a blinking question mark, because the hard drive has been completely wiped.

The cause of the supremely errant behavior is because Beyond Dark Castle is a 24 bit application and System 7.1 is a hybrid 24/32 bit OS. Due to the extremely limited memory on the original 68000 macs, programmers started using the upper 8 bits of the address as status flags. This was fine on the 68000, because they were ignored. But on System 7 and later 68020/030/040 processors, those flags were treated as a real address and the CPU goes off into lala land.

 

[MiaM]

yeah, with the file system and hard disk driver from Commodore there is a 4GB limit (32bit, for some reason the API for disk drives addresses each byte, even though afaik all drivers just ignore the lowest bits and thus only reads at 512 byte granularity. There are third party software that solves this, and since the API for disk drives allow raw SCSI commands these third party solutions work with all SCSI controllers (and there were so few IDE controllers that it's easy to support them too).

The main two downsides of having large disks on an Amiga is that if the dirty bit is set, i.e. due to a crash or three finger salute while a file is open for writing, it will do a validate where it linearly reads all of a partition, and that takes ages for a really large partition. Meanwhile if you split a large disk into more reasonably sized partitions, this validation runs at the same time for all partitions that had the dirty bet set when booting, which is terrible. The work around is to either only use one partition as a "work" area where files are open for writing, or in the boot menu disable all but one partition with the dirty bit set, let that validate, rinse and repeat for all partitions that might have the drity bit set. Fortunately a simple command lists all partitions that are being validated, and you can run that (and the general boot process also runs) while validating takes place, so you can at least first check which partitions need to be disabled rather than having to "blindly" try out which to use.

Re PSU: In general Amigas either had a decent sized PSU or there were no space for a (SCSI) hard disk internally anyways. There were some external hard disk controllers for the A500 that could use the A500's PSU but the best practice was for hard disk controllers (and thus their disks) to have their own PSU. (The first A500 PSU only outputs 2.5A at 5V and 1A at 12V (and 0.1A at -12V), but interestingly that seems to be the most reliable one to power a later A1200 with a 50MHz 030 accelerator card and a 3.5" IDE hard disk. You kind of have to let the PSU hang in the air with one of it's wires tied to something rather than let it lay on the floor or desk in order to ensure air circulation Poor L296 secondary switch regulator, and poor heavy mains transformer )