The Tornado operating system

by N. Douglas (ndouglas@digibank.demon.co.uk)

This is the alternative second edition of the guide to the tornado operating
system. It attempts to cover most facets of tornado from an average users
perspective, while being still detailed enough for a programmer to not find
it boring :-).

For the uninitiated, the tornado operating system runs under another
operating system, RISC-OS. This operating system comes with the range of
computers running on the Arm series of CPU's made since the Acorn A3000.
Older machines using the Arm CPU can also run RISC-OS, so long as the
propriatary hardware (MEMC1a, VIDC etc) is also available and is arranged
similarly to the archimedes series - also, any hardware compatible with the
original archimedes design should have no problems.

Problems with RISC-OS:
----------------------

While RISC-OS was originally constructed during the late eighties, it still
compares quite well to the latest operating systems from Microsoft, IBM and
Apple. However, it's age does show in many areas, and the only reason why it
can still be considered alongside other operating systems is because of
original design strengths in the original release.

Advantages of RISC-OS over other operating systems:

  * Extensive drag & drop facilities. RISC-OS allows dragging and dropping
from almost everywhere to everywhere else on the screen. This increases
intuitivity incredibly, but *only* when it's used to its full effect. Often
it isn't.

  * The ability of a program to assume complete control of the processor. In
multitasking operating systems, RISC-OS assumes the dubious status as the
only one to use non-preemptive multitasking. The great advantage of this is
the ability for a program to hog the processor and use all its power.

  * No application has control or precedence over others. This means you can
select a group of objects in a window belonging to another program currently
behind windows belonging to yet another program. While that might sound
complicated, System 7 shows how irritating not having this can be. You can be
working on something, and want to copy a file. Selecting a file in the
Finders window behind the main window brings all the Finders windows to the
front and now you can't see the main work window anymore.
   A similar problem exists will Windows 95 - except that each filer window
is its own task, so clicking in it only brings one window to the foreground.
But still it shows that the application that the user is working with has
precedence over any others.
   This also shows in dragging and dropping. In RISC-OS you can drag a file
out of one program into another. No other operating system allows *that* type
of flexibility and power.


Advantages of other operating systems over RISC-OS:

  * Multitasking on other systems is far more fluid and consistant. On
RISC-OS, multitasking seems a very 'bodged' affair indeed - things like
printing, or even disc i/o don't multitask [1]. If you get programs to do a
lot of processing, RISC-OS slows down incredibly. Multitasking on a heavily
loaded RISC-OS desktop is like watching a demo run at 12fps.

  * All tasks on RISC-OS are equal. This means that as far as RISC-OS is
concerned all tasks get equal processor time, and no task may get more than
another. This prevents an important process from getting more time so that
it gets completed quicker.

  * Tasks on RISC-OS take as much processor time as they want. There is
nothing to stop them giving up control every second. If every task on RISC-OS
did that, RISC-OS quickly becomes unusable.
   On other systems, a central multitasker handles how much time each task
gets. This allows the multitasker to give less or more time to each task
depending on circumstances.

  * Writing programs to run under RISC-OS is a real chore. While the
interface to the desktop is very flexible, it is also very manual, with each
task doing an awful lot of work for very little initial gain.

  * Programs not written to multitask on RISC-OS can't be made to. In other
words, run a single-tasking program and it will hog the machine until it
decides to finish. With many programs, you can't interrupt it without having
to start it up all over again.

  * Programs which crash on RISC-OS aren't handled well. Currently, when a
program tries to access memory not available to it a box appears saying at
best 'Fatal error ...' and multitasking stops until the user acknowledges
the message. On Windows 95, if a program crashes to the extent multitasking
stops, you can hit a hotkey and windows will ask you if you want to terminate
it. Or if you wait long enough, this happens automatically.

  * External access isn't handled well. RISC-OS contains no standard
provisions for network access [2], and to use the serial or parallel port is
fiendishly complicated.

  * RISC-OS does not adapt to its situations. RISC-OS fundamentally is still
designed to work well on an Arm2 TV standard resolution 512k machine. Running
it on an Arm700 series XGA+ 256Mb machine does not give huge improvements.
Nor does plugging in a SCSI card automatically cause it to be registered and
usuable. You have to go through a whole range of programs first.

  * RISC-OS has a very limited method of managing memory. The shared resource
of the RMA gets badly fragmented, leading to huge quantities of memory being
wasted after extended use. Data up to memory available can normally only be
edited, as RISC-OS does not provide virtual memory of any kind. These
restrictions cripple programs running under RISC-OS.

  * The facilities offered by RISC-OS to its programs are mediochre. They
never were great - in my mind never finished - but little things like OLE,
external editing of files, hotlinking, multiple views in different
applications, standardised scrap filing etc really detract from the power of
RISC-OS.
   Also, there is no standard method of making code multithreading. You can't
have a spreadsheet in one window recalculate while you work on another in
another window in the same program without a lot of hacking on the
programmer's part. Very few programs offer this, and quite rightly too.

  * RISC-OS does not provide help for users. Compared to Windows 95, where
things are stepped through bit by bit by detailed hypertexted documents,
RISC-OS just displays a message up to 256 characters in a window.

  * Filetypes are incompatible. Trying to load a GIF into Paint usually won't
work, unless you run it through an intermediate program to convert it first.
RISC-OS is extremely inflexible in this area - add to the above, neither will
it display unknown file formats in their native format. This means costly
amounts of memory being used to view a compressed filetype.

  * A lot of the RISC-OS window manager has become obsolete. Things like window definition blocks specify a whole amount of information which it nowadays totally useless. This in turn has led to a very bodged 'pretty' effect on the RISC-OS desktop, and things get very messy.

  * RISC-OS does not offer superior compression facilities, and neither is it
particularly future-proofed. RISC-OS 3 offers Squash, a facility difficult to
use and can only use LZW compression, which compresses badly on many formats
(eg; sound). This relates to the point above in the way that a program can't
play an MPEG or Replay without using one of a dozen propriatary methods.
   RISC-OS still uses a combination of 'magic numbers' and RGB to specify colours, and so the latest machines facilities aren't used to the fullest. This relates to how RISC-OS doesn't expand to the machine it's living in.

[1] when I say disc i/o doesn't multitask, I refer to all disc i/o. Things
like file copying and formatting multitask due to the revised filing system
on RO3+, but simple loads and saves don't.

[2] I discount Econet here in this statement. Acorn's propriatary Econet was
very clever - but by the time the Archimedes series was established it was
woefully outdated. Newer versions of RISC-OS do contain Acorn's TCPIP stack,
but the way it integrates into the environment is shoddy at best. Something
coming closer to Window 95's method is a better idea.


As you can see, the list of cons far outweighs the list of pros. And note
nothing has changed much since RISC-OS 2. RISC-OS 3 added a large number of
extensions to the original RISC-OS, but a lot of these have since been
replaced with third-party extensions. In some people's minds, RISC-OS 2 never
got finished.

The future:
-----------
   So how does this affect everyone in the future? Well, more than likely
Acorn will adopt a propriatary multiprocessor system based loosely around
TAOS, and will rewrite RISC-OS to run on it [3]. This RISC-OS that we see may
be considerably different to the one we know today.
   For a start, it probably will implement mulittasking in the kernel, and
the GUI will be shifted into assemblation with the kernel, like Fileswitch.
In fact, a lot of RISC-OS may be changed to function like other operating
systems, probably based a lot on Unix. More than likely life will be
considerably different.

[3] I base this on that Acorn are unlikely to develop a completely new
operating system completely incompatible with existing RISC-OS programs. I
would suggest they'll bung a dozen Arm's together and rewrite RISC-OS to use
the multiprocessor facilites. Meanwhile, old programs can still run correctly
by being only executed on one processor. In other words, only new programs
would fully exploit the multiprocessing latitude.

But we're not here to talk about the future of RISC-OS - or are we? In many
ways, what tornado implements is what the future RISC-OS's will have - in one
form or another, because tornado should still be able to run on a
multiprocessing machine just like existing programs.

Probably the best way to show how tornado is going to do this is to comment
on that long list of pros and cons I gave above. Keep reading - but please
feel free to skip anything you don't understand completely.

The advantages of tornado:
--------------------------

Extensive drag & drop facilites ...
   Tornado preserves that, and also automates a lot of it through its visual
editor. It also adds standard facilities for OLE, hotlinking, external
editing and multiple viewing. All these, shared amongst all programs, makes
the desktop considerably more powerful.
   Another minor fact is that any files loaded into or being edited by a
tornado application are in actual fact owned and managed by tornado, not the
application. This allows tornado to share files between tasks, or to save
files out when an application crashes. The amount of usability gained by this
single addition is incredible.

The ability of a program to assume complete control of the processor ...
   Also preserved by tornado programs informing tornado when they're going to
do this. This allows tornado to start preempting them, or if suddenly polling
stops without tornado being informed tornado can start up the crash handlers.

No application has control or precedence over others ...
   Under tornado, an program can be given more time easily [4].

Multitasking on other systems is far more fluid and consistant ...
   Under tornado, all programs are preempted under the tornado multitasker,
which runs alongside the RISC-OS multitasker, the window manager. To decribe
how the tornado multitasker is outside the scope of this document (but there
is more information at [4]), but be assured that it intelligently uses a
combination of preemptive and non preemptive multitasking and multithreading
to vastly improve program performance.
   One of tornado's main aims to to improve multitasking. Printing and *all*
disc i/o under tornado multitasks [5] and subtasking is available to have
heavy processing done by tornado and not by your task [6]. An incredible
difference shows when programs are written properly - the desktop becomes
fluid, and tasking does not halt momentarily.
   Also, I'll just mention that while tornado programs run entirely under
their own multitasker, and do not use the Wimp whatsoever, tornado uses the
Wimp to put tornado windows alongside Wimp ones, allowing partial interaction
of the two systems as far as the Wimp can be made to go. Note also that
tornado redraws its own windows, including frames, and these different window
frames posess quite a few additions to make life easier, like an iconise
button [7].

 All tasks on RISC-OS are equal ...
   Well, they aren't on tornado! :-)

Tasks on RISC-OS take as much processor time as they want ...
   Again, under tornado they get given what tornado gives them. They may ask
for full processor control, and while they may get it they also may not.
Either way, the task will not know if it is still being multitasked.

Writing programs to run under RISC-OS is a real chore ...
   Tornado runs programs written in a 'visual' manner. While programmers can
do this manually, it is even more work than the RISC-OS method - far better
is to get the tornado visual editor [8], which allows combination of C,
assembler and Basic in one program. To write a program visually, you create a
window template frame. To this frame you create windows, and in the windows
you create icons. To the icons you then attach sections of code in C,
assembler or Basic. You can also attach code to user-defined tickers & timers
and events, or attach code to windows themselves. By the way, when I say
'attach' I mean it very literally - you actually drag a tool/link etc from
the toolbox/linkbox etc onto an icon/window.
   You then can save the executable, which amalgamates all the code into the
various files and saves the entire lot as a directory. This approach to
programming makes writing multitasking code so easy and quick.

Programs not written to multitask on RISC-OS can't be made to ...
   Under tornado, when you hit f12 a window opens on the screen with the
*-prompt in it. When you double-click on a Basic program, a window opens and
the program gets executed in it. Or if you wish, the program can take over
the machine like it used to - but if you want to visit the desktop, hitting a
hotkey will bring you there, while the program continues to multitask on its
own. Another option available is for the program to take over the screen and
sound, but multitasking continues in the background. This allows multitasking
servers eg; fax servers to continue to work, but still allow you to see the
program's display in its entirity. Note that only programs that are enabled
to do so will multitask during full-screen operation - so a word processor
for example wouldn't multitask if you didn't want it to - leaving more
processing power available for the full-screened task [9].

Programs which crash on RISC-OS aren't handled well ...
   When a program crashes, for whatever reason, polling is suspended on that
task and a window appears and asks the user what he/she wants to do about it.
The user may choose to continue regardless, or save out the files currently
being edited by the program and then force an exit.
   This also applies when an application decides to depart without telling
anyone. Whatever files loaded into that application can be retreived. Or, if
you want, when an application shuts down due to an error, its files can be
saved out and a new copy of the application loaded in and the same files
reloaded back into it. And all this happens in the background, while
everything multitasks along nicely ...

External access isn't handled well ...
   On tornado, a number of device drivers exist. Quite simply, tserial:
refers to the serial port, tparallel: refers to the parallel port
[THIS WILL BE FILLED IN LATER AS AND WHEN THE DETAILS ARE FINALISED]

RISC-OS does not adapt well to its situations ...
   Unlike RISC-OS, tornado uses its advanced memory management facilities to
make full use of any memory available to it. It also uses any disc space you
have for virtual memory (and note only whatever shouldn't go into RAM goes on
the disc, thus losing you the disadvantage of other system's swap files which
must be a multiple of RAM size etc). Tornado uses the 24 bit RGB method to
describe colours in all cases. For higher spec machines, tornado will
calculate and render appropriately scaled down sprites and icons for the
current palette/screen mode. On the other hand, if you have a low powered
machine but a large fast hard disc, tornado will cache any rendered
sprites/icons on disc, with a secondary cache in memory, thus not hacking out
more CPU power than is necessary.
   Unlike RISC-OS, the tornado system heap can be any size up to machine RAM
size (the RMA has a limit of 4Mb); applications can have a slot of anything
up to machine RAM size too (RISC-OS limits this to 16Mb); both of the low and
high resolutions tornado shared sprite and icon pools can be up to machine
RAM size too.
   Also, under tornado, when you open the top and plug a SCSI interface card
in, it automatically is installed and becomes immediately available for use.
No more twiddling with configurations, although this still can be done if you
really want!
   Now, whether you own the latest RiscPC 700 series or a lowly Arm2 A310,
you will have a system than runs appropriately to your computer's available
resources.

RISC-OS has a very limited method of managing memory ...
   Tornado implements a vastly enhanced memory managment system, which is
available for all programs to use. It allows private heaps, RMA heaps, heaps
in heaps, postslot heaps and of course it manages the tornado system heap, as
well as the task and sprite pools.
   Tornado's heap manager provides autogarbaging, autoextending,
autopositioning heaps. You can allocate a fixed block or relocatable block
from them. Relocatable blocks can and will move without your knowledge - but
your handle, a negative number, remains constant at all times. Also, you can
get a relocatable block from a heap in a relocatable block in a heap in a
relocatable block in a heap. And if that bottom heap is too small, it will
extend any or all of the heaps above it to fit that block in.
   And of course, one of the best advantages of this is that blocks allocated
from the tornado system heap can be of almost any length, even beyond machine
RAM length [10].

The facilities offered by RISC-OS to its programs are mediochre ...
   As mentioned above, tornado provides visual editing, allowing programs to
be generated in very short times. A large library of code is provided via
SWIs and example code fragments in external libraries to interface with
tornado. Talking to other computers is no longer so horrible: the tft: device
allows file transfers to other computers, thus saving your program of
worrying about how it's being done eg; zmodem or TCPIP ftp?
[MORE WILL BE ADDED HERE AS AND WHEN THE DETAILS ARE FINALISED]

RISC-OS does not provide help for users ...
   Tornado provides two levels of help. The first pops up a message saying
where in the manual you should look (this is recommended). The second level
provides a hypertextualised document reading system which allows automation
of many complex configurations by filling in default values. At all times,
all of this help text may be partially or wholly installed or deinstalled:
ie; when using a program for the first time the help texts would be
installed. When you know it well enough, or if you have asked for a default
expiry time (say three weeks), the texts can be removed, thus returning disc
space.
   Or, if you still use a floppy machine (or have no HD space left!), the
help can be left out. This prevents what has happened on Windows, where half
of the HD is full or help texts you don't need anymore.
   Note also that you may choose to have the help texts archived - this saves
50% of the space needed while only delaying retrieval by a small bit.

Filetypes are incompatible ...
   Dragging a GIF file into a tornado program which can only understand
Sprites starts up one of a set of specialised subtasks, which convert the GIF
into a sprite, and when saved will convert it back again. Also, tornado
provides renderers, which will render files in their native format for the
application. It will be up to the application to edit the file though -
however, this still allows DTP programs to display files in their original
format without worrying what they are.

A lot of the RISC-OS window manager has become obsolete ...
   Tornado uses future-proofed formats. It has no limit of any lists it uses
internally, and uses 24 bit colour wherever it can. Defining a window in
tornado is a short block of data, although using the visual editor will save
you of ever needing to worry about those things.

RISC-OS does not offer superior compression facilities ...
   Internally, tornado uses compression in many places eg; in many of its
internal file formats and on the virtual memory cache, as data can be
decompressed on the fly while being read in. Tornado's file renderers can
also render movies and sound - this opens MPEG's and JPEG's to everyone's
view. Tornado on request can compress everything saved out (thus resulting in
a similar effect to DOS 6's DoubleSpace or whatever), or whatever it really
wants.

[4] In reality, it will be given a percentage of available CPU power.
'Available power' means the amount of processor bandwidth left over after
system processes are performed. System processes include disc i/o, printing,
serial i/o, all subtasks and maintance of them, and anything performed by
tornado. Therefore, a fully loaded system would have all the application's
percentages add up to 100%. A system running into overprocessing would have
percentages exceed 100%. Usually tornado manages what percentages of power
each application gets, and it's only when the user overrides tornado can
overprocessing happen.
   However, on a less powerful system (Arm250=<), overprocessing could happen
if system processes exceed the CPU power available. This would result in
non-system tasks not being multitasked at all until the overprocessing
ceased, or if the user has configured it then system tasks are denoted in
priority so they are treated as normal tasks. This would mean that system
processes may fall behind, but still relatively normal system operation would
be maintained.

[5] Note that depending on the media being accessed, disc i/o may single-task
for efficiency reasons eg; Loading in a file from a 1770 based floppy while
multitasking is incredibly slow, so it would probably be single-tasked.
Tornado is intelligent in this regard, and it adjusts its access parameters
(amount loaded in a cycle, time between accesses etc) on the fly while the
file is loaded. Then it may cache the values for use later on either in
memory or permanently on disc.

[6] The only essential differences between subtasked code and normal code are
that subtasked code is executed at a higher priority, and that multithreading
your code is much easier with subtasks (and multithreading Basic MUST be done
via subtasks). However, on later hardware, tornado may execute subtasked code
on an external processor - thus allowing massive speed gains. For these
reasons, it is suggested writers use subtasks as much as possible.

[7] Tornado windows are rendered entirely by tornado. They are integrated in
the RISC-OS Wimp environment by creating a Wimp window with no icons, title
or even frame (it's made transparent). Then tornado handles dragging,
resizing etc of the wimp frame according to what's being done to the tornado
window contents.

[8] Note that only a very basic editor will be supplied in the Tornado
programmers pack. A much much extended editor will be available for the sum
of 50 from the Tornado software group. This is because it is assumed most PD
writers will want to do it the hard way anyway, and commercial writers by
right should pay someone for all our hard work!!! (since they have the
money!) :-)

[9] Note this may have difficulties with single-tasking programs which do not
use the vdu calls ie; almost all games. Therefore, there is an option to halt
tasking on programs like this ie; - not to mulitask them when you have exited
temporarily to the desktop.

[10] Some have expressed concern why we haven't done full virtual memory,
whereby code can run in virtually paged space as well as having data reside
there. The reason is that RISC-OS obstinantly refuses to allow this with some
hacking (a la !Virtual), and anyway I personally have objections to providing
virtual memory for code. Data no problem - you can edit large files - but
code, well I don't like the idea. And hey, it's my OS, so I can do what I
like! :-)




Other things provided by tornado:
---------------------------------
   Many would argue that tornado has wonderful features and all, but what use
it is to anyone unless there are programs written to use it? Well, there is
another aspect of tornado: the patching.
   Tornado patches itself into much of RISC-OS to implement multitasking disc
i/o, better crash handling etc. Little things. There is not much that can be
really done under the current implementation of the window manager, but what
can be done is.

I would think that when writers get a hold of the visual editor, tornado will
soar off, simply because that in comparison to RISC-OS, there simply is
nothing like it. ResEd is very clever and all, but it simply can't bypass the
inherent restrictions the Wimp places on tasks running under it. And it
doesn't allow Basic to be used in code, and as the amount of programs out
there that are written in this language show, they is still quite a bunch of
people who want to use it.



More information:
-----------------
   More information is available at micros.hensa.ac.uk (find by doing a
search for 'tornado' in the acorn section), the demon shadow of hensa, or the
imperial mirror. Also, most of the larger Acorn BBS's will have a copy, or
have access to one.

If there is no other option, or you have some clever insight you'd like to
share with the programmers, I'm available at ndouglas@digibank.demon.co.uk,
or Riscnet#7:363/101.0 - whatever suits.

Thanks for taking the time to read this,
Niall Douglas, tornado developers team.
