imaging/duplicating HP tape cartridges - lots of questions


Jack Rubin
 

Today I found another HP-85 tape of interest - "5010-0567/2630 - CS80 HP85 DIAG TAPE". It is labeled as being in SIF format and part of the HP85 Service System. Again, the existing archived copy consists of a disk image of the tape files which is incomplete and partially corrupted.

I'm still suffering a bit of dis-belief about the problems of imaging these tapes. Setting aside the issues of physically reading the tapes, from what I've seen, tapes have been recovered by copying files to disk which somehow fails to capture some binary system data. Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

Hopefully, I'm not truly understanding the process and we do have the ability to do a raw block copy from tape to image and back.

Does anyone know how the "COPY ALL"  tape-to-tape function works on the 2644 terminal? 

Has anyone tried a "reverse QIC" approach? If the 9825/85 "DC100" tape drives can be re-engineered to read QIC-40 tapes, can a QIC-40 drive read an HP tape? If that's the case, then it is a short step to using ftape and dd to start tape imaging.

Jack


 


On Feb 20, 2017, at 8:39 AM, Jack Rubin <j@...> wrote:

Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

The standard 9825 tape firmware provides no commands to write binary programs back to tape.  Hence the incomplete tape images.


 

About the reverse quick approach, a QIC40 drive uses 20 tracks of data. The DC100 uses 2 tracks, the update is a mechanical adaption to the dimensions of the QIC40 cartridge and an increase of the write current to write to the media. QIC40 and DC100 don’t share any track and modulation configuration.

I’m not sure but I think it’s practically impossible to read a DC100 tape on a QIC40/80 drive.

But it should be possible to connect a DC100 HP FACT drive to something like a Arduino or other micro controller, and read the data as a stream. And so neglecting any error signals generated by missing layers etc…

The program should be something like: rewind to the begin, start slow forward and read everything it says, stop at end of tape.

The next thing would be more complicated because you will have to analyze the captured data with a smart written piece of software.

 

-Rik

 

 

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Jack Rubin
Verzonden: maandag 20 februari 2017 16:39
Aan: VintHPcom@groups.io
Onderwerp: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

Today I found another HP-85 tape of interest - "5010-0567/2630 - CS80 HP85 DIAG TAPE". It is labeled as being in SIF format and part of the HP85 Service System. Again, the existing archived copy consists of a disk image of the tape files which is incomplete and partially corrupted.

I'm still suffering a bit of dis-belief about the problems of imaging these tapes. Setting aside the issues of physically reading the tapes, from what I've seen, tapes have been recovered by copying files to disk which somehow fails to capture some binary system data. Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

Hopefully, I'm not truly understanding the process and we do have the ability to do a raw block copy from tape to image and back.

Does anyone know how the "COPY ALL"  tape-to-tape function works on the 2644 terminal? 

Has anyone tried a "reverse QIC" approach? If the 9825/85 "DC100" tape drives can be re-engineered to read QIC-40 tapes, can a QIC-40 drive read an HP tape? If that's the case, then it is a short step to using ftape and dd to start tape imaging.

Jack


Jack Rubin
 

For archival imaging, no need, at least initially, to do anything with the bit stream other than to capture it. At that point, either one could attempt to read the image itself or else write it back to another tape, hopefully allowing the creation of a new generation of system tapes.

What would be the "best" FACT drive to use from the standpoint of reliability and ease of control?

Does any other machine that uses these cartridges have a richer command set that allows full tape duplication? Does the 9875 dual drive allow this?

Jack


Ansgar
 

Guess the 9875 uses the TACO tape controller chip, just like the 9845. The chip itself is a great mystery, since sparsely documented (the most comprehensive description I think can be found the the 64940-90905 docs for the 64k tape system). However, I assume in theory it should be capable to be programmed to read & write the tapes on flux reversal level (including random gap lengths).

These are many assumptions, I know, but F.Ulivi has implemented the TACO chip for emulation, which gave us some more findings on it, although still being far from having a complete understanding. The analysis by the way also showed that the 9845 tapes are in fact SIF-tapes, where the full file system is stored into one single, large SIF file with record size of 256 bytes. Consequently, with the SIF utilities for the 9845 you also have access to SIF tapes (on file base, not for reading the low level data).

As a summary, it should be theoretically possible to process any DC100 tape with a device equipped with a TACO chip. Probably except (here it comes) Series 80 tapes. I have a strong feeling that the Series 80 (not equipped with TACO by the way) uses different writing currents and/or read sensitivity, although I did not check them yet (no Series 80 tape drive at hand). I tried to use the tapes from Athana (which are new replacements for DC100 for use in Series 80 computers) with a 9845 and got negative results, but they seem to work in a Series 80.

-Ansgar


Paul Berger
 

The HP-IB command set for the drive is documented in the users manual so I would guess in theory you could use it to just read blocks of data from the tape, but I suspect that if the tape is physically damaged, such as when the drive band peels off some oxide you would not be able to read them.  It does say it supports SIF format and I think that is the format that 9825 uses.  The 9875 uses a  TACO to drive the tape drives, but since the TACO chip manages a number of the low level functions on its own, I suspect that it too would have problems with damaged tapes.  You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.  For damaged tapes the best would probably be to talk directly to the drive and just capture the bit stream.  There is a good description of the SIF tape format in the 9875 users guide.  From what I can see in the manuals the drive units in the 9875 are the same as the ones in 9825/35/45.  There seems to be two versions of these drives, one that uses incandescent bulbs for light source for sensor and on that uses IR LEDs, the drives in both my 9825T and 9835A use the IR LEDs.   

Paul.
   

On 2017-02-20 12:58 PM, Jack Rubin wrote:

For archival imaging, no need, at least initially, to do anything with the bit stream other than to capture it. At that point, either one could attempt to read the image itself or else write it back to another tape, hopefully allowing the creation of a new generation of system tapes.

What would be the "best" FACT drive to use from the standpoint of reliability and ease of control?

Does any other machine that uses these cartridges have a richer command set that allows full tape duplication? Does the 9875 dual drive allow this?

Jack



 


On Feb 20, 2017, at 10:50 AM, Paul Berger <phb.hfx@...> wrote:

You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.

I wonder if the TACO chip is an enhanced version of the tape controller in the 9825.  The comments in the 9825 tape firmware listing led me to think some portion of the code might be shared with the 9875, in particular the portion known as the “Tape Driver” that resides in the ROM at 020000.  The 9825 FW keeps track of tachometer pulses to know how far  it has moved the tape, and does the data stream bit serialization/deserialization operations in FW.  It also manages the two levels of the read threshold to check if data will be likely to be read back correctly.


Paul Berger
 

From what Ansgar wrote on his site http://www.hp9845.net/9845/hardware/processors/  it does replace the discrete logic controller used in the 9825 and more.  It seems likely that it is more autonomous than the controller on the 9825, able to do some functions on its own.  There is a patent document for the 9845A but I don't know if it gets into the tape drive operation.  The 9835 and 9845 use TACO chips for the tape drive controller.   

Paul.


On 2017-02-20 3:00 PM, Craig Ruff wrote:

On Feb 20, 2017, at 10:50 AM, Paul Berger <phb.hfx@...> wrote:

You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.

I wonder if the TACO chip is an enhanced version of the tape controller in the 9825.  The comments in the 9825 tape firmware listing led me to think some portion of the code might be shared with the 9875, in particular the portion known as the “Tape Driver” that resides in the ROM at 020000.  The 9825 FW keeps track of tachometer pulses to know how far  it has moved the tape, and does the data stream bit serialization/deserialization operations in FW.  It also manages the two levels of the read threshold to check if data will be likely to be read back correctly.


 


On Feb 20, 2017, at 1:41 PM, Paul Berger <phb.hfx@...> wrote:

There is a patent document for the 9845A but I don't know if it gets into the tape drive operation.

Yes, it does, pages 297-300.


 

The series 80’s drive needs to be modified before it can write Athana tapes, because the tapes needs a bigger write current (about 20%) to write the Athana tapes. HP 9825 drives can be modified to increase the write current and write Athana tapes.

TACO: I suspect the TACO off having an internal tape counter which puts it in an error condition when the tape is too long.

The HP 98X5 drives are rather simple to control and placing an opamp after the pre-amp output should make it possible to put the read signal into an A/D converter and read the data into a file.

The 9877 tape drive comes with a utility tape which contains the tape copy software, a binary file ;)

 

-Rik

 

 

 

 

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Ansgar
Verzonden: maandag 20 februari 2017 18:38
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

Guess the 9875 uses the TACO tape controller chip, just like the 9845. The chip itself is a great mystery, since sparsely documented (the most comprehensive description I think can be found the the 64940-90905 docs for the 64k tape system). However, I assume in theory it should be capable to be programmed to read & write the tapes on flux reversal level (including random gap lengths).

These are many assumptions, I know, but F.Ulivi has implemented the TACO chip for emulation, which gave us some more findings on it, although still being far from having a complete understanding. The analysis by the way also showed that the 9845 tapes are in fact SIF-tapes, where the full file system is stored into one single, large SIF file with record size of 256 bytes. Consequently, with the SIF utilities for the 9845 you also have access to SIF tapes (on file base, not for reading the low level data).

As a summary, it should be theoretically possible to process any DC100 tape with a device equipped with a TACO chip. Probably except (here it comes) Series 80 tapes. I have a strong feeling that the Series 80 (not equipped with TACO by the way) uses different writing currents and/or read sensitivity, although I did not check them yet (no Series 80 tape drive at hand). I tried to use the tapes from Athana (which are new replacements for DC100 for use in Series 80 computers) with a 9845 and got negative results, but they seem to work in a Series 80.

-Ansgar


 


On Feb 20, 2017, at 2:32 PM, Rik Bos <hp-fix@...> wrote:

The 9877 tape drive comes with a utility tape which contains the tape copy software, a binary file ;)

Do we have the contents of that tape?  Is it meant to run on a 98x5 system or does the 9875 load it into its own memory (which is fairly small, I think)?


Jack Rubin
 

I don't think this moves us ahead - page 15 of the 9877 manual says that "binary files cannot be duplicated with the dupc statement. If binary files are detected on the master cartridge, error 57 will be printed and the file will only be marked." It then carries on with a discussion of Record Memory and Load Memory, again noting that "binary programs will not be recorded when a record memory (rcm) is executed". 

What is the rationale for making binary copies impossible? Is this intended as a copy protection mechanism by HP or is it a version of kernel space/user space?

Can the assembler/editor dump memory in a usable format that preserves binary content?

Jack



 

Yes, it’s on my to do list.

But I don’t have a 9877 tape drive, but I know the museum has one including the interface and if I’m correct also a copy of the tape.

I’ve send the interface with the tape (I believe) to Jon about two or three years ago.

The tape number is 09877-10002 Tape binary

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Craig Ruff
Verzonden: maandag 20 februari 2017 22:47
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

 

On Feb 20, 2017, at 2:32 PM, Rik Bos <hp-fix@...> wrote:

 

The 9877 tape drive comes with a utility tape which contains the tape copy software, a binary file ;)

 

Do we have the contents of that tape?  Is it meant to run on a 98x5 system or does the 9875 load it into its own memory (which is fairly small, I think)?


 

Using the rcm command should dump the complete contents of the RAM on tape, which should make it possible to distil the binary from it.

But maybe we should think about designing a tape emulator with an usb interface or sd card to replace the tape drive.

The head data is serial, tacho eot signals could be generated very simple. The crux would be converting the serial head data to an analogue signal for the tape controller and visa versa. Converting the head analogue signal to TTL… do-able but time consuming ;)

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Jack Rubin
Verzonden: maandag 20 februari 2017 23:07
Aan: VintHPco
m@groups.io
Onderwerp: Re: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

I don't think this moves us ahead - page 15 of the 9877 manual says that "binary files cannot be duplicated with the dupc statement. If binary files are detected on the master cartridge, error 57 will be printed and the file will only be marked." It then carries on with a discussion of Record Memory and Load Memory, again noting that "binary programs will not be recorded when a record memory (rcm) is executed". 

What is the rationale for making binary copies impossible? Is this intended as a copy protection mechanism by HP or is it a version of kernel space/user space?

Can the assembler/editor dump memory in a usable format that preserves binary content?

Jack

 


Paul Berger
 

I just looked at the service guide for the 9877 and it is a completely different animal from the 9875.  It does not look like it has any internal intelligence, but rather depends on the 9825 to do all the work, where as the 9875 has an embedded controller to run the tapes and manage the HPIB interface.

Paul.


On 2017-02-20 5:46 PM, Craig Ruff wrote:

On Feb 20, 2017, at 2:32 PM, Rik Bos <hp-fix@...> wrote:

The 9877 tape drive comes with a utility tape which contains the tape copy software, a binary file ;)

Do we have the contents of that tape?  Is it meant to run on a 98x5 system or does the 9875 load it into its own memory (which is fairly small, I think)?


 


On Feb 20, 2017, at 3:07 PM, Jack Rubin <j@...> wrote:

What is the rationale for making binary copies impossible?

My guess it is an income generator.


David Collins
 

Sounds like my cue to start searching...

David Collins


On 21 Feb 2017, at 9:15 am, Rik Bos <hp-fix@...> wrote:

Yes, it’s on my to do list.

But I don’t have a 9877 tape drive, but I know the museum has one including the interface and if I’m correct also a copy of the tape.

I’ve send the interface with the tape (I believe) to Jon about two or three years ago.

The tape number is 09877-10002 Tape binary

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Craig Ruff
Verzonden: maandag 20 februari 2017 22:47
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

 

On Feb 20, 2017, at 2:32 PM, Rik Bos <hp-fix@...> wrote:

 

The 9877 tape drive comes with a utility tape which contains the tape copy software, a binary file ;)

 

Do we have the contents of that tape?  Is it meant to run on a 98x5 system or does the 9875 load it into its own memory (which is fairly small, I think)?


 


On Feb 20, 2017, at 3:59 PM, Paul Berger <phb.hfx@...> wrote:

I just looked at the service guide for the 9877 and it is a completely different animal from the 9875.  It does not look like it has any internal intelligence, but rather depends on the 9825 to do all the work

Yes, that is exactly what is going on.  The minimal interface card has some buffer logic and select code detection logic that, essentially, adds 1 to 4 external tape drives to the 9825, and the equivalent of the built in tape controller is present for each drive, each enabled by the corresponding low order bits of the select code.  That explains the comments in the 9825 tape firmware, and why the current “cassette select code” is kept in RAM.  Interestingly, the “ssc” command used to set the current cassette select code is not documented in the 9825B operating and programming guide, as the 9877 was discontinued by then.  The command is still implemented in the firmware, so if you have a 9825B/T, you can attach a 9877 and continue to use it.


Dyke Shaffer
 

Paul,  am pretty sure the 9877 was just 4 9825 tape drives and their 4 discrete controller boards out of the 9825 set to individual peripheral address, do remember seeing them from time to time in production area.

Regarding the 9875 dual tape drive, this was known by the internal project name Spinner, and as best remember was a BPC alone with a pair of TACO controlling the two tape drives.

Turns out the source code for the 9875 has been preserved and is available to review if there were interest,  Dyke


 

On Oct 24, 2018, at 09:51, Dyke Shaffer <dykeshaffer@gmail.com> wrote:

Turns out the source code for the 9875 has been preserved and is available to review if there were interest, Dyke
Yes please, I have a 9875. It's not quite working at the moment, it seems it wants to spin the tapes in the opposite direction from the 85 and 9825.