On 10/2/23 06:03, Johnny Billquist wrote:
>>> It's not you - it's Johnny. He's just like that with everyone. :-)
>>
>>    Sure, but he's just usually nicer to me on some of the mailing
>> lists. ;)  Every highly intelligent person has one "thing" or another.
>> Johnny's is grumpiness, it's ok. :)
>
> I don't think I was unnice here. OP asked for a cryoflux-like solution.
> I said that's going to be hard. You disagreed, while not getting what he
> asked for. And claiming you can do it. In the end, you also understood
> the point and that a cryoflux-like solution is going to be hard.

I re-read the OP's posts. He didn't ask for a Kryoflux-like solution
there. In a subsequent post he asked for "raw disk images of all the
platters". He used the word "platters" where he clearly meant "packs".
taking all of this into consideration led me to believe that he's
looking to recover the files, and achieving that goal certainly needn't
involve flux-transition images, assuming the disks aren't corrupt.

I didn't claim we could do it; I claimed that we have all of the
required equipment. That equipment is not yet operational. When/if it
is made operational, then we can do it.

>>    We should import him to the States so he can help us work on
>> machines at the museum!
>
> In a sense I'd love it. But I also need to earn some money, and I
> suspect you don't havae budget for a salary. ;-)

No, we are an all-volunteer outfit. We may eventually have paid
employees, but in the interest of actually continuing to exist, we're
not taking that step yet.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On 10/2/23 05:59, Johnny Billquist wrote:
>>    I don't know why you're being so argumentative today.  I hope
>> everything is ok.
>>
>>    LSSM is not going to be doing any flux-transition imaging on a
>> 9766. If that's what the OP wants, he's not going to have an easy time
>> finding it.  We could certainly do it with a lot of time and money,
>> but there aren't a lot of 9766 packs out there anymore, so it really
>> wouldn't be worth the investment in time and effort.
>
> I'm not being argumentative, I think. I'm just trying to keep this to
> what the OP was writing. You offering something else is fine, but you
> need to understand that it was not what was suggested by the OP. And
> when I say that what the OP was suggesting is going to be very hard, I
> don't appreciate when you disagree with me, when you in the end appear
> to understand that what I said is correct - it is going to be very hard.

I still don't know where flux-transition imaging came into this
thread. It's not what the OP asked for. If you go back and re-read
what he said, I'm sure you'll reach the same conclusion.

Or perhaps he'll just speak up and clarify it. If he DOES actually
want flux-transition imaging, I'll stand corrected and apologize. And
if that IS what he wants, he's unlikely to ever get it, and I'd then go
down the road of trying to ascertain WHY he wants it, as he certainly
doesn't need it if the packs' data isn't corrupt and we have a way to
get at the files. If he's interested in something lower-level than the
files, like recording techniques etc, he can get that from the CDC
documentation for the drive, so logically, the files are the only thing
he could really be interested in. And we can get those without
flux-transition imaging.

> If anything, I would say you are being argumentative, for no good reason.

Please don't take it that way. I had no intention of being
argumentative at all.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On Monday, October 2, 2023 at 10:56:22 AM UTC-5, Dave McGuire wrote:
> On 10/2/23 05:59, Johnny Billquist wrote:
> >> I don't know why you're being so argumentative today. I hope
> >> everything is ok.
> >>
> >> LSSM is not going to be doing any flux-transition imaging on a
> >> 9766. If that's what the OP wants, he's not going to have an easy time
> >> finding it. We could certainly do it with a lot of time and money,
> >> but there aren't a lot of 9766 packs out there anymore, so it really
> >> wouldn't be worth the investment in time and effort.
> >
> > I'm not being argumentative, I think. I'm just trying to keep this to
> > what the OP was writing. You offering something else is fine, but you
> > need to understand that it was not what was suggested by the OP. And
> > when I say that what the OP was suggesting is going to be very hard, I
> > don't appreciate when you disagree with me, when you in the end appear
> > to understand that what I said is correct - it is going to be very hard..
> I still don't know where flux-transition imaging came into this
> thread. It's not what the OP asked for. If you go back and re-read
> what he said, I'm sure you'll reach the same conclusion.
>
> Or perhaps he'll just speak up and clarify it. If he DOES actually
> want flux-transition imaging, I'll stand corrected and apologize. And
> if that IS what he wants, he's unlikely to ever get it, and I'd then go
> down the road of trying to ascertain WHY he wants it, as he certainly
> doesn't need it if the packs' data isn't corrupt and we have a way to
> get at the files. If he's interested in something lower-level than the
> files, like recording techniques etc, he can get that from the CDC
> documentation for the drive, so logically, the files are the only thing
> he could really be interested in. And we can get those without
> flux-transition imaging.
> > If anything, I would say you are being argumentative, for no good reason.
> Please don't take it that way. I had no intention of being
> argumentative at all.
> -Dave
>
> --
> Dave McGuire, President/Curator
> Large Scale Systems Museum
> New Kensington, PA

Hi all,

Yes, the primary goal is to get the data off of the paks. We really don;t know what is on them. Based on other items I have archived from that period (9-track tapes, RL02 paks and 8-inch floppy disks.
they could be VMS, Unix, Data General AOS/VS or even RT-11.

The other idea was to get raw images made from the paks as to use in emulation if manual recovery does not work.

First and foremost, we are after the files and data that is on them.

On Monday, October 2, 2023 at 8:56:22 AM UTC-7, Dave McGuire wrote:
> On 10/2/23 05:59, Johnny Billquist wrote:

(snip)

> I still don't know where flux-transition imaging came into this
> thread. It's not what the OP asked for. If you go back and re-read
> what he said, I'm sure you'll reach the same conclusion.
That was me.

Well, also, the OP mentioned "images of them" in addition
to reading the files.

Flux transition imaging is especially useful if you don't have a running
model of the host that is supposed to read them. Even more, if you
don't know what host that is.

There are cases where you have the right drive to use with the disk
pack, and host that works with the drive, but not host that can
read the data.

As I understand it, SMD flux transition imagers exist.
Also, if I follow the discussion right, VAX doesn't know
about SMD drives.

> Or perhaps he'll just speak up and clarify it. If he DOES actually
> want flux-transition imaging, I'll stand corrected and apologize. And
> if that IS what he wants, he's unlikely to ever get it, and I'd then go
> down the road of trying to ascertain WHY he wants it, as he certainly
> doesn't need it if the packs' data isn't corrupt and we have a way to
> get at the files. If he's interested in something lower-level than the
> files, like recording techniques etc, he can get that from the CDC
> documentation for the drive, so logically, the files are the only thing
> he could really be interested in. And we can get those without
> flux-transition imaging.

When I mentioned it, not all the details were out.
I am not sure all details are out yet.

In any case, yes, if you can read the data without flux transition
imaging, might as well do that. But if you can't ...

On 10/2/23 12:39, gah4 wrote:
>> I still don't know where flux-transition imaging came into this
>> thread. It's not what the OP asked for. If you go back and re-read
>> what he said, I'm sure you'll reach the same conclusion.
>
> That was me.
>
> Well, also, the OP mentioned "images of them" in addition
> to reading the files.

This can mean either flux-transition images, or, as is much more
common, byte-for-byte images.

> Flux transition imaging is especially useful if you don't have a running
> model of the host that is supposed to read them. Even more, if you
> don't know what host that is.

Everyone here knows that.

> There are cases where you have the right drive to use with the disk
> pack, and host that works with the drive, but not host that can
> read the data.

Right.

> As I understand it, SMD flux transition imagers exist.

One was built, that anyone knows about.

> Also, if I follow the discussion right, VAX doesn't know
> about SMD drives.

There are plenty of SMD controllers for VAXen, including DEC's
Massbus to SMD adapters that are components of the RM02, RM03, RM05, and
RM80 drives.

>> Or perhaps he'll just speak up and clarify it. If he DOES actually
>> want flux-transition imaging, I'll stand corrected and apologize. And
>> if that IS what he wants, he's unlikely to ever get it, and I'd then go
>> down the road of trying to ascertain WHY he wants it, as he certainly
>> doesn't need it if the packs' data isn't corrupt and we have a way to
>> get at the files. If he's interested in something lower-level than the
>> files, like recording techniques etc, he can get that from the CDC
>> documentation for the drive, so logically, the files are the only thing
>> he could really be interested in. And we can get those without
>> flux-transition imaging.
>
> When I mentioned it, not all the details were out.
> I am not sure all details are out yet.

It seems they are.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On Monday, October 2, 2023 at 5:48:43 AM UTC-4, Johnny Billquist wrote:
> On 2023-09-30 01:06, Rich Alderson wrote:
> > "terry-...@glaver.org" <terry-...@glaver.org> writes:
> >
> >> On Thursday, September 28, 2023 at 5:31:07=E2=80=AFPM UTC-4, Johnny Billquist wrote:
> >
> >>> I've been reading the RM02/RM03 manuals, and I can't find any=20
> >>> documentation on any backplane jumper for such a purpose. There are
> >>> jumpers for drive type and serial number, but that's about it as far as
> >>> I can find.
> >
> >> I assume you mean in the Massbus controller in the bottom of the drive..
> >> The actual drive logic cage has not very many not very big not very bright
> >> cards. As I recall, maybe 5" x 5". I modified a couple sets of drive cards
> >> to change the upper cylinder limit. I was subcontracting data recovery
> >> and they'd send me crashed-but-cleaned packs and tell me "don't go past
> >> cylinder X" when doing the recovery.
> >
> > The DCL ("DEC control logic") on an RP06 is about a dozen hex height boards in
> > a special card cage on the side. The little 5"x5" cards in the top of the
> > drive are Memorex (the OEM).
> The RM and RP massbus interfaces are very different. Which, in a sense,
> is surprising, since I think they all have SMD in the end.

Indeed. Which is what makes the RP07 an oddity, since it is branded an
RP but is actually an RM Massbus device. Whether mixed RM/RP devices
worked or not was probably dependent on the particular operating system.
And even if it "worked", it might not have been "supported". For example,
RSTS/E would get very upset if you swapped unit numbers between dis-
similar drives (of any type, including MSCP which should have Just Worked)
while the system was up. I know, "Why would you ever want to do that?" But
it was apparently common enough that it made it into the release notes.

> But for the RM02/03 the massbus adapter sits below the disk in the same
> housing as the drive. The RM05 is yet again different and have it sortof
> on the side, but you can actually hook up two drives to the same massbus
> interface. And the RP04/05/06, as you note, have a side attachment to
> the drive, where the massbus interfacing sits. Also with the RP drives,
> DEC actually have a modified SMD interface, so no normal SMD drive can
> be conntected. And the drive from Memorex (was there some other source
> as well?) actually is of a special DEC variation, with a couple of cards
> not being the same as when the drive was sold as an SMD drive.

The RM05 Massbus cabinet could hold two Massbus adapters, so one
cabinet could serve two drives, but with separate Massbus adapters. This
is what I don't understand - the Massbus drive status and attention registers
had per-drive bits, and there's no reason a Massbus controller couldn't set
more than one drive bit and connect to multiple drives. I don't remember if
the 3rd-party controllers emulated multiple Massbus adapters, but I suspect
they did.

The RM05 dual-Massbus adapter is the reason that 3' Massbus cables
exist.

The RP07 was a Sperry/ISS drive.

Speaking of cabling oddities, I discovered that you can't actually have a
full string of RK07 drives on an RK611 (yes, I switched from talking about
RP07 to RK07 drives, but bear with me). Using the shortest DEC cables,
the propagation delay through a string of 8 RK07 drives caused all sorts
of oddball errors. After Field Service escalation, the answer from Engin-
eering was "We didn't think anybody would ever do that." 5 drives was
always safe, 6 drives was iffy, 7 and 8 were definitely problematic. Given
the DD11-DK sized backplane that was the RK611, multiple controllers was
not a viable option.

> > I don't understand what you mean here. We had strings of up to 8 RP07 or RP06
> > drives on our DEC-20s.
> Terry talks about tape drives as a comparison. For those, you have the
> formatter (usually a TM03) which is what actually sits on the massbus.
> One formatted can control up to 8 tape drives, meaning you could have as
> many as 64 tape drives on one massbus.

All of my TU78's were equipped with TM78 formatters, but that wasn't
the case at a number of other sites.

The TM78 was a hotbed of FCO activity - the wrong capacitors were in-
stalled on some of the formatter boards, and the first round of FCO
changed the wrong capacitors to different wrong capacitors. Of course,
this was an "Improvement" FCO, meaning non-contract customers had
to pay for the FCO kit and installation. The most famous example of
"Replace a bad part with different bad part" was probably the BA23 power
harness, which had a penchant for catching on fire.

There were also a bunch of FCOs for the transport itself. I got the actual
engineering documents from Triumph Adler and made my tape drives
work perfectly. I was putting some on a Field Service contract after doing
the TM78 and TU78 FCO's myself with my own parts. The FE said he had
to run diagnostics before it would be accepted. I told him "That's fine, but
you have to hang around until the first soft error". He thought that was a
safe bet. I let him leave after 4 hours, with diagnostics still running on the
first drive with no errors at all, hard or soft. I had a semi-clandestine side
deal going where TU77/TU78 drives would show up at SPC late at night
to be rebuilt. This was reserved for customers with particularly problem-
atic drives. I don't think DEC ever got the EZ-Load II to work right, but all of
the drives that came through SPC for rebuilding loaded them just fine.

> But at the same time, that's the crux of it. For disk drives, there were
> never anything equivalent to the tape formatter with subunits.
> But it guess in theory it could have been done.
>
> But people usually didn't have that many disk drives anyway, so there
> were no real need, I guess.
> Not sure if anyone ever really ran with that many tape drives either. I
> don't think I've ever seen additional slave drives hooked up to a tape
> formatter.

There's two separate things "in flight" in this conversation:

1) Can you mix RM/RP drives on the same Massbus? Depends on the
operating system.

2) Why does each RM or RP drive require its own SMD (or pseudo-SMD)
to Massbus adapter when SMD supports 4 drives per controller? The answer
to that is unknown.

On Monday, October 2, 2023 at 5:56:55 AM UTC-4, Johnny Billquist wrote:
> If we instead talk RA-81, then I'm not sure if the drive could be
> reformatted, or if it was actually just a performatted HDA for either
> mode. The RA60 I'm pretty sure can be reformatted for 16-bit or 18-bit mode.

My recollection is that RA81 HDAs shipped formatted as either 16- or 18-
bit HDAs and could not be reformatted in the field.

The RA60 was definitely reformattable. Probably a holdover from older re-
movable pack days.

The Rx80 was an odd one and also reformattable. Part of what was due to
the drive coming in 3 flavors - RM80 (Massbus), RA80 (SDI) and R80 (the
pseudo-SMD thing that attached only to the abomination that was the
RB730 controller. AKA "Sure, I have no problem backing the R80 disk to
13 RL02 packs once a week". 8-{

On 2023-10-03 04:10, terry-...@glaver.org wrote:
> On Monday, October 2, 2023 at 5:48:43 AM UTC-4, Johnny Billquist wrote:
>> On 2023-09-30 01:06, Rich Alderson wrote:
>>> "terry-...@glaver.org" <terry-...@glaver.org> writes:
>>>
>>>> On Thursday, September 28, 2023 at 5:31:07=E2=80=AFPM UTC-4, Johnny Billquist wrote:
>>>
>>>>> I've been reading the RM02/RM03 manuals, and I can't find any=20
>>>>> documentation on any backplane jumper for such a purpose. There are
>>>>> jumpers for drive type and serial number, but that's about it as far as
>>>>> I can find.
>>>
>>>> I assume you mean in the Massbus controller in the bottom of the drive.
>>>> The actual drive logic cage has not very many not very big not very bright
>>>> cards. As I recall, maybe 5" x 5". I modified a couple sets of drive cards
>>>> to change the upper cylinder limit. I was subcontracting data recovery
>>>> and they'd send me crashed-but-cleaned packs and tell me "don't go past
>>>> cylinder X" when doing the recovery.
>>>
>>> The DCL ("DEC control logic") on an RP06 is about a dozen hex height boards in
>>> a special card cage on the side. The little 5"x5" cards in the top of the
>>> drive are Memorex (the OEM).
>> The RM and RP massbus interfaces are very different. Which, in a sense,
>> is surprising, since I think they all have SMD in the end.
>
> Indeed. Which is what makes the RP07 an oddity, since it is branded an
> RP but is actually an RM Massbus device. Whether mixed RM/RP devices
> worked or not was probably dependent on the particular operating system.
> And even if it "worked", it might not have been "supported". For example,
> RSTS/E would get very upset if you swapped unit numbers between dis-
> similar drives (of any type, including MSCP which should have Just Worked)
> while the system was up. I know, "Why would you ever want to do that?" But
> it was apparently common enough that it made it into the release notes.

The RP07 being called "RP" is one of the big mysteries...

But mixing RP and RM disk drives was usually not a big problem. They are
not exactly the same, but the register differences are mainly in some
error registers, which only matters for error reporting and diagnostics.

But OSes could obviously still have opinions on the sheer principle of it.

The more tricky one was mixing disks and tapes on the same massbus, as
then we're into much more complicated territory. I don't know if VMS
supported that. However, among PDP-11 OSes, the only one I am aware of
that allowed this is RSX-11M-PLUS.

RSTS/E, RT-11, RSX-11D, IAS and so on did not allow you to have tapes
and disks on the same massbus.

As far as I can remember, neither did the DEC-2020. Not sure about the
other DEC-20 machines.

>> But for the RM02/03 the massbus adapter sits below the disk in the same
>> housing as the drive. The RM05 is yet again different and have it sortof
>> on the side, but you can actually hook up two drives to the same massbus
>> interface. And the RP04/05/06, as you note, have a side attachment to
>> the drive, where the massbus interfacing sits. Also with the RP drives,
>> DEC actually have a modified SMD interface, so no normal SMD drive can
>> be conntected. And the drive from Memorex (was there some other source
>> as well?) actually is of a special DEC variation, with a couple of cards
>> not being the same as when the drive was sold as an SMD drive.
>
> The RM05 Massbus cabinet could hold two Massbus adapters, so one
> cabinet could serve two drives, but with separate Massbus adapters. This
> is what I don't understand - the Massbus drive status and attention registers
> had per-drive bits, and there's no reason a Massbus controller couldn't set
> more than one drive bit and connect to multiple drives. I don't remember if
> the 3rd-party controllers emulated multiple Massbus adapters, but I suspect
> they did.

Ah! Right. I had forgotten the detail that the cab actually held two
massbus adapters.

As for the multiple drives per adapter, it would have required some more
hardware in there. With SMD you have one cable that is daisychained
through each drive, and one smaller cable which you have one of for each
drive connected. So if an adapter would control multiple drives, you'd
need interfaces for each of those added cables for each drive, which
leads to a cabling problem with flat cables that needs to go longer
distances. Shielding and actual distance becomes an issue. The massbus
cables were unwieldy, but otherwise pretty simple to deal with.

So I can see the DEC point of just have one adapter per drive, and
customers only have to deal with the massbus cable.

> Speaking of cabling oddities, I discovered that you can't actually have a
> full string of RK07 drives on an RK611 (yes, I switched from talking about
> RP07 to RK07 drives, but bear with me). Using the shortest DEC cables,
> the propagation delay through a string of 8 RK07 drives caused all sorts
> of oddball errors. After Field Service escalation, the answer from Engin-
> eering was "We didn't think anybody would ever do that." 5 drives was
> always safe, 6 drives was iffy, 7 and 8 were definitely problematic. Given
> the DD11-DK sized backplane that was the RK611, multiple controllers was
> not a viable option.

Interesting. I have obviously never ran anywhere close to 8 RK07. Is the
problem the same with the RK06 then?

I think I've ran at most two drives on an RK611.

>>> I don't understand what you mean here. We had strings of up to 8 RP07 or RP06
>>> drives on our DEC-20s.
>> Terry talks about tape drives as a comparison. For those, you have the
>> formatter (usually a TM03) which is what actually sits on the massbus.
>> One formatted can control up to 8 tape drives, meaning you could have as
>> many as 64 tape drives on one massbus.
>
> All of my TU78's were equipped with TM78 formatters, but that wasn't
> the case at a number of other sites.

Fun detail: The TM02/03 formatter was used for all other massbus tape
drives. It has a set of registers, and is single port only. If you
wanted dual port for those tape drives you needed a bus switch that
basically moved the whole massbus controller between different Unibuses
(assuming you had an RH11). And of course, the formatter can control up
to 8 slave units.

The TM78 have a completely different set of registers not at all
compatible with the TM02/03. It have way more registers, and is a very
fancy formatter. It actually was dual ported, so you could connect it to
two massbuses, just like with disks. However, it can only control up to
4 slave units.

The few TU78 I've played with have all had a TM78. But just as with the
TU77, I'm sure there were places that had multiple slaves on a
formatter. I just never saw any myself.

> The TM78 was a hotbed of FCO activity - the wrong capacitors were in-
> stalled on some of the formatter boards, and the first round of FCO
> changed the wrong capacitors to different wrong capacitors. Of course,
> this was an "Improvement" FCO, meaning non-contract customers had
> to pay for the FCO kit and installation. The most famous example of
> "Replace a bad part with different bad part" was probably the BA23 power
> harness, which had a penchant for catching on fire.

Yes. I've seen/heard about FCOs for the TM78.

And let's not talk about the BA23 power...

> There were also a bunch of FCOs for the transport itself. I got the actual
> engineering documents from Triumph Adler and made my tape drives
> work perfectly. I was putting some on a Field Service contract after doing
> the TM78 and TU78 FCO's myself with my own parts. The FE said he had
> to run diagnostics before it would be accepted. I told him "That's fine, but
> you have to hang around until the first soft error". He thought that was a
> safe bet. I let him leave after 4 hours, with diagnostics still running on the
> first drive with no errors at all, hard or soft. I had a semi-clandestine side
> deal going where TU77/TU78 drives would show up at SPC late at night
> to be rebuilt. This was reserved for customers with particularly problem-
> atic drives. I don't think DEC ever got the EZ-Load II to work right, but all of
> the drives that came through SPC for rebuilding loaded them just fine.

The autoloading was always a bit finicky in my opinion. You needed to
have a fairly clean, nicely cut, and smooth tape end for it to work. But
with that, it was working pretty well on all TU77 and TU78 I used.

>> But at the same time, that's the crux of it. For disk drives, there were
>> never anything equivalent to the tape formatter with subunits.
>> But it guess in theory it could have been done.
>>
>> But people usually didn't have that many disk drives anyway, so there
>> were no real need, I guess.
>> Not sure if anyone ever really ran with that many tape drives either. I
>> don't think I've ever seen additional slave drives hooked up to a tape
>> formatter.
>
> There's two separate things "in flight" in this conversation:

On 9/28/23 17:31, Johnny Billquist wrote:
>>> Reminds me of another DEC disk, which can be used on either PDP-10 or
>>> byte addressed machines. The controllers are different, and can only
>>> write
>>> blocks with the appropriate size, which I believe is 576 bytes for
>>> the PDP-10,
>>> and 512 otherwise.  You can't read disk packs on the other one.
>>
>>    RM02/RM03.  There's a jumper on the backplane.
>
> I've been reading the RM02/RM03 manuals, and I can't find any
> documentation on any backplane jumper for such a purpose. There are
> jumpers for drive type and serial number, but that's about it as far as
> I can find.
....
> But the disk packs just have a different format depending on what they
> are used for, and that formatting can be changed on a per-track basis.
> The format is in the header for each sector.

I've only used RM02 and RM03 drives on PDP-11s and VAXen in the good
old days, and have never had to worry about it.

I was told of the backplane jumper in the Massbus adapter underneath
an RM02/RM03 for 16/32- vs. 36-bit systems by an ex-DEC field service
guy who visited the museum when we first opened.

I took this information as gospel given the source, as former DEC
employees are treated as royalty at LSSM, and made a mental note of it
as something we'll need to deal with when we get one of our -2020s running.

Last night and this morning I spent some quality time with the RM0x
documentation, as well as the documentation for the (common) Massbus
controller used with them, and can find nothing on this jumper. It
seems the ex-DEC guy was wrong about this, or perhaps he had conflated
it with the "bit fiddler" board in the TM02 tape formatter, but that
doesn't involve a jumper that I'm aware of, it's a whole different
board. (the gentleman was elderly) So I now stand corrected.

That's one less thing to worry about when we get the first
DECsystem-2020 up and running, which will hopefully be this winter.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

Johnny Billquist <bqt@softjar.se> writes:

> The few TU78 I've played with have all had a TM78. But just as with the
> TU77, I'm sure there were places that had multiple slaves on a
> formatter. I just never saw any myself.

You did, you just didn't know it. The Tops-10 KL-10 in the LCM+L computer room
(the big orange system labeled "DECSYSTEM-20" :-) had a master/slave pair of
TU78 tape drives sitting on one Massbus.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

"terry-...@glaver.org" <terry-groups@glaver.org> writes:

> On Monday, October 2, 2023 at 5:56:55=E2=80=AFAM UTC-4, Johnny Billquist wrote:

>> If we instead talk RA-81, then I'm not sure if the drive could be
>> reformatted, or if it was actually just a performatted HDA for either
>> mode. The RA60 I'm pretty sure can be reformatted for 16-bit or 18-bit mode.

> My recollection is that RA81 HDAs shipped formatted as either 16- or 18-
> bit HDAs and could not be reformatted in the field.

Your recollection is correct. We had RA81s on the CI-connected DEC-20s and
SC-30M at Stanford LOTS, and were very unhappy that the RA82 was not going to
be available in an 18-bit variant.

The HSC-50 software also came in 2 variants, for 16- vs. 18-bit HDAs on the
attached drives, which is to say, with 512 byte vs. 576 byte sectoring.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2023-10-03 20:20, Rich Alderson wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> The few TU78 I've played with have all had a TM78. But just as with the
>> TU77, I'm sure there were places that had multiple slaves on a
>> formatter. I just never saw any myself.
>
> You did, you just didn't know it. The Tops-10 KL-10 in the LCM+L computer room
> (the big orange system labeled "DECSYSTEM-20" :-) had a master/slave pair of
> TU78 tape drives sitting on one Massbus.

Figures that someone would correct me on that one. :-D

Johnny

On 2023-10-03 17:33, Dave McGuire wrote:
> On 9/28/23 17:31, Johnny Billquist wrote:
>>>> Reminds me of another DEC disk, which can be used on either PDP-10 or
>>>> byte addressed machines. The controllers are different, and can only
>>>> write
>>>> blocks with the appropriate size, which I believe is 576 bytes for
>>>> the PDP-10,
>>>> and 512 otherwise.  You can't read disk packs on the other one.
>>>
>>>    RM02/RM03.  There's a jumper on the backplane.
>>
>> I've been reading the RM02/RM03 manuals, and I can't find any
>> documentation on any backplane jumper for such a purpose. There are
>> jumpers for drive type and serial number, but that's about it as far
>> as I can find.
> ...
>> But the disk packs just have a different format depending on what they
>> are used for, and that formatting can be changed on a per-track basis.
>> The format is in the header for each sector.
>
>   I've only used RM02 and RM03 drives on PDP-11s and VAXen in the good
> old days, and have never had to worry about it.
>
>   I was told of the backplane jumper in the Massbus adapter underneath
> an RM02/RM03 for 16/32- vs. 36-bit systems by an ex-DEC field service
> guy who visited the museum when we first opened.
>
>   I took this information as gospel given the source, as former DEC
> employees are treated as royalty at LSSM, and made a mental note of it
> as something we'll need to deal with when we get one of our -2020s running.
>
>   Last night and this morning I spent some quality time with the RM0x
> documentation, as well as the documentation for the (common) Massbus
> controller used with them, and can find nothing on this jumper.  It
> seems the ex-DEC guy was wrong about this, or perhaps he had conflated
> it with the "bit fiddler" board in the TM02 tape formatter, but that
> doesn't involve a jumper that I'm aware of, it's a whole different
> board. (the gentleman was elderly)  So I now stand corrected.
>
>   That's one less thing to worry about when we get the first
> DECsystem-2020 up and running, which will hopefully be this winter.

I never used RM disks on any PDP-10, so I wasn't completely sure.
I've moved RP06 and RP07 between PDP-10 and PDP-11, and only had to
reformat the disks on those drives. So I knew that much. (Well, I did
also have to move a jumper on the RP07 to change interleave, I think it
was, in order to get it a bit slower so the RH70 would be happy with it.)

Johnny

"terry-...@glaver.org" <terry-groups@glaver.org> wrote in
news:63f32b83-4326-49fe-8f3a-31a95a44abecn@googlegroups.com:

> My recollection is that RA81 HDAs shipped formatted as either 16- or
> 18- bit HDAs and could not be reformatted in the field.
>
> The RA60 was definitely reformattable. Probably a holdover from older
> re- movable pack days.
>
> The Rx80 was an odd one and also reformattable. Part of what was due
> to the drive coming in 3 flavors - RM80 (Massbus), RA80 (SDI) and R80
> (the pseudo-SMD thing that attached only to the abomination that was
> the RB730 controller. AKA "Sure, I have no problem backing the R80
> disk to 13 RL02 packs once a week". 8-{

The department I joined for my first job out of university had an 11/730
before I started. The guy looking after it never did backups. They
ordered a memory upgrade and somehow during that the R80 was corrupted or
wiped and had to have VMS and the application we used reinstalled. A
colleague said there were games like Star Trek installed which were lost
in the incident.

We had enough RL02 packs so that each engineer could back up his own
stuff, but not enough to do an image backup of the system.

A Cipher Data M891 tape drive and Pertec controller were installed just
prior to my starting and I then implemented a regular backup to tape. Of
course, in my 11 years there the backup was never used.

I ended up acquiring the 11/730 (minus the tape drive) for a charity
donation when it was no longer needed and it sits in my basement awaiting
my restoration (some time when I retire...).

--
Clark G
* take away the em's to reply

On 10/4/23 23:13, Clark G wrote:
> I ended up acquiring the 11/730 (minus the tape drive) for a charity
> donation when it was no longer needed and it sits in my basement awaiting
> my restoration (some time when I retire...).

We have an 11/730 at LSSM as well, also awaiting restoration.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On Tuesday, October 3, 2023 at 10:15:17 AM UTC-4, Johnny Billquist wrote:
> As for the multiple drives per adapter, it would have required some more
> hardware in there. With SMD you have one cable that is daisychained
> through each drive, and one smaller cable which you have one of for each
> drive connected. So if an adapter would control multiple drives, you'd
> need interfaces for each of those added cables for each drive, which
> leads to a cabling problem with flat cables that needs to go longer
> distances. Shielding and actual distance becomes an issue. The massbus
> cables were unwieldy, but otherwise pretty simple to deal with.

[E]SMD is a 60-pin control cable that doesn't have very picky shielding
requirements and is usually implemented as rainbow twist-n-flat ribbon.
The 26-pin data cables are a bit more picky and is usually implemented as
ribbon cable mesh-shielded on one side (like the BC06R). 3rd-party SMD
controllers managed to get by just fine with those, although it was best
to stagger the 4 data cables so they didn't make a big lump under the
BA11's cable retention brackets.

I would much rather have 5 ribbon cables in one place than 4 Massbus
cables (host to adapter 1, a1 to a2, a2 to a3, a3 to a4 ). Not to mention
saving the floor space of two adapter cabinets. I've done both.

> Interesting. I have obviously never ran anywhere close to 8 RK07. Is the
> problem the same with the RK06 then?

Probably. It took a long time to track this one down as it manifested as
random errors across the string. Much sacrificing of rubber chickens
happened before DEC gave up, including replacing all of the spindles in
the string. [There was an FCO regarding "non-repetitive run-out" (AKA
"wobble" 8-)]

> The autoloading was always a bit finicky in my opinion. You needed to
> have a fairly clean, nicely cut, and smooth tape end for it to work. But
> with that, it was working pretty well on all TU77 and TU78 I used.

There were 3 parts to having it work reliably:
1) Special tape cutter/crimper that put a curved tongue on the end of
the tape with some special stiffening creases.
2) A soft gasket over the air slot in the recessed tape part of the drive.
3) Changes to the algorithm for air valve operation and load retries.

With all of those in place, loading was equal to or better than the relia-
bility on our IBM 3420 drives.

And then DEC came out with the TK50 with its leader-and-buckle
design. It says something that the replacement buckles for the drive
were only available in packs of ten...

On 2023-10-08 04:31, terry-...@glaver.org wrote:
> On Tuesday, October 3, 2023 at 10:15:17 AM UTC-4, Johnny Billquist wrote:
>> As for the multiple drives per adapter, it would have required some more
>> hardware in there. With SMD you have one cable that is daisychained
>> through each drive, and one smaller cable which you have one of for each
>> drive connected. So if an adapter would control multiple drives, you'd
>> need interfaces for each of those added cables for each drive, which
>> leads to a cabling problem with flat cables that needs to go longer
>> distances. Shielding and actual distance becomes an issue. The massbus
>> cables were unwieldy, but otherwise pretty simple to deal with.
>
> [E]SMD is a 60-pin control cable that doesn't have very picky shielding
> requirements and is usually implemented as rainbow twist-n-flat ribbon.
> The 26-pin data cables are a bit more picky and is usually implemented as
> ribbon cable mesh-shielded on one side (like the BC06R). 3rd-party SMD
> controllers managed to get by just fine with those, although it was best
> to stagger the 4 data cables so they didn't make a big lump under the
> BA11's cable retention brackets.
>
> I would much rather have 5 ribbon cables in one place than 4 Massbus
> cables (host to adapter 1, a1 to a2, a2 to a3, a3 to a4 ). Not to mention
> saving the floor space of two adapter cabinets. I've done both.

Well. I had massbus drives many meters from the main cabinets. Not sure
I'd trust flat cables of that length...

But I certainly didn't exactly enjoy the massbus cable either. But at
least it was simple.

> And then DEC came out with the TK50 with its leader-and-buckle
> design. It says something that the replacement buckles for the drive
> were only available in packs of ten...

The tape pickup was far from the worst problem of the TK50. And I don't
think I've ever had to replace one. Sometimes they unhooked, but once
you knew the innards of the drive, that was easy to hook up again.
The constant cleaning, the tapes getting stuck because firmware got
stuck, and so on... That's what constantly puts me off of the TK50. The
firmware side at least got sorted with the TK70. But no helping the
constant cleaning of the heads...
(Not to mention the speed of the thing...)

Johnny

On 10/7/23 22:31, terry-...@glaver.org wrote:
> And then DEC came out with the TK50 with its leader-and-buckle
> design. It says something that the replacement buckles for the drive
> were only available in packs of ten...

LSSM personnel including myself picked up a truckload of DEC
donations from a company in NY yesterday. There was far too much to
really go through onsite, but there was one of those bags of ten TK50
picker tongues in there. That was a huge stroke of luck. I'm not a big
fan of TK50s, but at least now we can keep them running.

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On 10/8/23 09:50, Johnny Billquist wrote:
>>    And then DEC came out with the TK50 with its leader-and-buckle
>> design. It says something that the replacement buckles for the drive
>> were only available in packs of ten...
>
> The tape pickup was far from the worst problem of the TK50. And I don't
> think I've ever had to replace one. Sometimes they unhooked, but once
> you knew the innards of the drive, that was easy to hook up again.

Many years ago, late 1980s, running a few TK50 drives at home, they
unhooked pretty often. I got good at quickly re-hooking them. By the
early 1990s it wasn't uncommon for the hook end to succumb to plastic
fatigue and break off.

> The constant cleaning, the tapes getting stuck because firmware got
> stuck, and so on... That's what constantly puts me off of the TK50. The
> firmware side at least got sorted with the TK70. But no helping the
> constant cleaning of the heads...
> (Not to mention the speed of the thing...)

Definitely not what I'd call "fast". 8-/

-Dave

--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA

On Sunday, October 8, 2023 at 9:50:12 AM UTC-4, Johnny Billquist wrote:
> Well. I had massbus drives many meters from the main cabinets. Not sure
> I'd trust flat cables of that length...

The Fujitsu M2351A product specification says the limit for the A cable
is 100 feet and the B cable is 50 feet.

I'd rather drop a floor tile on a Massbus cable (it'll just bounce off) vs.
SMD cables (they'd probably be cut), though.

> The tape pickup was far from the worst problem of the TK50. And I don't
> think I've ever had to replace one. Sometimes they unhooked, but once
> you knew the innards of the drive, that was easy to hook up again.
> The constant cleaning, the tapes getting stuck because firmware got
> stuck, and so on... That's what constantly puts me off of the TK50. The
> firmware side at least got sorted with the TK70. But no helping the
> constant cleaning of the heads...

You've probably never had to use one of the EFT units which didn't have
the green activity light, so the only indicator you had to rely on was the
big red button. You had to be psychic (or just assume it was broken and
you'd be right 75% of the time 8-).

Maybe it was bad batches of TK50 tapes, but we had a lot of buckle
damage over the years.

> (Not to mention the speed of the thing...)

It WAS a lot better than loading VMS from RX50 diskettes. But that
system eventually got a Cipher F880 tape (on a Dilog DQ132 if I'm
remembering correctly) and never looked back.

On Saturday, October 7, 2023 at 7:31:41 PM UTC-7, terry-...@glaver.org wrote:

(snip)

> [E]SMD is a 60-pin control cable that doesn't have very picky shielding
> requirements and is usually implemented as rainbow twist-n-flat ribbon.
> The 26-pin data cables are a bit more picky and is usually implemented as
> ribbon cable mesh-shielded on one side (like the BC06R). 3rd-party SMD
> controllers managed to get by just fine with those, although it was best
> to stagger the 4 data cables so they didn't make a big lump under the
> BA11's cable retention brackets.

Sun used round cables for SMD, at least outside boxes.

They might have been ribbon cables inside.

On 2023-10-08 17:22, Dave McGuire wrote:
> On 10/8/23 09:50, Johnny Billquist wrote:
>>>    And then DEC came out with the TK50 with its leader-and-buckle
>>> design. It says something that the replacement buckles for the drive
>>> were only available in packs of ten...
>>
>> The tape pickup was far from the worst problem of the TK50. And I
>> don't think I've ever had to replace one. Sometimes they unhooked, but
>> once you knew the innards of the drive, that was easy to hook up again.
>
>   Many years ago, late 1980s, running a few TK50 drives at home, they
> unhooked pretty often.  I got good at quickly re-hooking them.  By the
> early 1990s it wasn't uncommon for the hook end to succumb to plastic
> fatigue and break off.

Interesting. I still have, and occasionally use a TK70. Still haven't
broken. But obviously it's a problem since replacements were sold.
(I do have TK50 drives as well, but I refuse to use them.)

Johnny

On 2023-10-09 03:37, terry-...@glaver.org wrote:
> On Sunday, October 8, 2023 at 9:50:12 AM UTC-4, Johnny Billquist wrote:
>> Well. I had massbus drives many meters from the main cabinets. Not sure
>> I'd trust flat cables of that length...
>
> The Fujitsu M2351A product specification says the limit for the A cable
> is 100 feet and the B cable is 50 feet.

Longer than I expected.

> I'd rather drop a floor tile on a Massbus cable (it'll just bounce off) vs.
> SMD cables (they'd probably be cut), though.

True.

>> The tape pickup was far from the worst problem of the TK50. And I don't
>> think I've ever had to replace one. Sometimes they unhooked, but once
>> you knew the innards of the drive, that was easy to hook up again.
>> The constant cleaning, the tapes getting stuck because firmware got
>> stuck, and so on... That's what constantly puts me off of the TK50. The
>> firmware side at least got sorted with the TK70. But no helping the
>> constant cleaning of the heads...
>
> You've probably never had to use one of the EFT units which didn't have
> the green activity light, so the only indicator you had to rely on was the
> big red button. You had to be psychic (or just assume it was broken and
> you'd be right 75% of the time 8-).

Nope. Never saw one without the green light. Not that the green light
really helped anyway. That red button light started its rapid blinking,
at which point it was power cycle time, and remove the tape by opening
things up, and manually rewind it back into the shell. Don't know how
many times I've done that. :-(
The green light wasn't much help. It was nice to see that there was
activity, but error was the most normal state of that drive.

> Maybe it was bad batches of TK50 tapes, but we had a lot of buckle
> damage over the years.

I have no idea. It's not been a problem for me, but I might just have
been lucky. When I worked at DEC I did media conversions for customers.
Had a TK50 on a VAX-11/750, and had to fight it all the time.

(The most fun time was the one time a customer came with a DECtape. I
did manage to get the data off, but it required firing up the PDP-11
that was just an exhibit in the custom training part of the building.
Only machine remaining that had DECtape - this was in the mid 80s.)

>> (Not to mention the speed of the thing...)
>
> It WAS a lot better than loading VMS from RX50 diskettes. But that
> system eventually got a Cipher F880 tape (on a Dilog DQ132 if I'm
> remembering correctly) and never looked back.

I did an installation of MicroVMS from RX50 once. That was definitely
not fun. I think it might have been faster, but it was something like 25
floppies, and having to swap them all the time was not something I'd
want to repeat. TK50, while maybe slower, was more convenient than that.

Johnny

On Mon, 2023-10-09 at 11:50 +0200, Johnny Billquist wrote:
> I did an installation of MicroVMS from RX50 once. That was definitely
> not fun. I think it might have been faster, but it was something like
> 25 floppies, and having to swap them all the time was not something
> I'd want to repeat. TK50, while maybe slower, was more convenient
> than that.

History repeats itself with the OSR2.1 release of Windows 95. It came
on 26 floppies. Windows NT 3.1 came with 22 floppies. :-D
--
Tactical Nuclear Kittens

> Sun used round cables for SMD, at least outside boxes.

> They might have been ribbon cables inside.

Ditto Prime. Interior cables were rainbow twist ribbon, connecting to
the controllers with card-edge connectors. Exterior cables were round
grey cable, d-sub connectors. Disk, tape, printers, and external
intelligent serial i/o.

De