Allison wrote; I so regret not having rescued an old computer that I played with through all four years of high school. The machine was made by Minnesota Mining and Manufacturing (aka 3M Corporation). Today, there seems to be no record that 3M ever was in the computer business. But...it was. The system was designed expressly for process control. Kind of makes sense for 3M to develop a system like this, since most of the manufacturing they did needed process controls, and at the time, computers were getting to into that role in place of electromechanical systems. The system was given to our high school by the local Natural Gas public utility that used the system from the mid-1960's through the early-1970's for monitoring and controlling gas flow in pipelines. It was replaced by more modern computer, a PDP-11 of some variety, IIRC. This 3M machine was a dual processor system, with two identical CPUs that could communicate to each other through a common register located in an I/O rack. The original process control software was designed so that both CPUs would operate in tandem, each doing a different part of the job. One CPU mainly did all of the I/O interfacing and data normalization, and the other CPU did the number crunching and processing for the process control, feeding results back to the I/O CPU to control the physical stuff, and generating reports on an IBM typebar-type output typewriter. Operator interaction with the process control system was through a Teletype 33-ASR terminal. The CPUs were transistorized. I recall that the cards were arranged in a U fashion looking at the CPU chassis from the top, some power supply circuitry and relays at the top of the U, the circuit cards making up the sides and bottom of the U, and the drum memory module in the middle.. Each CPU was something like 12RU height, and were in a small desk-high standard 19" equipment rack, with the CPUs stacked one above the other. The CPUs were 24-bit word machines, with an 8K-word magnetic drum as main memory. Instructions had five bits for the opcode, and two address fields, one for operand location (drum address in block/track/sector format) or in the case of some instructions a short constant number), and also a next instruction address (again in block/track/sector format). The I/O rack had the interprocessor communication register, along with registers for reading the time from a transistorized Parabam real-time clock (HH:MM:SS) in 24-hour time (The clock had those wonderful projection-type incandescent displays to show the current time), a Teletype current-loop interface at 110 baud, an interface for communication the IBM wide-carriage output typewriter (which we never we able to get working), and a whole slew of relay outputs, contact closure inputs, digital to analog converters with line drivers, and comparators with counters connected that could act as software-driven analog to digital converters, event counters, etc. One last output interface was a register that was write-only that could enable or disable an old Mallory Sonalert that would generate an ear-splitting shriek when turned on. There were also two banks of decimal thumbwheel switches, one with three digits, and another with 8 digits, that could be read from the CPU 4-bits at a time through an I/O register. When I got to high school in 1974, the drum in one of the CPUs had suffered a bearing failure and crashed hard. The instructor of the computing curriculum looked into seeing if the drum could be repaired, but it would have been prohibitively expensive, so the drum was removed from this CPU and used as a prop for illustrating different types of memory technology to his students. The other CPU ran fine through my years of high school, and I learned a great deal about programming at the machine level from the old 3M (I for the life of me can't remember the model number of the machine). I fondly remember writing an "alarm clock" program where a time in HHMMSS form could be wheeled into the low six digits of the eight-digit thumbwheel register, and when the time there matched the time on the Parabam clock, it'd fire off the Sonalert, and print an arbitrary message on the teletype repeatedly until the program was halted by dialing a stop code read from the three digit thumbwheel switch bank when the program was started. Once the program was started, I'd scramble the three digit thumbwheels, so no one but me would know the code to stop the program. You might think that you could just press the "STOP" button on the console...but there was a Plexiglas cover with a small padlock lock on it that covered the console controls...and I had a key). So, I'd set a time during one of the 1st year computer classes, start the program, and lock the cover over the console. In the middle of the class, the Sonalert would go off, and the teletype would rattle out "HELP, HELP!! I'M TRAPPED IN HERE!!! LET ME OUT!!!" with Control-G (ring the Teletype bell) interspersed amongst the characters). It would cause just a bit of a fuss. After watching the chaos for a few moments, I would calmly walk in and dial the code to stop the program. Needless to say, after I did this a few times, I was kindly asked by the computer instructor not to do that anymore. It was great fun while it lasted. The machine had no index registers. So, indexing meant writing self-modifying code. Never was bounds checking more important than when you were writing self-modifying code. The machine had a hardware loader, which would accept block/track/sector addresses followed by a space, then the 8-digit octal representation of the word to be placed at that drum address. The loader was initiated by pressing a "LOAD" button on the console when the CPU was stopped. The loader was fast enough to be able to take in programs from the tape reader on the 33-ASR Teletype hooked up to the machine. There were four other controls on the console not counting the main power switch. "STOP" (halted the machine), "CLEAR" (initialized the program counter and two accumulators (A & B) to zero), and "START", which started the CPU executing at the current program counter location, which most of the time was 0/0/0 because you'd press CLEAR before START, and have a jump at 0/0/0 to branch to your program. The STOP and START buttons were lighted, so you could tell if the machine was running or halted. The last control was a momentary toggle switch, that would single-step one instruction when the machine was in STOP state. There were five neon lamp indicators on the console that showed the current instruction opcode to be executed. With such minimalistic controls, debugging was interesting, to say the least. When powered up, the machine would have both the START and STOP lights turned off until the drum got up to speed and everything was synchronized, and then the lamp in the stop key would light up to tell you the machine was ready. The machine was completely bit-serial in nature, minimizing the number of flip flops. I recall that the circuit boards in the machine were something like 5x7 inches (give or take), and were not densely packed with components. They were fiberglass boards, with traces only on one side, and jumper wires on the component side. I remember date codes on the transistors as being from the 1963 - 1964 timeframe. I recollect that there were something around 48 circuit boards in each CPU. We occasionally had to scrounge boards out of the decommissioned second CPU to fix faults that developed in the running machine...it was musical board swapping to troubleshoot because we didn't have any schematics or service documentation for the machine. The machine was quite slow, even if you wrote the code to use instruction timing to optimize placement of instructions and operands on the drum to minimize latency. I recall writing a program that I optimized as best as I possibly could, and the machine couldn't output to the Teletype at its full rated speed when typing out text from an arbitrarily located text buffer. It'd do about 9 characters per second. The machine had interrupt capability, but most of the interrupt processing logic was in the I/O rack, and something was amiss with the logic, and we were never able to get it to work properly. So, alll I/O was CPU polling, which explains part of why the I/O was slow. I managed to write a minimal DEC FOCAL interpreter for the machine. IIt was really slow, but it worked. The floating point math routines were the most difficult. I had learned FOCAL on a DEC PDP 8 (straight 8) in a class I took when I was in 8th grade, and it seemed simple enough that I could make it work on the 3M machine. I had thought about trying to do BASIC for the machine, but I decided on FOCAL because it was a lot less complex. Glad I chose FOCAL, because It barely fit, even in somewhat minimalized form, on the 8K drum. It was very slow having to pack/unpack three ASCII characters into 24-bit words, but to make everything fit, I had to do it. And, with only two registers (accumulator A and B), and the interprocessor communication 24-bit register that was accessible through I/O instructions, it was quite a challenge. Anyway, I graduated in 1977. I went back during the 1979 school year to visit, and the whole place had changed. The amazing computer curriculum teacher was gone, promoted to somewhere in the district administration, and some younger new guy was there whom I took a pretty immediate dislike to. This was his first year teaching at the school, and the first thing he did was call a scrap dealer to come take away the 3M machine, along with another old machine that was donated to the school...hardly a computer, more like an accounting machine, made by SCM, called a 7816 Typetronic. They were both gone, and I was really angry that they had gone off to scrap. Also, the IMSAI 8080 microcomputer that a small group of students including myself had built from kit form as a high school project during the end of Junior and first part of Senior year in high school was nowhere to be seen. In their place were a number of shiny new Apple II computers. These, to me, seemed mere toys compared to the "real" computer that had gone off to scrap. Had I known this was going to happen, I would have somehow come up with a way to rescue the 3M machine (it wasn't small, nor lightweight) to some kind of safe storage until I would have the resources to restore them. Fortunately, through pure luck, I did manage to find that old IMSAI that we built....and it is in my collection today, and works great. A story for another time. So, even though I was born a bit late to have been "in the prime time" of the earlier computers, I did get the rare experience for a person my age of working with a machine that used magnetic drum memory as primary memory, and I wouldn't trade what I learned from that old beast for anything. Rick Bensene