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 2¹⁷ 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.

Joe Templeman