Eric, Way cool. The relays you spoke of for the status display are they *magnetic latching* relays to keep their state? What type of memory does the computer have? Core memory? I hear you talk about the 232 interface. Most people call it 2 Thirty 2. Nice job. Interesting video. Ken On Sun, Aug 20, 2023 at 8:33 PM Eric Moore via cctalk <cctalk(a)classiccmp.org> wrote: -- End of line JOB TERMINATED

Eric Moore wrote: This brings back memories for me. Except the gas line control computer (it didn't run gas turbines like this system did, but it monitored gas line pressures and would open and close distribution valves based to equalize pressures throughout the system) was considerably earlier than the SEL 810. The machine was made by 3M (Minnesota Mining & Manufacturing), and was all transistorized and had main memory of a magnetic drum instead of magnetic core. The CPU was designed in 1963, and the two CPUs in this system were manufactured in 1965. The control system was quite similar with magnetic latching relays to maintain state in event of power outage, and lots of A/D and D/A converters and relay controls and digital I/Os. The CPU was redundant, there were two of the CPUs that could talk to each other through a single hardware handshake register. If one machine failed, the other would take over, in a master/slave relationship. The control system had a Parabam transistorized digital clock using projection displays instead of Nixies with BCD readout, and it had a bank of BCD-encoded thumbwheel switches for setting various parameters. The console was a 33ASR Teletype, and it had a large-carriage IBM typebar-type typewriter (not Seletric-based) that it used for printing out the logs. The IBM had a tractor feed for standard green-bar printer paper. This machine was donated to our high school after it had been replaced by newer technology. The I/O lines going out to the remote stations were chopped, much like the cable you showed. We had to make sure there were no shorts caused by the chopping of the cables before we could power anything up. It all worked, except the drum on the "B" computer had some bad spots on it, so these areas had to be avoided. Eventually, that drum crashed (bearing failure), rendering the B computer unusable, but the A computer's drum was very solid and worked well. The CPU had a 24-bit word, used sign-magnitude math, and each instruction had a pointer to the next instruction to be executed. If there was an operand to be fetched, its address was also included in the instruction. Branches coded two next instruction locations, one if the condition as true, and the other if false. To optimize the speed of the machine, the operand and next-instruction addresses had to account for drum rotation to minimize time waiting for the drum to make another rotation. The system was built in to a big desk, with the CPUs below like a filing cabinet, the console on the table top with the clock and thumbwheel switches, and a Mallory Sonalert that could be programmatically turned on for alarm conditions. The IBM logging typewriter set off to the side on the tabletop. There was a standard 19" equipment rack located at one end of the tabletop that contained all of the relays, digital I/Os, and A/D and D/A converters. The CPUs were not terribly fast, being completely bit-serial in nature. Writing optimal code to print out a character string pre-stored on the drum on the console Teletype could not drive the TTY at full speed, probably about 8.5 to 9 characters per second maximum. I did have a hardware-based loader, though, that could read addresses and data in octal at full TTY speed from the paper tape reader. I wrote a FOCAL interpreter for the thing (based on DEC's FOCAL for the PDP-8). When you'd enter a line of program code (e.g., 1.02 ASK A) and hit RETURN, the machine would churn for approximately 4 seconds before it'd spit out a linefeed acknowledging that the syntax was reasonable and the line was stored in memory. The floating point math was very slow (it did not have hardware integer multiply/divide, so all of the math had to be done using integer add/subtract). Entering "TYPE 2+2" and pressing return out take about 15 seconds to print out "= 4". It was an exercise in programming, not effectiveness as a programming tool for the machine. It was quite educational writing re-entrant and recursive code on that machine, were there were no index registers, and no indirect addressing. It all had to be done by inline instruction modification. Despite the limits of the machine, it successfully and reliably managed the flow of natural gas through the various distribution networks around the region for about 10 years before it was replaced by, I believe, a process-control computer system developed by General Electric. Thanks for your nice video on this great old system that had a similar role back in the day! Rick Bensene The Old Calculator Museum https://oldcalculatormuseum.com Beavercreek, Oregon USA