Now with Arduinos and Raspberry Pis, if A won't talk to B, they jolly well will if
you stick a Raspberry Pi in the middle of them. Just write a bit of software to
convert that to that - and, of course, such is the performance of this modern
hardware, now, and such is the range of its networking capability that you can
do huge amounts. You're not compromising the overall quality of the chain in any
way. I mean, you know, your Raspberry Pi solutions are really very very good.
So, what did we do in the old days if hardware A wouldn't talk to hardware B?r
Or it could even be the software A produced by some machine had to be converted
into another software standard, for some other machines. So, whatever.
I think my introduction to all this, back in the day, was when we, at Nottingham, decided to
follow in the footsteps of Bell Labs [and] have our own typesetter. We couldn't do
it exactly the same way that Bell Labs did otherwise we'd have been in court
before we knew where we were, but it turned out that in the gap between
Bell Labs doing it, in about 1979-1980 and us doing it, in about 1983, that
things had come on with this particular typesetter. Now we're back in the era
that, yes, laser printers had been invented. They were there at Xerox PARC;
HP knew all about it. It was a technology waiting to happen but it hadn't quite
happened yet. And in the very early 80s if you wanted to be an early adopter of
a laser printer you'd be paying maybe 15 grand [$15,000] for resolution that was maybe only
300 lines to the inch. So, typical early adopter problem: yes it's the future but
the standard of it isn't fabulous at the moment. And it's darned expensive for what
it is! And this was why we were caught when deciding which kind of typesetter
we wanted. And part of me was saying: "Should we wait another couple of years,
three years maybe, for, you know, laser printer technology to improve sufficiently?
And the people doing the project with me -
principally George the Maths consultant who wanted to typeset beautiful Maths
papers NOW!. We were in the daft position that we had to adopt old technology to
bridge the gap. We were sold "The Future" for our typesetting. They said: " ... this, this,
this Omnitech is wonderful ! It uses laser technology." It was a very early, very high
quality laser printer but it's an example of: "Don't let the wrong industry
invent the future - because they'll get it wrong!" What they were obsessed by was
that traditional typesetting - going all the way back to hot metal and then
coming forward, if you remember, through characters as filmstrips, characters as ...
on an ultra high-definition cathode-ray tube? Yeah! "Our customers will not accept
anything less than 970 dots to the inch". But when this
laser technology started to be developed, by Mergenthaler,
they found that, really, it was happiest at 300 dpi. And you can imagine: "Our
customers will not accept 300 dpi - so we must drive this technology to the limits"
What they ended up doing was having ultra-finely divided toner ink and
special glossy paper that you had to use. Not ordinary A4 or US Letter out of a
packet. Oh no! >> Sean: Have you got some of that? >> DFB: What, some of the paper? Yeah! >> Sean: Shall we have a quick look ... is it possible ? >> DFB: Shall I bring it in? [goes to find Omnitech paper] Yes, this is the actual paper output,
everything, from the Omnitech. And it is a bit of descriptive prose about the
Omnitech, you see. Which is all very useful. And when you rub your finger over here ...
a very glossy finish. And if everything was working and set up beautifully it
was actually a really rather commendable effect. And they claimed to get 720
dots per inch and even that was just: "Oh! some of our customers won't like it!"
Because the 202, using the previous- generation technology could get 972 dots
per inch. So, we're compromising our standards already. But they couldn't
drive it any higher than 720. Even then it was a nightmare. It was
like ... I always thought of it as being rather like owning a very very, very expensive car.
Like oh! I dunno - like a Bugatti or a Duisenberg, something really way out.
That is fine but it needs a complete strip-down and total service after
every hundred miles of usage. This was the same. We found that ideally it was
happiest if it was cleaned and totally stripped down and done at the end of
every day, ready for the next day, you know. And it wasn't just us.
It was customers in America, and so on, reported exactly the same problems.
So, we had to give up on the Omnitech and we had to go back a generation. We had to
ask Linotype to supply us with a Linotronic 202 which we've also talked
about in the past. "Previous generation" because it had a high-resolution cathode
ray tube inside it. It was slow but it produced good quality output but it
was on bromide film, or bromide paper. It needed developing; it needed fixing
all of that hassle. But we did it. And it worked absolutely fine. So, I hear you say:
"But you were driving these things not with Linotype's own software? You of
course we're using UNIX 'troff' and 'eqn' because this was, even, just before Don Knuth's TEX.
It was happening, just about the same time as this, but actually this was
about a year or 18 months before it. So we used Brian Kernighan's 'eqn' for
typesetting mathematics equations Everything was hunky-dory but there was
I, the manager of the project, thinking: All of this
'troff' typesetting stuff is happening on the PDP 11/44, which we bought for use
by the Exams department when we eventually handed it over ....
>> Sean: Because all this ... I remember this. We said this in the last video which was a few
years ago. But you were trying to typeset the exam papers ... >> DFB: Yes, we were trying
to typeset all the exam papers for the University of Nottingham. Because we were
being charged by outside typeset companies £18,000a year.
They ignored [i.e. charged very little for] the dead easy English and History papers,
which were perfectly straightforward. They concentrated on my dear friend
George's Mathematics papers of which there were lots. They started
rubbing their hands and saying: "Oh! this is a job for a [typesetting] professional, I can feel sums
of money like £10 per page comi ghere", you know, and all this kind of stuff.
So, yes, that's what we were trying to do and in the end we did succeed but
one of the bigger problems was that either of those typesetters - the
Omnitech or the 202 - wanted to live in a world of everything being done the
Mergenthaler-Linotype way. In other words you didn't go to outside suppliers for
terminals. You used a CORA text preparation terminal, supplied by
Mergenthaler Linotype. Everything was like a special build for the particular
community that it was in. The era of generic machines and PCs wasn't far
away - but it wasn't quite there. So, we were very non-standard.
Those typesetters wanted their input down a parallel port. Now some of you
older types out there will know that there's a "printer parallel port" on
old-fashioned PCs but back in this era there was no compatibility about how
your parallel ports worked. So, what are you doing, basically, instead of sending 8
bits per character bang bang bang bang bang ... - eight of them serially - you
presented them on eight parallel wires, that's all you're doing. So in principle
you make it eight times faster because when you say "send" you're sending eight
times as much information. Problem is - as many of you know - you only need that
parallel cable which has to be wide enough now to maybe be 16 wide - to take
eight bits going in and a reply of eight bits coming back. Ribbon cable? Twisted?
Differential timings on the different bits of your character beacuse somebody's
trodden on the cable? It's not an easy technology and it always struck me as
very significant that they did not develop the Universal Parallel Bus
to be high-speed [technology of choice] No, USB. Serial is so much easier to cope with. And the answer
to go[ing] faster is make the dead easy protocol, serial, go faster. Don't mess
about with parallel. But we were there, we had to mess with [Linotype-proprietary] parallel. I was stuck
there with two different specs. for two different parallel interfaces to Linotype
machines [Omnitech and 202]. One had been developed in America one had been developed in the UK.
And of course they were completely different ... So, what you did in those days
- no Raspberry Pi - I got a guy called Steve Marchant, an excellent hardware engineer
in our Computing Centre to put me together a box running a Z80 chip.
[Explains animated diagram] "It's coming out of the PDP-11 and it's got the final, if you like, raw characters
with some control characters, that are to be sent to the typesetters, to tell them
to either change font, change spacing or just typeset the letter 'A', wherever you
are at the moment. So, all of those things. But they had to go in on this parallel
port so I had to develop the software on a single-board Z80, that took that
serial stream, parcelled it up into 8-bit parallel characters - exiting, you know,
in a wider buffer - ready to go, and sent them through the parallel port to either
the Omnitech, initially, but laterally the Linotype 202. You send off your eight
bits you then poll the interface and say: "Are you ready? Did you get that?" And it
comes back and says "Ready" So you're waiting all the time - is it
ready for the next character - but it worked! Now the thing for me, in that era
was, yes, you had to have a hardware person to design that interface for you.
Serial-in; Parallel-out. The thing that I thought " ... well this is
great" because I discovered I could just get away with it. I thought: "Will I have
to write that stuff in that PROM chip, which I'm going to burn, and I'll have to
do that in Assembler, somewhere, won't I, and then burn it?" No. Fortunately there was a
thing called the Whitesmith's C compiler
developed by a team at Queen Mary College, University of London, I think. And
I was delighted to have it because they had got a C to Z80 compiler but that was
running on the PDP 11/44, So it's an example of a cross-compiler.
It's not compiling code for PDP/DEC - for use on this machine. It's
compiling code for a foreign thing called a Z80 chip, which will go down a
serial line and end up being burnt onto a PROM to run in that board. And even for
relatively everyday things I was doing like: Wait for the character to come in.
Is it ready? Poll the interface. Send off the next character
Was that OK? Even for simple, routine, things like that I found it
such a relief to be able to write in C and not ... I mean, I am not Ken Thompson. We
are not talking about writing a whole Operating System but believe me just the
ability to write that simple interface and program in C, not in assembler, made
the world of difference to me. But it just made me, coming back again, reflect that
was the sort of level of effort you had to put into interfacing "foreign" kit
that didn't want to speak to each other. >> Sean: Did you have to test it on the actual
kit or did you have a simulator? >> DFB: No, I didn't have a simulator which was why I
had to explain to the Examinations Department, that had just shelled out the best
part of 35,000 pounds for the Linotype 202.
I said: "I'm sorry - and you will think this is just us taking it over - but I need
6 weeks to commission this thing I'm not Ken Thompson and Steve Marchant's
not Joe Condon ... and I don't know. No! even they took 6 weeks for their
project, which was arguably rather(!) harder than what we did. I said: "We need several
weeks to commission this". Because when we are trying its interface saying ' ... how fast
are we likely to be able to feed these characters at it' ... because it's going to
come back and say ' ... you've gotta wait for the Ready'. And the answer was ... it was
comfortingly slow! I didn't have any timing problems
to worry about. And it went 'plod' 'plod' 'plod' and by the end of '84 we really had, using the
202, typeset the complete University of Nottingham's papers - all of
them - for the very first time in-house. What then happened - perhaps to complete
the story - is that after doing that for two years even George, my consultant, said:
"Do you know - these are only exam. papers I do wonder if
people would find them acceptable to just have them done on this new 300 dpi
laser printer? Maybe people won't mind?" Most people never noticed, y'know!
It was using Times Roman, the Math symbols were there. The fact it was a bit
grainy, compared to the super-duper bromide .... Most people didn't care - that sort of
thing. And that's an example of how if you're wedded-in to a high-quality
industry, you find it incomprehensible that the great unwashed will accept a
lesser quality than you do. But, of course, that rules the world in a sense. I mean
laser-printers are more like 600 dpi now aren't they? >> Sean: So, was that switching - when you
mentioned that - that was switching to the Apple LaserWriter? >> DFB: Oh yes! It's
actually saying: "Well, we've had the Linotronic 202. Thanks Linotronic!
You were a great machine!" They still continued to use it for very high quality
jobs [e.g. books] but, frankly, for the grunt work, which was getting the exam. papers done,
people thought it was a miracle. They would cheerfully vote for lots and
lots more 300 dpi and do everything like that [rather] then wait a bit longer and get an
even smoother-looking version of an exam paper. So, I learned a lot from that
really, about what level of technology do you really need. And what your customers
really want, Even though one or two of our number might have thought it to be
- how should we say - abominable that they had such low standards. But never mind
that's what we need and that's what we use. >> Sean: It's been ... I think it's been the death of
many a specialist industry - the idea of "It's good enough". >> DFB: It's like 'every car
needs to be a Rolls Royce - customers for cars won't accept anything less'.
Until the Model T comes along and they're initially deprecated but then
quietly, people like them - saying: "Oh well! for what I use it for it's good enough, y'know".