Talk:IBM System/360 Model 20

Rationale

I created this article because the Model 20 differed in so many ways from the other System/360 machines that it offered only nominal compatibiity. It's a stub now, but the architecture, software, etc. can be expanded later. Peter Flass (talk) 14:35, 12 October 2012 (UTC)

Thank you.

I think the statement

"the Model 20 differed in so many ways from the other System/360 machines that it offered only nominal compatibiity"

should be in the article introduction. It is very important.

Because of the reduced number of registers I expect all assembly language programs would need to be rewritten for the Model 20. Is that true? I believe at the time most of the OS and compilers were written in assembler. That would explain why it had it's own OS and only a few languages.

Could it run any form of OS/360? Or just the DPS, TPS, etc? Ttulinsky (talk) 01:36, 30 July 2023 (UTC)

It couldn't run any normat S/360 OSen, including DOS or TOS. I think that, except for the I/O, assembler programs would need relatively small changes to run on a full-sized 360, as long as you were willing to accept the halfword limitations.

IME most /20's were programmed in RPG rather than assembler, and the RPG language was compatible, or almost compatible. Believe it or not there was a PL/I compiler for the /20. I don't know about COBOL, but I think most users stuck to RPG,

The lead does say "The Model 20 supports only a subset of the System/360 instruction set" in the second sentence. Peter Flass (talk) 03:56, 30 July 2023 (UTC)

Submodels

I haven't been able to find out the description of the various submodels. I suspect the difference was the combination of integrated features, but the /20 is rather poorly documented, unfortunately. Peter Flass (talk) 01:55, 17 October 2012 (UTC)

There is information on submodels 2, 4 and 5 in the disk utilities manual, referenced in the article. It gives minimum and maximum configurations for these submodels in terms of main storage size and supported peripherals. However, I wonder if this might be too much information for the article. I suppose submodel 1 is without any disk drives. John Sauter (talk) 15:36, 27 August 2014 (UTC)

There is information on the card/tape only submodels of the M20 that suggest these are the Submodels 1 and 3, the best one being

IBM System/360 Model 20 Card Programming Support Report Program Generator. What would be nice to find would be the tape equivalent of the disk utilities manual above, or better yet, IBM System/360 Model 20 Functional Characteristics,GA26-5847. Tom94022 (talk) 16:44, 27 August 2014 (UTC)

Another useful manual is IBM System/360 Model 20 / Card Programming Support / Input/Output Control System which describes the minimum and maximum configurations of submodels 2, 3, 4 and 5 on page 8. Comparing these three manuals it is clear that the definition of submodel depends on whether you are using CPS or DPS. I think a good summary would ignore the presence of submodels and just say that main memory ranged from 4,096 to 32,768 bytes, a card reader and printer were standard, and up to six tape drives, up to four disk drives and a keyboard were optional. What do you think? John Sauter (talk) 17:19, 27 August 2014 (UTC)

I'm starting to get the feeling that the M20 (no submodels) was at some point superseded by the submodels 2 thru 5. It maybe that the first machine was a card only, 2415 tape may have been announced circa July 65 and 2311 disk circa Sept 1966, a "slower cheaper model" 4-16K with slower peripherals (2560, 2203) circa April 1968 and a "higher speed" version (32k 4 2311s) circa August 68. All this is from various Datamations. So maybe it went

M20 no sub model Card only

M20 subM 1 - Card/Tape, announced: 7/65

M20 subM 2 - Disk, announced: 9/66

M20 subM 3 - Card/Tape, "slower" replacement for 1 announced: 4/68

M20 subM 4 - Disk, ???? Disk "higher speed" version 8/68

M20 subM 5 - Disk "higher speed" version announced: 8/68 shipped 3/69? Disk ???

We probably should say something about submodels; perhaps in a footnote to "were optional" Something like "Disk drives required on submodels 2, 4 and 5. Tape drives required on submodel 3)? Tom94022 (talk) 18:48, 27 August 2014 (UTC)

The System 360 Model 20 customer engineering announcement confirms that the first M20 was card only. Tom94022 (talk) 18:54, 27 August 2014 (UTC)

DPS manual C26-3830-3 is dated March 1969, and lists as one of its reasons for publication the availability of submodel 5, so I think that is a reasonable date for the submodel 5. However, in its listing of the minimum and maximum configurations of submodels 2, 4 and 5 it claims that only submodel 5 could have more than 16,384 bytes of main storage, and only submodel 5 could have more than two 2311s.

I have found very few references to submodel 1, so it may be that the original model 20 was redesignated submodel 1 when the later submodels were announced.

I don't think we can say that disk or tape drives were required on any of the submodels, because CPS manual GC26-3603-4, dated April 1970, describes submodels 2 through 5, but does not list disk or tape drives for them, even in their maximum configurations. From the hardware point of view, I suspect there were only three machines: the original model 20, for which we have very little information; the intermediate implementation, which supported up to 16,384 bytes of main memory plus disk and tape drives; and the final model 20, called the submodel 5, which supported up to 32,768 bytes of main memory and up to four disk drives, rather than the intermediate machine's two. CPS, DPS and probably TPS defined the submodels as the intersection of what the hardware and software supported. If Datamation doesn't describe the various model 20 configurations in terms of submodels, maybe we shouldn't either. John Sauter (talk) 13:37, 28 August 2014 (UTC)

On the other hand, CPS manual GC26-3602-5, the CPS BAL manual, lists submodels 2 and 5 as having optional tape drives, and submodels 2, 4 and 5 as having optional disk drives. Maybe this is because the assembler supported tape drives, even though it was a CPS program. It also has some interesting timing information on page 75: submodels 3 and 4 were slower than submodel 2, and submodel 5 was faster. So perhaps the submodel 3 was the replacement for the original model 20 (designated submodel 1), submodel 4 added disk drive support, and submodel 2 added to that tape drive support and increased processor speed. John Sauter (talk) 14:41, 28 August 2014 (UTC)

Nice find on the date of the submodel 5, I've corrected my table above. FWIW, I now think the 4 was a slower 2. It would be nice to find an IBM sales manual with specific configuration details. My guess is disk required on 2, 4 and 5 with tape optional and tape required on 1 and 3, but who knows. FWI, I think we still need to get something about submodels into the article. Tom94022 (talk) 19:32, 28 August 2014 (UTC)

Considering that the minimum and maximum configuration of each submodel seems to depend on which manual you read, I don't know what we could usefully say about them. Perhaps a separate section which lists the various configurations supported by CPS, TPS and DPS? John Sauter (talk) 21:11, 28 August 2014 (UTC)

Did the 2311-11 use CKD?

A user has expressed to me his belief that the controller for the System/360 Model 20 did write the individual sectors in a CKD format with the Count field having KL=0 and DL=270. In the S/360 version the record starts with an address mark while in the 360/20 version the record starts with a sector mark, otherwise they are the same (excepting end of record Gap 4). His recollection is that there was some degree of data compatibility between the IBM 2311 model 1 interfaced through the IBM 2841 and the 2311 model 11, interfaced through the model 20's SCU.

However, as I read Y26-5897, referenced in the article, which I regard as the best available source of technical information on the IBM 2311, there was no data compatibility at all. As described on page 1-9, on the IBM 2311 models 11 and 12, each of the ten sectors started on a sector pulse (a signal sent to the model 20 from the drive) and consisted of a count and data. The IBM 2841, on the other hand, wrote variable-length records consisting of a count, key and data. It had no circuitry for sensing the sector pulses from the drive, and so could not determine where the sectors started, even if it was attached to a 2311 model 11. On page 1-11 of Y26-5897, at the end of the description of the IBM 2311 model 11, there appears this sentence: “Because of the difference in format, disk packs written by the IBM System/360 Model 20 cannot be processed by any other model of System/360.” John Sauter (talk) 20:51, 24 August 2014 (UTC)

I posted the comment on Sauter's talk page since the article as written is still correct even though the deleted material was correct. Contrary to what he says above, the authoritative documents for the formats would be the controller documents not the drive document. For example, Appendix E to IBM System/360 Model 20 Disk Programming System Disk Utility Programs shows that the M20 sector format consisted of a Mark, a Gap, a Count Field, a Gap, a Data Field and a Gap to the next Mark, which is the same format as in the 2841, the only substantive difference being the Mark is an address mark in a pack written on a 2841 and a sector mark in a pack written on a M20. Furthermore the M20 written nine byte Count field is for all practical purposes identical to and indistinguishable from a 2841 written nine byte Count field, in particular with regard to KL and DL (three of the nine bytes):

Values of bytes in a M20 written Count Field

Byte 7 KL = Key length -- Is always O.
Byte 8-9 DL Data length -- Is always the binary equivalent of decimal 270

IBM System/360 Model 20 Disk Programming System Disk Utility Programs

Thus it seems clear that the M20 used a CKD format, with the key and data lengths fixed. My recollection is that there was one way interchangeability so given the quote Sauter found it must have been a M20 could read 1316 packs written on a 2841 with KL=0 and DL=10E₁₆. If the gaps were the right size then the sector marks would appear at the right time between each data field and the next count field. Maybe I'm thinking of a utility that wrote a full track record with the properly sized gaps. Regardless, the format on a M20 written 1316 disk pack was CKD. Whether we add it back or not depends upon other editors, I'm indifferent to that, but didn't want the error to remain uncorrected. Tom94022 (talk) 00:36, 25 August 2014 (UTC)

Thank you for finding information about the bits the model 20 wrote to disk—I was unable to find that information. I did, however, find the equivalent information for the IBM 2841: it is in section 1.4 of the Field Engineering Theory of Operation, archived at IBM 2841 Storage Control (Stage 2) Field Engineering Theory of Operation. As you said, both devices use an 11-byte count field before the data record, with the bytes having the same meaning. However, the IBM 2841 also wrote a Home Address area at the beginning of each track. This was a 7-byte record containing the flag, cylinder, and head bytes which are duplicated in the count field of each record. I don't see any way for the model 20 to have read or written this: in the model 20 the index mark was followed by the 11-byte count field for the first data record. Thus, I don't think there was any way to exchange data between the model 20 and a 2841 using the 1316 disk packs.

Calling the model 20's format “CKD” would be misleading, in my opinion, because it implies some control over the length of the key and data, as there is on the 2841. The model 20 provided no such control: the key length was always 0 and the data length was always 270. If I had designed the on-disk format for the model 20, I would have eliminated those three bytes from the count field, thus giving the user 273 bytes for data instead of 270. John Sauter (talk) 18:55, 25 August 2014 (UTC)

If we looked a little further we would likely find that the M20 gaps are mostly the same as the 2841, same sync field, same sync byte, same CRC, etc, except perhaps for an AM. I too would have eliminated much of the Count Field and made other changes to give the user a lot more than 3 more bytes, as in fact did most of the other systems manufacturers, but IBM didn't going as far as the quote above to establish that the format was CKD with KL=0 and DL "is always the binary equivalent of decimal 270." If IBM so describes it that way, I don't think our opinions have much weight and by describing the KL=0 and a fixed DL IBM removes any implication that the M20 supported variable record length.

Whether a 2841 could format a pack readable by the M20 may not be a function of the HA depending upon the size of the gaps. The 1316 pack had the sector marks so it all depends upon where the index and sector marks lie with respect to the sync byte before the Count field. It may well be that the HA field on a M20 fell into the gap before index and would be missed by the M20 controller (the index mark is between two sector marks so it must be aligned to a sector mark, meaning HA might be just before a sector mark in a -11 and just after index in a -1, who knows?). As I said I have a vague recollection of such interchangability going back to my work on a plug compatible version of the 2311-11 some many years ago. So I could be wrong but that has nothing to do with the format. Tom94022 (talk) 19:49, 25 August 2014 (UTC)

But IBM didn't describe the model 20's format as CKD. They don't use that term, or count-key-data, anywhere in the model 20 literature that I could find. However, the term is used in the description of the IBM 2841.

I used a plug-compatible version of the IBM 2311 on a PDP-10 in the 1970s. I didn't know about the 2311 model 11 at the time, but I did know that the drive I used had fixed-length sectors, though I don't remember their length. The PDP-10 software used blocks of 128 36-bit words on DECtape, so that might have been the length of the disk sectors.

Since we are speculating about how it might be possible for a model 20 to read a disk pack written by a 2841, or vice-versa, I imagine that the format of the count field was dictated by some IBM standard, and the model 20 people felt obliged to conform to it, even though it meant decreasing the amount of user data on a pack. I also speculate that making a 2841 write data on a 1316 in such a way that the model 20 could read it would be very difficult. Even assuming the model 20 could manage to overlook the HA, there is still the problem that the 2841 cannot see the index marks. It would have to “dead recon” the write stream, in the hope of putting the data in just the right spot so that the model 20 would see it.

Was the plug-compatible drive you worked with by any chance a Memorex? My memory is hazy, but I think that is the manufacturer of the drive we used. John Sauter (talk) 04:11, 26 August 2014 (UTC)

It was Memorex, I did the DEC version of both the 2311 (Memorex 630-1) and the 2314 (660-1) as well as Memorex's 620, it's version of the 2311-11. I worked mainly with DEC's John Greene to define what became the DEC early RP0x interface (and the internal to the later RPx Massbus drives). Dave Ives from the PDP-10 group also played a role.

There is only one 1316 disk pack with its sector/index disk; the index pulse to the controller is generated by the identical circuit in all 2311 models; "the major difference between the Model 1 and the Model 11 is the ten-sector-generator card" which generates the sector pulses on a separate line. So I think you might agree that a 2841 writing a full track Record 0 consisting of ten 270 byte data blocks interspersed with appropriate Count Fields and Gaps is one way that might "fool" the M20 SCU. This would have to be a utility program running on S/360 not M20.

IBM did say that its M20 fixed sectors use a Count [Field] with Key Length equal to Zero and a Data Length equal to 270 bytes, followed by the Data [Field] which sure sounds like CKD to me. I suspect they used CKD instead of CHS to take advantage of common OS stuff such as access methods, error recovery including defective tracks, etc. I also know that at the channel program level in the OS it was CKD for all S/360 including the M20. So I do believe it is accurate to say the M20 used a CKD record format with the data field size fixed to 270 bytes and no key field, or more succinctly, an FBA version of CKD.

I'm not proposing any reversion unless some other editors join in, so can we drop this now? Tom94022 (talk) 16:52, 26 August 2014 (UTC)

If you write just the data field, such as with BDAM, the count and key are not rewritten. In normal use on OS/360, the first write to a track will be a formatting write, overwriting any previous count and key data. If one bought a disk pack for the 360/20, I suspect it came preformatted. Rewriting the data blocks on a 2841 should preserve that format. Writing a whole track might not. Seems to me that the gaps should be the same size on the 20. Assuming reasonably accuracy on the speed and formatting, it should not be hard to get the sector pulses to come out in the gaps. Gah4 (talk) 21:39, 26 August 2014 (UTC)

The 2841 issue is likely the Address Mark in Gap 3 (marks the start of a record), we don't know if the M20 SCU writes one and because of the statement that a M20 written 1316 cannot be read on any other S/360 I suspect one was not written. Note that on a 2841 the maximum DL for 10 records is 295 bytes so the gaps on the M20 are larger. This gives lots of space to hide the HA, but it does suggest that using standard writes on a 2841 will not properly position the Count Fields; however, a full track R0 written to look like 10 blocks of 270 bytes of data, with appropriate gaps and Count Fields might work. Tom94022 (talk) 22:36, 26 August 2014 (UTC)

I suspect that the 360/20 doesn't format (initialize) disk packs. That might be documented somewhere. In that case, they are either formatted on a 2841, or on a special device designed to format them. It would seem convenient for IBM in system development to be able to move disk packs between systems, they just don't want users to do it. Even so, as far as I know the 2841 doesn't care about R0, though the OS might want to read one. I would have to read more about the 2841 to know, but floppy formatters usually allow one to specify the gap size. Does the 2841 allow for it? Gah4 (talk) 00:24, 27 August 2014 (UTC)

The utilities manual cited above describes the M20 Initialize Disk Utility Program (INTDISK) which "prepares one or more 1316 Disk Packs for use on the 2311 ..." The 2841 does care about Address Marks, although Space Count can be used to get around defective Count Fields including corrupted AMs. Tom94022 (talk) 00:44, 27 August 2014 (UTC)

You might be right, but you at least need a program to do "high level format" such as writing the label and an empty file system. Without more details, I couldn't say if INTDISK only did that, or completely wrote the block headers. The 360/20 can't IPL the disk, so you don't need to write IPL to it. Gah4 (talk) 20:52, 27 August 2014 (UTC)

INTDSK Primary Initialization appears to do a high level format and "If you want to initialize a disk pack that has never before been used on a Model 20, the ERASE option must be specified on the utility-modifier control statement." Since such a 1316 pack will have CKD records or be blank the implication is the utility will construct the M20 fixed sector format including the high level VTOC and other file stuff. Tom94022 (talk) 21:13, 27 August 2014 (UTC)

Seems to me that to accurately write blocks on a 2841 that the 360/20 could read might require more acccurate drive speed than normal. IBM could be sure that their drives are better than average speed accuracy, set the right gap sizes, and format away. They might even verify them on a 360/20 to see that the blocks start in the right place. Anyone happen to have a 2311 around? I know where a 2841 is. Gah4 (talk) 02:56, 15 July 2015 (UTC)

A utility could determine the rotational speed by use of the residual count on a track overflow and then write a full track RO with the appropriate gaps, fields, etc. so that the records are properly located with respect to the Sector signals. Essentially varying a gap size to properly locate the Sync Field after the Sector Pulse There would be no Address Marks but I suspect the 360/20 doesn't use or need them. Data subsequently written by the 360/20 could not be reliably read on a 2841. Tom94022 (talk) 18:05, 15 July 2015 (UTC)

Model 20 not the only computer to support the IBM 2560

According to GC22-6820-12, the IBM System/360 Installation Manual / Physical Planning, page 2025.4, the Sysem/360 model 25 could support an IBM 2560. In addition, GA23-1510-1, the IBM System/370 Model 115 Functional Characteristics manual, pages 111 to 126, describe support of the IBM 2560 on that machine. Thus, it is incorrect to say that the IBM 2560 was “unique” to the System/360 model 20. If there are no objections I will remove the incorrect statement. John Sauter (talk) 05:22, 25 February 2015 (UTC)

OK by me. I was going to update the 2560 page to read "only available on low-end systems", but, oops, there isn't one. Peter Flass (talk) 14:07, 25 February 2015 (UTC)

I have made the minimum edit necessary to correct the factual error. Perhaps there should be a page for the IBM 2560. John Sauter (talk) 10:35, 27 February 2015 (UTC)

tense

MOS:TENSE has the following example "The PDP-10 is a discontinued mainframe computer family.". Although I wtote the article originally in past tense, IIRC, I think present tense is correct. Peter Flass (talk) 22:44, 10 July 2015 (UTC)

Further on MOS:TENSE has the following clarification

"Tense can be used to distinguish between current and former status of a subject: Dún Aonghasa is the ruin of a prehistoric Irish cliff fort. Its original shape was presumably oval or D-shaped but parts of the cliff and fort have since collapsed into the sea. (Emphasis added for clarity.)"

Following that line, the 360/20 is a discontinued computer. It was capable of ....; comprised of ....; etc seems consistent Tom94022 (talk) 00:45, 11 July 2015 (UTC)

I suppose we could go back to MOS again, but lets continue this one. The IBM S/360 architecture is an idea. The idea generated a number of different ideas, as individual models. Then those ideas were implemented in hardware. Many of those implemented machines aren't around anymore. The S/360 Principles of Operation, and the individual Functional Characteristics manuals are the written documentation of the idea, and those still exist, along with a small number of actual machines. Now, compare to a prehistoric fort. Most likely the plans don't exist, if they even wrote them down before building it. Also, I suspect that there ever was only one implementation of the fort, and a partial fort isn't really a fort. Now, back to the PDP-10. Note that there never was a machine called the PDP-10. There are implementations of the PDP-10 architecture as the KA-10, KI-10, KL-10, etc. (Some might ignore the distinction, though.) The PDP-10 architecture, the idea, exists even if no implementations exist. It is unlikely that all copies of the description of the architecture will be destroyed in the near future. A lot of intellectual work went into creating the PDP-10 architecture. I suspect that the Irish cliff fort, more or less, just happened. People started building, and eventually it was a fort. Maybe a little preplanning, but much less than the PDP-10 architecture. There were no cameras to take pictures, for example. We can guess what it looked like when new, but really don't know. It really isn't a fair comparison. In a few thousand years, I suspect past tense will be reasonable for the 360/20. Gah4 (talk) 05:48, 11 July 2015 (UTC)

I'm pretty sure your comparisons of the S/360 (or PDP-10) to a prehistoric fort are distinctions without substance in this context. It gets back to how editors interpret "subjects that no longer meaningfully exist as such". We disagree which is fine. Peter Flass originally wrote the article in the past tense but now seems persuaded by yr argument. However, based upon a fairly small sample it seems that other editors prefer the past tense for similar articles, e.g. IBM_System/360,IBM_System/360_Model_67,Data_General_Nova,IBM_System/370,PDP-8,CDC_3000,RCA_Spectra_70,Burroughs_large_systems,IBM_1401, etc. FWIW there is at least one IBM_1401 operating daily at the Computer History Museum. To be fair there are some other articles about contemporaneous objects written in the present tense, e.g. PDP-10 and PDP-11. This does suggest somewhat of an editors choice; however, it seems the cutoff to switch tense for computer articles is sometime in the 1970s rather than thousands of years as suggested. So I would propose two reasons for not rewriting this article into the present tense:

1. It would remain consistent with its parent IBM_System/360 article and the other mainframe articles of that era
2. It would remain consistent with the original choice of the original author, even though he may now agree that a change is appropriate. This is an, "if it ain't broke don't fix it argument."

Tom94022 (talk) 19:12, 15 July 2015 (UTC)

interpreter

Regarding the 2560 being an interpreter. Since it can read, punch, and print on cards, it can read a card and print the data on the card, as an interpreter would do. But it can print anything on the card that you want, I forget now many lines worth. It used to be somewhat usual for bills to be printed on punched cards, that are then sent back along with a check. It is nice in that case to make the printing more human readable. In any case, the 2560 is more general than an interpreter. Gah4 (talk) 11:39, 6 March 2020 (UTC)

I've expanded that section to give general details of what the 2560 could do, indicating how they allow a program to make the 2560 act as an interpreter or sorter. If you want to expand that paragraph to add more examples of how those features can be used, go ahead. Guy Harris (talk) 18:31, 6 March 2020 (UTC)

slow

I believe that there is an IBM reference that TROS is slow, but I don't feel like looking for it, so I will leave it for now. It has inductance, which slows it down, at least compared to capacitance. I think if you look up the microcycle time you will see it. (If you put enough current through, you can make it fast.) Yes it is the 360/20 and 360/40 for TROS, 360/30 for CCROS and 360/65 for BCROS. (Unless I forgot from a few hours ago.) If there aren't two others that use the same one, then TROS is more (two is more than one). I am not sure about that, though. Gah4 (talk) 08:23, 17 June 2020 (UTC)

360/50 - CROS of some sort, according to the Model 50 FE handbook.

The /25 ran microcode from main memory, according to page 9 of the M25 Functional Characteristics manual.

The /85 had WCS along with read-only control store, according to page 14 of the Functional Characteristics manual for the M85. I'd guess the WCS was monolithic semiconductor memory; dunno whether that means the ROS was semiconductor ROM or not.

The /22 was, I think, just a cut-price /30, so presumably it used the same CCROS. The /67 presumably used the same BCROS as the /65.

So the slower(?) TROS was used in the slowest machine, the /20, but not in the next-slowest, the /30; the next-slowest after that, the /40, used it again. Maybe the CCROS was slower than the /40's TROS, and the BCROS was faster? Guy Harris (talk) 10:11, 17 June 2020 (UTC)

In addition to microcycle time, you have to figure out what it does in that time. That is where the horizontal microcode of the high-end machines comes in. There was also some testing out of different technologies. I don't know if it is in the article, but the 360/20 processor has a 4-bit ALU that can add/subtract zero or one on each cycle. Anything more than that, is a microcode loop. The ALU computes the parity on each operation, though, so it is parity checked all the way through. The 360/40 has much wider microcode, to do a lot more on each cycle. BCROS uses differential sensing, which might settle faster. Gah4 (talk) 19:06, 17 June 2020 (UTC)

The 360/20 and 360/40 have a 625ns microcycle, the 360/30 has 750ns. There isn't much detail on what they do during those cycles. Gah4 (talk) 20:14, 17 June 2020 (UTC)

The original claim was that TROS was slow. If one microinstruction is fetched per microcycle, the speed of the microstore is an upper bound on the microcycle length; are you saying that what's done in the microcycle is another upper bound, so that perhaps the M30's CCROS could have been cycled faster than the TROS, but the M30 hardware couldn't have executed microinstructions that fast, so it wasn't cycled faster than 750 ns/microinstruction?

The field engineering manuals, which can be found in subdirectories of http://bitsavers.org/pdf/ibm/360/fe, may give the details you want, although the 2020 Field Engineering Theory of Operation manual for machines with serial number 50,000 and above says, on page 1-19, "The micro-program is also stored in main storage, but in an area not accessible to the customer. This restricted area is called control area and is physically a part of the core storage array which also contains the customer's area." On page 6-7, it describes a process for loading microcode from punched cards.

Perhaps pre-serial-number-50000 machines used TROS, and later machines used main memory, for microcode? Guy Harris (talk) 20:52, 17 June 2020 (UTC)

Yes. There are more variables than the documentation answers. Most obvious is how much is memory access time and how much is logic delay. Some could be tracked from the FETOM. The ones serial number 50,000 and above are very different, as you note. I never got to work with one of them. Gah4 (talk) 21:14, 17 June 2020 (UTC)

TROS was also used in some storage control units. One reason for the various ROS's maybe the cost, that is time, for field changes which AFAIK is the reason for the FDD. BTW, 625ns and 750ns cycle times sounds pretty fast to me for 1965 technology. Tom94022 (talk) 18:28, 18 June 2020 (UTC)

The technology is pretty much TTL. As I found out a few years ago, it is close enough that you can just wire it to TTL gates and it works. Unlike TTL, it needs three power supplies, but in the end, it is about the same. (There is a negative supply to make pull-down a little easier.) TROS is inductive, so you can speed it up by increasing the current. CCROS is capacitive, so you increase the voltage. Gah4 (talk) 22:20, 18 June 2020 (UTC)

"I believe that there is an IBM reference that TROS is slow, but I don't feel like looking for it, so I will leave it for now." "The structure of SYSTEM/360 Part II - System implementations", in IBM Systems Journal volume 3 #2 (1964), has a table of microcode ROM cycle times - but they're identical to the system cycle times in another table, so that doesn't indicate whether the ROM's speed, or something else, determined the cycle time, and they don't speak of the characteristics of the ROM technologies (they don't even mention the technologies), so that's probably not the reference in question.

Section 4.5 "Control stores" of chapter 4 of IBM's 360 and Early 370 Systems does speak of transformer ROS as being slower than capacitor ROS ("Because of the relatively slow switching speeds of magnetic transformers, TROS was expected to have adequate speed only for the Model 30 and Model 40 processors."), but, later, in a combination of pages missing from the Google Books version of the page and pages not missing, it appears to discuss the replacement of TROS with CCROS in the Model 30. It sounds as if at least part of the reason may have been political, between the CCROS that came from Endicott work and the TROS that came from Hursley work, although they also mention the ability to replace the cards in CCROS and say that "An efficient means for changing control store content was believed to be especially important for the Model 30, the compatibility feature of which had to be made adaptable to thousands of differently configured 1401 systems.", so perhaps that weighed in favor of CCROS on the slower-than-the-M40 M30. CCROS, unlike BCROS, may not have been able to run as fast as TROS in any case, so may have been more of a case of "the general technology of capacitive ROS could be used to build faster memories than the general technology of transformer ROS" than of "all implementations of capacitive ROS can be made faster than any implementation of TROS", with CCROS being a cheaper form of CROS that couldn't run at the same speed of TROS but that could run fast enough for the M30.

The Internet Archive borrowable copy has the missing pages, which indicate that Endicott thought the CCROS would be "cheaper and functionally superior" to TROS. It also says, of TROS, that "The product design effort was directed toward making TROS easier to manufacture and service and capable of having its stored information easily altered in the field. These objectives were accomplished by fabricating ladder-shaped word lines on Mylar strips, two to a strip. ...", so I don't know whether CCROS ended up being cheaper or more easily changed in the field - a picture shows an IBM CE installing a new CCROS card in an M30, so that might have been easier than whatever would be done for TROS.

They decided to do both TROS and CCROS development, because it was late in the game and they thought just dumping TROS in favor of CCROS was too risky; CCROS development was moved to Hursley. The CCROS development ran into difficulties (too much electrical noise), so they ended up sticking with TROS for Hursley's M40 (and Boeblingen's M20); meanwhile, Endicott continued working on CCROS and eventually used it in the M30.

So it looks as if the choices of ROM technology at the low end were influenced as much by politics as technology.

The IBM reference you're thinking of might be "The Design of Transformer (Dimond Ring) Read-Only Stores" in the IBM Journal of Research and Development volume 8 #4 (1964). There's also "Design of a Printed Card Capacitor Read-Only Store", in the IBM Journal of Research and Development volume 10 #2 (1966).

Unfortunately, the reference arguing in favor of CCROM for the M30 is a "cable" sent inside IBM, so that may be hard to find. The references in the back of the Pugh book include some notes that suggest that making field changes to ROS easier, for the benefit of 1401 emulation, was at least one argument for the use of CCROS in the M30.

So it may be less "capacitors vs. transformers" and more "capacitor technology 1 vs. capacitor technology 2 vs. transformer technology", with one capacitor technology being cheaper and easier to modify in the field but slower even that TROS due to noise issues, i.e. "the right capacitor technology can run faster than transformer technology, but another capacitor technology might not be able to run as fast as transformer technology but might have other advantages", with the other advantages making it a win for the M30. And there also appeared to be Endicott vs. Hurley political issues. Guy Harris (talk) 04:49, 20 June 2020 (UTC)

If I remember right CCROS cards are the size and shape of ordinary IBM cards, though plastic with metalization. Individual capacitors can be punched out, which is the way they are programmed. I believe they can be punched on ordinary keypunches. BCROS is differential. Each bit has a capacitor in one position or the other, such that a differential signal goes into the sense amplifiers. That reduces noise, though it isn't so easy to connect that to time. Also, like all memories, there are both access and cycle time. That is, how long it takes to get the bits, and how long between bit retrieval. If there are conditional branches in microcode, the conditions have to be ready at the appropriate time. The little I know about the 360/20 is that it has a lot of conditional branches. Gah4 (talk) 07:21, 20 June 2020 (UTC)

There is a nice article on all of IBMs S/360 ROSs buried in Glenn's Museum Website entitled "IBM System/360 Read-Only Storage (ROS)]." He uses the term BCROS as opposed to CCROS; I don't know which is correct. Wikipedia has an article TROS but AFAIK nothing on the other IBM types. Maybe the time has come to rename and update the TROS article along the lines of Glenns Museum article. You guys seem to have done most of the work on the various Capacitive ROSs in this talk. Thoughts? Tom94022 (talk) 17:47, 20 June 2020 (UTC)

He uses the terms "Balanced Capacitor ROS" and "Card Capacitor ROS". The former is used when talking about the Model 50, which is correct; the latter is used when talking about the Model 30, which is correct. So both are correct. Guy Harris (talk) 18:44, 20 June 2020 (UTC)