Some quick URLs of items not yet added here:
This is a project organised by Graham Toal with help from Professor Gordon Brebner and Ian Young which we hope will also attract a lot of volunteers from Edinburgh - old hands from EUCSD, DMIP, and ERCC (to name but a few, not to mention many name changes over the years) who know us, and with any luck also some new faces, if there are any current students who are interested in discovering what went before them. We want to save as much of Edinburgh's computing history as we can, before it is permanently lost. We're currently going to focus primarily on identifying, finding and retrieving old source code - such as the PDP9/15 Imp compiler/linker, Legos, the File Server, and Layout to name but a few; programs which no longer have a home and which may soon be permanently lost as the old tapes and disks they are on become unreadable. We'll also archive related materials such as user guides or circuit diagrams.
At some point in the future we may also try to transcribe some oral history, but that is not a current priority. Although the initial members of this group are likely to be from EUCSD (as was), we'd also like any current or past AI, ERCC, and Electrical Engineering people to join us too. We're not quite organised enough yet to also invite Heriot-Watt and Moray House, but we are aware of their contribution to Edinburgh computing history, and will add them to the project at a later date.
This web page is going to be the main depository for the project. We will make notes here of what software we remember, what software we've tracked down but don't have copies of - and any software which we do get online will be filed here. Because code was smaller in those days, I have every hope that a complete historical archive of everything that was written in Edinburgh in the early days might be saved on one hard disk, and I am willing to burn CDs for people who want backup copies for posterity.
Note: I expect to find a lot of info only available on paper. Because the state of the art in OCR is not much better now that it was 20 years ago, I'm going to suggest that we scan these documents and keep the scans as primary source material, even if we do OCR it as well. That way they can be OCR'd again in future years with later software which may do a better job than that which we have now. I recommend that volunteers doing scanning save their files at the best optical resolution their scanners support - but do *not* use interpolated higher resolutions. Let the software take care of that in years to come. At the very minimum, please scan at 300x300 if you are scanning dot matrix listings. They are much harder to OCR than hard-strike type such as from the old EMAS band printers (or the one we had downstairs in the machine room)
There were several student projects based on Peter Robertson's Imp front end; Andy Davis ported imp to the TI9900. Rainer Thonnes ported Imp to both the Ferranti DISC ("Digital Inertial Systems Computer"), and the Data General Eclipse. I'm pretty sure Ian Young wrote an Imp compiler for an HP calculator.
Now, to make it even more interested, we have another version of GPM
contributed by Chris Whitfield:
I suppose I was a something of a fan of this thing. Can I say a couple of
things in its defence.
It's original raison d'etre was to boot the CPL compiler. It was very
definitely a tool not a theoretical exercise. The GPM implementation
was designed in CPL then handcoded.
A major thing in its favour is that it can quite literally substitute
anything anywhere.
The basic implementation does indeed run wild if anything goes wrong
but it can be improved fairly easily. I had a version for a number
of years which was progressively developed to the point where it was
a useful tool though the coding of the program is revolting. I attach
a copy for your delectation!
This came from the 1980 Mouses tape. I'll try to find evidence of when
it first appeared. My memory is when Hamish's PDP9 compiler first came
available around early 1969. Looking at the source, typed in uppercase
with some lowercase text literals, I'd suspect it originated on a real
or "glass" Teletype 33 with later additions.
I'm aware of a couple of the early AI pioneers who are in nursing homes. If we are to talk to them at all, we would need to do so by sending someone to interview them. Unless we have some volunteers, who are both knowlegable about computing and good writers, who specifically want to do this, I'm afraid it's an opportunity we are likely to miss. Note there is a small possibility of aquiring some funding to conduct interviews so if someone does want to take this on, contact me directly (gtoal@gtoal.com), and don't wait too long, for obvious reasons.
Proof of concept: yes, it is possible. Here is an Imp program and here is a C program. They are functionally identical. I did this translation by hand. Can you do as well with a program?
Temporary solution: in the APM Archive, several Layout documents had been converted to TeX by a command VTOT. I have written another converter which takes that TeX source and generates HTML. Given that some of the previously-generated TeX is itself broken, the subsequent translation actually works rather well. The translated documents are here, and the translator is here. The parser-generator which was used to build the translator is here.
JGH has copies of:
This is a update on my EMAS years and the bits and pieces I still have.
I started with the ERCC in late 1974 (I think) and left in 1981 to join DEC. Previous to that I worked in the Medical Computer Group with Jeff Tansley, Walter Lutz, and Brian Gilmore (another piece of Edinburgh computing history).
On EMAS I worked on the following things.
Bits and pieces I have. (Unfortunately it is all on paper at the moment.)
I know it had the VMS implementation of ECCE I did, half in IMP and half in assembler. I'm pretty sure I don't have it rather than just hidden it in an unopened box.
It is a shame I don't have the code for Legos. It was a pretty elegant system when you consider it ran on a 64K (or less) machine. I was always amazed when the PC and Mac came out that they didn't have proper multi-process operating systems. It seems so trivial to implement, and so powerful and makes it so much easier to implement lots of the things that people must have struggled with (Borland's sidekick, network protocols etc).
The original filestore had nothing to do with ISYS (other than running on the same type of hardware). ISYS was indeed an Interdata operating system (written by Hamish). It supported several (6 I think) terminals which could edit and manipulate files simutaneously, and a background memory area that actually was about 2/3 of the memory, that could be used for other programs, primarily HAL assembly and later, Peter Robinson's IMP compiler. Users could not run their own programs on ISYS (no protection), they downloaded them over a serial departmental link to their own personal Interdata and ran them there. Legos was essentially a re-write of ISYS as a single-user (but still multiprocess) operating system with no discs or filesystem of its own, it used the original filestore for that. Unlike on ISYS you could run your own programs on Legos (if you crashed the machine you only inconvenienced yourself). If they were small enough they could be run in a disc (actually filestore) buffer so everything did not pile up behind the semaphore for the background partition, as would happen on ISYS coming up to any sort of course deadline.
The original file server had a multi-threaded scheduler (written by a woman called Vicki Eachus) and the file-system itself (which I wrote). It didn't really operate like FTP since there was no virtual-circuit level to the network protocol and you would want to have lots of files open at once (although it did have a regurgitate a whole file command that was used by bootstraps to suck down the operating system). Instead it had commands like open a file and give me a channel number, read a block from this channel, close this channel (more like NFS - GT). Like so much of what was done in those days, the system was fairly basic but the challenge was getting everything to run in a max of 64K bytes of memory while reserving lots of space for disc buffers.
The scheduler was actually horrible. It had been built on the notion that switching processes and saving state would degrade the I/O performance too much, so most of the state had to be saved in transaction records explicitly. The PC was not saved automatically for a transaction. This holds an unbelievable amount of state information as everyone discovers the first time they write a program in any sort of windows (small w) environment and have to return control after ever character typed, menu shown etc. Nor were any registers saved so every time you lost control (to perform I/O of any type or to claim a semaphore) you had to do all this housekeeping manually. It was very non-deterministic when you got it wrong since, except under heavy load, your register would still have its old value after the I/O or after you got the semaphore, even if you forgot to save it. Until one day it wouldn't.
When Hamish re-wrote the filestore, he based it on the ISYS/LEGOS kernel as well as cleaning up lots of other things. I see from some Fred machine documentation I looked at, that the basic functionality of the file system itself survived through several re-writes. The basic notion that saving state was expensive was correct - you couldn't have a process for each open file just waiting for the next read command - but it seemed to me that the approach taken was (garbled in transmission - GT)
Curiously, having ended up in EDA for integrated circuits all my adult life, the problem remains fitting everything into memory. Eight gigabytes of real memory just isn't enough for a chip with 50 million gates and people are starting to think about designing logic chips with a billion transistors.
As an aside, ISYS (and LEGOS) had the most extraordinary bit of Hamish code as part of its bootstrap. The bootstrap would load the code from disc (ISYS) or the filestore (LEGOS) into an area of memory and then jump to the first location of the loaded code. This loaded code had no idea of the exact address at which it had been loaded, and the only way to find out was to call a subroutine that would leave the return address of the next instruction in a register. Having done that it finally had an offset in a register it could use to address its own code. Then it would copy the entire tiny code sequence down to location 0 in a pair of load multiple registers, store multiple registers instructions, then jump to this new cloned copy of itself. For this to work, the entire program had to fit into 16 instructions. It would then copy the entire operating system down into low memory and enter the operating system scheduler proper, which would find (magically) several process ready to run to initialize everything else. Starting at address 32 just after this bit of program were hardwired address like the PSW to load on an illegal instruction, interrupt, SVC etc. So the operating system had values it wanted pre-loaded there, not some random code from part of the bootstrap, so it was doubly imperative that the copying code fitted into 32 bytes.
We are VERY lucky to have Donald Michie as a contributor. I'm giving serious thought to flying over to Scotland in July myself to help examine and scan/OCR his archive!
He doesn't explicitly mention having any old source code, but even if there's no code, we really must transfer as much of this history to online media as we can.
> Dear Graham Toal > > I have an archive brimming with documentation > of every kind covering the early days, -- technical > reports, minutes of the weekly staff meetings in the > EPU and DMI, correspondence galore with University > Admin and Court, with international AI scientists, > with visitors and Machine Intelligence Workshop > contributors, with editors, authors, other Departments > of the University at that time, proposals, manifestos > and goodness knows what else. > > There is in addition a complete History of the > Machine Intelligence Research Unit written by > my wife, then a member of the said MIRU. The > special point of interest is that it documents > an organization that had a ten-year run, from > 1974 - 1984. But its existence and history > remains I believe almost entirely unknown. This > is because a usual account of events is that after > the departure from Edinburgh of Professors Richard > Gregory (who left in 1970) and Christopher Longuet- > Higgins (around 1974) I also departed, to Glasgow > to found the Turing Institute, at the same time > that the Department of Artificial Intelligence was > being set up in Edinburgh. In actuality I did not > leave for Glasgow and set up the TI until 1984. > > The dramatic collapse of funding following the > Lighthill report temporarily stranded a community > of several dozen AI research workers. The > University had to set up new structures and a > new mission for as many as could be retained > in Edinburgh. > > The DAI was the main result. In the process > each person was asked whether he or she would > accept assignment to undergraduate teaching. > Uniquely, my University post was a so-called > Personal Chair. In those days such appointments > carried no teaching obligation. Never having > done any teaching in my life, I opted out. I > also had private doubts about whether the field > had yet sufficiently matured to support > undergraduate courses*. > > The University accordingly set up two Departments, > of which the DAI was one. The other, named the > Machine Intelligence Research Unit, consisted of > myself, my secretary, and 1/11th of the time of > Dr Horace Townsend, of the medical faculty. We > were allotted space for four postgraduate > students. One or two self-funded workers also > attached themselves, including Jean Hayes who > ten years later wrote the History, and there > was also a constant stream of visiting workers > from overseas. So although from the outside > the MIRU was almost invisible, it had a vigorous > internal life and a steady and varied output. > It was quite unbelievably crowded and chronically > broke. But in its peculiar way the MIRU was fun. > > My boxes of documents are of course overkill > from your point of view. I am sure you will only > want to retain or copy a few fragments. At the > same time it seems pointless to try to offer > anything from here in Australia. > > It will be best, I think to wait until I get > back, unfortunately not until July 1st. I will > be delighted then to get access to my files > and give you the run of them. > > For the Computer Science Dept history, Peter > Schofield's memory should stretch back to the > beginning. He also contributed an excellent > paper to one of the first two Machine Intelligence > volumes. > > Best wishes > > Donald Michie > > > *My doubts were soon refuted by the newly- > formed DAI's publication of the world's > first-ever AI textbook. Written by Alan Bundy, > Rod Burstall and Pat Ambler this set a standard > that no subsequent text that I have seen has > come near.I later wrote to Donald talking about his "Memo Function" idea that we had learned as undergrads... he replied:
Dear Graham Toal
Thank you for your generous letter. Curiously, on the same day as I received it I had just composed a letter to Tom Dietterich, now at Orgon State U, in which I referred to memo functions.
>>it may be that the best way to get good performance over a range of >>tasks is to build a separate expert system for each subtask, but I >>suspect that there will be important computational advantages in >>having shared knowledge and memory structures and shared learning >>methods that can be applied across all of the tasks. > >I agree. In a well-organised program-library some of these >shared materials are, as we know, called utilities. An example >of an AI-oriented utility was POP-2's incorporation of "memo" >functions, initially as a library utility, and subsequently as >a built-in language feature. Although I approved at the time, >I've come to distrust this second (building-in) step. Keep it >loose and keep it recombinable, I say, unless unbearable >overhead penalties assert themselves.It would certainly be nice if the origination of memo functions were to become more generally known. But Robin Popplestone did made an important design contribution in his implementation.
The reference to my 1968 paper is: 'Memo' functions: and machine learning, Nature, 218, 19-22.
Much else in your letter strikes a chord. I meant to add to what I said in my earlier letter. I there omitted mention of a rich historical source I have in the form of the minutes of the "Round Table" that governed the Experimental Programming Unit from early days around 1963-65 until the establishment of the Department of Machine Intelligence and Perception around 1969. During the 1963-65 we were a wild-cat group who had managed to get into abandoned buildings in Hope Park Square and to resist University attempts to starve us out (e.g. they controlled the supply of amenities to the building including telephones).
We wouldn't have made it, but for the covert support of the then Vice-Chancellor, Sir Edward Appleton (of "Appleton layer" fame). But sometimes it was a close run thing!
Robin Popplestone was almost a founder member of the EPU. I don't know his current whereabouts. The person who almost certainly would know is Pat Ambler, now at Aberdeen.
Best wishes
Donald Michie
One other highly visible AI person to add to your list is Pat Hayes (http://www.coginst.uwf.edu/~phayes/) who was a student of Bernard Meltzer (last heard of, at least by me, living in Italy).
Computing had got off to a bad start at Edinburgh. In the first UGC round the University had been asked its intentions. Aitken, Professor of Math, said there was no interest (meaning he had no interest, but Edinburgh Professors tended to think that way then). This meant that in the second round the University started from behind the eight ball. The University of Manchester's offer of a landline connection seemed preferable to the second hand Pegasus from the University of Leeds (if I remember correctly). We were initially installed in 1-2 rooms in the Chemistry Dept. at Kings Buildings, but moved to Buccleuch Pl. as Atlas began its first attempts at job processing. Installation of the link proved interesting. The Post Office didn't seem enthusiastic, and when a technician eventually arrived he had no technical data and no idea how to proceed. In the end he watched while Sidney connected it. Of course the appetite for computing resources far exceeded any possibility of Manchester servicing them, and the links (never on line) were low on their priority scale, so we ended up sending jobs plus our own operator to Manchester. Turn around time of a week was about the norm, so careful checking of programs before dispatch was crucial. This was the context in which Harry Whitfield was cornered into agreeing to develop the AA compiler for the KDF9 (He and Bratley were in the ELRU at the time, one morning over coffee Harry overextolled the virtues of recursive programming and phrase structure grammars, and there was a not insignificant component of calling Harry's bluff then and there in getting the project started - Peter Schofield had skills in this direction, but I don't think he actually wrote any of the code). Once committed the committment was total.
This was the seminal step on which the rest of the story rests because it was the success of this project which led the Flowers' Committee to leapfrog Edinburgh into the top bracket of the pecking order (it also put paid to a number of local political type distractions). Jimmy Thorne probably had good reason to feel somewhat resentful at his (ELRU) staff's involvement but I was not aware of him complaining. It should be noted that Bratley's accuracy in programming was phenomenol and played an enormous part in the overall success (not wanting to minimize the roles of either Harry or David Rees who were just ordinarily remarkable). There was a first trip to Manchester in which a boot tape for the KDF9 was prepared on Atlas (using the compiler compiler?), corrections/repairs to the (paper tape) were made by eye and hand punch, before remarkably substantial action on the Liverpool KDF9 on the next evening and more surgery on the compiler tape on the train home. The real story is every bit as remarkable as any coffee table embroidary could make it. The Gates and Allen basic Basic compiler story is rather small beer by comparison.
Given the KDF9 compiler our options were substantially broadened. With the generousity of Ewan Page at Newcastle, plus some help from Glasgow, plus the Schofield organizing ability, things did improve, and improve enough to really impress the Flower's visitation. The PDP8 came a bit later. I guess we had argued that a local syntax checker would help. Not as much as a real computer helped our morale!
Our first teaching activities apart from AA courses (I still have a copy of the Atlas Autocode manual by Schofield and myself - CU report #1) had to do with a numerical analysis postgrad diploma. Alec Wight was one of our first students. Alistair Watson (now Professor at Dundee) was an early graduate student. David Rees was one of two graduate students from Imperial College who came with the initial appointments. The next staff appointment was Don Kershaw who came from the Admiralty and subsequently went to Lancaster. Sidney pushed for Computer Science in the undergraduate curriculum from the beginning with the result that it was ready to roll in step with the other developments.
Michael R. Osborne
Centre for Mathematics and its Applications
Australian National University
Canberra, A.C.T. 0200
I have got listings of some of the EMAS stuff I wrote in the early 70's: Director 714 (30/6/72) and CEDRIC 703 (2/6/72) plus many of the manuals we wrote at the time. I also have a listing of the last EMAS2900 kernel I wrote, dated 26/2/80.
The earliest stuff I have is `Computer Unit Report No. 2 : A Guide to a Survey Program for Atlas', dated November 1965 (probably a unique copy, by now)!
I just remembered I do have something machine readable - I have paper tapes of the assembler source for my PDP8 music compiler which must date from around 1966. The PDP8 itself is in storage in the Chambers St. museum I think.
Astra was the subject of my PhD thesis, so it's in the library with a good bit of the code in appendices. (Although it was a pretty simple compiler by today's standards, I've never seen anything like its high-level string handling facilities in any subsequent language!)
Paul Bratley was involved with the AA compiler for KDF9 (with Harry, me, Peter Schofield and later Alex Wight) and then with the first year or so of EMAP before he emigrated to Canada (Uni. of Montreal). Paul also wrote the first video game we ever saw - 'two tanks' for the oscilloscope of the PDP8. (I wonder what happened to my PDP8 Reaction Timer?)
Has the name John McKay cropped up yet? He was here for a few years in the mid 60s. His claim to fame was running a program for 48 hours solid on the PDP8. It was unheard of for computers to run that long in those days! He was doing 'partitions' of numbers, I think. He was (and is, at Concordia Univ., also Montreal) a computational group theorist.
Chris Whitfield adds to the above:
So far as I can remember, John was Joanne Officer's (now Lamb)
Ph.D supervisor. She was doing work in reducing systems of
algebraic expressions so far as I remember. I'll confirm this
with her when she comes back from abroad next week.
While not a member of the department, Cliff Pavelin, as part
of the ICL contribution to the EMAS team did leading edge work
on physically reordering code to improve its paging behaviour.
Much later, IBM applied the same technique to OS/2 to get it to
run in 4Mb rather 8Mb.
Harry Whitfield would know about this.
I wrote the Atlas Autocode compiler for KDF9 which was used as the
basis for IMP (with some help from Alex Wight). I also used this AA
compiler as the basis of my PhD work on Astra (AA with strings). It's
conceivable that the source of my Astra compiler might still be
archived (the run-time string processing assembly code sub-routines
are in an appendix of my thesis).
IMP was essentially just AA plus a few extra things that I invented
such as records. I remember Tommy Thomas having a press conference in
the North British Hotel at the start of EMAP where I gave a talk about
the AA extensions. (The other thing I remember about that was that
the journalists were only there for the alcohol!) I can't remember
what the sequence of authors of the KDF9 compiler was. I started it
off because I vaguely remember altering the 48-bit word KDF9 version
just to use 32 of the bits for future compatibility with System-4.
Who took it over from me and when I'm not sure. No idea about the
source for it.
(David also wrote the IMP syntax checker that ran on the PDP8 to
check paper tapes, before sending them off on the 2-week turnaround
to Manchester -- GT. Here is the grammar of
Version
K of Atlas Autocode from 1966)
Re the syntax checker: Chris Whitfield adds:
I was employed as a vacation student over the summer of 1967 and spent
that time writing an AA syntax checker for just this purpose. This was
done by handcoding the analysis phase of the then current Atlas Autocode
compiler in PAL8. This checked for parity on the input tape and correct
syntax but did no semantic checks given a 4Kb machine.
A working program was delivered to Sid. What happened to it when I went
back to being a final year student in October 1967 I have no idea.
Will try to find a listing or something.
By around 1983 someone (Rainer?) had connected up one of the original brown-box style ether stations to the Interdata filestore. It didn't work very well, though, as the station didn't have enough memory in it and packets kept getting dropped. The first thing I did when I joined the Department as staff was to write a version to run on the Fred-machines. (Because the Interdata-Fred connection was so unreliable I actually ran the protocol interpreter code first on the VAX, as its brown-box was so little used that I could do a reasonable amount of Fred work each time before things hung, and only after that was working was a filesystem written and the whole thing ported back to a Fred-machine.) The first of the Fred filestores had a 160Mb SMD disc (zapped controller and driver by Rainer), with a couple more 300Mb filestores being added later. The Interdata filestore ended its days as a printer spooler, though even that ultimately migrated to the Fred version once the link-based printer was replaced by an RS232 one.
My version did its own multi-processing non-preemptive scheduling (even on the VAX!). IIRC there was a process to unpack inbound requests, a bunch of filesystem processes, which were convenient for keeping state while waiting for the disc as well as for doing the internal copy operations, and a bunch of ether output processes which were there to keep state while waiting around for the ACK/NAK from the other end.
The Mouse kernel (of which someone else might write more) prompted another rewrite, with a somewhat over-complicated hierarchic filesystem and the very useful ability to run the filesystem on a "user" machine. We had a handful of stand-alone Fred-machines latterly (early '90s I suppose) with one or two 70Mb discs each. The wire-protocol was still essentially unchanged from the 1976 spec that I worked from when I did the 198x rewrite.
BTW, did you know that Dave Mills
Chris Whitfield adds: This project perhaps wouldn't have been necessary if anybody had listened to
him at the time. He was frequently given to muttering "if you haven't
written it down you haven't done it."
Of his other talents, he was interested in short wave radio and had a
programmed phase-lock loop which ran on the PDP8. This was fast enough
to lock onto the audio tones used by morse code, teleprinter transmissions
and so on. Let's just say it was quite amazing what could be picked out
of what sounded like white noise on the radio's speaker.
If you want to get EMAS going again you had better get hold of
a secure tape or copy of its contents. It is an archive of the entire
system in a self loading format. You boot the tape reload the system disc
form the next
1024 pages of the secure tape and you are there. You have the resident
supervisor,
director and the crucial processes up to and including MANAGR from which
you can do everything else.
The guy that did most of the ERCC systems design work on comms was Robin
Johns.
It included progamming a Modula One computer. This was a thing invented
by Ian Baron (not Baron of Southampton but Baron of the Transputer).
Shelness may remember him because I think Shelness as still working for
the ERCC then.
Just been talking with Peter Robertson. We're both happy for
the source of the whole Mouses system, compilers and other support
software to be made available. Depends on that 1600 bpi tape I have
still being readable though.
Incidentally, a command line editor which preceded ECCE was written by Alan Freeman for the PDP-8
in around 1964. I think he's a financial analyst in London now ... at
least I saw someone called Alan Freeman on a financial talk show on the box
who was his spitting image.
(b) Paul Bratley was
responsible for a PDP-8 game .... ca. 1965.
Push buttons, a CRT display and a loudspeaker. Two highly stylized
tanks drawn on the CRT. You chase the other tank and fire your gun at
it with much bleeping from the loudspeaker. All 2D and crude by today's
standards .... but must have been one of the early examples of such a
thing?
(I remember playing this - GT. It was later than Pong but I think it predated arcade games like
asteroids. The tanks were in a very similar vein to Asteroids but it
was a much simpler game. Two player, however!)
(Note: this code sequence and how it was generated is referred to
in Brian Wichmann's paper, "Latest results from the procedure
calling test, Ackermann's function".
"The code generated by the Imp 77 compiler for the PDP11 is quite remarkable.
It is better than what was thought to be the optimal hand coding. Peter
Robertson, the designer of the compiler, explains this by noting that the
compiler is in three passes.
Allocating the two parameters to registers means that no stack frame is
required. Classical optimization is then effective, including code motion.
The improvement over Bliss is achieved by making the entry address the
third instruction - the two previous incrementing and decrementing each
parameter. This means that instructions are saved due to the commonality
of the expressions in the calls". Brian very kindly scanned in the
three most important of his Ackermann's papers. They are online here. - GT.
Copies of many of the above documents should be in the DCS and/or ERCC
archives. Other members of the EMAS team may have copies. There may even be
machine readable copies of some.
Reference copies of the EMAS source code and system were made in December 1970.
These should have been kept.
There were also paper tape copies made of the KDF9 AA and IMP compilers.
Graham is likely to be able to help us with access to the EUCS archive,
which contains all the old EMAS tapes converted to CD.
I would be very happy to help with this preservation task. I'm a little
pushed this (coming) week, but will talk with you after that to see what
makes sense. Other good people to consult are Andrew McKendrick (who was
always sympathetic to preservation) and John Murison (who was EMAS
documentation officer for some years).
I have some old yellow listings of the last emas supervisor I worked on
[Summer 89]. I do not believe much work was done thereafter. It just ran on
till closed down.
(I was asking about the name of the person at GEC who wrote a version of
Ecce there - GT):
Not sure -- think it was Steadman. BTW Hamish may remember him. He did his
4th year project on the ICL 2970 that was in the CS machine halls.
Also, did you know that David Rosenthal - one of the graphics guys at SUN
along with Gosling (became part of one or more of the window kits etc.) - was
ex Edinburgh CAAD. I am also reminded of all the comms work connecting up
Strathclyde and Glasgow, all our own protocols and everything, pre-dating
JANET, yellow book, done at about the same time as ARPA net.
Lee Smith is at Arm and is their compiler (C and C++) guru.
Well done Graham another champion for learning from the past I observe.
Colossus http://www.codesandciphers.org.uk/lorenz/colossus.htm
and
the Manchester Baby
http://www.computer50.org/mark1/new.baby.html
have been rebuilt and
maybe the lessons of EMAS, etc can be revisited too.
[Dr Thomas has] a collection of ERCC annual reports from July 1967 to July
1984. I also have a copy of Arthur Wilson's 'History of the ERCC' written by
Arthur in May 1986. Let me know what you need.
Rainer has contributed the PDP9/15 version of ECCE, and has a paper
listing of the HAL7502 source (written in HAL70 - the Interdata version).
Did you know that (V)ECCE was once considered as a national project to
produce a portable screen editor for the UK AC, particularly at the
National Supercomputer Centres (ULCC, RAL and UMRCC at the time)? I may
still have notes from a proposal somewhere from the time I was EUCS's
remote facilities contact.
Things that spring to mind ... and I hope I still have m/c readables ....
I wrote the Inktronic driver for the PDP9/15 operating system sometime
immediately after the first one of these printers was delivered. I have
a listing of it printed on an Inktronic(!!).
I think the first printer was delivered about a year after the PDP9.
Must have been around Summer 1969.
Hamish must also have written a driver for these printers too about the
same time since the operating system supporting his Imp was completely
independent of the DEC operating system (except for the bootstrap).
These printers were very good for a student environment. They had a
huge ink-tank and used cheap teleprinter rolls.
There were two of them - one on the PDP9 one on the PDP15. For reasons
that were never quite discovered, the first one delivered (for the PDP9)
worked very well. The second was faint and never really satisfactory
despite having practically the whole machine replaced a piece at a time
by engineers.
Used heavily at Moray House (_M_oray '_ouse_ _s_ystem !) and by CS undergraduates
I still have the complete source of this on a 1600 bpi 1/2" tape which may
or may not still be readable.
Peter has written up a short paper on his PDP11 compiler which you can read here.
Among other things, Harry has contributed several versions of ECCE. He has
some EMAS-relevant exam questions on his web site that I've not yet linked
to.
While teaching in Groeningen, he and his students built a PDP-11
operating system called GUTS which had some similarities
to EMAS.
Publications:
Harry has:
The Computer Journal, vol.16, no.4, 1973, pp 331-346.
The Computer Journal, vol.18, no.3, 1975, pp 213-219.
EMAS Project minutes list the following documents relating to IMP:
apart from the big manuals.
These are reprints of papers published (mainly) in the Computer Journal.
Note:
Not all the above are subscribed to this group at the moment. There are
also several people still at Edinburgh University who can doubtless be called
on: Malcolm Atkinson, Chris Mellish, Austin Tate, Alex Wight -
to name just a few from the staff list whom I recognise.
Although he arrived at the University after my own time there and I cannot
claim to have known him personally, I would like to add my voice on behalf
of this project to the
condolences for Michael Boylan who died on Fri 25th
Jan this year. We in the Edinburgh History Project owe him our thanks as
he was the person who only recently finished transferring 20 years worth
of EMAS tape archives to the EUCS CD jukebox system, and I'm sure he
would feel that our best tribute to him would be to make good use over the
coming year of the new archive he created.
Contact Research
People to get in contact with. (Not in any order, just folks I remember.
Mail me with any additions. Or even better, if you know someone who can
help, contact them yourself)
Keith was the author of the EMAS file system. Bill Laing thinks he's
currently in Yugoslavia, or whatever it's called now.
Located, but unlikely to be in contact with us.
In Memoriam
We have unfortunately lost several of those to whom we owe a debt
of gratitude:
