I've heard from someone that used one that the 360/91 was microcoded, just very differently both compared to contemporaries and to today's machines. That the fetch, decode, and dispatch was in pure logic, but the execution units themselves (at least in the float unit, which was the only unit that was out of order) ran their own microcode programs.
You wouldn't happen to know where more documents than what's on bitsavers exist for the 360/91 (or related like the 95 and 195) do you? Competing anecdotes are less than satisfying. My source has been worng before but he bats a pretty good average for his contrarian comparch statements.
That's a great paper! I really appreciate you finding that; it was a great read and does go further in depth than the funcChar docs.
It unfortunately doesn't seem to disambiguate the specific question of if floating point execution units were implemented via microcode unless I'm missing it.
I don't think the Mod 91 ever shipped. It was a combat machine designed to squash CDC (IBM was sued by them for their anti-competitive actions here) and was eventually transmogrified into the Mod 95/195 which did ship.
There were approximately 15 Model 91s produced. The Computer History Museum has the console from one, and the Living Computers Museum has another.
The Model 95 was the even more rare version with thin-film memory instead of core memory. Only two of them were produced, for NASA.
The Model 195 was a reimplementation of the Model 91 with "monolithic" integrated circuits instead of hybrid SLT modules. The System 370/195 was very similar to the System 360/195. Curiously, the System 360/195 has the black styling of System/370 control panels, rather than the beige control panel of System/360.
According to wiki, there were 15 model 91s, 4 kept by IBM and the rest went to customers including NASA. There were two 95s and both went to NASA (and really the 95 was a 91 with a different RAM technology but the same CPU).
That lines up with my source who started his career doing simulation and analysis of rocket propellent in micro gravity for the tail end of the Apollo program and some of the initial work for the space shuttle.
I'm trying to understand how they read out that BCROS memory. From the picture, it appears to be a single layer of copper on a mylar sheet. How did they get the bits out?
They read the data capacitively. A sheet with perpendicular drive lines was put on top of the copper sheet. Energizing a drive line capacitively coupled to the square capacitors on the BCROS sheet. Each bit had two capacitors (balanced), driving a differential amplifier (sense amplifier) to produce the output bit. Using two capacitors reduced noise since the differential amplifier would cancel out the noise.
There's not really much risk. Because the S/360 was built from gates (SLT) rather than an integrated circuit, they could easily change the design if needed. (Even at a customer site!) It's not like a microprocessor chip that would require an expensive re-spin if something went wrong. So if they discovered they needed another micro-operation, they could just add it to the design. There are a few micro-operations that seem rather contrived, as if they realized it would really help performance to do this random combination of things.
The System/360 I/O channels are kind of like a DMA (direct memory access) controller, so I/O can happen in the background instead of making the CPU wait. The Raspberry Pi PIO is more of a programmable state machine for low-level I/O protocols. So they are kind of similar in that they offload I/O tasks from the main CPU. But they also act at different levels: a System/360 channel does something like reading a block of data from tape, while a PIO deals with individual up and down transitions on a line.
Is this I/O channel architecture basically the same thing that makes mainframes so reliable even today? Might you or anyone else have any recommendations on mainframe I/O architecture evolution? I've tried to look it up in the past but without much success.
They are reliable through exhaustive testing of components, plus error-checking, plus redundancy (on some models). What channels get you is high I/O throughput. Especially in 80 character long records
The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better.
Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video:
In 360 a channel could connect to a number of control units that each connected to a number of devices. Early on, just one IO could run on a channel; so all other devices were locked out until the IO was performed (several details omitted).
Early disk IO held the channel until the desired record came under the head. That was after the arm was positioned. 370 brought in rotational position sensing allowing other disk IO to take place.
Later on, tapes also accommodated record positioning. Forward Space File came with 360.
Remember though that these days tapes are often archived in a virtual tape library physically on disk, but processed with tape channel commands.
Back in 360,control units that could handle simultaneous IOs appeared. They were connected to two channels.
The Apple Macintosh IIfx had IOP's which I think were 6809's as I/O controllers. I believe they only worked in System 6 and were not used in System 7.
Somebody mentioned that the Mac Quadra 950 had IOP's as well.
