Hey all,
I'm trying to track down a manual or instructions for the Message Center
program on the Interact One (from 1978).
I've run this in the MAME emulator, and it seems the program has a
"partial" BASIC-like interpreter. You can do line numbers, like
10 HELLO
20 WORLD
Then issue the command SCROLL, and it will start scrolling text in the
numeric sequence they were specified. Then you can also do commands like
FLASH, BUZZ, BEEP in its equivalent of "immediate mode" -but I don't know
yet how to specify these commands in the numeric program. And in the
emulator, I can't yet parse the commands PLOT, SOUND, SIZE - these "message
center" program specific commands,not BASIC (BASIC on this system is
loaded from tape).
Anyway, a manual on a program for the Interact One called "Message Center"
is what I'm trying to track down.
Thanks,
Steve
Hello All,
A long time ago I acquired a System/23 desktop unit and eventually a number
of the tower units including the HDD tower unit. The plan was to setup a
System/23 Muli-User system with multiple terminals connected together. Well,
like many great plans real life got in the way and the units have been
sitting in storage for a few years. I have accepted that this is one of the
projects I will never get to and it is time to pass them on to someone else
who can enjoy them. The systems are in SoCal (Upland, CA to be more exact).
More info can be found at the following links:
https://forum.vcfed.org/index.php?threads/ibm-system-23-datamaster-5324-towe
r-model-of-the-5322-with-original-clicky-keyboard.1253651/
https://forum.vcfed.org/index.php?threads/ibm-system-23-datamaster-5324-towe
r-model-of-the-5322-with-one-floppy-drive.1253652/
https://forum.vcfed.org/index.php?threads/ibm-system-23-datamaster-5322-or-5
324-hdd-tower-model-5247.1253653/
I hate to part/scrap them as the towers rarely show up so I am hoping
someone local would be interested in them. Feel free to email me directly or
reach out through VCF. Thanks
-Ali
I did some digging and found one 3000-400 with no lid( It could be here
somewhere) and I'll have to move it to look it over to see what's there.
I had 6 or so 3000s and I guess I sold them, but more digging to do.
MV3100 M76
MV3100s I can't get to the model number
4000-60
5000-25
5000-125
5000-133
5000-200
I had to pull some boards and made a small list.
M7621
M7622
M7624
M7625
M7626
54-21149 KN15
If you need a board I have not listed, please email me off list. If I
haven't replied, bug me.
I did not list qtys- some items are more than one.
Thanks, Paul
As many of you know I have been trying to finish organizing my Unibus parts
and finish building several systems for years. Other than time and my
health I don't have enough space. I would like to sell, at reasonable
prices, all of my q-bus parts which include 400 - 500 boards, about a dozen
boxes, and a lot of spare parts. I have BA11-M, BA11-N, BA11-S and a few
BA23 boxes left.
If you have an original 11/03, I have a dozen or so H780 power supplies,
which are very hard to find. They are also used in the Vax 11/780 front
end, the
RKV11-D and possibly a few other items. I can test them if I have time, but
that might take awhile.
I'm also taking offers on some of my 8-E and all of my 8-A items. I will
entertain offers on the VT14 and all of the PDP 14 industrial controller
parts.
I have a few Vax 3000, 5000, and a few others along with parts including
memory.
Those of you who have been here know I have a ton of DEC and
DEC-compatible parts, but no one has seen everything. I have brand new
disk heads, tape drive heads, alignment packs, and literally tons more. I
went through over 50 backplanes a few weeks ago looking for a few specific
ones.
Some Unibus items are also going. Probable some 11/05s, 11/34s, 11/83
and/or 84s and a lot of options and boards.
So if you need or are thinking about DEC items, feel free to send me a wish
list off list.
I prefer phone calls and will send my number upon request. I was never
great at typing and I'm getting worse.
Oh- I also trade for US and foreign coins and currency.
Thank, Paul
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.
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.
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
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
