According to MitchAlsup1 <[email protected]>:

S.E.L created a thing they called the RCU (Remote Control Unit).
It was basically a channel with writable microcode. NASA bought
a bunch of them because they had tapes from the deep space radio
telescopes where an entire 9-track tape contained 1 record. NASA
just started the tape and recorded satellite data until the end
of the tape, where they would start the next tape just before the
end of the previous tape.

So we programmed the RCU to read as much as the system memory
allowed, backed the tap up 1 second while dumping the data to
disk. Then we started the tape forward with the RCU watching
the pattern on the tape, when it detected 4096 bytes of the
last read, it would start streaming data in to memory again.

No other company could demonstrate that they could read one
of those tapes.

Presto, reading a whole 9-track tape with no inter record gaps !!

That is pretty amazing. Did NASA have a plan for reading
those tapes, or did they not realize that normal tape units
need record gaps, or what?

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 3 Jul 2024 23:03:24 -0000 (UTC), John Levine <[email protected]>
wrote:

That is pretty amazing. Did NASA have a plan for reading
those tapes, or did they not realize that normal tape units
need record gaps, or what?

It would be interesting to find out the real historical answer to that question.

But I can guess at a possible answer. This is before COTS became an
acronym. They felt they needed to record those tapes that way, and
they figured that reading them should be no big deal, even if existing
hardware didn't support it.

Another possible approach from the one described (which could
potentially lead to errors if data on the tapes was repetitious),
would be to connect two computers to the stream of data coming from
the tape drive, with them synchronously handing off the responsibility
for reading the data back and forth. I'm sure they could have thought
of that back then.

But they really shouldn't have used standard 9-track tape for this.
Something like DECtape, with random-access capabilities, would have
been more appropriate. Getting DEC to make a higher-performance
DECtape drive with vacuum columns may have been a problem, though.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 03 Jul 2024 22:17:59 -0600, John Savard
<[email protected]d> wrote:

On Wed, 3 Jul 2024 23:03:24 -0000 (UTC), John Levine <[email protected]>
wrote:

That is pretty amazing. Did NASA have a plan for reading
those tapes, or did they not realize that normal tape units
need record gaps, or what?

It would be interesting to find out the real historical answer to that >question.

But I can guess at a possible answer. This is before COTS became an
acronym. They felt they needed to record those tapes that way, and
they figured that reading them should be no big deal, even if existing >hardware didn't support it.

Another possible approach from the one described (which could
potentially lead to errors if data on the tapes was repetitious),
would be to connect two computers to the stream of data coming from
the tape drive, with them synchronously handing off the responsibility
for reading the data back and forth. I'm sure they could have thought
of that back then.

But they really shouldn't have used standard 9-track tape for this.
Something like DECtape, with random-access capabilities, would have
been more appropriate. Getting DEC to make a higher-performance
DECtape drive with vacuum columns may have been a problem, though.

Actually, even given the technology of the time, NASA engineers
probably figured that solving the problem was trivial on existing
computers. For example, like this:

1) Channels on IBM mainframes were programmable computers in their own
right, you could write channel programs. Thus, a Control Data 6600
with Peripheral Processors is not a requirement.

2) Since the channels are programmable, it should be easy to tell them
to do this when reading the tape:

Just read the data continuously into a circular buffer which is at
least three times the size of a normal tape record, ignoring
overwrites.

Issue an interrupt, to let the computer know a record's worth of data
is available, whenever a record boundary in the circular buffer is
passed.

3) The computer hands off the incoming records alternately to be
written as records with gaps to two other tape drives.

4) After this process finishes, take those two tapes, and turn them
into two tapes with the first and second halves of all the records,
instead of one with odd records and one with even records, through the
use of a computer with four tape drives. This is just standard data
processing stuff, which any computer that can to a tape sort can do.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine wrote:

According to MitchAlsup1 <[email protected]>:

S.E.L created a thing they called the RCU (Remote Control Unit).
It was basically a channel with writable microcode. NASA bought
a bunch of them because they had tapes from the deep space radio
telescopes where an entire 9-track tape contained 1 record. NASA
just started the tape and recorded satellite data until the end
of the tape, where they would start the next tape just before the
end of the previous tape.

So we programmed the RCU to read as much as the system memory
allowed, backed the tap up 1 second while dumping the data to
disk. Then we started the tape forward with the RCU watching
the pattern on the tape, when it detected 4096 bytes of the
last read, it would start streaming data in to memory again.

No other company could demonstrate that they could read one
of those tapes.

Presto, reading a whole 9-track tape with no inter record gaps !!

That is pretty amazing. Did NASA have a plan for reading
those tapes, or did they not realize that normal tape units
need record gaps, or what?

The satellite sending the data just sends a continuous stream
from up to 1 light hour away. So the original data had no IRG.
It might be the satellites were sending data at the fastest
rate the 9-track tapes could write and there was no time to
put IRGs on them.

{{It has been 40 years since I did some of that}}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 wrote:

John Levine wrote:

According to MitchAlsup1 <[email protected]>:

S.E.L created a thing they called the RCU (Remote Control Unit).
It was basically a channel with writable microcode. NASA bought
a bunch of them because they had tapes from the deep space radio
telescopes where an entire 9-track tape contained 1 record. NASA
just started the tape and recorded satellite data until the end
of the tape, where they would start the next tape just before the
end of the previous tape.

So we programmed the RCU to read as much as the system memory
allowed, backed the tap up 1 second while dumping the data to
disk. Then we started the tape forward with the RCU watching
the pattern on the tape, when it detected 4096 bytes of the
last read, it would start streaming data in to memory again.

No other company could demonstrate that they could read one
of those tapes.

Presto, reading a whole 9-track tape with no inter record gaps !!

That is pretty amazing. Did NASA have a plan for reading
those tapes, or did they not realize that normal tape units
need record gaps, or what?

The satellite sending the data just sends a continuous stream
from up to 1 light hour away. So the original data had no IRG.
It might be the satellites were sending data at the fastest
rate the 9-track tapes could write and there was no time to
put IRGs on them.

{{It has been 40 years since I did some of that}}

Or someone replaced an analog tape system with a digital one
at the minimum cost (so no computer in the loop).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)