My contribution to an Oral History of Robotics

In March 2013 I was interviewed by Peter Asaro for the IEEE.tv Oral History of Robotics series. That interview has now been published, and here it is:

In case you're wondering, I'm sitting in Noel Sharkey's study (shivering slightly - it was a bitterly cold day in Sheffield). It was a real privilege to be asked to contribute, especially alongside the properly famous roboticists Peter interviewed. Do check them out. There doesn't seem to be an index page, but the set starts on page 2 of the IEEE.tv history channel.

Postscript: a full transcript of the interview can be found here: http://ethw.org/Oral-History:Alan_Winfield

Copyright violations bring Forth memories

Last week I found a couple of copyright violations. Am I upset? Not at all - actually I'm delighted that stuff I did in 1983 is alive and well on the Interweb thanks to the efforts of others.

The first is an online readable copy of my 1983 book The Complete Forth. It's a textbook on the programming language Forth that I was heavily into at the time. The book was first published by Sigma Press, then internationally by John Wiley, and was translated into both Dutch and Japanese. Someone - I assume from the Jupiter Ace archive - has gone to the trouble of scanning every page. Even the pull out reference card. Whoever you are, thank you.

Just before I wrote that book, I had developed a Forth programming system (a programming environment that integrates compiler and interpreter) for the NASCOM 2 Z80 micro computer. Myself and a friend then marketed Hull-Forth and, I recall, sold several hundred copies. Of course this was pre-internet so marketing meant small ads in the magazine Personal Computer World. What we actually shipped was a printed manual together with the code on a cassette tape. Floppy disks were hugely expensive and beyond the reach of hobby computers, so for saving and loading programs we used audio cassette recorders. They were slow and very unreliable; if there was a checksum error you just had to rewind, cross your fingers and try again. I can't imagine anyone feeling nostalgic for that particular technology.

This brings me to the second copyright infringement. By accident I discovered there is a webpage for NASCOM enthusiasts, and several emulators, so you can run a virtual NASCOM on your modern PC. Scrolling down the long list of software in the NASCOM repository, in the section Programming Languages, I find

• Hull Forth Interpreter/Compiler (1982)

Hah! Someone must have gone to alot of trouble to get the code from the original cassette*, recorded using the Kansas City Standard at, I think, 300 baud (so slow you could almost hear the noughts and ones!), to a .NAS file you can download into your NASCOM emulator.

Ok, now to get that NASCOM emulator running. It will be fun (and slightly absurd) to run Hull Forth again for the first time in about 33 years.

---

*I probably still have one of those cassettes in my loft**, but no way of reading the data from it.
**Along with stacks of punched cards, rolls of paper tape, and all kinds floppy disks.

A Close(ish) Encounter with Voyager 2

It is summer 1985. I'm visiting Caltech with colleague and PhD supervisor Rod Goodman. Rod has just been appointed in the Electrical Engineering Department at Caltech, and I'm still on a high from finishing my PhD in Information Theory. Exciting times.

Rod and I are invited to visit the Jet Propulsion Labs (JPL). It's my second visit to JPL. But it turned into probably the most inspirational afternoon of my life. Let me explain.

After the tour the good folks who were showing us round asked if I would like to meet some of the post-docs in the lab. As he put it: the fancy control room with the big wall screens is really for the senators and congressmen - this is where the real work gets done. So, while Rod went off to discuss stuff with his new Faculty colleagues I spent a couple of hours in a back room lab, with a Caltech post-doc working on - as he put it - a summer project. I'm ashamed to say I don't recall his name so I'll call him Josh. Very nice guy, a real southern californian dude.

Now, at this point, I should explain that there was a real buzz at JPL. Voyager 2, which had already more than met its mission objectives was now on course to Uranus and due to arrive in January 1986. It was clear that there was a significant amount of work in planning for that event. The first ever opportunity to take a close look at the seventh planet.

So, Josh is sitting at a bench and in front of him is a well-used Apple II computer. And behind the Apple II is a small display screen so old that the phosphor is burned. This used to happen with CRT computer screens - it's the reason screen savers were invented. Beside the computer are notebooks and manuals, including prominently a piece of graph paper with a half-completed plot. Josh then starts to explain: one of the cameras on Voyager 2 has (they think) a tiny piece of grit* in the camera turntable - the mechanism that allows the camera to be panned. This space grit means that the turntable is not moving as freely as it should. It's obviously extremely important that when Voyager gets to Uranus they need to be able to point the cameras accurately, so Josh's project is to figure out how much torque is (now) needed to move the camera turntable to any desired position. In other word's re-calibrate the camera's controller.

At this point I stop Josh. Let me get this straight: there's a spacecraft further from earth, and flying faster, than any manmade object ever, and your summer project is to do experiments with one of its cameras, using your Apple II computer. Josh: yea, that's right.

Josh then explains the process. He constructs a data packet on his Apple II, containing the control commands to address the camera's turntable motor and to instruct the motor to drive the turntable. As soon as he's happy that the data packet is correct, he then sends it - via the RS232 connection at the back of his Apple II - to a JPL computer (which, I guess would be a mainframe). That computer then, in turn, puts Josh's data packet together with others, from other engineers and scientists also working on Voyager 2, after - I assume - carefully validating the correctness of these commands. Then the composite data packet is sent to the Deep Space Network (DSN) to be transmitted, via one of the DSNs big radio telescopes, to Voyager 2.

Then, some time later, the same data packet is received by Voyager 2, decoded and de-constructed and said camera turntable moves a little bit. The camera then sends back to Earth, again via a composite data packet, some feedback from the camera - the number of degrees the turntable moved. So a day or two later, via a mind-bogglingly complex process involving several radio telescopes and some very heavy duty error-correcting codes, the camera-turntable feedback arrives back at Josh's desktop Apple II with the burned-phosphor screen. This is where the graph paper comes in. Josh picks up his pencil and plots another point on his camera-turntable calibration graph. He then repeats the process until the graph is complete. It clearly worked because six months later Voyager 2 produced remarkable images of Uranus and its moons.

This was, without doubt, the most fantastic lab experiment I'd ever seen. From his humble Apple II in Pasadena Josh was doing tests on a camera rig, on a spacecraft, about 1.7 billion miles away. For a Thunderbirds kid, I really was living in the future. And being a space-nerd I already had some idea of the engineering involved in NASA's deep space missions, but that afternoon in 1985 really brought home to me the extraordinary systems engineering that made these missions possible. Given the very long project lifetimes - Voyager 2 was designed in the early 1970s, launched in 1977, and is still returning valuable science today - its engineers had to design for the long haul; missions that would extend over several generations. Systems design like this requires genius, farsightedness and technical risk taking. Engineering that still inspires me today.

*it later transpired that the problem was depleted lubricant, not space grit.

Extreme debugging - a tale of microcode and an oven

It's been quite awhile since I debugged a computer program. Too long. Although I miss coding, the thing I miss more is the process of finding and fixing bugs in the code. Especially the really hard-to-track-down bugs that have you tearing your hair out - convinced your code cannot possibly be wrong - that something else must be the problem. But then when you track down that impossible bug, it becomes so obvious.

I wanted to write here about the most fun I've ever had debugging code. And also the most bizarre, since fixing the bugs required the use of an oven. Yes, an oven. It turned out the bugs were temperature dependent.

But first some background. The year is 1986. I'm the co-founder of a university spin-out company in Hull, England, called Metaforth Ltd. The company was set up to commercialise a stack-based computer architecture that runs the language Forth natively. In other words Forth is the equivalent of the CPU's assembly language. Our first product was a 16-bit industrial processor which we called the MF1600. It was a 2-card module, designed to plug into the (then) industry standard VME bus. One of the cards was the Central Processing Unit (CPU) - not using a microprocessor, but a set of discrete components using fast Transistor Transistor Logic devices. The other card provided memory, input-output interfaces, and the logic needed to interface with the VME bus.

The MF1600 was fast. It ran Forth at 6.6 Million Forth Instructions Per Second (MIPS). Sluggish of course by today's standards, but in 1986 6.6 MIPS was faster than any microprocessor. Then PCs were powered by the state-of-the-art Intel 286 with a clock frequency of 6MHz, managing around 0.9 Assembler MIPS. And because Forth instructions are higher level than assembler, the speed differential was greater still when doing real work.

Ok, now to the epic debugging...

One of our customers reported that during extended tests in an industrial rack the MF1600 was mysteriously crashing. And crashing in a way we'd not experienced before when running tried and tested code. One of their engineers noted that their test rack was running very hot, almost certainly exceeding the MF1600's upper temperature limit of 55°C. Out of spec maybe, but still not good.

So we knew the problem was temperature related. Now any experienced electronics engineer will know that electrical signals take time to get from one place to another. It's called propagation delay, and these delays are normally measured in billionths of a second (nanoseconds). And propagation delays tend to increase with temperature. Like any CPU our MF1600 relies on signals getting to the right place at the right time. And if several signals have to reach the same place at the same time then even a small extra delay in one of them can cause major problems.

On most CPUs when each basic instruction is executed, a tiny program inside the CPU actually does the work of that instruction. Those tiny programs are called microcode. Here is a blog post from several years ago where I explain what microcode is. Microcode is magic stuff - it's the place where software and hardware meet. Just like any program microcode has to be written and debugged, but uniquely - when you write microcode - you have to take account of how long it takes to process and route signals and data across the CPU: 100nS from A to B; 120nS from C and D, and so on. So if the timing in any microcode is tight (i.e. only just allows for the normal delay and leaves no margin of error), it could result in that microcode program crashing at elevated temperatures.

So, we reckoned we had one, or possibly several, microcode programs in the MF1600 CPU with 'tight' timing. The question was, how to find them.

The MF1600 CPU had around 86 (Forth) instructions, and the timing bugs could be in any of them. Now testing microcode is very difficult, and the nature of the problem made the testing problem even worse. A timing problem at elevated temperatures means that testing the microcode by single-stepping the CPU clock and tracing the signals through the CPU with a logic analyser wouldn't help at all. We needed a way to efficiently identify the buggy instructions. Then we could worry about debugging them later. What we wanted was a way to test (i.e. exercise single instructions, one by one), on a running system at high temperatures.

Then we remembered that we don't need all 86 instructions to run the computer. Most of them can be emulated by putting together a set of simpler instructions. So a strategy formed: (1) write a set of tiny Forth programs that replace as many of the CPU instructions as possible, (2) recompile the operating system, then (3) hope that the CPU runs ok at high temperature. If it does then (4) run the CPU in an oven and one by one test the replaced instructions.

Actually it didn't take long to do steps (1) and (2), because the Forth programs already existed to express more complex instructions as sets of simpler ones. Many Forth systems on conventional microprocessor systems were built like that. In the end we had a minimal set of about 24 instructions. So, with the operating system recompiled and installed we put the CPU into the oven and switched on the heat. The system ran perfectly (but a little slower than usual), and continued to run well above the temperature it had previously crashed. A real stroke of luck.

Here's an example of a simple Forth instruction to replace two values on the stack with the smaller of those values, expressed as a Forth program we call MIN
: MIN  OVER OVER > IF SWAP THEN DROP ;
(From my 1983 book The Complete Forth).

From then on it was relatively easy to run small test programs to exercise the other 62 instructions (which were of course still there in the CPU - just not used by the operating system). A couple of days work and we found the rogue 2 instructions that were crashing at temperature. They were - as you might have expected - rather complex instructions. One was (LOOP) an instruction for do loops.

Then debugging those instructions simply required studying the microcode and the big chart with all the CPU delay times, over several pots of coffee. Knowing (or strongly suspecting) that what we were looking for were timing problems, called race hazards, where the data from one part of the CPU just doesn't have time to get to another part in time to be used for the next step of the microcode program. Having identified the suspect timing I then re-wrote the microcode for those instructions to leave a bit more time - by adding one clock cycle to each instruction (50nS).

Then reverting to the old non-patched operating system, it was the moment of truth. Back in the oven, cranking up the temperature, while the CPU was running test programs specifically designed to stress those particular instructions. Yes! The system didn't crash at all, over several days of running at temperature. I recall pushing the temperature above 100°C. Components on the CPU circuit board were melting, but still it didn't crash.

So that's how we debugged code with an oven.

Philip Larkin - a recollection

My first encounter with Philip Larkin was as a fresher in October 1974. As university librarian it was Larkin's annual duty to give an introductory lecture to the year's fresh intake. I recall seeing this tall, portly man with bottle-top glasses in a bank manager's suit. Not at all how I imagined a poet should look. (My Dad had told me about Larkin when I first announced I'd chosen to go to Hull University, otherwise I'm sure I'd have taken no notice at all.) To this audience of several hundred 18-year olds - more interested in eyeing each other for fanciableness than listening to some bloke in a suit - Larkin declared with a plummy, resonant voice and measured delivery, as if it was a line from Shakespeare, "...educated people should know three things: what words mean, where places are and when things happened".

My first encounter with his poetry was several months later. It was a vacation and I was at home with Mum and Dad, younger sister and brother. Larkin was to be featured in a TV documentary and the whole family gathered expectantly round the set at the appointed time. Then the first stanza was read "They fuck you up, your mum and dad/They may not mean to, but they do/They fill you with the faults they had/And add some extra, just for you." Cue acute, embarrassed silence. My Mum, I think, said "Well I don't think much of this" and without another word the TV was switched off. We didn't discuss this (in fact I don't think we ever discussed it). It was some years later that I got to know (and love) Larkin's poetry and to reflect on the idiot producer who chose to start that TV programme with arguably his worst poem, just for the shock value of the word fuck on the BBC (this was 1975). It's not that I'm prudish about the sentiment expressed, it's just not a good poem.

Fast forward about six years. I've accepted a junior lecturing post while finishing off my PhD, and find myself a member of the science faculty board. As librarian Larkin is an ex-officio member and I recall him contributing his opinions to the board's debates. I've long forgotten the subject of those debates but I vividly recall the manner of Larkin's contributions. He would stand, as if addressing parliament, and speak what I can only describe as Perfect English. His articulation, diction and metre was actor-perfect. If you had written down exactly what he said, and punctuation would have been easy for he paused in commas and semi-colons, you would get perfect prose; each word exactly the right word, each phrase perfectly turned. I was, at the time, going out with a girl who worked in the library and she told me Larkin's memoranda were the same: each a miniature essay, a perfectly formed construction of letters.

I never knew Larkin. Nobody did. He was a distant, unapproachable man and, by all accounts, not at all likeable. The closest he and I came to conversation was exchanging nods across the lunchtime staff common-room bar. I find it satisfyingly ironic therefore that a man so apparently detached and unemotional should have written what is, for me, the finest love poem of the 20th Century: An Arundel Tomb (1).

The poem starts: Side by side, their faces blurred, the earl and countess lie in stone, and then in the second verse the beautiful observation: Such plainness of the pre-baroque hardly involves the eye, until it meets his left-hand gauntlet, still clasped empty in the other; and one sees, with a sharp tender shock, his hand withdrawn, holding her hand. I love the words sharp tender shock; then in the next verse: Such faithfulness in effigy... A sculptor’s sweet commissioned grace.

In the fifth verse Larkin constructs a spine tingling evocation of the long passage of time: Rigidly they persisted, linked, through lengths and breadths of time. Snow fell, undated. Light each summer thronged the glass. A bright litter of birdcalls strewed the same bone-riddled ground. And then the remarkable conclusion of the poem: The stone fidelity they hardly meant has come to be their final blazon, and to prove our almost-instinct almost true: what will survive of us is love.

Forgive me for removing the line breaks in these extracts from the poem. In doing so I want to illustrate my observation that, in Larkin's writing, there is little distance between prose and poetry. When reading his poems I've reflected often on why it is that a man with such an apparently effortless ability to produce perfect English published so little, and agonised so much over his writing. I now realise that he didn't have a problem with writing, but with life. "The object of writing," Larkin once said, "is to show life as it is, and if you don't see it like that you're in trouble, not life.

---

(1) from The Whitsun Weddings, Faber and Faber, 1964. And here is both the full text of An Arundel Tomb and Larkin reading the poem.

"By, you were lucky..."

My friend, erstwhile mentor and visiting professor colleague Rod Goodman and I were reminiscing a few days ago about our first experiences (~1977) with the Intel 8080, which arrived on a circuit board with 1K bytes RAM, a 1K byte EPROM and absolutely no software. We were having one of those conversations inspired by Monty Python's four Yorkshiremen sketch (and thanks to Dave Snowden for this link from his excellent blog):

"When I were a lad, we only had 4K bytes of RAM and a hex keypad"

"Hex keypad! By, you were lucky. We only 'ad 1K of memory and had to key in t'boot loader by 'and in noughts and ones before we could even start work".

"Well you were lucky. We were so poor we could only afford noughts..." and so on.

But the truth is (and I realise how perilously close I am to becoming a grumpy old man parody here) that my fellow graduate students and I really did have to start from scratch and make all of our own development tools. I recall that we first had to write a cross-assembler, in Algol-68, on the university mainframe: an ICL 1904S. We took advantage of the fact that the mainframe was accessed by electro-mechanical 'teletypes' which were fitted, as standard, with paper-tape punches. We got hold of a paper tape reader and interfaced it to the Intel 8080 development board (designing by hand the necessary interface electronics and device driver code - remember this is long before 'plug and play'). Then we were able to write symbolic 8080 assembler on the mainframe, generate 8080 machine code on paper tape, and load that directly into the 8080 development board to test it. Of course the edit test cycle was pretty long, and not helped by the fact that our lab was two floors from the mainframe terminals, so to speed things up we invested in a special device that allowed us to directly 'edit' the paper tape. The device allowed us to make extra holes and cover over - with a special kind of sticky tape - unwanted holes. Here's a picture of this marvellous device.

So, to anyone out there who grumbles about their software development tools I have only one thing to say. "You're lucky you are. When I were a lad..."