On 26 Nov 2008 at 21:00, Lance Lyon wrote: Other way 'round for the ST. The ST had a SCSI-like interface (ACSI) and there were adapters to allow use of MFM drives for it. On my old 540ST, I constructed one using a stock OMTI bridge and some added logic to adapt the SCSI signals to ACSI. Cheers, Chuck

Fred Cisin wrote: Isn't that the other way around, though: IDE controller -> bridge -> MFM drive? The previous poster's saying* they're doing this the other way around: MFM controller -> bridge -> IDE drive, which is a different kettle of fish entirely. * unless they've misinterpreted Michel (or I have!), who seems to want a way of connecting a SCSI disk to an MFM disk controller... The prospect of using a more modern (whether it be SCSI or IDE) opens up useful prospects for the preservation of vintage machine where ST506/412 drives are getting pretty long in the tooth, now. I believe there are only a couple of commercial solutions out there (serious $$$), and it's a problem that the hobbyist movement hasn't cracked (except on paper) yet. cheers Jules

Oliver Lehmann wrote: While it wouldn't be universal... at least for certain platforms, wouldn't it be simpler to replace the MFM controller chip(s) with a circuit that simply accessed an IDE or SCSI disk instead ? i.e. replacing the MFM chip in an AT&T 3B1 with a daughter board that then had a 50 pin IDC header on it for connecting to a SCSI disk (or disks) ? How hard would that problem be ? It wouldn't be a universal application... would only work effectively with systems with socketed (or at least through hole) chips... but I'd think it would be much simpler, no ? Anyone ever attempt something like that ? -- Curt

Quoting Oliver Lehmann <lehmann at ans-netz.de>: What we are doing is to replace more than one drive, with the same logic. So few spare GBytes ar enot that bad. Takes time, time, time ;-)

On Wed, 26 Nov 2008, Jules Richardson wrote: That doesn't make sense. IDE stands for Integrated Drive Electronics, which means that the controller is located on the drive. Therefore IDE controller cards don't exist, and you can't bride IDE to an ST-412 interface type drive. And the (original) IDE controller is just a plain old WD1003 integrated on the drive PCB. "MFM" and "IDE" are register compatible, the programming is the same, otherwise you would need an extra extension BIOS for your IDE drives. And an IDE HBA can be built with just an address decoder and some drivers/receivers (usually 74LS245). Christian

When this was done, the term "controller" migrated; it still (usually) refers to the hardware that goes with the machine rather than the drive. That is, the glue between the ISA/PCI/whatever bus and the 40-conductor cable (more recently, 40 conductors with 40 more conductors used as shields) to the drive (including whatever electronics may be onboard). So, I think it does make sense. I'm sure this would come as quite a surprise to the people using them. I can't see why not. Bulding glue logic between two interfaces is, I think, always possible (except in a few cases where the technology isn't yet up to, say, handling the necessary data rates); it's just a question of how complicated it'll be. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Thu, 27 Nov 2008, Tony Duell wrote: Right, that's what I've called an IDE HBA (host-bus-adapter). Ehm, that *is* a WD1003, because the so-called IDE interface really is a simplified ISA interface for the AT-Bus. That is why it is (more correctly) called AT-A (or ATA) = AT-Attachment. AT here means IBM AT Bus. Right. Well I prefer to deny the existence of a dedicated IDE bus, but IDE interface is OK since the extinction of the AT-Bus. And since we're at it, I'd like to point out that SCSI drives are IDE drives, too, but noone calls them so ;-) Oh, what a world, you buy ATA drives (or even SATA) but don't have an AT bus any more. Instead you have IDE interfaces on the PCI bus (mostly integrated into the MB chipset). But SATA is more like SCSI when compared with SAS... Christian

On Nov 28, 2008, at 4:23 PM, Sridhar Ayengar wrote: Well sorta...the address, data, and control buses of an 8088! ;) (damn IDE/ATA is such a friggin' nasty kludge) -Dave -- Dave McGuire Port Charlotte, FL

On 28 Nov 2008 at 11:37, Chris M wrote: Given that modern IDE drives are designed for very different data rates (and a host of other things), even if one could tap into the read/write circuitry directly (with high integration, I'm not sure that this is even possible) there would be no assurance that it would work. Cheers, Chuck

On 3 Dec 2008 at 16:36, Chris M wrote: Condider that on modern drives, R/W circuitry isn't all that simple. You might have GMR heads, certainly have PRML read processing. The other concern is that the heads and associated circuitry are likely optimized for the denisty and recording mode. You're in analog country, buckaroo, and things aren't digitally simple any more. Cheers, Chuck

Chris M wrote: ISTR there's still quite a bit of logic on a ST506/412 drive (I think the manual's kicking around on Bitsavers and contains schematics) - and I'd assume that the analogue circuitry has to be pretty closely matched the the heads used by the HDA (and that the heads on a more modern IDE drive have different characteristics to those on an older ST506/412 drive) Heh - it's more like taking a hippo apart and then adding the bits which turn it into an elephant, though... cheers Jules

There's a fair amount of circuitry, but it's quite simple in fuction, and splits into several separate blocks. It's basically similar to a floppy dirve in that you have : Spindle motor (get the disk turning at the right speed -- unlike a 5.25"/3.5"/3" floppy drive, a hard disk turns all the timem, there's no motor_on/ signal no the interface connector) Head positon. On older/simpler drives this is a stepper motor, later ones ahve a voice coil postioner and have conisderably more complex circuitry. Often, even in the stepper motor positioned drives this is based round a microcontroller Index pulse. On the original ST412, this was a proximity sensor that detected a magetic 'flag' on the spndle motor, this 'flag' being balanced by a non-magetic one oposite it. Write : The normal differential write driver driven from a toggle flip-flop clocked by the wtite data pin. Proaly some kind of write current control (either driven from the RWC/ pin on the connector or automatically from the positioner control circuit) Head switch. Again similar to a floppy, a diode-based switch Read : Normal differential read amplifiers followed by a comparator and the nn a pulse generator. If you compare the circitry to that of an old-ish floppy drive (TM100 or similar), you'll see that although the component values change (the hard drive works at a muuch higher data rate), the circuiry is very similar in concept. The one dead IDE drive I pulled apart used a voice coil positioner. There was no separate servo head AFIAK, presumably this thing used an embedded servo system. Which means you can't write just where you like on the platter, you mustn't overwrite theservo bursts. Obviously the internal 'IDE' controller enofrces this, but you couldn't simply feed an ST412 type of bitstream to the heads. As I said, the electronics was built round a few ASICs. It would be very difficult to modify. As a more prcatical issue, I thought the idea of this project was to be able to use a more modern drive with machines that expected an ST412 kind of interface. If you have to modify the IDE drive, then presumaly it would only work with that particualr model of IDE drive (and maybe only one version of it). This hardly seems a Good Thing, I susepct finding the 'right' type of IDE drive (== the one that the original desiger hacked about iowth to make it have an ST412 interface) would be harder than finding an ST412. -tony

On 27 Nov 2008 at 12:41, Fred Cisin wrote: Okay, call it "the ST-412 interface", but everyone here knows what's being discussed. Exactly what "MFM" or "RLL" means, however, is more of a problem. Manufacturers of controllers varied wildly in their implementation of the encodings, address marks and checksum polynomials. But yeah, MFM is (1,3) RLL and what we usually refer to as "RLL" is (2,7) RLL, but there were ARLL controllers using longer runs (3,11)? to get more capacity. I have a question for the guys with the sharp pencils. What is the minimum satisfactory sampling rate if one wanted to emulate an ST-412 interface and have it RLL (2,7)-capable? Would 16x oversampling of the 5MHz interface be adequate? How about 8x? Cheers, Chuck

On 27 Nov 2008 at 22:31, Roy J. Tellason wrote: Perstor was certainly one, and I think there were others. ISTR that it was pretty finicky about drive selection--more so than RLL (2,7) controllers. Sometimes it wasn't the bearing noise that got to you. Dragging spindle brakes could raise a racket, as could the copper grounding spring at the end of the spindle. Many folks just tossed one or the the other into the circular file to cure the noise. And then some "MFM" drives were just plain noisy, such as the Atasi/Priam FH units. I put an Atasi 120MB drive in a unit a couple of months ago and pulled it out after about a week of putting up with the noise. I replaced it with a 760MB Miniscribe ESDI. Much better. Cheers, Chuck

On Thu, 27 Nov 2008, Chuck Guzis wrote: Do you mean the guy who controls the automobile? ("You drive; you're too drunk to sing.") or the tool that cams out of Phillips screws.

Fred Cisin wrote: Yeah, or SASI. Incidentally, I kept finding DoA Adaptec ACB4000 bridges - anyone else had the same issue (and is there a typical failure mode for them)? I had a few of them kicking around so just labeled the dead boards up and shelved them, thinking I might get around to trying to fix them one day. Perhaps there's some common fault that affects them, though... cheers Jules

On 26 Nov 2008 at 15:34, Curtis H. Wilbar Jr. wrote: beast... I've got some OMTI bridges with Mac-specific EPROMs. No IDENTIFY support there either. Actually, it's not clear to me if any of the bridges supported that command. Cheers, Chuck

Curtis H. Wilbar Jr. wrote: Yeah, I tested against good boards in a vintage setup (with and without swapping in ROMs from a working board). The only other possibility would be that the timing constraints changed vastly between different board revisions and that was tripping me up. Been there, done that :-) I did have a brief muck around with that a few years back, but the Linux SCSI code is rather spaghetti-like. the boards I believe will work - but from what I recall, Linux marks anything offline that doesn't respond to the Inquiry command and then won't let you go near it. I suspect that the HBA doesn't care, so long as the board is SCSI rather than single-target SASI - and in theory it might be possible to hack the Linux kernel to not offline the board at boot time (and then be able to throw commands at it post-boot via the sg interface). Not sure - it did have support for a few ST506 boards once (not sure if that's still true), and there was some "third party" code for supposedly driving one of the OMTI bridge boards - but it was written against such an old kernel that there was no hope of integrating it with a reasonably modern one. cheers Jules