On 3 Jul, 2007, at 18:09, cctalk-request at classiccmp.org wrote: > From: "Andy Holt" <andyh at andyh-rayleigh.freeserve.co.uk 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.