Drum vs. Core
roger.holmes at microspot.co.uk
Tue Jul 3 14:19:08 CDT 2007
On 3 Jul, 2007, at 18:09, cctalk-request at classiccmp.org wrote:
> From: "Andy Holt" <andyh at andyh-rayleigh.freeserve.co.uk>
> Initially most were printing terminals with
> lights inside, not Teletypes, can't remember the maker's name.
> Probably Trend
Maybe, though it doesn't ring any bells in my head.
> There was also just two CRT terminals, on which you typed a load of
> and told the computer to read it.
> Could well have been "genuine" ICL block-mode terminals
Yes they we ICL badged IIRC, I think the two shared a box on the
floor with the character generator in it.
> Do you think the drum got kicked out when we went over to the 4S?
> Probably when they went to a dual '4S configuration -
> they really tried to have a resilient system - each 4S had its own
> motor-generator set and _all_ the peripherals were "Y"-switched.
> The flaw in the configuration only appeared when the power-supply
> to the Y switches failed :-(
> [actually, they could have kept running even then, but the Engineers
> naturally refused to work on that without turning the power off]
Seems reasonable. I remember one day the 1900 at QMC went down and we
users were getting annoyed at the delay and we asked what was up, and
were told the air conditioning system had failed and under the raised
floor they had found nearly a foot of water. This was on the fifth
floor! Thinking about it now it's not feasible. The false floor had
ramps up from the normal floor at the computer room entrance, so the
water would have flowed out under the ramp and down the stair well
and lift shaft. Still, the story kept us quiet for a while.
> Was it really that slow! We really put up with a lot back then.
> I've still got the timings from the acceptance benchmarks and
> have run the same benchmarks on many machines since.
> ** the most important of these benchmarks was the original "Whetstone"
> benchmark - Fortran carefully crafted to not be optimisable*1 - in
> in ran slower on the optimising compiler than on the standard one.
> *1 eventually (20 years later) compiler technology did manage to
> optimise away much of the code.
As an ex-compiler writer (Coral 66) working for a computer
manufacturer, I can say that we considered running the program up to
the first input/output at compile time and starting execution from
there. We figured the resulting benchmark timings would get us called
cheats. Could have calculated the real runtime and halved it I suppose.
My 1301 simulator now runs faster than real time so I'm thinking
about yielding the CPU whenever simulated time gets ahead of real time.
>> (I think they were still, however, written in engineers assembler
>> which used
>> numeric op-codes rather than the mnemonics of PLAN or GIN5).
> Interesting. Maybe it was like my school maths teachers who forced us
> to use fountain pens instead of ball points because it slowed us down
> so we thought more about what we were doing and so made less
> No - it was that the engineers _knew_ the ciruit diagram of the
> and "000 3 100" was more meaningful to them than "LDX 3 base", say.
I see. I had to write a microprogram assembler once and that was
similar. The words were 72 bits wide and most of the bits just
directly controlled gates in the processor. There was an address
field for jump instructions though, which was more traditional, and I
gave them the facility to define macros for any field, so they could
have defined their own mnemonics for commonly occurring patterns. For
instance some of the bits selected the function in some AMD2900 bit
slices, which could have used the names assigned by AMD.
> Very difficult. I had always assumed the executive lived at a fixed
> position in memory. Maybe it used relativisers, 1300 style, where
> every instruction could specify what block start address should be
> added to it, but maybe that would slow down loading the overlays too
> The fixed part of Exec loaded at 0 - but the overlays could be on any
> 64-word boundary.(actually, probably 128 word - but the code would
> on a 54 word boundary)
> I wonder if any of the concepts in the 1302 executive got re-
> used on 1900.
> I don't know, but I doubt it - wasn't the 1300 series a Stevenage
> while the earliest 1900s came from West Gorton (well, actually the
> earliest 1900 was the Canadian FP6000).
> Different parts of ICL had very much a "not invented here" attitude
> the previous West Gorton product was Atlas.
1300/1301 was designed by Raymond Bird who worked for British
Tabulating Machines at Letchworth (starting with adapting someone
else's design to make the HEC / ICT200 series), then presumably moved
to the joint BTM / GEC subsidiary Computer Developments Ltd at Kenton
where he did the 1300/1301 design. I am not sure who/where adapted it
to make the multi-programmed 1302 (maximum 4 programs at once). Am I
right in thinking Atlas did not have an executive?
> Maybe ICL had been bumping up the maintenance charges for old kit
> they really did not want to support any more.
> That wouldn't have affected us - we had our own engineers and did
> our own maintenance. I suspect we were the only none-MOD site
> in that position. I wish I had saved more of the engineering
> documentation -
> I probably have enough to make a very close approximation on a FPGA,
> but there doesn't seem to be a survivng operators Exec for a 1900,
> only George 3 stuff.
Oh, from which I presume there are no surviving 1900s?
Can you run George 3 without an executive? I only got involved as a
user (Maximop/George 2 at QMC and IIRC, George 4 at RAE Fanrborough)
so know almost nothing about operating the machine. Odd facts did
trickle down though, switch 9 was used to disable the overflow
exception, and SWON 9 and SWOFF 9 in software around the place where
I was packing characters into a word would make my program run. Funny
how the most trivial things stick in your head for decades.
More information about the cctech