Thoughts on a datascope

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sat Jul 14 10:56:14 2001

This might take a lower-level approach, because a simple thing like a different
number of sectors or a different sector size will make the drive totally
unreadable under DOS, or any other OS that doesn't use the same sector count and
size.

If you are brave enough to write some code to attempt to read a drive with
different sector and gap sizes (those are programmable on a WD HDC, and most
others) you might be able to recognize what's been done on your datascope's
drive. I'd recommend you consider hard-wiring the write-gate to the disabled
state on your HDD while you're trying to read/sample its contents.

The WD HDC was very widely used, but not universal. SMC made a pretty good MFM
HDC that was not compatible with the WD, as did ADAPTEC and others. The
differences were mainly in address mark-related circuitry, but that's enough to
foul up readability.

IIRC, (somewhat of a stretch, BTW) you're pretty familiar with the CATWEASEL FD
interface. A similar approach, with a sample rate that's a harmonic of the
nominal data rate will enable you to acquire the data stored on your drive.
Unfortunately, writing it back will require you reimpose the precompensation,
since that's lost in the recovery process. You can use any controller you've
got to move the heads around and to detect the INDEX pulse, however, so you
don't have to build a whole controller. You just need code to step the head
stack from track to track, switch the heads, and record the signal sampled from
the read data line. Timing won't be critical beyond the business of getting the
sampled data into a RAM.

Since I don't know what the hardware on the CATWEASEL is, I don't know whether
it is reasonable to consider using a faster (10x or so) crystal oscillator, but
something on the order of 30-40 MHz might be worth a try if it looks like the
logic is fast enough to get the job done. At precisely 10x the original rate,
the software might even work without modification, and I seem to recall someone
telling me that the sample rate isn't that critical. Who knows ... it might
even work!

Dick

----- Original Message -----
From: "Bruce Lane" <kyrrin_at_bluefeathertech.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, July 14, 2001 8:53 AM
Subject: RE: Thoughts on a datascope


> At 15:16 21-08-2000 -0400, you wrote:
>
> >> Any thoughts on how I can back this beastie up? Anyone
> >> done anything with this line of datascope?
> >
> >No experience with this device, but you could try this:
> >
> >Remove the HD and attached it as the second drive in an
> >old bootable PC that already has one MFM drive. You'll
>
> <snip>
>
> The problem with that (yes, I'll try it at some point) is, with MFM, the
drive's format was entirely dependent on what chip the controller was using. If
the controller in the datascope isn't using the same chip as in, say, a WD1003,
1006, or other controller, I'm pretty much screwed.
>
> Thanks, though. Perhaps I'll get lucky and find that AR used a PC-like format
on the thing. It's certainly from the right era.
>
> >Then, assuming this datascope doesn't turn out to be an embedded DOS
> >machine (and thus the drive formatted as FAT12), use DEBUG under DOS
> >to load the boot sectors, then write to a .BIN file and set aside.
>
> <snip>
>
> All the above sounds great except for one thing... I lack the experience to
translate it into step-by-step!
>
> >If it's loading more than 64k, you could just write a quick-n-dirty
> >program using your favorite language (unless that's COBOL!) to read
> >the datascope code in and store it in a binary file.
>
> Sorry. Won't work in my case. I speak an ancient version of DEC BASIC-PLUS,
DOS batch language, and a tiny bit of shell scripting under AIX. Again, I lack
the skill to write something like you describe.
>
> >However, as I said above, you may find this machine is an embedded
> >DOS machine, and the drive may already be readable, file by file.
>
> Let's hope so...
>
>
>
Received on Sat Jul 14 2001 - 10:56:14 BST