- cctalk - classiccmp.org

by Ali

I also have the following available for whoever is interested: Sony StorStation AIT Library LIB-162 https://forum.vcfed.org/index.php?threads/sony-storstation-ait-library-lib-1 62.1253656/ HP SureStore SC10 https://forum.vcfed.org/index.php?threads/hp-surestore-sc10.1253657/ HP Impact Line Printer 2563C (this is one nice printer and if I had the room I would keep it but alas....) https://forum.vcfed.org/index.php?threads/hp-impact-line-printer-2563c.12536 54/ -Ali

11 months, 3 weeks

1
0
0 0

Lee Felsenstein at VCF West August 1 at 4:30PM

by Jeffrey Brace

Lee Felsenstein at VCF West Friday, August 1 at 4:30PM. He will talk about the 50th Anniversary of The Homebrew Computer Club. Get tickets here: https://connect.computerhistory.org/.../1ffceb98-f556... <https://connect.computerhistory.org/events/1ffceb98-f556-df49-f011-42475680…> Info here: https://vcfed.org/events/vintage-computer-festival-west/ <https://vcfed.org/events/vintage-computer-festival-west/?fbclid=IwZXh0bgNhZ…> Jeff Brace

11 months, 3 weeks

1
0
0 0

Re: Burroughs backplane story, was Re: Another 780 backplane story

by Freek Heite

Ah, thank you Paul, for sharing this story. Postings like this make cctalk worth every penny, IMO! Regards, Freek. -----Original Message----- Date: Tue, 08 Jul 2025 21:30:36 -0000 From: paul.kimpel(a)digm.com Subject: [cctalk] Burroughs backplane story, was Re: Another 780 backplane story To: cctalk(a)classiccmp.org Message-ID: <175201023609.1228.2550589532797629102(a)classiccmp.org> Content-Type: text/plain; charset="utf-8" In early 1971, I started working as an on-site software tech on a rather large (for the time), dual-processor Burroughs B6500. It was early days for that system, and we had a lot of problems with it in the field. We got those ironed out pretty well and eventually got the system up to an acceptable level of operation. <<< snip>>> We finally deduced that the problem had been present since the system left the factory floor. The original I/O software had been so poor that the system was seldom (if ever) able to initiate more than one I/O to disk at a time, but the new version we had recently installed was really good at initiating multiple I/Os. Mux 1 had a lower selection priority than Mux 0, so under the old software it was seldom selected, and perhaps never so for tag transfer I/Os, which are relatively rare. The new software allowed the system to get busy enough that Mux 1 started to be used a lot more often, and eventually it got busy enough that a paging I/O for that master PCW array got scheduled to Mux 1, and the system just didn't survive for very long after that.

11 months, 3 weeks

1
0
0 0

Burroughs backplane story, was Re: Another 780 backplane story

by paul.kimpel＠digm.com

In early 1971, I started working as an on-site software tech on a rather large (for the time), dual-processor Burroughs B6500. It was early days for that system, and we had a lot of problems with it in the field. We got those ironed out pretty well and eventually got the system up to an acceptable level of operation. About a year later, a major upgrade to the MCP (the OS) was released. A major component of that release was a completely rewritten I/O subsystem with much higher reliability and much, much better performance, especially in "Logical I/O," the interface between user programs and the memory buffers and physical I/O mechanism. Soon after installing this release, we started to get fatal system crashes in Logical I/O. Describing what was happening requires a little background on the system architecture. The B6500, like its predecessor the B5500, is known as an ALGOL-oriented stack machine, but it is less well-known as a type of capability system. To support that, it used a segmented memory model and tagged memory. Each word had an extra three bits, not accessible to user programs, that identified the type of data in a word. For example, tag 0 was ordinary data, tag 2 indicated a double-precision word, tag 5 was a data descriptor through which data segments were addressed, and tag 7 was a Program Control Word (PCW) that effectively addressed a location in an object-code segment. It was used primarily as a procedure (subroutine) entry-point address. In reading the dumps from the crashes and the MCP source code, we started to learn how the new Logical I/O mechanism worked. It cleverly used the stack addressing of the system to implement a very object-oriented interface. The "methods" of this interface were small procedures that were customized to handle very specific cases of record handling -- random vs. sequential I/O, blocked vs. unblocked I/O, translation or no translation, etc. There were scores of these methods. The idea was do a little as possible for each user request and to avoid making as many decisions as possible and to optimize the buffer handling in each case. There were about a half-dozen different types of user requests, and the methods for those were accessed through a branch table in the FIB (control block) for each open file. That branch table contained PCWs for the appropriate methods needed by that file. The table was set up during file open, but could be changed as the nature of the user program's requests changed, e.g., from sequential to random access. We discovered that the crash was caused by some PCWs in the file-level branch tables having tags of 5 instead of tags of 7. Attempting to call a procedure using a tag-5 word was a no-no that was trapped by the hardware, hence the fatal dump. Then we discovered that the branch tables were loaded from a master array of PCWs for all of the possible methods, and when we looked at that array in the dump, ALL of the PCWs in the array had tags of 5! We know that array initially had to have had words with tags of 7, because the system had run for quite a while before crashing, so how could all of the words in the array suddenly have changed to tags of 5? There wasn't any straightforward way to do that in software. That master array was loaded from from the OS image on disk at the initial boot, but then we found out the array was overlayable -- it could be paged out and back in by the virtual memory mechanism. So we began to suspect there was an issue with I/O. Normally, a disk read stored words in memory with a constant tag of 0, but there was a special I/O mode, termed "tag transfer," that would read and write the tag bits along with the regular data bits. Fortunately, the other tech on the site had worked in the MCP group for a while and knew the I/O hardware pretty well, so he started writing some standalone programs to exercise the hardware in specific ways. This system had two I/O Multiplexors (multi-channel DMA units) numbered 0 and 1, and the disk drives were dual-ported so that either Mux could address any of them. My colleague's programs tried doing I/Os with various combinations of Mux and channel assignments. And as you might expect by now, he discovered that doing a tag transfer read through Mux 1 always dropped the middle tag bit. We turned that finding over to the on-site Field Engineers, who pulled out their schematics and started tracing signals. It took several hours, but eventually they discovered not a loose wire, but that Mux 1 was completely missing a wire. Of course, it was the wire that carried the middle bit of the tag during tag transfer. We finally deduced that the problem had been present since the system left the factory floor. The original I/O software had been so poor that the system was seldom (if ever) able to initiate more than one I/O to disk at a time, but the new version we had recently installed was really good at initiating multiple I/Os. Mux 1 had a lower selection priority than Mux 0, so under the old software it was seldom selected, and perhaps never so for tag transfer I/Os, which are relatively rare. The new software allowed the system to get busy enough that Mux 1 started to be used a lot more often, and eventually it got busy enough that a paging I/O for that master PCW array got scheduled to Mux 1, and the system just didn't survive for very long after that.

11 months, 3 weeks

1
0
0 0

Update on Qbus backplanes

by Paul Anderson

For those of you who wanted the Qbus backplanes here is the list. I've been moving things around and found them while looking for something else. Please contact me off list with any questions. H9270 4 x 4 used in the BA11-M for the original PDP11/03 H9270 with card cage complete 11/03 box, boards available H9276-B H9276-B with card cage H9278-A 2x12 micro backplane with card cage BA123-A Sygma 4x8 with card cage Heath

11 months, 3 weeks

1
0
0 0

Re: Another 780 backplane story

by Marvin Johnston

While not on a 780 back plane, about 50 years ago, I was basically in charge of some 26 PDP16M computers. Periodically, one of the chips would be found with the top blown off. At some point, I pulled the computer and examined the backplane filled with wirewrap wires. The solution turned out to be fairly simple... a -15V bus was about .001" near one of the wirewrap posts. A slight moving of that bus away from the wirewrap post solved that problem. I have to assume it was a temperature related problem since increasing that spacing solved the problem. Unrelated to the computer problem, another source of angst was intermittently one of those computers would crash. That one took probably a year to find... one of the interface M series pullup cards had a pulldown card installed in its place. I should mention all the above took place on a newly install system. Marvin

11 months, 3 weeks

3
2
0 0

IBM backplane story was Re: Another 780 backplane story

by trp

I worked part time at a computer center for a large bank while getting my undergraduate degree. The center was getting one of the first IBM 3081 machines to replace the existing 3033 MP. Because of the helium filled modules, getting the machine from the climate controlled truck to the center, which was on the 7th floor of the bank building was crazy; the move had to be accomplished in 30 minutes. As a dry run, IBM supplied a size and weight dummy 3081 in advance to make sure the delivery went smoothly. As you might imagine, the install and switch over to the 3081 was high profile. The VP in charge of the center was under pressure to get it done on schedule. The delivery and initial install went according to plan. The data was migrated to the new disks and the various application software was run through its paces. Unfortunately, the 3081 would occasionally throw a power fault. The local FE’s could not determine the cause, so after a week or so second level support was called in. They could not figure it out, so IBM brought in Ivan (I think that was his name). You know when you get the hot shot from IBM when he arrives in bib overalls and tennis shoes, not a suit and 5 pound wingtips. After the second day, Ivan got tired of the stream of managers asking him when the 3081 would be available, so he went down the the main bank floor and grabbed the thing (I cannot remember the proper name) banks used to use to create teller lines (posts and satin “ropes”), and formed a cordoned area around the 3081’s console. Note that each computer console had a telephone (1 for each 3033 and one for the new 3081) for communicating with the computer operator. On the third day, the VP bypassed the cordon and asked Ivan when the 3081 would be operational and Ivan replied he was’t sure. The VP said he had already told the president it would be up by the end of the day, and Ivan handed the VP the phone on the console and said, and I quote, “Call someone who cares”. I kid you not, I still remember verbatim. Early afternoon of the third day, Ivan asked the Lead FE to get a torch. There was an awesome hardware store about 6 blocks away, so in about 20 minutes the torch was delivered. The power bus on the 3081 had enormous cables composed stranded 4-6 large gauge wires that were soldered to large metal plates. Ivan had determined that the wires were improperly soldered and used the torch to resolder them. You can imagine the horror on the faces of the staff as Ivan opened the power bay, lit the torch, and started melting the solder. And it worked! No more power faults. — Todd

11 months, 3 weeks

3
2
0 0

PDP8-A parts

by Paul Anderson

As requested, here is a partial list of the 8-A parts available. I have a few more to go through, but most are on here except for possibly a 128K memory board. I have some omnibus boards, M8357 RX8e, LA180, LQP, etc, and will try to make a list next week. If you need something not on here, please ask. I have at least one of each of the following, and more than one of some. G8016 G8018 H9194 12 slot 8-A backplane limited front panel programmers panel MM8-AA MM8-AB M8315 M8316 M8317 M8319 M8416 M8417 Also some non dec: REMEX PC8E core memory A complete 8-A mounted in the desk with RX02s. It's currently in the back of a 20 or 25 foot rental locker, but I hope to get it out this summer. It came with a LA35 and maybe a VT52.

11 months, 3 weeks

1
0
0 0

VAX 86x0 schematics

by P Gebhardt

Dear list members, I was wondering if anybody is aware of VAX 86x0 schematics having survived the product life cycle within DEC? I searched the web extensively but could not find any hints on this. It seems that DEC never published such details as schematics for the successor of the VAX 11/78x systems, not even on microfiche, maybe due to the macrocell array implementation (just a guess). All I could find is that there were illustrated parts list on microfiche. However, maybe Hewlett Packard handed DEC-internal documents over to a museum such as the CHM? Or a former designer still have schematics in their archives? Any pointers would be greatly appreciated! Best regards, Pierre ----------------------------------------------------------------------------- http://www.digitalheritage.de

11 months, 3 weeks

13
33
0 0

Another 780 backplane story

by Mark Kahrs

Jon Elson's take hits home. A 780 was delivered and VMS was running. We installed 4.1BSD and it ran fine until it crashed. Field service insisted we needed a full set of RS-232 wires in our cable. Still crashed (surprise!). Switched to VMS, still crashed after a while. Local field service couldn't find it. The big guns flew in from Maynard. First day: Couldn't find it. Second day: "What, what's that wire doing there? Have a wire-wrap tool?". Removed wire from backplane. Boots, runs. Engineer flies home.

11 months, 3 weeks

21
34
0 0

2026

2025

2024

2023

2022

cctalk