DECtapes have 5x redundant tracks. If you could find an 8-track head that
had the same track pitch, and maybe track width, you could read the tape
but lose redundancy on the Mark and Timing tracks. That probably would not
work with a marginal DECtape.
On Mon, Feb 7, 2022 at 3:33 PM Wayne S <wayne.sudol at hotmail.com> wrote:
> I?ve often wondered if the tape heads from consumer tape devices such as
> cassette or 4-8 track tape players could be used or be made to be used as
> replacements. Anybody ever try that?
>
> Sent from my iPhone
>
> > On Feb 7, 2022, at 11:51, Michael Thompson via cctech <
> cctech at classiccmp.org> wrote:
> >
> > ?
> >>
> >>
> >> From: Gary Oliver <go at aerodesic.com>
> >> Subject: DECTape head problem
> >>
> >> In debugging my DECtape interface lashup, I found that one of my head
> >> has two open windings.? Specifically, one channel has an open 'ground'
> >> with the other two lines apparently the full winding of the channel.?
> >> The second channel failing has no continuity between any of the three
> >> lines.? I have tested the other head and it has all the requisite
> >> continuity so I'm hoping I can at least get a single spindle running.
> >>
> >> Has any ever attempted repair of one of these?
> >>
> >> -Gary
> >>
> >
> > At the Rhode Island Computer Museum we found several DECtape heads on
> TU55
> > and TU56 drives with open connections. A volunteer got one head X-Rayed
> so
> > we could see the solder joints between the tiny wires for the head coils,
> > and the larger twinax wires that go to the relay board. We couldn't see
> any
> > damage to the wires or solder joints.
> >
> > We tried heating the potting material to soften it, and digging it out to
> > get to the solder joints. While digging at the potting material you can't
> > see the tiny wires, so they will likely get damaged.
> >
> > We considered using a solvent to remove the potting material, but thought
> > that it would eat the enamel off the head coil wires and damage them
> beyond
> > repair.
> >
> > So far we haven't found a way to repair the heads.
> >
> > Michael Thompson
>
--
Michael Thompson
>
> From: Gary Oliver <go at aerodesic.com>
> Subject: DECTape head problem
>
> In debugging my DECtape interface lashup, I found that one of my head
> has two open windings.? Specifically, one channel has an open 'ground'
> with the other two lines apparently the full winding of the channel.?
> The second channel failing has no continuity between any of the three
> lines.? I have tested the other head and it has all the requisite
> continuity so I'm hoping I can at least get a single spindle running.
>
> Has any ever attempted repair of one of these?
>
> -Gary
>
At the Rhode Island Computer Museum we found several DECtape heads on TU55
and TU56 drives with open connections. A volunteer got one head X-Rayed so
we could see the solder joints between the tiny wires for the head coils,
and the larger twinax wires that go to the relay board. We couldn't see any
damage to the wires or solder joints.
We tried heating the potting material to soften it, and digging it out to
get to the solder joints. While digging at the potting material you can't
see the tiny wires, so they will likely get damaged.
We considered using a solvent to remove the potting material, but thought
that it would eat the enamel off the head coil wires and damage them beyond
repair.
So far we haven't found a way to repair the heads.
Michael Thompson
I'm going through? a few of my ESDI? and MFM hard drives? and ran across?2 Maxtor? XT 2190 drives with? all of the Drive Id's (1-4) tie together with 1 long
jumper and the drives have the write protect jumper is installed.? Not sure what theywould have been used for ??? Both are the same.
Jerry
There is a nice looking IBM 129 keypunch on Ebay for what I think is a very
reasonable "buy it now" price of US$1799:
https://www.ebay.com/itm/333898748391
Shipping to Australia would be horrendous otherwise I would have bought it.
Best regards
Tom Hunter
I'm putting stuff together here and it's time to begin working on the
8/E. Looks like a pretty generic system but it has two odd boards.
Pair of g227 memory boards, 4 board CPU+Console board, serial board,
nothing too special.
But two odd Omnibus cards: One is a memory board, half populated, my
guess is it's enough memory to bring the computer to 32kw. The other is
an mets 303-0115-001. Bunch of 7400 series logic chips, nothing too
special.
Any idea what it might have been? Timeshare option? Something else? Not
a peripheral controller from what I can see.
C
On Thu, Feb 3, 2022 at 1:08 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. (John Ames)
> 2. Re: (Paul Koning)
> 3. Re: (Jon Elson)
> 4. Re: KMC11/DMC11 folllow up (Dave Mitton)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Feb 2022 10:20:25 -0800
> From: John Ames <commodorejohn at gmail.com>
> To: cclist at sydex.com
> Cc: cctalk at classiccmp.org
> Message-ID:
> <CABCBCvP8SX_1rB3FXVxZuXx1SUFTfiJBTqePd_SZiNeReX7PEw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
> I think "witch settings" is my new preferred term for this. They're
> certainly mysterious and arcane enough.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Feb 2022 13:30:33 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: John Ames <commodorejohn at gmail.com>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re:
> Message-ID: <B8F20F9C-A329-4CED-9A00-036EAA8F4D1A at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Feb 2, 2022, at 1:20 PM, John Ames via cctalk <cctalk at classiccmp.org> wrote:
> >
> >> Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
> > I think "witch settings" is my new preferred term for this. They're
> > certainly mysterious and arcane enough.
>
> Nice. It would be a good term to apply to VMS SYSGEN parameters that are documented as having units "microfortnights".
>
> paul
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 2 Feb 2022 16:49:42 -0600
> From: Jon Elson <elson at pico-systems.com>
> To: Paul Koning via cctalk <cctalk at classiccmp.org>
> Subject: Re:
> Message-ID: <b0989916-7493-481d-7c45-a696ce5ecc31 at pico-systems.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2/2/22 12:30, Paul Koning via cctalk wrote:
> >
> >>
> > Nice. It would be a good term to apply to VMS SYSGEN parameters that are documented as having units "microfortnights".
> >
> A footnote in the system config guide noted that ufortnights
> would be approximated at one second.
>
> Jon
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 2 Feb 2022 14:31:27 -0500
> From: Dave Mitton <dave at mitton.com>
> To: "cctech at classiccmp.org" <cctech at classiccmp.org>
> Subject: Re: KMC11/DMC11 folllow up
> Message-ID: <20220202193130.24EDC4E775 at mx2.ezwind.net>
> Content-Type: text/plain; charset="utf-8"
>
> Date: Tue, 1 Feb 2022 18:46:46 -0500
> From: Bob Smith <bobsmithofd at gmail.com>
> Subject: Re: KMC11/DMC11 folllow up
> Message-ID:
> I?ve been watching this thread go by, and never finding time to contribute?.
>
> I started in Aug 1977 and finished the CommIOP products from Bob and Harvey. Clarise was no longer involved.
> It was basically done, I just did the QA on them and released it. I did find some bugs in the debugger we provided.
>
> I basically did KMC software support, on and off, going forward. When the KMC-B came out (I think Remi did that)
> I rev?ed the tools. I also did a KMC Tools package for VMS. I tossed into that package a VMS line printer driver, I wrote as an example and POC, that ran multiples LP11s at significantly better speed. We ran that in our lab. The MIT LCS lab loved that.
>
> My memory is weak on things like the ?DMX? and other things that CSS did. The Lab Products group built some successful data collection products around the KMC.
>
> Attempts in the Comms HW group to do an updated UNIBUS DH never got off the ground. We (NAC) did pitch the idea of using the CommIOP-DZ to VMS, as a way to off-load character terminal loads, and they would have nothing to do with it. For whatever reasons, they did not like the idea of smart devices.
>
> That led to the attempt to build a ?universal? terminal concentrator based on an 11 networked into the system. That project was complicated by what it tried to integrate, and took too long to build. It was overtaken by the simpler LAT based products that DEC went forward with.
>
> George Conant, Bob Rosenbaum, and Pete Nesbeda left the company and founded Xyplex that fielded successful products in this space.
>
> I could go on, but ? I do have copies of the KMC Tools doc and maybe the CommIOPs, but no KMC hw docs.
> Dave.
>
> Sent from Mail for Windows
>
>
Hey Dave! I did not mention you because I was not sure you wanted to
recall those days! you are correct it was Remi Lisee doing the design,
I did the first line units, and then they were redone a few years
later. Glad you piped in!! Hope you are doing great! All of you guys
were brilliant, except Harvey, he was a royal pain, said with lots of
laughs we both got tired or burning roms!!
bob smith
> Back in the bad old days of the 5160 PC, some DTC controllers allowed for partitioning a drive (using witch settings)
I think "witch settings" is my new preferred term for this. They're
certainly mysterious and arcane enough.
Date: Tue, 1 Feb 2022 18:46:46 -0500
From: Bob Smith <bobsmithofd at gmail.com>
Subject: Re: KMC11/DMC11 folllow up
Message-ID:
<CAHtNYbXBRwrOQm2cH+T+CDn5nq3sZN+PQRa9fEMVhqQ=pAMDSw at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Yes! thank you! Nice, smart, and did good work despite the magateer, I
mean marketing dweeb.
I lost track of Harvey, Bob wen ont to start a company over in west
concord, can't recall the name, used some of his gear for projects in
the mid 80s.
I was designing a comms system in late 80s and heard Len Bosak had
started a company, had a couple of meetings with him, and went with hs
gear. Man those were fun post DEC projexcts.
bob smith (PDP8 engineering, DecComm (Stockebrand, VInce et al), small
systems, then of toe LCG for 2080...
On Tue, Feb 1, 2022 at 2:43 PM John Forecast <john at forecast.name> wrote:
>
> On Feb 1, 2022, at 8:20 AM, Bob Smith via cctalk <cctalk at classiccmp.org> wrote:
> >
> > KMC11 - Paul K cited the docs. It was a bit different from DMC CPU board
> > in both cycle time and in the use of ram versus prom.
> > Both boards/products used the 4bit Alu but I don't call that bit
> > slice, as the 2901 is more of a bit slice.
> > KMC and DMC are Harvard architecture based devices, as is the 11/60 CPU.
> > DMC and KMC benefited from the microcode work of Harvey Schlesinger,
> > Bob Rosenbaum, Richie Larry, and I think Clarise joined the team in
> > 77. Can't recall her last name.
>
> Patton? Harvey, Bob and Clarise joined the DECnet-RSX development team sometime in 77/78.
>
> John.
>
> > DMC had (when I left the project and it had been shipping for a year
> > or two) a 300NS cycle time, while the KMC had a 240NS cycle time
> > thanks to the instruction register I had suggested to remi as we were
> > thinking of a RAM based device because PROMS were a royal pain with 2
> > and 3 code changes a day. This change allowed the machine to begin to
> > access the next instruction as one was executing - there are no
> > interrupts in either board.
> > bob
>
I?ve been watching this thread go by, and never finding time to contribute?.
I started in Aug 1977 and finished the CommIOP products from Bob and Harvey. Clarise was no longer involved.
It was basically done, I just did the QA on them and released it. I did find some bugs in the debugger we provided.
I basically did KMC software support, on and off, going forward. When the KMC-B came out (I think Remi did that)
I rev?ed the tools. I also did a KMC Tools package for VMS. I tossed into that package a VMS line printer driver, I wrote as an example and POC, that ran multiples LP11s at significantly better speed. We ran that in our lab. The MIT LCS lab loved that.
My memory is weak on things like the ?DMX? and other things that CSS did. The Lab Products group built some successful data collection products around the KMC.
Attempts in the Comms HW group to do an updated UNIBUS DH never got off the ground. We (NAC) did pitch the idea of using the CommIOP-DZ to VMS, as a way to off-load character terminal loads, and they would have nothing to do with it. For whatever reasons, they did not like the idea of smart devices.
That led to the attempt to build a ?universal? terminal concentrator based on an 11 networked into the system. That project was complicated by what it tried to integrate, and took too long to build. It was overtaken by the simpler LAT based products that DEC went forward with.
George Conant, Bob Rosenbaum, and Pete Nesbeda left the company and founded Xyplex that fielded successful products in this space.
I could go on, but ? I do have copies of the KMC Tools doc and maybe the CommIOPs, but no KMC hw docs.
Dave.
Sent from Mail for Windows
There is a discussion of the origin of the term "partition" in storage
devices such as HDDs at:
https://en.wikipedia.org/wiki/Talk:Disk_partitioning#Where_did_the_term_%22p
artition%22_originate?
It seems clear it was used in memory well before HDDs but when it got
started there is unclear.
* IBM PC DOS v2 was an early user in 1983 with FDISK and its first PC
support of HDDs
* UNIX, Apple OS's and IBM mainframe all seem to come later.
Partitioning as a "slice" probably predates IBM PC DOS v2
Would appreciate some recollections about DEC usage, other minicomputers and
the BUNCH.
You can either post directly to Wikipedia or let me know; links to
references would greatly be appreciated
Tom
> From: Tom Gardner
> You define logical disks by assigning a logical disk unit number to a
> file on a physical disk. You can then use the logical disk as though it
> were a physical disk.
To me, 'partition' implies a contiguous are of the disk; "a file" to me
implies that it might not be contiguous? Or are files contiguous in the RT-11
filesystem? (I know there were filesystems which supported contiguous files.)
This reminds me of the swapping/paging area in Windows 95/98 (maybe other
versions too), which was kept in a file, and therefore might be scattered all
over the physical disk. (Norton disk optimizer would coalesce the swap/paging
area to a contiguous area of the disk.)
Noel
KMC11 - Paul K cited the docs. It was a bit different from DMC CPU board
in both cycle time and in the use of ram versus prom.
Both boards/products used the 4bit Alu but I don't call that bit
slice, as the 2901 is more of a bit slice.
KMC and DMC are Harvard architecture based devices, as is the 11/60 CPU.
DMC and KMC benefited from the microcode work of Harvey Schlesinger,
Bob Rosenbaum, Richie Larry, and I think Clarise joined the team in
77. Can't recall her last name.
DMC had (when I left the project and it had been shipping for a year
or two) a 300NS cycle time, while the KMC had a 240NS cycle time
thanks to the instruction register I had suggested to remi as we were
thinking of a RAM based device because PROMS were a royal pain with 2
and 3 code changes a day. This change allowed the machine to begin to
access the next instruction as one was executing - there are no
interrupts in either board.
bob
> From: Paul Koning
> When did Unix first get partitions?
'Partitions' the mechanism, or partitions the term for the mechanism?
The former appeared about V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c
when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16 blocks,
so the 406*10*20 blocks of an RP03 had to be split up into partitions (called
'sections' or 'pseudo-disks' in the documentation) to make all of it useable.
The latter? No idea...
Partitions may have appeared in DOS/Windows for much the same reason; with 32
KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall
having to use partitions when I bought a 13GB hard drive for my Windows 95
machine (FAT32 only came in with Windows 95 OSR2).
Noel
A somewhat broader search found the 1984 RT-11 System Release Notes with the following:
1.4.2.4 Logical Disk Subsetting Handler (LD) - The logical disk subsetting handler lets you define logical disks, which are subsets of physical disks. You define logical disks by assigning a logical disk unit number to a file on a physical disk. You can then use the logical disk as though it were a physical disk.
AA-5286F-TC-T1_RT-11_System_Release_Notes_Jul84.pdf (bitsavers.org) <http://www.bitsavers.org/pdf/dec/pdp11/rt11/v5.1_Jul84/AA-5286F-TC-T1_RT-11…> p15/102
Suggests DEC had not yet adopted the term ?partition? for a segment of a disk
Tom
-----Original Message-----
From: Tom Gardner [mailto:tom94022 at comcast.net]
FWIW a Google search: "partition site:http://www.bitsavers.org/pdf/dec/pdp11/rt11" returns no relevant hits prior to 1983
I suspect that ESDI and MFM controllers emulating RL/RK disks are also later than 1983
Tom
-----Original Message-----
From: Zane Healy [ <mailto:healyzh at avanthar.com> mailto:healyzh at avanthar.com]
Sent: Monday, January 31, 2022 12:40 PM
To: Paul Koning; General Discussion: On-Topic and Off-Topic Posts
Cc: <mailto:t.gardner at computer.org> t.gardner at computer.org; Tom Gardner
Subject: Re: Origin of "partition" in storage devices
On Jan 31, 2022, at 11:28 AM, Paul Koning via cctalk < <mailto:cctalk at classiccmp.org> cctalk at classiccmp.org> wrote:
>
> Both of these are memory partitions. The only OS I can think of predating the ones you mentioned is RT-11, the later versions (V2 did not have them). When did Unix first get partitions?
>
> paul
Partitions are pretty important in RT-11 v5.x, after all, there is the partition size limit, so you have to have multiple partitions for almost any HD, except very small ones.
Let?s not forget hardware enforced partitioning, the WEQSD/04 ESDI controller comes to mind. It see?s a single large ESDI HD as a single disk, but you can partition it on the controller, and the OS sees each partition as a separate physical disk. I seem to remember some MFM controllers that made the MFM drive appear to be RL01/RL02 or RK05 packs.
Zane
Anyone got any 8i switch or panel parts they Wana trade for any of these?
Got 6 3 pin spring loaded rockers appear to test good might need some
deoxot not sure came off the 8e below
8 of the 8e m rocker paddles orange and redish orange
https://drive.google.com/file/d/1Eprlv8d3TmSPFJ3rCHIJTFkQOyAZesCM/view?usp=…
Some are missing the plastic pivot dimples
8m with out it's switches
The rotory it's bit weird but possibly usable. Dunno enough about them.
It's center hole is ovaled a bit might gotten bashed. Might have some
usefull bits still
https://drive.google.com/drive/folders/1EpAag1J5r6RAR8ln_fprrdCEiOnJx5kq
I've got some other bits that might be usefull as well from the 8i to
anyone
I'm looking for 5 more rockers with or with out the 8i paddles
Or some 8i paddles I've got 5 brown and 10 white ones that I wanted to find
when I rescued my poor 8i outs the mud
Or any other parts that might be usefull
> From: Bob Smith
> the original UART was designed by DEC, Vince Bastiani was the project
> lead and designer, Gordon Bell was behind the project, and it may have
> been his idea.
"Computer Engineering: A DEC View of Hardware Systems Design" covers this, in
a footnote on pg. 73.
I seem to recall reading that Ken Olsen was involved in doing early modem
work (presumably on Whirlwind), but maybe my memory is failing, and it was
someone else (like Bell, or someone). Too busy to research it at the moment...
Noel
While moving some things around I found the following:
7 M8588
6 M8591
6 M8592
4 M8593
14 M8594
All appear to be NOS.
I also found :
G103
G222
G223
M911
Which I did not count, and they seem to be memory related, but I
haven't checked to see which memory they are from. If you have any interest
please contact me off list.
Thanks, Paul
> From: Chris Zach
> Maybe that is the dhv11.
The DH11, DHV11 and DHU11 are all very similar, although not 100.00% program compatible.
(The DHQ11 can be set to exactly emulate either the DHV11 or DHU11.) So, all provide
DMA output, but not DMA input.
Differences with the DH11 include two full word registers for DMA address,
hardware ^S/^Q support, built-in diagnostics, etc. The DHV11 and DHU11 differ
in hardware echo, output FIFO, a fix for the infamous DH11 input silo level
bug, etc.
Noel
In order to further the effort of scanning and preserving ALL of the
things, I picked up a Canon Microfilm Scanner 300 for $cheap. It has
a SCSI interface and doesn't work with anything past Windows XP, but
that's not a problem. What is a problem is that Canon's link to the
XP driver is a big 4 0 4:
https://www.usa.canon.com/internet/portal/us/home/support/details/scanners/…
By any chance, does someone out there have this driver? The filename
in question is "300350DRIT_V11.exe". You can google that name and end
up either back at Canon's site or in Malware Hell ("just download this
Chrome plugin to get your driver!").
Note that this is not the Canon Microfilm Scanner 300-II, which is a
USB device and uses a different driver.
Thanks for any leads...
jt
IIRC, John Mac was the designer for the DHQ/DHV. If my memory is
correct, after DH was done, John had the idea of a mix and match
synchronous/Async mux and came up with those designs. I dont remember
who was on his team. COMMS 11 group had led (farmed out) the designs
of the Sync version of a UART called USynRT in some parlance SIg 2652
and SMC 5027 IIFC. I ran the Signetics contract tech side. A fresh MIT
PhD was the Sig POC, and there are more stories about that. I cant
recall his name at this juncture.
bob
On Sun, Jan 30, 2022 at 1:00 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: What was a Terminal Concentration Device in DEC's
> products? (Noel Chiappa)
> 2. Re: What was a Terminal Concentration Device in DEC's
> products? (Paul Koning)
> 3. Re: What was a Terminal Concentration Device in DEC's
> products? (Chris Zach)
> 4. Re: What was a Terminal Concentration Device in DEC's
> products? (Glen Slick)
> 5. Re: What was a Terminal Concentration Device in DEC's
> products? (Noel Chiappa)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 29 Jan 2022 15:58:53 -0500 (EST)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <20220129205853.15EEA18C07B at mercury.lcs.mit.edu>
>
> > From: Paul Koning
>
> > DH-11 is unusual in that it has DMA in both directions
>
> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
>
> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
>
> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
>
> Noel
>
> PS: I am familiar with the term 'terminal concentrator' from the networking
> world, but as a generic term, not the name of a particular product. (Although
> Cisco's first boxes may have included a terminal concentrator, so named.)
>
> Noel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Jan 2022 17:12:41 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: Noel Chiappa <jnc at mercury.lcs.mit.edu>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <684F1FCF-A6E6-4F3C-AC39-ADA1504FC9E1 at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> >
> >> From: Paul Koning
> >
> >> DH-11 is unusual in that it has DMA in both directions
> >
> > McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> >
> > http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> >
> > it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
>
> Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
>
> paul
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 29 Jan 2022 18:49:06 -0500
> From: Chris Zach <cz at alembic.crystel.com>
> To: Paul Koning <paulkoning at comcast.net>, "General Discussion:
> On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>, Paul Koning via
> cctalk <cctalk at classiccmp.org>, Noel Chiappa
> <jnc at mercury.lcs.mit.edu>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <24F062E4-8B26-4EB3-A573-B47C69A53B67 at alembic.crystel.com>
> Content-Type: text/plain; charset=utf-8
>
> Maybe that is the dhv11. Or the dv11 I'll look it up tomorrow
>
> On January 29, 2022 5:12:41 PM EST, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
> >
> >
> >> On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> >>
> >>> From: Paul Koning
> >>
> >>> DH-11 is unusual in that it has DMA in both directions
> >>
> >> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> >>
> >> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> >>
> >> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
> >
> >Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
> >
> > paul
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ------------------------------
>
> Message: 4
> Date: Sat, 29 Jan 2022 16:47:27 -0800
> From: Glen Slick <glen.slick at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID:
> <CAM2UOwL2hi2Crm7ovphGd+UZFPePV+vUzoduan7a2a5Xo+eimw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> http://www.bitsavers.org/pdf/dec/qbus/EK-DHQ11-UG-002.pdf
> DHQ11 User Guide, EK-DHQ11-UG.002
>
> The main application of the M3107 DHQ11 is for interactive terminal
> handling; it can also be used for data concentration and real-time
> processing. It has two programming modes, DHV11 and DHU11. The
> register sets in these modes are compatible with those of the DHV11
> and DHU11 respectively. The preferred mode of operation is DHU11 mode.
> The main features of the DHQ11 are:
>
> ? For transmission: DMA transfers; or for each line, program transfers
> to a 1 character transmit buffer in DHV11 mode, or to a 64-character
> transmit FIFO in DHU11 mode
>
> ? For receive: a 256-entry FIFO buffer for received characters,
> dataset status changes, and diagnostic information
>
> The M3118 CXA16 and the M3119 CXA08 have the same programming
> interface as the M3107 DHQ11
>
>
> The M3108 DSV11 can do DMA transfers in both directions, although it
> is a synchronous interface, not asynchronous.
>
> http://www.bitsavers.org/pdf/dec/qbus/EK-DSV11-TM-001_Jan87.pdf
> DSV11 Technical Manual, EK-DSV11-TM-001
>
> Functional Description (Section 1.5). The DSV11 supports a range of
> synchronous protocols on the serial interface, and transfers data to
> and from the host by DMA transfer. This section describes the way in
> which the DSV11 handles data.
>
> On Sat, Jan 29, 2022 at 3:49 PM Chris Zach via cctalk
> <cctalk at classiccmp.org> wrote:
> >
> > Maybe that is the dhv11. Or the dv11 I'll look it up tomorrow
> >
> > On January 29, 2022 5:12:41 PM EST, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
> > >
> > >
> > >> On Jan 29, 2022, at 3:58 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> > >>
> > >>> From: Paul Koning
> > >>
> > >>> DH-11 is unusual in that it has DMA in both directions
> > >>
> > >> McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
> > >>
> > >> http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
> > >>
> > >> it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
> > >
> > >Oh. That's amazing, all these years I thought it had DMA both ways. Clearly not. I wonder how I got that misunderstanding.
> > >
> > > paul
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 30 Jan 2022 09:26:46 -0500 (EST)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <20220130142646.5614818C074 at mercury.lcs.mit.edu>
>
> > From: Chris Zach
>
> > Maybe that is the dhv11.
>
> The DH11, DHV11 and DHU11 are all very similar, although not 100.00% program compatible.
> (The DHQ11 can be set to exactly emulate either the DHV11 or DHU11.) So, all provide
> DMA output, but not DMA input.
>
> Differences with the DH11 include two full word registers for DMA address,
> hardware ^S/^Q support, built-in diagnostics, etc. The DHV11 and DHU11 differ
> in hardware echo, output FIFO, a fix for the infamous DH11 input silo level
> bug, etc.
>
> Noel
>
>
> End of cctalk Digest, Vol 88, Issue 30
> **************************************
Back in 75-77 time frame, the KMC11 was packaged with DD11 backplane,
a controller interface board or an SLU to implement version 2 of the
DoD AUTODIN II. Philco Ford element then called Aeronuetronic Ford out
ot Cali was the prime. DEC won the hardware portion bidding PDP11
systems using the KMC11 and SLUs ranging from Mode1 to Mode VI. I did
the SLUs for Mode VI (ADCCP/SDLC et al) and Mode II (BiSync) out of
the Comms 11 group. CSS Nashua did the Async system with I think 64
lines, or more, and labeled it DMX IIRC - my memory could be bad on
the name.The COMM IOP concept was another alternative using the DZ/DU
boards. Barney Loiter, if he is still around can probably remember
who in CSS did the product. I think Frank Zareski, who had moved from
Comms group to Semiconductor was involved with or the lead for the
DUAL UART chips DEC invented (point for the record, the original UART
was designed by DEC, Vince Bastiani was the project lead and designer,
Gordon Bell was behind the project, and it may have been his idea.)
On Sat, Jan 29, 2022 at 1:00 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: simulation of an entire IBM S/360 Model 50 mainframe
> (Curious Marc)
> 2. What was a Terminal Concentration Device in DEC's products?
> (Chris Zach)
> 3. Re: What was a Terminal Concentration Device in DEC's
> products? (Paul Koning)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Jan 2022 20:53:22 -0800
> From: Curious Marc <curiousmarc3 at gmail.com>
> To: Liam Proven <lproven at gmail.com>, "General Discussion: On-Topic and
> Off-Topic Posts" <cctalk at classiccmp.org>
> Subject: Re: simulation of an entire IBM S/360 Model 50 mainframe
> Message-ID: <E6C6C3FB-E0A0-4472-A485-3EA9E1102CEC at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Ah, it was you Liam. Ken is enamored with the new title you bestowed on him. He will now be officially called: Master Ken, Hardware Boffin.
> :-)
> Marc
>
> > On Jan 27, 2022, at 11:54 AM, Liam Proven via cctalk <cctalk at classiccmp.org> wrote:
> >
> > ?On Thu, 27 Jan 2022 at 17:20, Guy N. via cctalk <cctalk at classiccmp.org> wrote:
> >>
> >> This might be old news to a lot of people here, but I noticed a fun
> >> article on The Register today:
> >
> > Oh cool. Thanks for the link -- that's one of my stories. Glad to hear
> > people enjoyed it. :-)
> >
> > --
> > Liam Proven ~ Profile: https://about.me/liamproven
> > Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
> > Twitter/LinkedIn: lproven ~ Skype: liamproven
> > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Jan 2022 00:28:30 -0500
> From: Chris Zach <cz at alembic.crystel.com>
> To: CCTalk mailing list <cctalk at classiccmp.org>
> Subject: What was a Terminal Concentration Device in DEC's products?
> Message-ID: <ba6ec80e-e099-4015-9d58-f33fb4e51c02 at alembic.crystel.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Old question: I'm looking through some old reports from 1977 about a
> failed DEC project with the DMX11 multiplexer system and there is
> reference to the following key items:
>
> 1) The DMX was designed to handle block mode devices. Fine.
> 2) Character mode devices like the VT52's were supposed to use a "TCD"
> product from DEC.
>
> The reason the project imploded was because apparently DEC stopped
> supporting the TCD in RSX11/D in late 1976, so someone in CSS had the
> great idea of agreeing to extend the microcode in the DMX11 to handle
> both block AND character mode devices. This did.... not work well and it
> sank the project.
>
> What I'm wondering is what was the TCD for PDP11's back then? I don't
> see anything in my communications handbooks on this, and even the DMX11
> doesn't really appear, instead there is the COMM/IO/P type boards which
> worked with a pile of DZ11's. From what I can glean from this
> documentation it looks like the DMX11 worked in a similar fashion as the
> requirement was the DMX11 system was a nine board solution (possibly 8
> DZ11's and one controller board).
>
> More odd it looks like the TCD *was* still supported in RSX11/M and
> ultimately the decision was made to build the thing in M so it's weird
> they continued to whack away at the DMX solution instead of going with
> TCD's for async and proven DMX microcode for block devices.
>
> Any thoughts, or does this jog any memories?
>
> C
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 29 Jan 2022 10:24:56 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: Chris Zach <cz at alembic.crystel.com>, "cctalk at classiccmp.org"
> <cctalk at classiccmp.org>
> Subject: Re: What was a Terminal Concentration Device in DEC's
> products?
> Message-ID: <7F4B4A3F-4114-4FF9-9D6C-28AA7E26E475 at comcast.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On Jan 29, 2022, at 12:28 AM, Chris Zach via cctalk <cctalk at classiccmp.org> wrote:
> >
> > Old question: I'm looking through some old reports from 1977 about a failed DEC project with the DMX11 multiplexer system and there is reference to the following key items:
> >
> > 1) The DMX was designed to handle block mode devices. Fine.
> > 2) Character mode devices like the VT52's were supposed to use a "TCD" product from DEC.
> >
> > The reason the project imploded was because apparently DEC stopped supporting the TCD in RSX11/D in late 1976, so someone in CSS had the great idea of agreeing to extend the microcode in the DMX11 to handle both block AND character mode devices. This did.... not work well and it sank the project.
> >
> > What I'm wondering is what was the TCD for PDP11's back then? I don't see anything in my communications handbooks on this, and even the DMX11 doesn't really appear, instead there is the COMM/IO/P type boards which worked with a pile of DZ11's. From what I can glean from this documentation it looks like the DMX11 worked in a similar fashion as the requirement was the DMX11 system was a nine board solution (possibly 8 DZ11's and one controller board).
> >
> > More odd it looks like the TCD *was* still supported in RSX11/M and ultimately the decision was made to build the thing in M so it's weird they continued to whack away at the DMX solution instead of going with TCD's for async and proven DMX microcode for block devices.
> >
> > Any thoughts, or does this jog any memories?
>
> Nothing comes to mind here; the name "DMX" does not ring any bells. It's a bit before my time, admittedly.
>
> DEC made some products that used block mode terminals: the moderately successful Typeset-11 with the VT-61/t forms and page editing terminal, and the VT-71 with embedded LSI-11 to do full file local editing. Both have some form of block transfer to the host, but as far as I can remember they used ordinary DH-11 terminal interfaces. DH-11 is unusual in that it has DMA in both directions, which is unhelpful for interactive use but great for block transfer. Typeset-11 also supported a specialized terminal made by Harris (the 2200), another local processor device, this one connected to the PDP-11 host with a DL-11/E, using half duplex multidrop BISYNC with modem signal handshakes. I kid you not... I have some scars debugging that protocol at 2 am in downtown Philadelphia.
>
> DEC also built yet another VT-51 variation, the VT-62, which was the terminal for the TRAX system. That was, I think, some sort of RSX derivative (-M+ perhaps, but I'm not sure), which made it to field test but was canceled before becoming an official product. Not sure why.
>
> paul
>
>
>
>
> End of cctalk Digest, Vol 88, Issue 29
> **************************************
> From: Paul Koning
> DH-11 is unusual in that it has DMA in both directions
McNamara's DH11? (I don't know of another DECdevice of that name.) Per:
http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_1…
it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU.
Noel
PS: I am familiar with the term 'terminal concentrator' from the networking
world, but as a generic term, not the name of a particular product. (Although
Cisco's first boxes may have included a terminal concentrator, so named.)
Noel
Old question: I'm looking through some old reports from 1977 about a
failed DEC project with the DMX11 multiplexer system and there is
reference to the following key items:
1) The DMX was designed to handle block mode devices. Fine.
2) Character mode devices like the VT52's were supposed to use a "TCD"
product from DEC.
The reason the project imploded was because apparently DEC stopped
supporting the TCD in RSX11/D in late 1976, so someone in CSS had the
great idea of agreeing to extend the microcode in the DMX11 to handle
both block AND character mode devices. This did.... not work well and it
sank the project.
What I'm wondering is what was the TCD for PDP11's back then? I don't
see anything in my communications handbooks on this, and even the DMX11
doesn't really appear, instead there is the COMM/IO/P type boards which
worked with a pile of DZ11's. From what I can glean from this
documentation it looks like the DMX11 worked in a similar fashion as the
requirement was the DMX11 system was a nine board solution (possibly 8
DZ11's and one controller board).
More odd it looks like the TCD *was* still supported in RSX11/M and
ultimately the decision was made to build the thing in M so it's weird
they continued to whack away at the DMX solution instead of going with
TCD's for async and proven DMX microcode for block devices.
Any thoughts, or does this jog any memories?
C
This might be old news to a lot of people here, but I noticed a fun
article on The Register today:
Hardware boffin is building a simulation of an entire IBM S/360 Model 50
mainframe
https://www.theregister.com/2022/01/27/ibm_s360_simulation/
The article has a handy link to a post on Ken Shirriff's blog:
https://www.righto.com/2022/01/ibm360model50.html
While I'm kind of a "DEC guy", I still have a certain nostalgic fondness
for the IBM System/360, since that was my first in-depth exposure to
computer programming.
Some years ago I was on a mission to rack mount all my computer and test equipment. I found three front panels at a hamfest that I planned to use. I never did anything with them but still have them. These are from Datum systems, but they appear to be rather hard to find much information on.
The short story is, if anyone needs them for something, let me know. I would hate to do away with them if someone needs them. Two of the panels are marked:
Datum, inc Rotating Drum Memory 6008
Datum, inc Data Acquisition System 120
The last isn't marked.
A picture is here:
http://wrcooke.net/FrontPanels.jpg
I will likely be moving in a few months and these are on the "get rid of" list.
Thanks,
Will