On 29 Oct 2008 at 23:23, ethan.dicks at usap.gov wrote: In general, it's useful to think of MFM drives as being large, fast floppies in that by and large, they consist of two parts--the drive- selection, head positioning and side-select electronics and the read/write electronics. The drive is pretty much blind to the data being placed on it, like a floppy. So picking a drive that meets or exceeds the original in all of the parameters generally works pretty well. Unlike ESDI, IDE and SCSI drives, there is no "identify" facility in an MFM drive. If you want to figure out the capacity the hard way, you can try seeking to successively higher cylinders and tracks until you hit an error (a binary search will speed the process up). There are some exceptions--one of which is the MFM drives used on the "baby" models of the DG MV series. Apparently (as nearly as I can determine), the controller firmware looks for a specially formatted track that contains the drive parameters--just plonking an off-the- shelf drive of the same model number just doesn't work. The other exception that comes to mind are drives that have a higher rotation speed than the customary 3600 RPM. Whether or not the HP drive in question falls in this latter category, I am unable to say. Cheers, Chuck

Did these MFM interfaces and associated controllers ever expect to write individual sectors on a track? or was the entire track always written at once? I realize that the operating system had individual sector write-ability but was that accomplished by read-modify-write of that individual sector in a controller buffer and then the entire track rewritten? or did the controller sync to the beginning of the specific sector and write it in place? I'm still dreaming about a way to emulate these drives with modern hardware and I know that has been hashed over a lot over the years... but I have no interest directly mapping an old drive to a new one. I'd be happy with emulating the old drive in a file (image) on a new drive or say, compact flash or other non-rotating media. -- Chris Elmquist mailto:chrise at pobox.com

Dave McGuire wrote: I think the end of the last discussion on this resulted in the conclusion that it could be done, but required frequencies high enough to rule out just slapping some TTL together on a bit of prototype board... To be honest I'd just be happy with something that could snapshot a drive for now, without necessarily having to understand the contents or give write access - far as I'm concerned, the priority is to get the data off* the ageing media; a drop-in replacement for the physical hardware is a secondary consideration (I do like to keep my systems running, but it's no good if a bells-and-whistles system comes along ten years too late) * I'd even sell my soul and consider a USB solution for that ;) cheers Jules

On Oct 31, 2008, at 4:12 AM, Chuck Guzis wrote: What do the signals on the data connector look like? I seem to recall that there are some differential pairs on there...are they analog or digital? -Dave -- Dave McGuire Port Charlotte, FL

Wondering if anyone out there has or has seen a Corvus made Novell 386 Server? I have a promo sheet showing a 386 (and available at the time - 486) File Server in a custom Corvus Plastic case design. Meant to be a Novell 386 OS (3.11) fileserver with protocols to support IPX/SPX and Corvus RS422 "Omninet" protocol as well. Curt

Dave McGuire wrote about the ST412 interface: recall that there All electrical signals are analog, but I suppose we shouldn't start that discussion again. In practical terms, the differential pairs are RS-422, so they are digital, but you need RS-422 drivers and receivers to talk to them properly, and termination on the receivers. There are many suitable quad driver and quad receiver chips, such as the MC3486/3487 and Am26LS31/32. Eric

On 31 Oct 2008 at 14:22, Dave McGuire wrote: What I said. In fact, no need for quad devices if you're just emulating a single drive. There are plenty of dual-unit RS-422 drivers/receivers available. How about the ST-412 OEM doc? http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf As a matter of fact, on page 21 it states "NOTE: ANY EIA RS-422 DRIVER/RECEIVER PAIR WILL INTERFACE". Cheers, Chuck

On Oct 31, 2008, at 2:56 PM, Eric Smith wrote: That's plenty to go on. Thanks! -Dave -- Dave McGuire Port Charlotte, FL

If emulating a drive though, couldn't one standardize on one valid (faster) data rate (versus the difference between inner/outer cylinders) ? If you have the bitstream represented, and the timing variability need not be duplicated, wouldn't this become simpler (and hence more feasable) ? -- Curt

Chuck Guzis wrote: Sure, but I believe one of the assumptions was that it'd be useful to oversample the data and decode in software (possibly as an aid in error recovery, possibly to make the hardware independent of data encoding used - I don't remember which). That ends up pushing things into tens of MHz, and I suspect there's quite a few people who can happily throw LS-TTL logic onto a bit of breadboard but who don't have the experience or equipment to make something running at that sort of speed. Perhaps I'm completely misremembering, though, and mixing up a device which can archive a drive from a device which emulates such a drive (and it's only the emulation which needs the oversampling aspect) Related note: I think there's a whole range of data recovery devices / techniques that are worth thinking about (not only just with hard drives) - I keep wondering if a separate discussion medium for such topics would be useful, along with the support of various computer museums, but then we know how people can't generally agree on anything when it comes to some of these things :-) Seems a shame both that there's a wealth of info scattered around out there that could in theory be collected together, and that separate groups could easily end up doing the same tasks in parallel. cheers Jules

It's not conceptually that complicated. The basic idea is to have an 'image' of a track stored in some kind of semiconductor memory. And you keep on replaying that a s bitstream into the read data input of the controller, generating an index pulse of course at the appropraite time. When you get a write gate fro mthe controller you then start sampling the write data output from the controller and overwriting the stored bitstream. Yes, there might be glitches at the start/end of a write, but presumaly no wores than on a physical disk. On a head swtich or head step (to a different cylinder) you replace the image in memory with the correct one for the new track. The problem is in the details. In particlur I don't think any normal flash memory will be fast enough to directly read out the track image and blast it to the controller, and I'm darn sure it's not fast enough for a direct write. Which means you need to have a buffer memory of high-speed SRAM to store the current track image This needs to be loaded from flash on a track change, and written back afterwards _iff it was updated by the controller_ Now, there are 2 types of track change, a head switch and a cylinder movement .The latter is easier, since it can take as long as you like (within reason), there's a seek-complete line back to the controller. But a head swithc has to be essentially instantaneous. Which probably means having enough SRAM to buffer the tracks for all heads on a given cylinder and then keeping an 'undated' flag for each track, writing back only those that have changeed. I didn't think SPI was anything like fast enough for this. I looked into using a _lot_ of F-series TTL chips, and rather gave up on the idea. Maybe I should have another go. -tony

On 30 Oct 2008 at 7:44, Jules Richardson wrote: What I understand to have been the case is that there were some "authorized service agents" who had the capability to provide the LLF- ed drives. The ugly part was that if a customer obtained a new off- the-shelf model of the needed drive, the system wouldn't see it. So not only did you need a specific drive, but you needed the correct format on it. Reminds me of the old Drivetec floppies--formatted with an embedded servo, so you didn't dare pick up used ones--they could be erased or have errors that would render them useless. I've still got some of the old Drivetec/Kodak drives and some media, but I'm not aware of anyone offering the media in the last 15 years or so (my last samples came from the Dysan Sunnyvale plant liquidation). What do Kaypro Robie collectors use for blank media? Cheers, Chuck

I doubt that. Precompenation is slightly altering the timing of the write pulses, and there's no easy way for the drive to detect that. More likely the drive simply knew what cylinder the heads were on (e.g. by keeping a count of step pulses inside the microcontroller) and simply reduced the write current on cylinders beyond a certain value. I think some drives did the precompensation themselves too, thus the controller didn't have to bother with either the RWC or the Precompensation. -tony