Some of my most interesting anecdotes are from 50 years ago.
Aspects of the main CPU clock(s) on 370/145, the 158MP and the 168MP
seem interesting to me. I'll start with the 370/145 in this post;
and follow up with the larger MP systems if there's interest.

The cycle time on IBM's 370/145 was variable. That time was a multiple
of 45 nanoseconds, to wit 4«, 5«, 6« or 7 times the basic 45 nanosecond
unit. *Do those fractional « increments seem odd?*

The basic oscillater had a 45-nanosecond period (22.5 up and 22.5 down)
but this was soon converted into 90-nanosecond pulses:
"0 time" was 0 to 90; "0 time Delayed" was 45 to 135;
"1 Time" was 90 to 180 and so on. But why were the extra 22.5 nanosecond "pauses" needed and how were they implemented?

IIUC a critical path was decoding the control word, and using it to determine and gate appropriate status bits to form a next control word. Ideally
that next microinstruction should be available at the beginning of "0 time." When that couldn't be achieved they reluctantly grafted
on the extra 22.5 nanoseconds.

The microinstructions were fetched from the same memory that was used
for (the "internal" portion of) main memory, and was subject to ECC.
HOWEVER detecting and correcting an error was NOT a reason for the needed delay. The processor began operating on the microinstruction BEFORE
it was corrected, with *nothing irrevocable* being done during the first
45 nanoseconds or so. If a correctible error was detected, the "Correction Cycle" condition would turn on, and the processor would back up to begin
at "0 time" again.

HOW were the extra 22.5-nanosecond pauses implemented? The 22.5/22.5 basic clock was fed into one leg of an exclusive-or gate, with the other leg
coming from a latch that was toggled appropriately. Now, 50 years later, this seems a bit flakey; the circuitry was probably more involved than a single XOR.

90-second clock pluses may seem ridiculously slow today, but some important signals (including the clock pulses) had to travel several feet inside
the 3145, so the routing of the clock pulse wirings was laid out carefully.

Cheers,
James

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

James Dow Allen <user4353@newsgrouper.org.invalid> posted:

Some of my most interesting anecdotes are from 50 years ago.
Aspects of the main CPU clock(s) on 370/145, the 158MP and the 168MP
seem interesting to me. I'll start with the 370/145 in this post;
and follow up with the larger MP systems if there's interest.

Interest was minimal in the (startling?) fact that the main 145 oscillator
is immediately passed through an XOR gate. But I'll persist and mention interesting(?) facts about the clocks on the Big IBM Multiprocessors.

The 370/168 was, arguably, the Top Of The Line among IBM mainframes
in the mid-1970s. Sure, there was a 370 Model 195 but it was almost just
a gimmick: Salesmen might say "You're complaining about the $3 Million price-tag on our wonderful Model 168?
Just be thankful I'm not trying to sell you a Model 195!"

But here we speak of the 168MP -- Double the Price and Double the Fun. Nowadays, I don't think you can even buy a processor chip with less
than two CPUs so it may be hard for young folk to imagine how
grandiose the 168MP was! The first time I saw one I first noticed
the TWO L-shaped "3066 consoles." One is pictured here:
https://static.righto.com/images/ibm-360/Supercomputer_NSA-IBM360_85.jpg You can't tell from the brown-scale photo, but these consoles had
the look of luxury! And these weren't even the CPUs. The CPUs were in
an adjacent room, where almost nobody ever went. These giant CPUs were enclosed cabinet complexes with no lights or other controls except
an Emergency Power Off pull-switch.

Instead of the 168MP or 158MP, customers could buy a 168AP or 158AP.
For our purpose here, we needn't distinguish the APs from the MPs.
But there are very big differences between the 168MP and the 158MP.

Each of these MP behemoths had TWO independent clocks, one for each
of the two processors.

On the 168MP, when MP mode was selected or when memory was cross-configured
one of the two oscillators was ignored. A toggle switch determined
whether it was the clock from CPU A or the clock from CPU B which was
used throughout the system. Cable delays introduced a nifty weirdness
into the clocking.

BUT on the 158MP *each CPU used its own oscillater*. Both machines operated
at 8.69565217 MHz (115 nanoseconds) but the clocks were NOT synchronized.
This presented some difficulty when one processor needed to operate
on signals from two processors whose edges had no known relationship.

This post is long enough, so I'll leave the topics as "cliff-hangers"
for now. I'm sure there are many other old-timers here.
They are welcome to post their "punch-lines" and thereby "steal my thunder!"

Cheers,
James

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Interest was minimal in the (startling?) fact that the main 145 oscillator is immediately passed through an XOR gate. But I'll persist and mention interesting(?) facts about the clocks on the Big IBM Multiprocessors.

This _is_ interesting, thanks!

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/25 04:04, James Dow Allen wrote:
But here we speak of the 168MP -- Double the Price and Double the Fun.

Nowadays, I don't think you can even buy a processor chip with less
than two CPUs so it may be hard for young folk to imagine how
grandiose the 168MP was! The first time I saw one I first noticed
the TWO L-shaped "3066 consoles." One is pictured here:
https://static.righto.com/images/ibm-360/Supercomputer_NSA-IBM360_85.jpg

Oh, is there computer equipment in that picture somewhere?

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

James Dow Allen <user4353@newsgrouper.org.invalid> writes:

Interest was minimal in the (startling?) fact that the main 145 oscillator
is immediately passed through an XOR gate. But I'll persist and mention interesting(?) facts about the clocks on the Big IBM Multiprocessors.

The 370/168 was, arguably, the Top Of The Line among IBM mainframes
in the mid-1970s. Sure, there was a 370 Model 195 but it was almost just
a gimmick: Salesmen might say "You're complaining about the $3 Million price-tag on our wonderful Model 168?
Just be thankful I'm not trying to sell you a Model 195!"

After joining IBM, the 195 group talk me into helping with
hyperthreading the 195. 195 had out-of-order, but conditional branches
drained the pipeline ... so most codes only ran at half the rated speed. hyperthreading, simulating 2CPU multiprocessor possibly would keep the
hardware fully busy ... hyperthreading patent mentioned in this about
the death of ACS/360 (Amdahl had won the battle to make ACS, 360
compatible, the ACS/360 was killed, folklore was executives felt it
would advance the state of art to fast and company would loose control
of the market).
https://people.computing.clemson.edu/~mark/acs_end.html

modulo MVT (VS2/SVS & VS2/MVS) documentation (heavy-weight
multiprocessor overhead) SMP, only had 2-CPU throughtput 1.2-1.5 times
single processor throughput.

early last decade, I was asked to tract down the decision to add virtual
memory to all 370s (pieces, originall posted here and in ibm-main
NGs). Basically MVT storage management was so bad that region sizes had
to be specified four times larger than used ... as result typical 1mbyte 370/165 only ran four concurrent regions, insufficient to keep system
busy and justified. Going to single 16mbyte virtual address space
(i.e. VS2/SVS ... sort of like running MVT in a CP67 16mbyte virtual
machine) allowed concurrent regions to be increased by factor of four
(modulo caped at 15 because 4bit storage protect keys) with little or no paging.

It was deemed that it wasn't worth the effort to add virtual memory to
370/195 and all new work was killed.

Then there was the FS effort, going to completely replace 370 and
internal politics was killiing off 370 efforts, claims that lack of new
370s during FS gave the clone 370 makers their market foothold). http://www.jfsowa.com/computer/memo125.htm https://en.wikipedia.org/wiki/IBM_Future_Systems_project https://people.computing.clemson.edu/~mark/fs.html

Note 370/165 avg 2.1 machine cycles per 370 instruction. for 168 they significantly increase main memory size & speed and microcode was
optimized resulting in avg of 1.6 machine cycles per instruction. Then
for 168-3, they doubled the size of processor cache, increasing rated
MIPS from 2.5MIPS to 3.0MIPS.

With the implosion of FS there was mad rush to get stuff back into the
370 product pipelines, kicking off the quick&dirty 3033 and 3081
efforts. The 3033 started off remapping 168 logic to 20% faster chips
and then optimized the microcode getting it down to avg of one machine
cycle per 370 instruction.

I was also talked into helping with a 16-CPU SMP/multiprocessor effort
and we con the 3033 processor engineers into helping (a lot more
interesting than remapping 168 logic). Everybody thought it was great
until somebody reminds the head of POK that POK's favorite son operating
system ("VS2/MVS") 2CPU multiprocessor overhead only getting 1.2-1.5
times throughput of non-multiprocessor (and overhead increasing
significantly as #CPUs increased ... POK doesn't ship a 16-CPU machine
until after the turn of century). Then head of POK invites some of us to
never visit POK again and directs the 3033 processor engineers, heads
down and no distractions.

trivia: when I graduate and join IBM Cambridge Science Center, one of my hobbies was enhanced production operating systems and one of my first
(and long time) customers was the online sales&marketing HONE systems.
With the decision to add virtual memory to all 370s, there was also
decision to form development group to do VM370. In the morph of
CP67->VM370, lots of stuff was simplified and/or dropped (including multiprocessor support). 1974, I start adding stuff back into a
VM370R2-base for my interal CSC/VM (including kernel-reorg for SMP, but
not the actual SMP support). Then for VM370R3-base CSC/VM, I add
multiprocessor support back in, originally for HONE so they could
upgrade their 168s to 2-CPU systems (with some slight-of-hand and cache affinity, was getting twice throughput of single processor).

other trivia: US HONE had consolidated all their datacenters in silicon
valley, when FACEBOOK first moved into silicon valley, it was into new
bldg built next door to the former consolidated US HONE datacenter.

--
virtualization experience starting Jan1968, online at home since Mar1970

--
virtualization experience starting Jan1968, online at home since Mar1970

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Peter Flass <Peter@Iron-Spring.com> posted:

On 10/12/25 04:04, James Dow Allen wrote:
But here we speak of the 168MP -- Double the Price and Double the Fun.

Nowadays, I don't think you can even buy a processor chip with less
than two CPUs so it may be hard for young folk to imagine how
grandiose the 168MP was! The first time I saw one I first noticed
the TWO L-shaped "3066 consoles." One is pictured here:
https://static.righto.com/images/ibm-360/Supercomputer_NSA-IBM360_85.jpg

Oh, is there computer equipment in that picture somewhere?

I'm sure you're being sarcastic but I'm not exactly sure how.
I assume the colors in the photo were brownified just to hinder any
temptation to lust after the bare-legged operator!

I Googled for an image of "IBM 3066 Console" and this was the only close approximation that turned up. That seems like a shame since the console
for the Models 165 and 168 really was grandiose! Note the TWO microfiche viewers at the left. One was an ordinary viewer, the other seemed like
a microfiche viewer but was actually used to selectively read out
the many thousands of bits from the (broken) CPU that might interest
a field engineer using the console to debug.

The photo isn't even of a 370/168 console; as the Jpeg file name suggests,
it must be the console of a 360/85. But the 3066 was VERY similar,
just somewhat more grandiose with more lights, toggles and rotaries to operator's right.

About 1978, the 370/168 was superseded by the 3032 and 3033. These were
a disappointment for anyone infatuated with blinking lights and fancy
switches and dials. The console disappeared entirely except for an ordinary CRT, keyboard, light-pen and a tiny number of lights and buttons (e.g. "IPL"). This trend began a few years earlier when the fancy front-panel of
the 370/155 was replaced with a boring CRT/light-pen for the 370/158.

(Disclaimer: My own fond memories of the fancy consoles may be an aberration. Most of the CE's and FE's I talked with preferred the much simpler
console of a 158 or 303x.)

Cheers,
James

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

James Dow Allen <user4353@newsgrouper.org.invalid> writes:

About 1978, the 370/168 was superseded by the 3032 and 3033. These were
a disappointment for anyone infatuated with blinking lights and fancy switches and dials. The console disappeared entirely except for an ordinary CRT, keyboard, light-pen and a tiny number of lights and buttons (e.g. "IPL").
This trend began a few years earlier when the fancy front-panel of
the 370/155 was replaced with a boring CRT/light-pen for the 370/158.

when FS imploded, they start on 3033 (remap 168 logic to 20% faster
chips). They take a 158 engine with just the integrated channel
microcode for the 303x channel director. A 3031 was two 158 engines, one
for the channel director (integrated channel microcode) and 2nd with
just the 370 microcode. The 3032 was 168-3 reworked to use the 303x
channel director for external channels.

I had transferred out to the west coast and got to wander around IBM
(and non-IBM) datacenters in silicon valley, including disk bldg14 (engineering) and bldg15 (product test) across the street. They were
running pre-scheduled, 7x24, stand-alone mainframe testing and mentioned
that they had recently tried MVS, but it had 15min MTBF (requiring
manual re-IPL) in that environment. I offer to rewrite I/O supervisor
making it bullet-proof and never fail, allowing any amount of on-demand, concurrent testing ... greatly improving productivity. Then bldg15 gets
the 1st engineering 3033 outside POK process engineering. Testing was
only taking percent or two of CPU, so we scrounge up a 3830 controller
and string of 3330 drives and setup our own private online service.

One of the things found was the engineering channel directors (158
engines) still had habit of periodic hanging, requiring manual re-impl. Discover then if you hit all six channels of a channel director quickly
with CLRCH, it would force automagic re-impl ... so modify missing
interrupt handler to deal with hung channel director.

--
virtualization experience starting Jan1968, online at home since Mar1970

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

James Dow Allen <user4353@newsgrouper.org.invalid> posted:

James Dow Allen <user4353@newsgrouper.org.invalid> posted:

Some of my most interesting anecdotes are from 50 years ago.
Aspects of the main CPU clock(s) on 370/145, the 158MP and the 168MP
seem interesting to me....

But there are very big differences between the 168MP and the 158MP.

Each of these MP behemoths had TWO independent clocks, one for each
of the two processors.

On the 168MP, when MP mode was selected or when memory was cross-configured one of the two oscillators was ignored. A toggle switch determined
whether it was the clock from CPU A or the clock from CPU B which was
used throughout the system. Cable delays introduced a nifty weirdness
into the clocking.

Each half of a 168MP was almost identical to an ordinary 168. But the MP
had an extra large cabinet just to facilitate memory sharing. Several
feet of cabling cost many nanoseconds. Data both to and from memory
had to pass though multiplexors. On a uniprocessor, the memory
cycle time was 320 nanoseconds (four 80-nanosec cycles) for both
reads and fast writes, but neither the inbound nor the outbound paths
could achieve that speed when the extra large cabinet with its multiplexors
and cabling was added for the memory sharing.

Neither the in-bound nor the out-bound paths could keep up speed-wise.
Naively one might think that an extra 80-nanosecond clock period
would be needed to accommodate the inbound slow-down and an extra period
for the outbound, turning the 4-cycle read into 6 cycles. This would
have been a big shame, since the slowdown in each direction was much less
than 40 nanosecs, let alone 80 nanosecs.

A simple trick to the rescue. The basic system clock -- a {+40,-40}
square wave -- was now INVERTED (i.e. shifted 180 degrees) inside
the memory cabinets. This added a HALF-cycle in each direction,
so the ordinary 4-cycle read became 5 cycles (not 6) on the MP.

An obvious trick? Maybe. But still NIFTY in my opinion!

- - - - - - - - - -

The 158MP was VERY different. I'll guess that IBM's CPU design teams
had very little communication with each other.

... on the 158MP *each CPU used its own oscillater*. Both machines operated at 8.69565217 MHz (115 nanoseconds) but the clocks were NOT synchronized. This presented some difficulty when one processor needed to operate
on signals from two processors whose edges had no known relationship.

The obvious solution is to simply use an edge-triggered flip-flop
and thereby "clock" the signal from the remote CPU with the local
clock. But this has a well-known flaw denoted by the term
"metastability." If the remote signal switches at EXACTLY the wrong
moment relative to the local clock, the flip-flop "won't know what
to do"! With some logic families, the output may oscillate. I
think with the ECL logic used on these mainframes, the output may just
stay near the threshold between High and Low for a while, making
up its mind. In either case, the output of that flip-flop cannot
be used reliably for an (unknown) period of time.

Solution? Direct that unreliable output to a 2nd flip-flop and clock
it again, several nanoseconds later. Only bad luck would lead to
BOTH flip-flops going metastable!

Murphy's Law dictates that bad luck WILL strike. So introduce a THIRD flip-flop! Maybe even a 4th!! Just make the net probability of
failure less than that of the apocryphal cosmic ray, and you've
done your duty.

These longish chains of flip-flops in series were only needed for a
few control signals. By the time the local CPU decided the remote
control signal was usable, the associated remote data had long been stable.

If you've read this far you MIGHT be interested in an unrelated application
of Murphy's Law which DID strike 158MP's and 158AP's. It was a
hardware problem but only showed up on "new" operating systems like
MVS/SE. I've written up a detailed description of this weird bug here:

https://fabpedigree.com/james/bug22.htm

Cheers,
James

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-10-13, James Dow Allen <user4353@newsgrouper.org.invalid> wrote:

If you've read this far you MIGHT be interested in an unrelated application of Murphy's Law which DID strike 158MP's and 158AP's. It was a
hardware problem but only showed up on "new" operating systems like
MVS/SE. I've written up a detailed description of this weird bug here:

https://fabpedigree.com/james/bug22.htm

Fascinating reading. Keep them coming - it's a great shot in the arm
for a.f.c, which has been getting rather moribund lately.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

I'm afraid a long "Background" section is appropriate to place some of
my anecdotes in context.

Background:
"Add-on IBM memory" was a very big business in the 1970's. There were at least six or seven memory manufactures supplying "Brand X" memory, usually via
an intermediary (e.g. CDC, Memorex, Itel). ("Brand X" was a term of ridicule applied by IBM CE's iirc.)

IBM had dramatically underestimated customers' need for memory and did NOT
have the capacity to meet orders. This was partly because they thought -- incorrectly -- that "virtual memory" might significantly reduce the demand
for real memory. There were several reasons why even loyal IBM customers
might want to buy "Brand X" memory for their mainframes:

* The Brand X memory was MUCH cheaper than IBM's.
* Because of their undercapacity, IBM made customers requesting
memory upgrades wait for MONTHS. Brand X companies would deliver ASAP.
* IBM imposed strict limits on the memory they would or could attach
to a given model. This was partly because of their undercapacity, but also because they wanted to sell faster, more expensive CPUs. But the
customers didn't need added speed; they needed more memory.
Brand X companies developed the necessary hardware to surpass the
IBM-imposed limits on memory size.

To give an idea of IBM's underestimating appropriate memory size; the LARGEST 370/135 that IBM would allow was one Quarter-Meg. (The smallest was 96 kbytes.) Just a very few years after the 135, IBM came up with the 370/138 --
VERY similar to the 135 -- and its SMALLEST allowed memory was a Half-Meg.
Our company went beyond the One-Meg max to 2 or 4 Megs. The story is similar for other 370 Models.

(Remind me to tell an interesting anecdote about a microcode patch needed to exceed 1MB on the 370/138.)

(I once installed a 10 Megabyte 158MP for the central bank of Spain.
As far as I know, that was the ONLY 158, whether UP or MP, to go beyond 8MB.)

- - - - - - - - - - - - - - - - - - -

Charlie Gibbs <cgibbs@kltpzyxm.invalid> posted:

On 2025-10-13, James Dow Allen <user4353@newsgrouper.org.invalid> wrote:

If you've read this far you MIGHT be interested in an unrelated application of Murphy's Law which DID strike 158MP's and 158AP's. It was a
hardware problem but only showed up on "new" operating systems like
MVS/SE. I've written up a detailed description of this weird bug here:

https://fabpedigree.com/james/bug22.htm

Fascinating reading. Keep them coming - it's a great shot in the arm
for a.f.c, which has been getting rather moribund lately.

I have a few other anecdotes of weirdness, some shown at the website
above; and some that have never been published. To reduce confusion I'll
use different subject lines for different weirdnesses.

But this topic (published here for the 1st time) -- A "write buffer"
for the Model 168 -- has multiple weirdnesses, or at least multiple punchlines!

The add-on memory company I worked for was in a hurry to develop
memory for the 370/168. The memory chips they planned to use met
ALMOST all the specs: Their cycle speed was fast enough; the critical Address-In to Data-Out delay was fast enough. The problem occurred
when a write was immediately followed by a read to a different address.
The write signal arrived early enough, but the data and/or address
defining the write weren't available until some time AFTER the write
was signaled. The chips' write was delayed and used up some of the
relaxation time the chips needed before a subsequent read.

The story goes on to interesting punchlines, but FIRST demonstrate
your mettle by designing a fix for this design problem. (The subject line offers a clue.)

I'll save two punchlines for a follow-up post but here's a 3rd punchline:

The company didn't even want to sell the 8-kilobit chips with the
timing problem. They were waiting for 16k chips that didn't even have
that timing problem. The whole project to rush implementation
with the inferior chips was just a "We've got to get our foot in the
door" marketing necessity.

Dearest regards, James Dow Allen (mail address: jamesdowallen at gmail)

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 12 Oct 2025 19:50:59 GMT, James Dow Allen wrote:

About 1978, the 370/168 was superseded by the 3032 and 3033. These
were a disappointment for anyone infatuated with blinking lights and
fancy switches and dials. The console disappeared entirely except
for an ordinary CRT, keyboard, light-pen and a tiny number of lights
and buttons (e.g. "IPL"). This trend began a few years earlier when
the fancy front-panel of the 370/155 was replaced with a boring
CRT/light-pen for the 370/158.

Most computers were getting rid of Teh Blinkenlights (and panel toggle switches) around that point. Also I think banks of reel tape drives
were disappearing around the same time.

Yet both persisted in depictions of computers in popular culture for
maybe up to a decade after that.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

James Dow Allen <user4353@newsgrouper.org.invalid> posted:

(Remind me to tell an interesting anecdote about a microcode patch needed to exceed 1MB on the 370/138.)

(I once installed a 10 Megabyte 158MP for the central bank of Spain.
As far as I know, that was the ONLY 158, whether UP or MP, to go beyond 8MB.)

I still want to discuss the Write Buffer for Model 68 with its interesting punchlines, but let's first clear up these loose ends.


*An interesting anecdote about a microcode patch needed to*
*exceed 1MB on the 370/138*
-------------------------------------------------

370 has 64 bytes (16 x 32-bit) of General Purpose Registers, of course --
more than enough to satisfy most program's needs -- but these are not
available for work by the microcode. The working microcode had but
14 bytes (7 x 16-bit). That's hardly enough for some simple tasks.

For example, consider the console display firmware which displays
memory contents on the CRT. Three bytes for the address, and two bytes
for data; and we'll also need counters for both the memory range and
for CRT display (characters per row) Yet another nibyl was needed for
some formatting count (prob. not simply characters between spaces on CRT).
It's been decades since I thought of the details but altogether the routine needed 14.5 bytes (including that nibyl) when only 14 were available.

The machine had 8 zones of eight 2-byte work registers altogether (W0 - W7)
but only 1 zone was available at a time. (Channels, Console, I/O emulater, and S370 instruction each had its own zone. W7 was overwritten (became
saved microinstruction address) when a "trap" occurred so I (and most
of IBM's code) never used it. I didn't have a thorough guide to 3135 programming so deduced some of it.)

The operator could display virtual memory (16 MB) or physical memory (1 MB)
but the virtual address was converted to physical address whenever a counter triggered; thus the microcode could make do with 5 nibyls instead of 3 bytes. That's how IBM reduced the 14.5 byte need down to 14.

But what about us? The memory add-on folk who had given the customer
TWO Megs, or even 3 or 4 if he wanted them. The microcode as written
would only display the first 1 Megabyte of physical addresses.

I patched the microcode as required; IIRC we copied IBM's
IMPL floppy disk, made the small software change, and delivered the
new floppy to end-user.

Another extraneous anecdote

I once installed a 10 Megabyte 158MP for the central bank of Spain ------------------------------------------------------------------

Not much to report here. I'll number address bits such that 29-30-31
select a byte within a doubleword, and address bit 8 is the MSB unneeded
when the configuration is limited to 8 Meg.

The 158MP had an extra big cabinet mainly just for cable routing.
(Any unnecessary largeness was probably a feature rather than a bug
for IBM pricings.) That cabinet DID have several configuration rotary
dials, allowing memory to be rearranged in 1 Megabyte clumps.
Address bit 9-10-11 fed the dials.

On the unique 10-MB machine, stickers were added to the rotaries
to make them operate on 2-MB chunks rather than 1-MB chunks.
Address wires 9-10-11 were swapped to become 8-9-10. The IBM circuitry
DID support address bit 8 -- it just didn't go anywhere. We could use
that for the address bit 11 that had been pre-empted in the 9-10-11
swap.

The customer's starting machine was 4-Meg MP 2+2, all IBM.
He wanted a 10-Meg machine 5+5, with 3 Megs of new "add-in"
on EACH side. I suggested he go with 2+8, putting all the Brand X
on one side, but to no avail.

Why did I prefer the 2+8? Briefly, it was almost amazing that even one
of these Brand X boxes would work, let alone two. 8-)
With 2+8 one side of the MP could be left as a virgin.

The memory was supplied by a company for which "fly-by-night"
would be no exaggeration. I was their sole representative in Europe, and
was working only with junior Spanish technicians. I was never good
with customers but even I suspected the central bank of Spain would be disappointed if there new 10-Megabyte machine failed and took days to fix.

Cheers,
James

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Sun, 12 Oct 2025 19:50:59 GMT, James Dow Allen wrote:

About 1978, the 370/168 was superseded by the 3032 and 3033. These
were a disappointment for anyone infatuated with blinking lights and
fancy switches and dials. The console disappeared entirely except
for an ordinary CRT, keyboard, light-pen and a tiny number of lights
and buttons (e.g. "IPL"). This trend began a few years earlier when
the fancy front-panel of the 370/155 was replaced with a boring
CRT/light-pen for the 370/158.

Most computers were getting rid of Teh Blinkenlights (and panel toggle >switches) around that point. Also I think banks of reel tape drives
were disappearing around the same time.

18-Track Cartridge drives showed up in the late 1980's/early 1990s. Before that, and for many years thereafter, 9-track PE/GCR drives were still common
in many shops.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)