Earl Baugh writes:
> Why not build a variation of this with an Arduino?
> https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/.
> You could use cardboard rather than wood if it’s just a one time job. ( or scan
> the tape into files and process digitally ?)
>
> Earl
I thought that I said earlier that I had a paper tape reader here but don't
remember much about it or if it ever worked. If I didn't have a huge project
list and it wasn't ski season I could hook it up to a pi. More likely that
I'll get to a computer museum sooner.
Just to keep this UNIX-related so that Warren doesn't get cranky, I believe
that this reader came out of some sort of experimental telephone exchange
in our group that was decommissioned. Dave Weller was very supportive of my
interests and somehow arranged for me to take much of it home as surplus
equipment. Kept me in 7400-series parts and Augat wire-wrap boards for a
long time. While there was no way that I could have kept the thing, I wish
that I had the magnetic drum memory because it was so cool from an industrial
art perspective.
Heinz may remember more about this than I do because he actually worked on
this project, but our department developed what I believe was the first
all-digital telephone exchange that used digital filtering (Hal Alles and
Jim Kaiser were in the group). I think that it had a pair of PDP-11/10s
in it, and a bigger PDP-11 as a supervisory machine that ran UNIX. I have
vague memories of Heinz and Carl poring over huge C program listings. I
also remember that there was a bug in the long-distance code where it wasn't
sending out the ST tone that ended up taking all of the key pulse senders in
the Berkeley Heights telephone exchange that provided the trunk line to our
lab off line as they didn't have timeouts and needed to be manually reset.
But hey, we were the phone company too so what could they do about it?
Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s
but those turned out to be useless because of the way that DEC did the DRAM
refresh; it wasn't interleaved, they just stopped everything every so many
ms and refreshed everything. Non-starter for real-time systems.
And another thought, this machine may have been why Heinz wrote MERT.
I was gone before this system was completed so I have no idea how it fared
and how many of the ideas were incorporated into production systems. Oh,
yeah, I think that it was called the SS1 for Slave Switch 1.
Jon
I thought the concern was about the fragility of the tape and the concern about running it thru a period reader. I was just thinking these two options would be safer on the tape. That’s why I was suggesting them. Just trying to be helpful .. all to familiar with the long project list :-)
Earl
Sent from my iPhone
> On Jan 15, 2020, at 2:12 AM, Jon Steinhart <jon@fourwinds.com> wrote:
>
> Earl Baugh writes:
>> Why not build a variation of this with an Arduino?
>> https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/.
>> You could use cardboard rather than wood if it’s just a one time job. ( or scan
>> the tape into files and process digitally ?)
>>
>> Earl
>
> I thought that I said earlier that I had a paper tape reader here but don't
> remember much about it or if it ever worked. If I didn't have a huge project
> list and it wasn't ski season I could hook it up to a pi. More likely that
> I'll get to a computer museum sooner.
>
> Just to keep this UNIX-related so that Warren doesn't get cranky, I believe
> that this reader came out of some sort of experimental telephone exchange
> in our group that was decommissioned. Dave Weller was very supportive of my
> interests and somehow arranged for me to take much of it home as surplus
> equipment. Kept me in 7400-series parts and Augat wire-wrap boards for a
> long time. While there was no way that I could have kept the thing, I wish
> that I had the magnetic drum memory because it was so cool from an industrial
> art perspective.
>
> Heinz may remember more about this than I do because he actually worked on
> this project, but our department developed what I believe was the first
> all-digital telephone exchange that used digital filtering (Hal Alles and
> Jim Kaiser were in the group). I think that it had a pair of PDP-11/10s
> in it, and a bigger PDP-11 as a supervisory machine that ran UNIX. I have
> vague memories of Heinz and Carl poring over huge C program listings. I
> also remember that there was a bug in the long-distance code where it wasn't
> sending out the ST tone that ended up taking all of the key pulse senders in
> the Berkeley Heights telephone exchange that provided the trunk line to our
> lab off line as they didn't have timeouts and needed to be manually reset.
> But hey, we were the phone company too so what could they do about it?
>
> Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s
> but those turned out to be useless because of the way that DEC did the DRAM
> refresh; it wasn't interleaved, they just stopped everything every so many
> ms and refreshed everything. Non-starter for real-time systems.
>
> And another thought, this machine may have been why Heinz wrote MERT.
>
> I was gone before this system was completed so I have no idea how it fared
> and how many of the ideas were incorporated into production systems. Oh,
> yeah, I think that it was called the SS1 for Slave Switch 1.
>
> Jon
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --] On Wed, Jan 15, 2020 at 2:12 AM Jon Steinhart <jon@fourwinds.com> wrote: > we tried to use LSI-11s > but those turned out to be useless because of the way that DEC did the DRAM > refresh; it wasn't interleaved, they just stopped everything every so many > ms and refreshed everything. Non-starter for real-time systems. > Be careful as to who you denigrate, my friend. 😂 Very interesting history, IMO. Yes, DEC sold the LSI-11, but Western Digital designed it. DEC (KO specifically) had just put Ray Ball and Ken O'humundro's CalData out of business for cloning the PDP-11/45 with a Unibus on his Caldata 500 <http://www.bitsavers.org/pdf/calData/CalData_Brochures_1974.pdf>. At the time, WD had developed and started to sell to the systems manufacturers a new set of bit-slice chips the MCP-1600 <https://en.wikipedia.org/wiki/MCP-1600>, to compete with AMD's 2900 and Intel 3000 series (plus they were already a chip supplier to DEC for UARTS). So WD designs and builds a few LSI-11 as a sales demo of what you could do with their new bit-slice chip (*i.e. *as those things often go, the board, bus, and memory was a quick and cheap hack). It's important to note that the way DEC nailed CalData was the *same instruction set on the same bus*, WD did their own bus for their demo. Also, please remember that at the time, WD was in the chip business. KO's reaction this time was different. Instead of suing, DEC got the design and started to build and sell them. WD took the board design, wrote a new set of microcode based on the USCD Pascal-P machine <https://en.wikipedia.org/wiki/UCSD_Pascal>, then sold that as a 'system' called the Pascal MicroEngine <https://en.wikipedia.org/wiki/Pascal_MicroEngine>, but primarily used it is the sales demo. I remember seeing one of the WD Pascal-P systems once when we were at Tek (along with my favorite named workstation, the Modula based Lilith <https://en.wikipedia.org/wiki/Lilith_(computer)>). But I do not think the Pascal-P (nor Lilith) was very successful. Also, AMD ultimately won the bit-slice chip business, as most designers at manufacturers like DEC, Masscomp, FPS, *et al*. designed their new systems or at least the FP/AP coprocessors with the 2900 series. BTW: this is also why a few years later when Ken O'Humundro created another full computer board with a 68000 on it with his new Able Computer Corp, he put it on the QBUS which DEC could not lock up because they did not create it as WD had. [-- Attachment #2: Type: text/html, Size: 4997 bytes --]
> From: Clem Cole > So WD designs and builds a few LSI-11 as a sales demo of what you could > do > ... > he put it on the QBUS which DEC could not lock up because they did not > create it as WD had. Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to the QBUS between the original demo WD boards and the first DEC ones? Are there any documents about the WD original still extant, do you know? (FWIW, it seems that whoever did the QBUS interrupt cycle had heard about the metastability issues when using a flop to do the grant-passing arbitrations; see here for more: https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS#QBUS_Interrupts DEC had previously bent themselves into knots trying to solve it on the UNIBUS: https://gunkies.org/wiki/M782_Interrupt_Control#Revisions so it would be interesting to know if it was WD or DEC who did the DIN thing to get rid of it on the QBUS.) Noel
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --] On Wed, Jan 15, 2020 at 11:47 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to > the > QBUS between the original demo WD boards and the first DEC ones? I can not say I know and I would suspect they peed on it in some manner, that *was the DEC culture*. I've just sent a note to Mr. BI to see if he knows and I'll pass back anything I learn if I do. Sounds like the sort of thing they might have gotten changed before it was release. > Are there any documents about the WD original still extant, do you know? > I'm pretty sure we had some stuff from WD at CMU, because CM* was made out of a lot of them, and CMU did custom microcode so they could talk to the capabilities and K.map HW. I remember seeing some prints with WD markings on it, but I was not heavily involved other than working the new distributed front-end which we did with LSI-11s. Somebody from the CMU HW lab like Jim Teter might know, although he did the 11/40e for C.mmp, I'm not sure who was the microcode guru on CM* as that was all happening as I was leaving. I sent a couple of emails to folks like Danny Klein, Mike Liebensberger, and Tron McConnell. Danny and Mike are SW folks, Tron was a EE/HW type but mostly worked on other stuff at Mellon Institute in those days. But, IIRC, Tron was worked on a 3Mbit Xerox board for the LSIs, so he might have had something. We all did some stuff with CM* (Mike more than any of us). FWIW: Tron was (is) a bit of packrat and if he ever had anything like that, he might still have it. [-- Attachment #2: Type: text/html, Size: 2598 bytes --]
On 1/15/20 6:50 AM, Clem Cole wrote:
> WD took the board design, wrote a
> new set of microcode based on the USCD Pascal-P machine <https://en.wikipedia.org/wiki/UCSD_Pascal>, then sold that as a
> 'system' called the Pascal MicroEngine <https://en.wikipedia.org/wiki/Pascal_MicroEngine>, but primarily used it is the
> sales demo.
And Volition Systems, took the P-System chip set and put it on the QBus, later put Modula-2 on it.
On Wed, 15 Jan 2020, Noel Chiappa wrote:
> Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes
> to the QBUS between the original demo WD boards and the first DEC ones?
> Are there any documents about the WD original still extant, do you know?
Which reminds me: I heard a story that DEC did not implement the Unibus as
specified, in order to lock out 3rd-party vendors; apparently the timing
was not quite right. You couldn't complain to DEC because it was not
their gear, and you couldn't complain to the vendor because they followed
the spec...
-- Dave
[-- Attachment #1: Type: text/plain, Size: 3148 bytes --] [ Getting into COFF territory, I think ] On Thu, 30 Jan 2020, Clem Cole wrote: > BTW: Dave story is fun, but I think a tad apocryphal. He's right that > DEC marketing was not happy about people using it, but it was well > spec'ed if you had CPU schematics. They way they tried to control it > was to license the bus interface chips (made privately by Western > Digital for them IIRC but were not available on the open market). IIRC > if you did not use DEC's chips, you could have issues if you >>similar<< > function chips from National Semi. I remember Ken O'Munhundro giving a > talk at a USENIX (while he was CEO of Able) talking about 'be careful > with foreign UNIBUS implementations.' If I recall it was the analog > characteristics that were tricky with something like the BUS acquisition > for DMA and Memory timing, but I admit I've forgotten the details. Ah; the chips could explain it. I can't remember where I heard the story, but it was likely in ";login:" or some place. Hey, if the DEC marketoids didn't want 3rd-party UNIBUS implementations then why was it published? > I think you are confusing VAX's SBI with UNIBUS. With the Vax, unlike > PDP-11, the systems did not come with complete schematics for all > boards. So to design for the SBI you had to reverse engineer the CPU > and Memory boards. DEC having successfully won the CalData suit, went > after Systems Industries who was the first to build SBI controllers. > DEC lost, but the truth was that because they had work had been reverse > engineering, SI was close but not 100% right and they had a number of > issues when the boards first hit the street, particularly with UNIX > which did a better job of overlapped I/O than VMS did. At UCB we had a > logic analyzer in one of the 780s at all times, and the phone number of > the SI engineers. We eventually helped them put out a couple ECO's > that make the original boards work in practice much better. No; it was definitely UNIBUS (I wasn't aware of the SBI at the time). As for overlapped seeks, when they were implemented in Unix it broke the RK-11 controller, and DEC pointed the finger at Unix (of course) since their own gear worked. To cut a long story short, they were forced to use some fancy diagnostic (DECEX?) which hammered everything at the same time, and the problem showed up. Turned out that their simpler diagnostics did not test for overlapped seeks, because they knew that it didn't work; out same the FE to modify the controller... > BTW: My friend Dave Cane lead the BI at DEC after finishing up the > VAX/750 project (he had designed the SBI for 780 before that). In > fact, the BI was >>supposed<< to be 'open' like Multibus and VME and all > chips were supposed to be from the merchant market. But at the last > minute, DEC marketing refused and locked down the specs/stopped shipping > schematics with the new systems destined to use BI. Dave was so pissed, > he left DEC to found Masscomp and design the MC500 (using the > Multibus). Yet another reason why DEC went under, I guess... -- Dave