Re: Tape reel data recovery from MERA-400 polish computer

[Jon Elson via cctalk]

On 03/10/2017 01:40 PM, Paul Koning via cctalk wrote:
A stretch with no transitions occurs of course at the 
block boundary (the gap). It also apparently occurs in 
other spots, for a few bit times: tape marks seem to 
consist of two frames separated by a few clocks worth of 
blank space. Ditto between data and block check frame(s), 
if I remember right.
The classic NRZI definition for 800 BPI 9-track is that 
there is a 2-character gap after the end of the user data 
block, then the CRC and LRCC characters follow.  We had some 
tapes made on out IBM 360 that had little short gaps all 
over them, as they had the machine misconfigured and were 
exceeding memory bandwidth.  The IBM could read them fine.  
I think they only detected the big gap to define the end of 
the record.  Our DEC controllers all used the 2-character 
gap to detect where the block was ending.  No way to fix 
that if the hardware tape control decided those gaps were 
the end of data.


Jon

Re: Tape reel data recovery from MERA-400 polish computer

[Jon Elson via cctalk]

On 03/10/2017 12:58 PM, Paul Koning via cctalk wrote:

On Mar 10, 2017, at 1:39 PM, Al Kossow via cctalk  wrote:


The next extension is to track the tachometer values so that you can detect and 
compensate for tape stick/drag
which is absolutely critical for formats that don't self-clock, like NRZI.

NRZI is not self clocking if you consider an individual track in isolation.  
But it IS if you consider all the tracks at the same time, provided either (a) 
the data is recorded with odd parity, or (b) the all-zeroes data character 
isn't used.  (a) is the case for 9-track tapes.
Yes, but the problem is 800 BPI is about the upper limit on 
density due to tape skew.  I don't know for sure, but I 
strongly suspect that skew gets worse as the tape gets 
older.  I've seen some tapes that were only a few years old 
where the skew got very bad.  You could put a scope on the 
skew alignment test point and see the skew pattern pulsing 
as the supply reel rotated, meaning the tape got 
differentially stretched while sitting on the reel.


But, glad they were so successful in their effort!

Jon

Re: Tape reel data recovery from MERA-400 polish computer

[Paul Koning via cctalk]

> On Mar 10, 2017, at 2:25 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 03/10/2017 10:58 AM, Paul Koning via cctalk wrote:
>> 
>>> On Mar 10, 2017, at 1:39 PM, Al Kossow via cctalk
>>>  wrote:
>>> 
>>> 
>>> The next extension is to track the tachometer values so that you
>>> can detect and compensate for tape stick/drag which is absolutely
>>> critical for formats that don't self-clock, like NRZI.
>> 
>> NRZI is not self clocking if you consider an individual track in
>> isolation.  But it IS if you consider all the tracks at the same
>> time, provided either (a) the data is recorded with odd parity, or
>> (b) the all-zeroes data character isn't used.  (a) is the case for
>> 9-track tapes.  7 track tapes may be even parity, but that case seems
>> to apply by convention only to text data (not binary data) and there,
>> (b) applies.  You do have to correct for track skew in this process,
>> but that applies in any case even if you have an independent
>> authoritative bit clock.
>> 
>> It clearly can help to have tach signals as a way to improve bit
>> framing, but I don't see that it's mandatory.
> 
> I think I mentioned that a couple of years ago.  Even parity 7 track
> tapes were used on very old systems for reasons that escape me.  One of
> the problems, then was how to represent an all-zero character, since
> there would be no transitions in that particular frame.

Sure.  One tape document I looked at mentions the use of odd parity on the 
7-track tapes when writing binary data, even parity when writing "IBM BCD" 
character coded data, with one of the 6-bit values forbidden in that case (the 
value encoded on tape as 6 zero bits). 

A stretch with no transitions occurs of course at the block boundary (the gap). 
 It also apparently occurs in other spots, for a few bit times: tape marks seem 
to consist of two frames separated by a few clocks worth of blank space.  Ditto 
between data and block check frame(s), if I remember right.

> A tach signal is useful for adjusting the width of the "window" when
> deskewing.

Yes, that was my point: useful to make the process easier or to improve the 
quality of the result if the inputs are marginal, but you can make it work 
without a tach signal.

> I wonder if there's not a better way to attack the problem with some
> simple hardware.   The original posters mentioned an AVR Arduino as
> their initial platform, but cheap SBCs are available that run much, much
> faster.  Consider, for example, the RPi zero or the Orange Pi zero or a
> host other sub-$10 hosts running at a GHz or more.
> 
> You'd need level-shifting for a modern MCU/CPU anyway, as logic levels
> are most commonly 3.3V, not 5V.

Al's mention of that Saleae device fits there: you could plug that into any 
suitable fast enough computer, and it deals with analog data so you can do the 
threshold in software.  (Thanks Al, those look like nice devices.)

paul

Re: Tape reel data recovery from MERA-400 polish computer

[Chuck Guzis via cctalk]

On 03/10/2017 10:58 AM, Paul Koning via cctalk wrote:
> 
>> On Mar 10, 2017, at 1:39 PM, Al Kossow via cctalk
>>  wrote:
>> 
>> 
>> The next extension is to track the tachometer values so that you
>> can detect and compensate for tape stick/drag which is absolutely
>> critical for formats that don't self-clock, like NRZI.
> 
> NRZI is not self clocking if you consider an individual track in
> isolation.  But it IS if you consider all the tracks at the same
> time, provided either (a) the data is recorded with odd parity, or
> (b) the all-zeroes data character isn't used.  (a) is the case for
> 9-track tapes.  7 track tapes may be even parity, but that case seems
> to apply by convention only to text data (not binary data) and there,
> (b) applies.  You do have to correct for track skew in this process,
> but that applies in any case even if you have an independent
> authoritative bit clock.
> 
> It clearly can help to have tach signals as a way to improve bit
> framing, but I don't see that it's mandatory.

I think I mentioned that a couple of years ago.  Even parity 7 track
tapes were used on very old systems for reasons that escape me.  One of
the problems, then was how to represent an all-zero character, since
there would be no transitions in that particular frame.

A tach signal is useful for adjusting the width of the "window" when
deskewing.

I wonder if there's not a better way to attack the problem with some
simple hardware.   The original posters mentioned an AVR Arduino as
their initial platform, but cheap SBCs are available that run much, much
faster.  Consider, for example, the RPi zero or the Orange Pi zero or a
host other sub-$10 hosts running at a GHz or more.

You'd need level-shifting for a modern MCU/CPU anyway, as logic levels
are most commonly 3.3V, not 5V.

--Chuck

Re: Tape reel data recovery from MERA-400 polish computer

[Paul Koning via cctalk]

> On Mar 10, 2017, at 1:39 PM, Al Kossow via cctalk  
> wrote:
> 
> 
> The next extension is to track the tachometer values so that you can detect 
> and compensate for tape stick/drag
> which is absolutely critical for formats that don't self-clock, like NRZI.

NRZI is not self clocking if you consider an individual track in isolation.  
But it IS if you consider all the tracks at the same time, provided either (a) 
the data is recorded with odd parity, or (b) the all-zeroes data character 
isn't used.  (a) is the case for 9-track tapes.  7 track tapes may be even 
parity, but that case seems to apply by convention only to text data (not 
binary data) and there, (b) applies.  You do have to correct for track skew in 
this process, but that applies in any case even if you have an independent 
authoritative bit clock.

It clearly can help to have tach signals as a way to improve bit framing, but I 
don't see that it's mandatory.

paul

Re: Tape reel data recovery from MERA-400 polish computer

[Al Kossow via cctalk]

The next extension is to track the tachometer values so that you can detect and 
compensate for tape stick/drag
which is absolutely critical for formats that don't self-clock, like NRZI.

Fortunately, they mention that the tapes they worked with were in good 
condition.

The killer problem with the Qualstar is the reel motors are low torque. If you 
get a sticky tape, the RPMs go wonky.

Good news is the Saleae 16 can do digital and analog capture.


On 3/10/17 10:22 AM, Paul Koning via cctalk wrote:

> The software mentioned in the article sounds very interesting.  It talks 
> about starting with digital data streams from the 9 heads, but adds that you 
> can start with analog data too.  That would be a small change: you'd 
> basically have to add the slicer in software.  That's potentially valuable, 
> if the signals are marginal so the threshold needs to adjust on the fly.
> 
> Obviously this can also be adapted to other tape formats, for example 7 track 
> tapes.  Or esoteric stuff like 10 track tapes.
> 
> Thanks for that link!
> 
>   paul
> 

Re: Tape reel data recovery from MERA-400 polish computer

[Paul Koning via cctalk]

> On Mar 9, 2017, at 10:10 AM, Liam Proven via cctalk  
> wrote:
> 
> http://museo.freaknet.org/en/recupero-dati-nastri-magnetici-del-computer-polacco-mera-400/

Neat.

The software mentioned in the article sounds very interesting.  It talks about 
starting with digital data streams from the 9 heads, but adds that you can 
start with analog data too.  That would be a small change: you'd basically have 
to add the slicer in software.  That's potentially valuable, if the signals are 
marginal so the threshold needs to adjust on the fly.

Obviously this can also be adapted to other tape formats, for example 7 track 
tapes.  Or esoteric stuff like 10 track tapes.

Thanks for that link!

paul

Re: Tape reel data recovery from MERA-400 polish computer

[Al Kossow via cctalk]

Spinning at 50ips probably helped instead of the default 20

I would have digitized the tach signal too, but luckily it wasn't needed

Sad neither you or I are mentioned in the credits

I'm going to try it as well, since I have all the hw to try it out.

On 3/10/17 10:16 AM, Chuck Guzis via cctalk wrote:
> On 03/10/2017 09:59 AM, Al Kossow via cctalk wrote:
>> This is fsckin cool. Chuck and I were wondering how it turned out.
>>
>> On 3/9/17 7:10 AM, Liam Proven via cctalk wrote:
>>> http://museo.freaknet.org/en/recupero-dati-nastri-magnetici-del-computer-polacco-mera-400/
> 
> That's pretty amazing, considering the crappy nature of those Qualstar
> drives.
> 
> I may give it a try.
> 
> --Chuck
> 

Re: Tape reel data recovery from MERA-400 polish computer

[Chuck Guzis via cctalk]

On 03/10/2017 09:59 AM, Al Kossow via cctalk wrote:
> This is fsckin cool. Chuck and I were wondering how it turned out.
> 
> On 3/9/17 7:10 AM, Liam Proven via cctalk wrote:
>> http://museo.freaknet.org/en/recupero-dati-nastri-magnetici-del-computer-polacco-mera-400/

That's pretty amazing, considering the crappy nature of those Qualstar
drives.

I may give it a try.

--Chuck

Re: Tape reel data recovery from MERA-400 polish computer

[Al Kossow via cctalk]

This is fsckin cool.
Chuck and I were wondering how it turned out.

On 3/9/17 7:10 AM, Liam Proven via cctalk wrote:
> http://museo.freaknet.org/en/recupero-dati-nastri-magnetici-del-computer-polacco-mera-400/
>