(Classic Computers) HP 7970 1/2" 9-Track Reel-to-Reel Tape Drive

Jack Harper harper at secureoutcomes.net
Tue Oct 3 20:17:33 CDT 2017


Hello Jay et. al...

I appreciate the feedback.

I begin to understand - so, for example an HP2100 with the 7970 tape 
option had a specific tape controller board that talked direct to the 7970.

That certainly makes sense.

I never used an HP2100 with a "real" tape drive such as the 7970 - 
actually just paper tape back in 1974-1978 where I wrote in ASM (a 
bit ugly with no index register) and ALGOL (I still have the box of 
paper tapes somewhere with that four pass ALGOL compiler  - that nice 
black oiled paper with the smell  :)

I am delighted to hear that people have actually built a 7970 
interface and got it to work mostly in pure software.

That is good news and gives me hope :)

It sounds fairly straightforward with GPIO and a simple processor and 
probably a good sized chunk of fiddling around with timing and all 
that - e.g., gap detection.

The clocked data would certainly be a help.

The obvious(?) thing to do would be to wire-wrap a custom VME board 
similar to what Chuck Guzis did to interface into the 68K system that 
I have put together - but, I am far stronger in software than 
hardware (for sure) and the VME interface would be a headache for me 
- probably the main headache.

But, I could cure that by simply using a small processor of some sort 
on the wire-wrapped VME board and just draw power for that from the 
VMEbus - and transmit the data back and forth to the MVME177/68060 
processor board (actually five of those in my rack) across something 
simple such as serial or some such, though would certainly be better 
to go through the VMEbus.

Interesting indeed.

Jay, I appreciate the helpful response.  Thank you.

I will read the 7970 interface specifications more carefully now that 
I understand better the context.  The timing issues are, of course, key.


Regards and my best to the list.

Jack





At 06:30 PM 10/3/2017, Jay West via cctalk wrote:
>Jack wrote....
> > Question:  I understand that most (all?) of the '7970 drives 
> interfaced through the HP-IB IEEE-488 bus.
>
>To which AEK replied....
>------
>wrong.
>
>full stop.
>------
>
>Welcome to our nook of the net. The grizzled veterans are here, and 
>there's quite a few HP 2100/21MX folks lurking about. Ask away....
>
>To start... Al is correct. The 7970A/B used a basically proprietary 
>interface. So did the 7970E, but on the E you could get an HP-IB 
>option. I've never once seen that option in the wild though, so I 
>don't think one would say "most" had it. I do have a handful of 
>7970E's running and a 7970B I should probably get rid of.... Chuck 
>Guzis had recently posted the following which may shed light:
>
>----- Chuck Wisdom Follows ------
>If you're accustomed to a Pertec interface, then the 800 interface 
>isn't terribly different, just dumber.  You still have a connector 
>for the basic motion and status commands (i.e. forward, reverse, 
>rewind, high-speed and online, loadpoint, ready, protect) and you 
>have two 8-bit+parity clocked data channels for read and write 
>respectively, each with their own connector.
>
>However, there is no formatter, as on Pertec interface drives.  You 
>get the raw, framed and deskewed data on read and pretty much 
>anything you want to put in on write.   No "handshaking" as the 
>interfaces are not buffered. {snip} The lack of a formatter means 
>that you'll have to do the work of gap detection, parity 
>checking/generation and CRC/LRCC interpretation and generation 
>yourself, as well as manage the control lines.
>
>I used a small STM32F407 MCU board (about $10) which has lots of 5V 
>tolerant I/O, so receiving data and status is no problem.  For 
>driving control lines, simply set the GPIO pins for open-drain operation.
>There's something like 24ma of sinking capacity on those, so again, 
>no need for intermediate logic.   Since I'm interested in reading 
>tapes, but not writing them, I can't address the issue of what to do 
>about that end.  My setup uses a serial port for interaction and a 
>USB port that makes the onboard SDHC look like a generic storage 
>device.  So, read a tape, dump the data into the SDHC (Chan's FATFS 
>software is useful); suck it out via the USB port to a PeeSee.
>
>To handle 1600 PE data would require yet another layer of software.
>--------------------------------------
>
>Hope this helps....
>
>J

----------------------------------------------------------------------------------
Jack Harper, President
Secure Outcomes Inc
2942 Evergreen Parkway, Suite 300
Evergreen, Colorado 80439 USA

303.670.8375
303.670.3750 (fax)

http://www.secureoutcomes.net for Product Info. 



More information about the cctalk mailing list