Gee! I didn't mean to suggest there was any inadequacy in what you've done
here, Tim. It just rang a bell with respect to the archival discussion that
went on for some weeks a couple of months back, and that suggests thee were
numerous people interested enough to follow it. I have a revised sampler
that will work in both directions in rework down in my basement, and I've
determined it needs more memry, but there isn't much space on that rather
small board. Fact is, I need to DRAM to make it fit physically, without
rearranging components. Nobody else has to use them. It's just a FREE
solution for me and perhaps others.
Please see my embedded remarks below.
Dick
----- Original Message -----
From: <CLASSICCMP_at_trailing-edge.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, July 04, 2000 11:11 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> >For quite some time I've tried to persuade Eric Smith, who's quite
> >knowledgable about programming the SCENIX SX processor, to write some
> >firmware that would create, functionally, a FDC chip out of one of these
> >ultra-fast single-chippers.
>
> "Better" is the enemy of "good enough". If I can throw something together
> in an afternoon out of TTL chips from Radio Shack, why go to the effort of
> creating what amounts to a custom chip?
>
I've used the same comment myself, Tim, but what I meant by this remark is
that, since most of the popular FDC's commonly used to read/write floppies
are not to easy to find/implement these days, a single person programming an
FDC code set into a programmable single-chipper with enough drive at the
pins to dispense with the need for external buffers would be an easy and
general solution to the problem of how to build an interface. I didn't
intend this to be mixed up with the sampling arrangement, which could,
conceivably, work in parallel with ANY FDC, but would, of course, be best
with a FDC that could read/write the format in question so that it would
provide assurance that a given sample of the bitstream from the FDD was
readable.
>
> Maybe my priorities are too much on the "just do it" side, and not enough
> on the "do it Dick's way" side :-).
>
> >Interpreting it in light of the modulation, data format, data rate, etc,
is
> >quite involved, but certainly achievable, though someone has to undertake
to
> >write the code with which to accomplish this.
>
> The code obviously varies depending on the encoding method, but my
method -
> a completely public circuit design with easy interface to a wide variety
> of computers - allows the user to write the decryption code in whatever
he/she
> might be familiar with on whatever platform he/she wants.
>
I was not aware that any form of encryption was involved, though the sampler
would, indeed grab the data as-is, and allow its external processing off
line, and subsequent regeneration of the by-then-massaged file. I did
suggest a completely public approach. The entire core process is achievable
with a few common, standard-logic (and therefore already obsolete) IC's and
an oscillator at 32x the fastest data rate one will attempt to sample.
AFAIK, that would be 16 MHz, BTW. The assumption is that the device will be
used with a PC that has EPP parallel port capability as nealy all PC's made
after '93 have. The FDC keeps track of the heads and operates the drive
mechanism, and the sampler grabs the entire track where the heads sit at
that moment by tapping onto the data path, albeit in parallel by means of OC
drivers.
>
> > Having the entire diskette
> >sampled as has been suggested, a track at a time means that one's
computer
> >can, at its own pace, reduce, interpret, reformat, etc, the data prior to
> >writing it to a duplicate. The reformatting of the data into its
original
> >format offers the advantage of phase coherency between sectors so the PLL
on
> >the controller doesn't have to shift phase between sectors. That will
make
> >the job easy in a case where the PLL has, over time, drifted off its
nominal
> >data rate.
>
> ??? There is no need for a hardware PLL if you oversample by a factor of a
> few.
>
You've clearly missed my point, Tim. The PLL of which I wrote is the one on
the system that will attempt to read the regenerated diskette, produced by
sampling to a data file at another place and time, subsequently reduced in
size, and then re-"inflated" at a resolution compatible with the appropriate
write precompensation, since that MUST be used in the regeneration process.
The sampler doesn't need a PLL due to the high sample rate. The FDC that
later reads the regenerated file will be presented with a diskette, the
transitions on which are written with the approriate write precompensation.
This will mean the PLL only has to sync once per track, since all the data
on a given track is coherently timed, transition-by-transition. So long as
the diskette is not subsequently written, the data will always be coherent,
thereby requiring no resynchronization. THIS WOULD BE BETTER THAN A BRAND
NEW DISKETTE, since it wojuld be clock-coherent. This would only be of
benefit to the system attempting to read the regenerated diskette.
One additional advantage would be that it would allow anyone, ostensibly
with any system at all capable of handling the target drive, and even some
that can't, to write a diskette in any sufficiently well-understood
modulation (FM, MFM, GCR, RLL, ERLL, etc) and format that's desired without
having a capable FDC. A PDP-8, then, could generate a diskette readable by
an APPLE-][ even though it hasn't got an Apple controller. Moreover, a PC
could write hard-sectored 8" diskettes using an external 8" drive and the
sampler, if properly implemented.
>
> >There are, IIRC, 10416 byte-times, nominally in an 8" FD track at MFM.
at
> >16x ovrsampling, that's a fair amount of data.
>
> That's absolutely true. But RAM chips are fairly cheap these days, and I
took
> advantage of that in my design.
>
> > While there are a number of
> >256Kx8 SRAMS out there, they're not likely to be lying in the corner
unused.
>
> I used an ISSI 62C1024-7, a 128K*8 70ns 32-pin DIP, and it's good enough
> for me. Cost was $12.00. Looking in my Digi-Key catalog, it seems you
can
> get 512K*8 parts for about $15.00 today, but they're in TSSOP's which
aren't
> so quickly breadboarded for me. (Though they are the obvious solution
> if you transfer my design to a PCB layout.)
>
> I'm sure a fair number of people on this list have access to unused 486
> motherboards with socketed cache RAM parts in the 32K*8 to 128K*8 range.
> These oughta do fine too.
>
> >I recommend, therefore that such a circuit be devised with DRAMS.
>
> Again, "better" is the enemy of "good enough". I made my circuit
> with parts that were easily available to me, and I decided that it
> wasn't worth the effort to build a DRAM controller when SRAM is so
> cheap. (And SRAM kept the parts count down, too...) You obviously
> have different priorities.
>
Modern (or fairly modern) DRAMs are quite simple, and I was thinking in
terms of circuit size and cost, counting on the likelihood that most of the
participants in this discussion have an old '386/486 or even a video card
with 256kx4 drams on board, and therefore availablel for scavenging. 256K
bytes are necessary to oversample at 32x, and thats the rate required for
write precomp. Hard-sectored MFM diskettes are probably rare, but 8"
diskettes in ERLL with hard sectoring would be closer to 250K. If all you
do is read, you can do things with much less hardware, and much less
software as well.
I made no assertion that what I proposed was BETTER than anything at all.
4x oversampling is adequate for reading. That's what you set out to do.
However, In the context of the prior discussion regarding archiving of boot
diskettes or whatever other diskettes, a device capable of writing
physically incompatible diskettes was called for. It's that target I was
addressing.
The reason I mentioned the SX is that it's capable of functioning as a
combined HDC/FDC and possibly addressing more different formats than any of
the chips I've used, largely since that's limited only by the capacity of
its program store and the imagination of the author of its firmware. That
came up only because I've seen more than one plaintive cry that the FDC that
someone wanted either wasn't available any more, or that the one they had
couldn't do one thing or another. It's a relevant concept from the
standpoint that at, say 96 MHz, the SX could present an entirely
self-contained solution to both these problems in addition to which it could
also handle the sampling. It's possible, but not until the code is written.
That, Sir, would be the ideal solution, in my opinion, since everybody could
then hook up this single device in whatever way is deemed appropriate for
their application, and I like the EPP myself, to handle "foreign" disk
formats in any way that's desired. It would take lots of future projects
off the "back burner" and let them be realized.
>
> --
> Tim Shoppa Email: shoppa_at_trailing-edge.com
> Trailing Edge Technology WWW: http://www.trailing-edge.com/
> 7328 Bradley Blvd Voice: 301-767-5917
> Bethesda, MD, USA 20817 Fax: 301-767-5927
>
>
Received on Tue Jul 04 2000 - 14:31:20 BST