Drum vs. Core

Roger Holmes 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  
> lines
> 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  
> fact
> 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
> mistakes.
> <<<
> No - it was that the engineers _knew_ the ciruit diagram of the  
> processor
> 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
> much.
> <<<
> 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  
> have
> worked
> 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  
> design,
> 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  
> and
> 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 mailing list