[rescue] Getting QIC tapes images

Fri May 15 15:44:36 UTC 2026

It's always worth a shot to approach them. Although my hunch is the typical
materials they use for audio drive belts is very different. The cartridge
drive belts are very thin and with very little elasticity in comparison to
an audio drive belt. And audio drive belts don't need to rapidly reverse
direction and accelerate/decelerate. However if the classic computer
community shows a wnough interest in replacement belts, it may be enough of
a business case to get someone to get something made. I'm sure China has a
fab that can made them to those original 3M specs.

This has been something that has been on my mind for a while. It's a shame
that all these cartridge tapes become completely inoperable due to a single
band that could probably be made pretty easily with the right fab.  I have
some tapes that are still in shrink wrap that already have their bands
snapped. I agree this whole use of plastibands and baking the old bands,
etc is such a waste of time with such inconsistent results.

Furthermore I think it's not just one time data extraction, but there is
plenty of vintage hardware where the way to install the OS is through QIC
tapes - I'm thinking early Sun and Apollo among others. So making
aftermarket bands available would be in valuable from a preservation
perspective to keep these machines running.

-Kurt

On Fri, May 15, 2026, 08:08 John Hudak via rescue <rescue at sunhelp.org>
wrote:

> I've seen/read a number of 'gum band/rubber band approaches to find
> replacement belts for the tape transports.  Why not get a 'real' belt from
> houses that sell replacement belts for classic audio gear?  It is fairly
> easy to measure for the length of a belt, and the width which can be used
> to find a replacement.  There are guides on the web that explain how to
> take into account tightness/stretch to have it function properly and avoid
> over tightening that will cause bearing degradation and   misalignment.
> Many places have interactive search windows in which you enter the belt
> specifics and it will search its data base for the closest match.
> Some places will actually make a belt to your specs. Places I've dealt
> with in the past include:
> Turntableneedles.com, lpgear.com, vintage-electronics.net,
> turntabledrivebelts.com.
> One can also get a belt that is close that can be cut and glued to the
> appropriate length.  This approach works best for flat belts although it
> can be done with square or rectangular belts with some patience and good
> dexterity.
> Am surprised this hasn't been done before given the number of digital tape
> machines out there.
>
> I get the idea of a quick fix just to get data off of tapes and never use
> the device again but all that time to try various suppliers products
> without repeatability seems like a huge time sink.  In addition, the
> findings may not be repeatable.  The designated mfg may change the product.
> Eventhough they may claim the same, it can be different
> J
> .
>
> On Fri, May 15, 2026 at 9:36 AM Alan Perry via rescue <rescue at sunhelp.org>
> wrote:
>
>> I have the green plastibands and the clear bands. I have found that the
>> clear bands have too much tension and can lift material from the tape. The
>> tension of the green bands vary and it seems like there is a window where
>> they work best.
>>
>> The tapes came with a Sun 3/160 based Model 32, and some are clearly for
>> it. My goal is to restore the CADDStation and I hope all of the software is
>> there on the tapes.
>>
>> Where can one find copytape for SunOS?
>>
>> I was able to use tapetool to extract a file called tapedir from two
>> different tapes
>>
>> alan
>> On 5/14/26 11:35 AM, Clem Cole wrote:
>>
>> First, what are you using for bands?  (size and manufacturer).
>>
>> With regard to the tape itself, given that these are old tapes, assume
>> you will get one shot in the transport.  So I >>highly<< recommend using
>> the old 1985 copytape utility from the USENET (pdf of its man page of
>> the command and the format it writes attached), and creating a tape
>> image you can decode without needing to touch either the tape or the
>> transport.   If you don't have it, send me an email off-list, and I'll be
>> happy to provide it to you.
>>
>> copytape will attempt to read 262144 (256K) bytes at a time.  On a QIC
>> drive, which has fixed-size (512-byte) records, that will equate to 512 blocks
>> (on a 9-track, which used variable-sized records, each 256k read, will
>> return as many bytes as were written on that tape record, which can be a
>> small integer to no more than 65536 (64K bytes).   Copytape will read
>> tape marks. Tape "files" are delineated by tape marks.  On drivers that
>> were written properly, the last "tape file" will have a second tape mark [
>> *i.e.*, two in a row] to delineate EOT. Note that many of the QIC
>> drivers do not do that (and neither did Ken's original 9-track tape driver
>> for Fifth Edition and IIRC Sixth, but by then a number of us had rewritten
>> to 9-track drivers to be  much smarter, but I digress)
>>
>> Once you have a copy of the tape in "copytape" format, you can decode it
>> much more easily.
>>
>> As for the format itself, it depends on which Computer Vision system
>> wrote it.   Their early systems were based on DG Novas and ran RDOS
>> (similar to DEC's RT11).  From the late 70s until the mid 1980s, they
>> replaced RDOS with their own OS called CGOS (Computervision Graphics
>> Operating System), and by the late 80's, early 90's, they had ported their
>> CADDS system to run on UNIX and started shipping it on Suns. Finally, they
>> got bought by Prime, and then moved it again to PRIMOS.
>>
>> Given that this is a QIC tape, the time frame says either late CGOS or
>> SunOS, although Prime might have supported QIC; I never saw anything but
>> 9-track on their systems.
>>
>> So ... if it was written on an early CV system, it is likely to be in
>> what DG called MTIO format or possibly in the DG backup format.  Data
>> General’s RDOS natively used raw, streaming sequential blocks without a
>> complex, metadata-heavy file system structure, such as ANSI labeled tapes
>> (DEC often used a superset - embrace and extend - ANSI tape format).   I
>> don't know what CGOS used, but I suspect it was similar to the DG style.
>>  If it was written on a Sun or other UNIX box, it is likely to be TAR
>> (hopefully) or CPIO.  If the latter, there is a slew of different CPIO on
>> tape formats - this is historical because it was created for PDP-11s and
>> was a binary format.   It could also be one of the many UNIX backup
>> formats, so you will need to do a little examination to determine which
>> one.  Modern versions of the original V7 Unix file(1) >>might<< be able to
>> identify the format. Finally, like DG, Prime opted not to use DEC-style
>> (pseudo-ANSI) labeled file structures natively. Instead, they also created
>> their own proprietary, streaming binary format deeply tied to PRIMOS’s
>> unique disk architecture and character encodings.  I've never seen
>> documentation on this format.
>>
>>
>> On Thu, May 14, 2026 at 9:44 AM Alan Perry via rescue <rescue at sunhelp.org>
>> wrote:
>>
>>> I seem to have found a working combination of drive and replacement's
>>> bands to be able to get images of the dozens of Computervision install
>>> tapes that I have.
>>>
>>> They are QIC-24 from the late 80s and aren’t in the “collection of tar
>>> files” format that I usually use mt fsf and dd to read. Each tape starts
>>> with a file with a “tapedir” record with permission and other stuff,
>>> followed by a bunch of records that look like a number followed by a topic
>>> or title. What am I looking at and what do I use to get the info off of the
>>> tape?
>>>
>>> alan
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
>>>
>> _______________________________________________
>> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
>>
> _______________________________________________
> rescue list - http://sunhelp.org/mailman/listinfo/rescue_sunhelp.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20260515/27e89a0e/attachment.html>