[vcf-midatlantic] Zilog System 8000

[Microtech Dart]

Herb, I just thought of another example of my successful construction of a
full, "large" (by early 80s standards) file from a QIC-11 format tape:

http://microtechm1.blogspot.com/2015/11/microtech-m134-iris-r7-tape-read.html

The file I produce on this page was reconstructed by my programs, from
about 21,000 individual 512-byte blocks of data written to the tape.  Each
block of data was decoded from the GCR 4/5 data pulses that I captured with
the logic analyzer, and then decoded straight to hexadecimal characters,
which I stitched together in a hex editor.

I think if we were to continue this conversation much further, it may
greatly help me organize what I've done into a format that would be ready
to share more quickly, so I appreciate this discussion very much!  Before
talking with you about this, I've mostly been working in a vacuum on this
project.  Just discussing this with you is helping my organization of it.


On Fri, Nov 20, 2015 at 11:22 AM, Herb Johnson via vcf-midatlantic <
vcf-midatlantic at lists.vintagecomputerfederation.org> wrote:

> Microtech Dart wrote:
>
> > Actually, I've already done something that works well for a lot
> > of what you mention.  [With]  my Universal QIC  tape reader....
> > I've read a number of different head/track configurations
> > with this, by finding the tracks of the 9 that overlap with
> >  the 4, and choosing the correct direction on my
> > manual switch control.
> >
> > http://microtechm1.blogspot.com/2015/09/
> >kennedy-6450-tape-drive-data-format.html
>
> I have a question, but first some set-up for it. I have a point in
> spelling this out.
>
> Over the years, a number of people have read off binary data streams from
> either cartridge tape drives or very old hard drives; they store the binary
> samples as huge files (relative to the original data). And there are
> devices like the Catweasel series of cards, which operate floppy disk
> drives and sample their binary data streams. "Sampling" means there's many
> bits saved, to detect each "bit" of real data on the medium.
>
> Sometimes, these methods aren't sampling, they include the drive's
> "decoder" to produce actual binary data from the media. So a recovered
> "bit" is a real "data bit".
>
> But not all of those who produce these methods, take the next step of
> decoding the samples into blocks of original-as-recorded data; and then
> decode the blocks back into the original files which were written-to the
> storage devices in the first place.
>
> result: there's data "recovery" but not file recovery. I've explained what
> I mean by that.
>
> Now, I've looked at the microtechm1 blog. Since like most blogs it's
> written as a sequence of events, there's no obvious-to-me summary of
> current progress, beyond the "most recent" entry. I don't have time to read
> all prior entries. I can see there's progress on decoding the recovered
> data; and some hints that data at the "block" level may have been
> recovered. Some posts about "here's a binary extraction". This is good
> work, this is hard work. But I'm not clear about how far it has gone; and I
> made a good-faith effort to look.
>
> So here's my questions. Have you 1) reproduced the actual block-by-block
> data from the tapes you've processed ? 2) do you have programs to decode
> the blocks to interpret checksums, block numbers and so on? and 3) can you
> therefore process the successful blocks further to recover actual,
> individual files?
>
> I'm not trying to minimize all the good, and necessary, technical work
> done. I'm asking if files have been extracted, and if so where they may be,
> and where the supporting programs may be. Why am I interested? I "get" your
> point, these methods may be useful to me, in recovering other data from
> other tapes or devices; as was suggested.
>
> Herb Johnson
> --
> Herbert R. Johnson,  New Jersey USA
> http://www.retrotechnology.com OR .net
>



-- 

Thanks,
-AJ
http://MicrotechM1.blogspot.com