[Intel-devsys] IMAGEDISK for MDS 8" SSSD disks

Jon Hales jonhales at gmail.com
Thu Feb 27 02:40:58 MST 2020


Roger

You are fortunate to have built a collection that allows you to make
choices.

I agree with you that in principle you would expect be able to write an
image that the MDS-225 is happy with. One way to do that is to copy using
the drives on your MDS.

As you mention, it's possible to adjust some of the tolerances built into
Imagedisk - with many possible combinations.

An initial point is that the iSBC-201 employs bit-slice ICs. That's
different from later floppy controllers in your PC running Imagedisk.

A second point is that the Shugart drives in your MDS are belt-driven from
an AC supply and may introduce timing variations even when you have written
an 'exact copy'. The drive attached to your PC for writing should ideally
be the one you want to read the disk on (yes, difficult in practice).

A further point is that flux transitions are analogue patterns. They become
an encoding pattern when cut-offs are applied to convert the stream to
binary. Even a device that provides a record of the timing between flux
transitions is retaining less data than contained in the waveforms in the
disk's oxide. Every copy may differ from the original.

I was told a few days ago about a device that would conduct a number of
read operations on each track with varying settings and would then
(automatically - i.e. in software) combine these data streams to
reconstruct the best likelihood model of the data. This may involve a
narrow read head or heads to provide data from different lateral positions
within the track. I imagine such devices may exist for forensic use, but
haven't found details. We are told that over-written data can be recovered
under some circumstances, which I assume means recovering multiple versions
of the data retained in the magnetic layer. And lots of processing.

The essential point is that floppy technology was remarkably effective but
was never expected to provide interchange between disparate platforms. We
can imagine how an ideal interchange medium might be constructed. I don't
think it would be based on magnetic signals.

I found it useful to learn about a device for imaging 3.5 inch disks - I
built the device but haven't used it. The author developed software to
record and examine the waveforms for errors which could then be manually
'corrected'. One of the videos is at
https://www.youtube.com/watch?v=qKqQ3QsZwp4

Best regards

Jon

On Thu, 27 Feb 2020 at 00:48, Roger Arrick <Roger at arrick.com> wrote:

> I've collected the evidence that there is something picky about the MDS II
> internal SD drive controller (8271) causing an incompatibility with IMD
> (Imagedisk).
>
> My MDS225 has an internal SD drive (E:) and 2 external DD drives (A:,B:)
> using the standard intel DD board pair.
> This is a nicely working system (after much work).
> I boot the MDS225 into CPM 2.2 using the external DD drive.
>
> Insert a CPM User group disk 8" SSSD disk (unknown origin) into E:.
> It DIR's fine.
>
> Now, I have a working imagedisk PC setup that successfully creates 5.25 SD
> disks
> as well as 8" SD disks which can be read by other vintage systems.
> This PC uses the Adaptec AHA-1542CF (820778L) because it will write SD.
>
> I take this CPMUG1 disk and read it using IMD.
> Reads fine and saves as CPMUG1.IMD.
> This file is available at http://www.rogerarrick.com/misc/CPMUG1.IMD
>
> I then write a new disk using IMD named CPMUG1R.IMD with the CPMUG1.IMD
> file.
> This file is available at http://www.rogerarrick.com/misc/CPMUG1R.IMD
>
> This new disks which was duplicated through IMD will not read on the
> MDS225.
> But it will read on a XEROX 820II CPM system.
>
> Maybe it's something in the format or R/W gap settings.  I've tried a few
> different values with no success.  It would take a lifetime to try all
> possibilities.
>
> This is mostly curiosity for me.  I was hoping to use my MDS225 as a
> standard
> CPM workhorse because I love it but this is a show-stopper.  I'll be
> switching
> over to the Xerox 820II - it's a boring, but solid and well-documented CPM
> sys.
>
> _______________________________________________
> Roger Arrick
> Roger at Arrick.com
> Tyler, TX
> _______________________________________________
> Intel-devsys mailing list
> Intel-devsys at lists.brouhaha.com
> http://lists.brouhaha.com/mailman/listinfo/intel-devsys
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.brouhaha.com/pipermail/intel-devsys/attachments/20200227/4fb19d8e/attachment.html>


More information about the Intel-devsys mailing list