I have a bunch of DECTAPE II cartridges from which I want to try recovering as much data as possible, including the console cartridges for my VAX-11/730, none of which have managed to boot the machine. Inspired by the various floppy disk imagers I have, my thinking has wandered in the direction of building an imaging device using a TU58-XA mechanism and my own drive electronics. I happen to have a few TU58-XA mechanisms sitting about to experiment with. The imagined imager would sample both tracks simultaneously with ADCs so that I could post-process the data repeatedly from a single physical pass past the heads. Maybe I'd even hack in the missing optical end-of-tape sensor rather than relying on the written end-of-tape signals. This scheme might let me recover data from tapes which confuse the normal TU58 drive electronics (say, because of corrupted sector marks).
With that in mind, I dug into a box of acquired tapes to select a sacrificial dummy for experimentation, and picked out one labeled "NFG" by the previous owner, figuring I had nothing to lose with that one. Inspection revealed that the drive belt had broken and was stuck to the tape, and as expected, it peeled the oxide right off when I removed it. Is there any way to remove pieces of stuck drive belt from these tapes without harming the underlying oxide?
Next, I moved on to trying to replace the drive belt with a Plastiband brand elastic band, as I've previously seen discussed for tape cartridges with this style of mechanism (including the larger QIC cartridges). I used the 2-1/8" size, and found that it seemed to be of suitable diameter to stretch around the required path. However, I have had no luck getting it to stay in place when the tape is moved. It quickly jumps off and gets tangled when I drive the tape, and I suspect that it's because these Plastibands are a bit too narrow to properly ride the crowned drive wheel and idler rollers.
Let me interject that I have nothing good to say about this belt-driven cartridge design. I thought it was a bad design the first time I encountered one, and nothing has changed my opinion since then!
Now I finally get to the main topic I'd like to discuss: "Destructive" imaging of DECTAPE II media. By eye, the DECTAPE II tape media looks very close to the same width as normal audio cassette tape. What if I built an imaging drive in which I remove the tape from any DECTAPE II cart to be imaged rather than trying to use the original &(#$%*$ belt drive system? I wonder whether there's any prior art for a scheme like this.
One idea would be to transplant the tape media into a cassette tape housing, but I'm not yet sure whether that might offer any advantages over building an ad-hoc open reel system, or even a reel-less system since any given tape would only be run past the heads a small number of times in one event, and then might be discarded once any remaining data is extracted.
I have doubts that a cassette transport's pinch roller and capstan system would work well for this scheme, since the normal tape speed of a DECTAPE II is over 15x the tape speed of an audio cassette. So, I'd probably need to fashion a different sort of capstan system, possibly negating any advantage of using cassette tape housings. I'm not sure whether it would be better to pull the tape with a capstan and pinch roller drive vs. pulling it with a take-up reel hub and providing a free-spinning capstan with an optical encoder to provide tape speed feedback. Either scheme would allow me to move the tape past the head at constant speed, but I'm not sure if one scheme might be easier to build than the other.
Next, the imaginary device would need appropriate heads. I might salvage the head from a TU58-XA, though that could be a bit challenging since the heads are epoxied in place after adjustment. Or, maybe I would get lucky and discover that the heads from an auto-reversing audio tape deck (which I believe have four gaps in order to play stereo tapes in either direction without flipping them) might have gaps in the right places for reading both tracks of DECTAPE II media? Audio cassette tape heads have a few potential advantages, including not being epoxied in place and having a tape alignment guide welded on one side.
What do you folks think about this silliness?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
On 2015-01-31 19:00, cctalk-request at classiccmp.org wrote:
> On 01/30/2015 11:23 AM, js at cimmeri.com wrote:
>> It's not a pond.. it's an ocean. Why do some people insist on
>> calling it a
>> pond?
Because a pond is rather smaller than an ocean.
The same logic as when I was at school and milk was known as "bull",
because milk comes from a cow, which is the opposite sex to a bull.
Hello,
I'm developing a system similar to VTserver for PDP11, but for DG Nova
machines.
The system uses a serial console connection and a Python back-end on the PC.
Now I need to debug the binary code developed for the Nova, but I have
to do it on
an emulated machine on a PC.
In other words, I would need to use SIMH connected to a real serial
port: is it possible?
Thanks
Andrea
I am offering (for free) ACM publications I?ve accumulated over 40+ years as a subscriber:
CACM (Communications of the ACM) 1967-2013
ACM Computing Surveys 1972-1997
SIGOPS Operating System Review 1972-2011
TOCS (ACM Transactions on Computer Systems) 1983-1991
In all, they fill about 7 file boxes. There are some gaps because I?ve already donated batches to ACM and the Computer History Museum to fill gaps in their archives.
I live in Mountain View, California, and it would be best if you could pick them up. If you?re willing to pay for postage and packaging, I could mail them media mail rate within the US.
Paul McJones
Hello,
I also have an 11/730, but not working yet and it needs to be restored.
The TU58 are all rusty, so probably should be replaced.
I tried to find a complete TU58 system (mechanics + board) to read the
cassettes, modify firmware to format DC100,
and in the end to replace the bad one in the 730, but no luck so far
(anybody has a suggestion on how to find one?)
I have a bunch of cassettes of original software, including console
tape, but they all suffer from sticky belt problem.
I always avoided to move the tape to avoid the hole spot problem, and
stored all of them in vacuum packaging together with silica-gel,
waiting for a good restoring procedure and suitable hardware.
In these days I read all these posts about reading the tape in different
way, that gave me an idea:
I have a TASCAM 4-tracks recorder that was using normal audio tapes.
As the tape width is the same, and also track position is similar, I
could try to move the tape from a TU58 cassette to an audio cassette,
then read it on the 4-tracks. The machine has a knob to adjust head
position slightly, so it could help.
I don' t remember if the speed of the tape could be adjusted too (maybe
normal / double).
Sampling the audio with a good sound card could give some good data to
be elaborated to extract data,
of course a filtering/recovery algorithm has to be developed (using
Matlab/Octave)?
If the procedure would prove to be working, I could offer my help to
image tapes, specially for 730 as they would be very useful
also to restore my machine (I really would like to have diagnostic tapes).
This procedure could work?
Andrea
> From: Al Kossow
> I just bought a big selection of difference sizes of Norprene tubing
> from US Plastics to see how they work on various QIC drives. The first
> ones I'm trying are the HP 9145 and TU58.
If/when we get our wiki up, the outcome of your work would be a great thing to
record there. (If you're too busy, I would be more than happy to scribe for
you!)
I, for instance, have a TU58 I'd like to get running some day, but given that
I have about 173 higher-priority things on the list in front of it, I'm sure
that by the time I get to it, I'll have some dim memory that it was talked
about here, but short of good luck with Google, or a voluminous search
through the archives, I won't be able to find what I need - and I'll have to
ask... :-( Had we all that kind of stuff in a wiki, on the other hand... :-)
Yes, not everyone will be diligent enough to check the wiki before they ask,
but hey, if they don't, you all can enjoy yourself flaming them for not being
willing to exert themselves to learn how to fish, before asking to just be
given some.. :-)
Noel
On 30 January 2015 at 23:43, js at cimmeri.com <js at cimmeri.com> wrote:
>
>
> On 1/30/2015 5:35 PM, Jules Richardson wrote:
>>
>>> And "whilst" I'm at it, why do some insist on using "blinkenlights" in re
>>> CPU front panels instead of correct English -- blinking lights?
>>
>>
>> Because it's mildly amusing.
>
>
> Maybe the first time it was... :)
It's not only that. It's because 'blinking lights' is generic, it
could mean anything. But 'blinkenlights'.. you'll *know* what it
means.
Here:
http://www.ebay.com/itm/141300893919
The seller has them listed at 'Buy-It-Now' for $1,800, but the listing does
say 'make an offer', so you might be able to get it down a ways, to something
more reasonable. They seem like they have an interesting (non-identical) set
of peripheral cards. However, I know nothing of HP's, so take this all with a
large grain of salt!
Noel
-----Original Message-----
>From: Noel Chiappa <jnc at mercury.lcs.mit.edu>
>Sent: Jan 30, 2015 5:19 AM
>To: cctalk at classiccmp.org
>Cc: jnc at mercury.lcs.mit.edu
>Subject: Re: strange number corruption on pdp11/34
>
> > From: Don North
>
> > So here is the octal print routine in the M9312 console boot prom for
> > the '34:
>
>I'm curious, is that the 'original' source, or is this dis-assembled from the
>PROM contents? Is the complete program available somewhere?
Disassembled and re-commented source. Available here:
http://ak6dn.dyndns.org/PDP-11/M9312/
along with most all of the other M9312 boot and device PROMS.
>
> > So I would speculate either 'rol' or 'rolb' are always rotating in a 0
> > bit instead of the c-bit, or possibly the c-bit is stuck at zero.
>
>Yup, good suggestion. And that would likely explain why things boot; I can't
>see too many OS's using 'ROLB'!
>
> Noel