The Unexpected Satellite – Part 4

After several hours of discomfort for all of the crew members, the Chronos had finally reached a velocity more suitable for making contact with the stranded asteroid miner. Alan had switched the centrifuge in the main crew compartment back on, but it would take several minutes for the motors to defeat the inertia of the heavy disc that comprised that part of the spacecraft. In the meantime, the Commander and Vice-Commander traded reports about various navigational and scanning issues. The evidence was becoming clearer: There certainly was a metallic object of substantial proportions proceeding on the trajectory that the ECSA had predicted for the asteroid miner, large enough to be a spacecraft and, to the relief of all, appearing to be in one piece.

As Alan rolled up his reading screen and placed it into his pocket, Gerhard, the mathematician on board the Chronos, pulled himself out of his seat and floated over to Alan.

Is the crew compartment almost prepared?” Gerhard asked, in a German accent which Alan perceived with his paltry knowledge of German to have been tempered somewhat by years of speaking English.

Yeah, Gerhard,” Alan replied. “Just waiting for the centrifuge to spin up fully. Do you have those read-outs handy?”

Yes, yes,” Gerhard said with an air of reassurance. “They’re on my tablet.”

Right, then, Gerhard. I’ll see you in the recreational room, then?”

Gerhard raised his hand in a salute, turning towards the hatch in the centre of the room and pushing himself towards the ceiling to grip a handhold. Alan checked his wrist computer to check the rotational speed of the centrifuge, seeing that it was close to full speed, and unstrapped himself from his chair. He shouted over to Gerhard, telling him that he could pass through the hatch, then pushed himself up to the ceiling, pulling himself over to Andrew’s chair.

Andrew, by this point, was slumped over his chair in a deep slumber. Alan knew all too well the exhaustion that was inflicted on inexperienced spacecraft crew members, but there was work to be done. Gingerly, Alan pushed himself down and gently prodded Andrew in the shoulder with the toe of his boot. After a few attempts, Alan finally elicited a response as Andrew groggily shook his head and murmured some barely understandable words, “Whadda you want?”

Time to wake up,” Alan replied, “We’ve got work to do.”

After a few seconds’ pause as Andrew awkwardly fumbled with the straps of his chair, he managed to free himself and push himself out of his chair. Alan, not content to wait for Andrew to wake up properly, pulled himself towards the central hatch and plunged into the tunnel beneath him.

A couple of minutes later, he made his way back into the crew compartment and proceeded towards the recreational room. Once he arrived there, he saw Gerhard sitting at one of the tables, looking inquisitively at his tablet. As Alan opened the door, Gerhard raised his head, waved his hand and took another brief glance at his tablet while Alan found a seat on the opposite side of the table.

Where’s the computer expert?” Gerhard asked as Alan adjusted his chair.

Andrew? He’ll be down in a few moments. I just woke him up a few minutes back.”

While Alan and Gerhard waited for Andrew to arrive, they briefly discussed some of the technical details that they had arranged the meeting about. “I’d like to get as close to the asteroid miner as possible on autopilot,” Alan said. “That entry hatch looks awkward to get into, even if you’re a confident shuttle pilot.”

Well,” Gerhard replied, “we can go for a preliminary approximation here and try refining our guess when we have more information on the situation, right?”

Yeah, that sounds like a good idea. We’ll have to agree on the loadout on the shuttle here and now, though. I’ll take on some extra fuel just in case, but adding extra inertia doesn’t sound like my idea of a good time.”

Suddenly, the door slid open. Andrew stepped into the room, with a rather dishevelled look and bags around his eyes. “Sorry for keeping you,” he apologised as he sat down beside Alan.

Don’t worry about it,” replied Alan and Gerhard in unison. “Now that we’re all here, we can begin,” Alan continued once Andrew had made himself comfortable.

After some preliminary discussion of the mission profile, with some of the details reiterated for the benefit of Gerhard, Gerhard began to speak.

So, we’re basing this on a one-hundred kilometre round journey with some additional fuel for manoeuvring around the asteroid miner, correct?”

That’s correct,” Alan replied. “We’ll also have to take into consideration the mass of our payload, including myself and Andrew, my toolkit, the computer nodes and whatever other equipment and ephemera we need. Andrew, do you know off-hand how heavy each of those computer nodes are?”

I think about 10 to 12 kilograms,” Andrew replied. “The specification sheet says 11.2 kilograms, as far as I remember, but that’s for a certain standard which the ones we have on board don’t conform to.”

Well,” Alan asked, “that’ll do well enough for an approximation, won’t it, Gerhard?”

Replying in the affirmative, Gerhard proceeded to enter some preliminary data into his tablet, drawing up the framework of an equation in the process. Stopping occasionally to ask questions, Gerhard continued his work in relative silence while Alan and Andrew discussed and occasionally argued about the equipment that they would need.

Are you sure that we need to bring all thirty-six nodes at once?” Alan asked as Gerhard continued on with his calculations. “I mean, we don’t even know if the power is on in the asteroid miner, and we don’t have anywhere to put them on the other spacecraft if we need to come back to get the equipment to work on the generator over there.”

We don’t need to bring all thirty-six,” Andrew conceded, “but I will say that I’d prefer if we brought the lot in one go. It’ll save us time later in terms of going back and forth.”

Right, well, you’re bringing that equipment down to the shuttle bay then. I’m going to need to get the plasma cutter out of storage anyway.” Alan paused for a second, then continued with a sardonic undertone, “I’m pretty convinced that the power in the asteroid miner’s gone, and that we’ll have to cut our way through the doors.”

Andrew ignored him, and the room remained in silence for the next few minutes while Gerhard continued to calculate. Suddenly, Gerhard raised his head and said, “Alright, gentlemen, I have all the information I need so far. Alan, I’ll discuss this with you later. Andrew, thank you for the assistance. Good day!”

* * *

The following day saw Alan and the rest of the crew of the Chronos almost swept off their feet with work. The spacecraft was close to its objective, and the engines had been set to act at a slow but consistent rate to slow the spacecraft to a constant velocity in respect to the stranded asteroid miner. In the meantime, the crew of the Chronos were making sure that everything was in order, with Alan’s subordinates in the maintenance department taking over Alan’s duties while Alan helped to prepare the shuttle for launch.

Andrew, for his part, was providing ample assistance, quickly proceeding to place the computer components neatly into the cargo bay of the shuttle, and once Alan had managed to wrestle the plasma cutter and its large gas cylinder from the storage bay, Andrew gracefully agreed to carry down the cutting equipment while Alan lugged the gas cylinder through the narrow corridors and tunnels leading to the shuttle bay.

After a few moments of wrestling the cumbersome cylinder around door edges and corners, Alan lifted the gas cylinder up the rear-mounted ramp of the boxy, bluff-nosed shuttle and dropped it with a clatter in a corner of the rear compartment. Alan could see Commander Jackson and Vice-Commander Matthews controlling the refuelling cycle of the shuttle from a remote terminal on a raised platform, while Gerhard could be seen through the door leading to the cockpit, programming the flight plan into the shuttle’s computers.

Resting for a moment against one of the side walls of the shuttle, Alan briefly considered the upcoming shuttle flight. The one-hundred kilometre distance between the Chronos and the asteroid miner wasn’t far off touching distance in interplanetary distances, but was a bit further in terms of the shuttle he would be flying. Most of the distance would be covered under the control of Gerhard’s flight program, with Alan and Andrew just passengers until the end. It was the final five hundred metres to a kilometre that Alan had to fly, and the most potentially fraught with danger.

Almost as soon as Alan had returned to work, carefully strapping the gas cylinder to the side of the spacecraft with an aluminium chain passed through a set of wall-mounted loops, the doors of the shuttle bay opened. Alan looked over his shoulder and saw Andrew walking in, arms filled with the box with the plasma cutter equipment.

Hey Alan, where should I leave this?”, Andrew shouted as he continued towards the shuttle ramp.

On the ground here, beside the wall,” Alan replied loudly. “Don’t worry about being exact – I’ll secure it to the shuttle while you get the computer components.”

Once Andrew had ascended the ramp and placed the equipment box onto the ground, Alan started dragging it over to the wall, where he began feeding another chain through the handles and wrapping it around a few loops on the wall. As Andrew was walking down the ramp, Alan suddenly called out, “Hey, Andrew, have you got a container for those computers, something I can secure to the wall?”

Uhh… no,” Andrew replied. “I still don’t get why you need to fix everything to the wall anyway.”

Keeps everything from being thrown about during acceleration, of course,” Alan replied. “There should be some appropriate boxes in the storage area – go for the lighter plastic ones. Don’t want to add more weight to the equation.”

Advertisements

Historical Operating Systems Reborn – RISC OS and the Raspberry Pi

The early-1980s 8-bit microcomputer battle brought the personal computer from a hobbyist’s plaything to a genuinely useful device for general use, and was fought by a host of companies. Most of these companies were from the United States, such as Commodore, IBM, Apple and Atari, but various British companies played a significant part including Sinclair, Amstrad and Acorn. By the mid-1980s, many of the smaller competitors had fallen by the wayside, and even the once-strong Sinclair Research had been bought up by Amstrad.

The big players who remained decided to produce more powerful machines using newer processors than the MOS 6502 and Zilog Z80 8-bit processors common in the early 1980s. Commodore bought up the Amiga Corporation, which had designed an eponymous computer; Apple designed the Macintosh; Atari developed the Atari ST and IBM continued to develop on their IBM PC platform. Most of these computer designs, with the notable exception of the IBM PC, were based around the Motorola 68000 processor. As Amstrad decided to focus on their PCW series of word processors, discontinuing the disappointing Sinclair QL, this left Acorn alone in the British market to try to fight out the battle of the post-8-bit era.

Acorn decided to take a different approach to the American companies, focusing on the educational segment rather than the business, desktop publishing and multimedia markets focused on by Commodore, Apple, Atari and IBM. Instead of using the Motorola 68000 processor familiar to other computers of the time, Acorn decided to design their own processor, using the then-novel RISC architectural design to develop the Acorn RISC Machine processor, better known as ARM.

In 1987, Acorn released the Archimedes. The ARM2 processor which Acorn used proved to be a great advantage for the Archimedes, with a simple, power-efficient design which nevertheless performed calculations about twice as quickly as a 68000 processor with the same clock speed. Allied to the ARM processor was Acorn’s Arthur operating system, which came on a ROM chip similar to the Amiga’s Kickstart ROM. Arthur, on balance, was on par or not far behind the Commodore Amiga’s notoriously advanced OS, and ahead of the single-tasking operating systems used by Atari and IBM.

AcornArchimedes-Wiki

The Acorn Archimedes – one of the several advanced computers of the late 1980s.

Unfortunately for Acorn, the Archimedes was not a particular sales success. Its focus on the educational market had come at the cost of the multimedia coprocessors available in the Amiga and Atari ST, leading to a system that was too expensive and not good enough at gaming for a home audience. Meanwhile, the business market became consumed by IBM and the various clones which arose from the easily-reverse-engineered BIOS of the IBM PC and its successors. Nevertheless, Acorn persisted and continued to develop new machines with more advanced operating systems. Arthur was updated, becoming RISC OS in the process, keeping to the same general structure but gaining new features.

Eventually, Acorn fell to the wayside, suffering a similar ignominious fate to Commodore and Atari as the personal computer market gradually became dominated by IBM-compatible computers with Intel processors. Apple managed to cling onto life during some very slim years, moving to the PowerPC architecture along the way, but eventually gave in and took up the Intel x86 processors as well, moving their BSD-derived Mac OS X operating system over to the new architecture.

Acorn has had one significant lasting legacy, however – the intellectual properties for the ARM processor were divested in a new company, ARM Holdings, who collaborated with Apple to continue developing the ARM architecture for Apple’s own devices. Today, the ARM processor is the most popular 32-bit processor architecture in the world, underpinning everything from smartphones and tablets to embedded processors inside other devices.

RISC OS has survived as well, with the intellectual property for the Acorn computers sold to Castle Technology Ltd., a small British company who has continued to develop ARM-based personal computers using RISC OS. A small but dedicated community grew up around the company, much like the remnants of the Amiga or Atari ST communities, and has continued to support the OS.

Now, we have the Raspberry Pi. The inexpensive, credit-card-sized computer has been a massive success, demonstrating a far more simple, hackable approach to computing than has been usual today. Something that has been a pleasant surprise is how readily the RISC OS community has decided to support the Raspberry Pi.

Given that until recently, I haven’t had a computer without an Intel processor, I didn’t have an opportunity to try RISC OS on anything but an emulator. However, I sometimes despair for the sheer homogeneity of the personal computer market, even though I have contributed to it for many years. Now, I have been granted a chance to try an operating system natively on modern hardware that isn’t part of the Microsoft Windows, Mac OS X or Linux families.

My initial thoughts when I first booted up RISC OS 5 were that it actually boots up as astoundingly quickly as others said it would. Frankly, this shouldn’t have been a surprise; not only is RISC OS still designed with the StrongARM processors of the Acorn Risc PC in mind, it is still developed for a 6MB ROM chip, and is therefore extraordinarily tuned for its environment. I had used RISC OS before on the ArcEm emulator about four years ago, so I recognised that RISC OS was slim and fast in the early 1990s, but it’s nice to see that this behaviour persists today. The same sort of responsiveness applies to the shutdown process as well. RISC OS has instant shutdowns. None of this behaviour where shutdowns can take almost as long as the boot process – as soon as you click the Shutdown option, short of certain file operations being in progress, the computer will immediately be ready to shut down.

After about ten to fifteen seconds, the GUI environment booted up. Two things were quickly apparent. The first is that the environment was immediately responsive as soon as it had finished loading, unlike contemporary Windows or Linux desktop environments, which, based on the number of background processes that are set to start – can leave you waiting a minute or more for full responsiveness.

The second thing is that the RISC OS GUI environment is, in fact, very pretty. Mac OS X and iOS are often held up as being the exemplars of pretty environments, but I’d argue that RISC OS is, in its own ways, marginally prettier. Much of what Mac OS X does to ensure its pretty environment is down to impressive, shiny graphics and high-resolution displays, whereas RISC OS manages to look good at 640×480 on a simple non-high-definition television screen.

A lot of this is down to the inherent design philosophy of RISC OS. The original Arthur OS for the Archimedes was the first operating system to incorporate a dock, or in RISC OS parlance, an icon bar. The icon bar distinguishes between application icons, set to the right-hand side of the icon bar, and storage devices, set to the left-hand side of the bar. This helps to create a distinct divide between applications and devices which store applications and data. In comparison, the Mac OS X dock can occasionally look a bit untidy and busy when you load up too many applications at once.

Another detail in RISC OS’s favour in the design stakes is the high-quality anti-aliasing technology that has been a part of the operating system since 1989. The renderer is designed, as are some of the more recently designed competing technologies available in other operating systems, to render type accurately at the cost of readability, but frankly, even at the 640×480 resolution I have been using, the typefaces still look clean and legible, which helps make the interface look clean and stylish.

screen_20121126_1s

RISC OS – stylish even at low resolutions, even better in high definition.

Enough about the style – how about the substance? It turns out that you get quite a few things even from your 6MB ROM image, including the full GUI environment, a text editor, a vector graphics program, a simple scientific calculator and a BBC BASIC interpreter.

Of course, it seems awfully odd and antediluvian to be supporting a BASIC interpreter in 2013, but BBC BASIC was one of the most sophisticated BASIC interpreters of its time and was extended with its move to RISC OS with capacity to write full, multitasking GUI applications. BBC BASIC is also one of the most optimised and rapid interpreted languages on any platform, proving sufficiently quick for the entire Arthur GUI interface to be written in it. The interpreter also includes capacity for inline ARM assembly language, providing a low-level programming environment inherent to the system. Few other operating systems actually have any inherent capacity for programming, and while Linux, Mac OS X and other Unix and Unix-like operating systems typically have programmability through their command shell, this isn’t going to fit in 6MB along with a GUI environment.

Unfortunately, when it comes to other applications, RISC OS currently looks a bit sparse. Given that the operating system has been maintained by a single, small company and kept alive mainly by hobbyists, this is to be expected, but you’re certainly not going to have the wealth of software that you have on Linux or Mac OS X, let alone Windows. This may improve if the community grows with the popularity of the Raspberry Pi, but it will prove difficult to use RISC OS for most serious work right now.

From a technical perspective, RISC OS is a very different beast to the three most popular desktop operating systems. Microsoft Windows comes from a lineage that incorporates elements of CP/M, OpenVMS and so on, while Mac OS X and Linux are obviously derived from Unix. RISC OS doesn’t derive from either lineage – or from any other apparent one either. Directory paths are delineated by full stops rather than slashes, for instance. Disc formatting uses the proprietary ADFS system first developed for the BBC Micro. Files don’t have extensions as default, with the file type determined by a six-byte file type number stored separately, and when extensions are used, perhaps from imported files from another operating system, the extension is delineated from the name by a forward slash.

One of the most distinctive details of RISC OS is how it deals with applications. Application names always begin with an exclamation mark, and RISC OS applications more closely represent directories in other operating systems than they do the executable files of Windows or Linux. In fact, RISC OS applications are extraordinarily modular in nature – you never have to “install” an application on RISC OS as you would in Windows, and you can just drag an application icon onto the icon bar to open it.

Another particularly distinctive detail of RISC OS comes from the way it handles the mouse. Acorn designed the Archimedes with a three-button mouse from the very start, and each of the buttons on the mouse have very individual functions. Unlike Windows, Mac OS X or Linux – or most other desktop GUI systems – RISC OS has a separate Menu button set to the middle button, and therefore, applications are not expected to have a program-specific menu bar, or a Ribbon interface or anything like that. The middle button performs menu tasks in every application, including the ones normally done by the right mouse button in Windows or Linux.

The other two button functions are Select, set to the left mouse button and performing tasks similar to the left mouse button in other desktop operating systems, and Adjust, set to the right mouse button. Adjust performs various functions, ranging from an alternate way to perform various tasks in most programs to an alternate menu for some application icons.

There are some places where RISC OS betrays its Eighties origin, though, and not necessarily in a good way. RISC OS uses cooperative multitasking rather than the pre-emptive multitasking common in operating systems from Unix to Microsoft Windows to AmigaOS and others besides. I have, in the past, been quite disparaging about the use of cooperative multitasking in any operating system, including RISC OS, and using RISC OS, it’s clear that it is an underlying disadvantage of the system.

I’m quite fond of pushing my systems to the limit when it comes to multitasking – it’s common for me to have a web browser, a word processor, a music player, a PDF reader and the file manager for my operating system all open at one time, with other tasks perhaps happening in the background. With a pre-emptive multitasking system, the programs are given a fair share of the computer’s free time, only occasionally locking up because one task is a bit too greedy with the clock cycles. With a cooperative multitasking system, it’s more difficult to run multiple applications at once, since one program that is badly designed or simply resource-heavy can lock up the system until it resolves. Using RISC OS for multimedia applications at the same time as performing a processor-heavy task is therefore a potential no-go area, which is a pity considering how smoothly the system runs on a single task.

Mostly, though, I like how different RISC OS 5 feels to other contemporary operating systems. Certain technical details, such as the obsolete cooperative multitasking model, make it difficult to recommend for everyday use right now, while the relative lack of applications also works against it. However, being allied to the Raspberry Pi could well give RISC OS a renewed lease of life, especially in the educational sector where it would be perfect for demonstrating that not every operating system is, or even has to be, the same as Windows or Mac OS X. In that sense, the OS could come full circle – from its educational roots right back around to them again.