What made the Molecular special?
At a time when most computer systems had a "use by"
date of a year to two, many Molly owners held on to their system for as long as
possible - why? Perhaps because its capabilities were aimed precisely at their
level and were wholly relevant to their requirements. People living in their
world, not in some remote corporate or academic tower had designed their
system. When their needs grew, the Molly came up with a trick or two to break
through what had previously been considered its limits.
In this environment assemblers, compilers,
"high-level" languages and all such technicalities were not an issue.
What mattered was performance. Better reliability would have helped (but this
was before the Japanese showed us what could be done, so nobody expected
perfection). It wasnít until the 1990s that Unix boxes began to match the
Molly for performance, and thereafter reliability became the issue.
LOS was designed on the principle of co-operation, both with
the Mollyís hardware and with the programmer, to produce what was wanted. In
return it was not an option to divert resources to protect programmers from
themselves (or from their colleagues). This didnít just work; it often opened
up possibilities well beyond what had originally been proposed. Of course, some
programming developments were justified as they improved productivity. Such as
the ability to load or edit a program while seated at a keyboard, rather than by
flicking it in bit by bit standing at the control panel switches.
Elsewhere in the computer industry, manufacturers were
rapidly evolving hardware to meet the perceived needs of the software
developers. These people would always want more, no matter how much you gave
them, so the industry was on to a sure thing, which continues to this day. At
BCL we wrote our programs in pencil on foolscap coding sheets. Each of these
sheets held 64 steps (instructions), and 32 sheets were needed to fill a whole
Task Partition (2K words). If you laid these out on the desk, it looked a
formidable amount of coding space (especially when you recall how much rubbing
out you did before it was finished) - who could possibly need more?
At one extreme we might cram several
little programs into one "module" and at the other a complex program
(invoicing was usually considered "complex") could span several
modules by fetching in the relevant code as required. Who could possibly need
virtual memory when managing real memory was so easy? Also, the Task Partition
had a specific layout, and we had to allow for workspace for our variables, so
that not all of the partition could be filled with code. Incidentally,
pre-defining the layout greatly reduced the amount of parameter passing between
subroutines. Several operating system services took no parameters, e.g. the
single instruction "JSBR IZ 1651" was sufficient to "spool and
post" a simple job to a print queue. Knowing where our variables were in
the partition meant that we could find them, watch them and even change them by
running the programming program from another keyboard. We could modify the very
code too, even whilst it was being executed! Others (encumbered by text editors,
compilers and linkers) could only dream of such capabilities, but we had it all!
The processorís instruction set barely changed
and neither did its speed. Memory reference instructions took 2.4 microseconds
in the 1970ís and they still took 2.4 microseconds in the 1990ís. Actually,
2.4 microseconds were pretty good for the 1970ís. Although we didnít realise
it we were already using RISC technology (albeit because the Molly never
"progressed" to micro-code).
The 1K word page-addressing scheme never changed either. It
is this aspect which stymied the development of an effective Assembler (let
alone high level language). Try it and youíll soon get into big problems!
Whilst other manufacturers implemented more flexible addressing schemes in
hardware, BCL meandered occasionally down this software dead-end.
The "Metacode" character set was an interesting
case of making full use of the seventeen-bit word format. The cube root of 217
is just over 50. This means you can pack three characters into one word if you
restrict the character set to 50, which is enough to be useful (in the 1970s
respectable computers disdained lower case lettering anyway). To pack three into
a sixteen-bit word you must restrict the set to 40 characters.
The hardware implementation of the "Greater Than"
flag deserves comment, as it chose to ignore the sign bit thereby introducing
inefficiency in software when working with signed numbers!
There are a couple of switches on the control panel that
deserve "special mention". Interrupt if MA=SW allowed us to set
a breakpoint whilst debugging a program. Alternatively, it could just as easily
catch any read or write of a program variable. I have yet to meet any modern
debugger offering this sometimes very useful service. The apparently useless (to
software) Continuous Interrupt switch found its niche as a mains-off
emulator. The real mains-off interrupt was supposed to trigger when there was
enough juice left for maybe 300 instructions (I forget the exact timing). When
it actually triggered depended on the setting of a variable resistor somewhere.
Occasionally this resistor would be wrongly set and the juice ran short, so the Continuous
Interrupt switch offered a stopgap means to switch off until it was fixed (a
job very definitely left to an engineer). In the 1970s we always advised
switching your Molly off at night: someone did leave one running on a first
floor and next morning the staff found it in the basement with their smouldering
building around it.
Even with the mains-off interrupt triggering correctly, LOS
had to keep all its interrupt handlers short in case a mains-off became pending
(it was not practical to interrupt an interrupt handler). Watching the system
pick up after a power cut was quite a thrill, so how did it work?
Remember the trouble we could have with the track alignment
on disc cartridges? To install our programs on the customerís Molly meant we
had to travel there and hope the cartridge weíd brought with us would be
readable on the customerís drive. If not, I recommended going for a walk
outdoors, taking the cartridge with you. Slapping it quickly back onto the drive
usually did the trick.
How did LOS evolve?
Well, I joined BCL in May 1975 so my story begins a little
while after that, as it took a little time to gain familiarity with the Molly
through maintaining some existing Mark I installations. C Victor (in St. Albans) was the first project we did from
scratch but it certainly wasnít LOS. Its foundation was the "BCL
Supervisor". As I recall, this was a task scheduler sitting on top of the
Mark I "firmware" with a gap in between where you could put the
application code. You were supposed to order your Supervisor from Brighton, so I
filled the form in and sent it off, visualising a hectic office despatching
reels of paper tape to new projects starting up around the country. Nothing
happened. Eventually I got the last BCL Supervisor tape ever issued, from a
surprised Peter Dale. As youíve recorded, we had to set out separate areas for
each "task", and write separate versions of code for each task that
might run it. We didnít solve that problem with C Victor, rather it drew
attention to the need to find a solution whilst we attended to other rather more
pressing matters, such as setting up a file structure instead of working with
absolute sector numbers on the discs. The 300 baud 8-line VDUs were certainly a
novelty (what on earth could that key marked "Escape" be for?), and
there was the girl at C Victor who heroically stayed at her screen through a
thunderstorm, to the admiration of her colleagues. Next came the Tate Gallery. Again this was a pre-LOS system
(though Mark Adams upgraded it at the first opportunity), but it was probably
the first place where we used "offset" addressing to run program code
in different partitions without maintaining separate versions. The
"offset" solution revealed itself in the Newcastle Arms in Nottingham
one evening. It was implemented in software by lunchtime the next day.