AmigaOS

AmigaOS is the default native operating system of the Amiga personal computer. On top of a basic kernel called Exec, it includes an abstraction of the Amiga's unique hardware, a disk operating system called AmigaDOS, a windowing system called Intuition and a graphical user interface called Workbench.

Components of AmigaOS
AmigaOS can be divided into two parts: the Kickstart (ROM) and Workbench disks. It used to be the case that versions of Kickstart and Workbench were released together, for use with each other. From Workbench 3.5 onwards, the first release after Commodore International stopped development, AmigaOS has become software-only, standardising on Kickstart version 3.1 in ROM.


Kickstart

The image shown by Amiga OS 1.x on start-up, asking the user to insert the kickstart disk.Kickstart is the name given to the bootstrap ROM. On the first Amiga model, the A1000, this was loaded from disk into a special section of memory called the writable control store (WCS), although eventually the Kickstart was embedded in a ROM chip inside the computer. The Amiga 1000 could be modified to take these chips, and subsequent Amiga models all used ROM chips.

Kickstart contained the code needed to boot the standard Amiga hardware and any Autoconfig expansion hardware. The Kickstart also contained many stock parts of the Amiga's operating system, such as Exec, Intuition and the core of AmigaDOS. This meant that a powered-on Amiga already had a lot of the essential parts of the operating system available. Later versions of the Kickstart contained drivers for IDE and SCSI controllers, PCMCIA ports and various other hardware that came built into Amigas. It can be compared to the BIOS plus the main Windows kernel in IBM PCs, however it has far more functionality available at boot time - the full windowing environment, for example.

With third party software, it is possible to have a different Kickstart loaded in RAM and to use it instead of the ROM one - for example Kickstart 1.3 may be loaded in order to run old games incompatible with Kickstart 2.0 and higher. These programs are called softkickers. There are also hardware Kickstart switchers which allow you to have more than one set of Kickstart chips inside the computer, which are selectable either by a switch or a keyboard shortcut when you first turn the machine on.

MMU-enabled Amigas typically loaded a copy of kickstart from a file on disk and passed control to it at cold-boot time. Subsequent warm-boots would reuse the already-loaded copy of kickstart, reducing boot time. An Amiga 3000 could fully warm-boot in 7 seconds; cold-boot in 11 seconds.


Workbench
Main article: Workbench (AmigaOS)
Workbench is the name given to both the core operating system software that is not stored in the Kickstart ROM (the "Workbench disk"), and also the native graphical shell for the Amiga computer. The Workbench environment does not have to be loaded for software to run. In fact, to take over the Amiga hardware and keep all memory and resources to themselves, many games boot directly from Kickstart (using a custom bootblock on the floppy disk).

As the name suggests, the metaphor of a workbench is used, rather than a desktop; directories are depicted as drawers, executable files are tools, data files are projects and GUI widgets are gadgets. In many other aspects the interface resembles Mac OS, with the main desktop showing icons of inserted disks and hard drive partitions, and a single menu bar at the top of every screen. Unlike the Macintosh, the standard Amiga mouse has two buttons – the right mouse button operates the pull-down menus, with a Macintosh-style "release to select" mechanism.

A unique feature of Workbench is multiple screens. These are conceptually similar to X Window System virtual desktops or workspaces, but are generated dynamically by application programs as necessary. Each screen can have a different resolution and colour depth. A gadget in the top-right corner of the screen allows screens to be cycled - as the OS stores all screens in memory simultaneously, redrawing is instantaneous. Screens can also be dragged up and down by their title bars. On older Amigas this functionality was provided by the custom chipsets specially designed for the platform, but since AmigaOS4 a new technique is adopted and the screens are draggable in any direction. Drag and drop between different screens is possible too.

Underlying the Workbench is the Intuition windowing system. This controls and draws screens, windows and gadgets, and handles input from the keyboard and mouse, passing messages to programs.


Workbench 2.0 user interface improvements
Until Workbench 2.0, there was no unified look and feel design standard - application developers had to write their own widgets (both buttons and menus), with Intuition providing minimal support. With Workbench 2.0 came gadtools.library, which provided standard widget sets, and the Amiga User Interface Style Guide, which explained how applications should be laid out for consistency.

Workbench 2.0 also added support for public screens. Instead of the Workbench screen being the only shareable screen, applications could create their own named screens to share with other applications.

Workbench 2.0 introduced AmigaGuide, a simple text-only hypertext markup scheme and browser, for providing online help inside applications. It also introduced Installer, a standard software installation program, driven by a LISP-like scripting language.

Finally, Workbench 2.0 rectified the problem of developers hooking directly into the input-events stream to capture keyboard and mouse movements, often locking up the whole system. Workbench 2.0 provided Commodities, a standard interface for modifying or scanning input events. This included a standard method for specifying global "hotkey" key-sequences, and a Commodities Exchange registry for the user to see what commodities were running.


Workbench icons
The icons that Workbench uses to represent the files in a volume or a drawer are stored in special .info files, with the name of the .info file matching the name of the file it represents. For example, the icon for NotePad, a text editor, is found in the file NotePad.info.

The .info file includes the graphical representation of the icon and its position in the volume or drawer window. The icon also specifies the type of the file, as used by Workbench. Workbench recognises five different file types:

Tool: An executable program.
Project: A data file of an executable program. The program which created the file is named in the icon file, double-clicking on the icon loads the program that created it.
Drawer: A directory containing files, and other drawers.
Volume: A physical disk or a RAM disk.
Garbage: The Trashcan - a deleted file backup, which works in a similar way to the 'Recycle bin' in Microsoft Windows.
An additional three file types are available and are intended for future expansion:

Device: designed for displaying information about attached devices
Kick: The icon of a bootable disk
App Icon: An icon which will be used as (part of) the GUI for an application
Of these three only App Icons currently are used by any part of Workbench/AmigaOS.

Tool files can include "tool types" in the .info file. These are used as configuration options for the program. Each tool type is a single line of text, which can optionally include parameters, written after an = sign. Tool types can be commented out by writing them in parentheses. For example, the tooltype "CX_POPKEY=ctrl alt f1" says that the application (a Commodity) will pop up the user interface in response to the key sequence Ctrl-Alt-F1.

The colours used in the icon are normally only stored as indices to the Amiga Workbench screen's current palette. Because of this, the icons' colour scheme is inherently tied to the chosen hues in the screen's palette, and choosing non-standard colours can give the icons an ugly appearance. This problem was party solved by a third-party system called NewIcons, which adds additional features to the standard .info files. Unlike normal Workbench icons, NewIcons include actual RGB colour information, and the system tries its best to match the icons' colour hues to those in the screen palette.

Since AmigaOS 3.5, Workbench supports icons with up to 256 colors, still based on the screen palette. This release of AmigaOS features the Glowicons icon set by Matt Chaput. With AmigaOS 4.0, a screen-palette-independent system is used. The 4.0 icons, designed by Martin Merz, can use a palette of 256 colors each.


AmigaDOS
Main article: AmigaDOS
AmigaDOS provides the disk operating system portion of the AmigaOS. This includes file systems, file and directory manipulation, the command line interface, file redirection, console windows, and so on.

In AmigaOS 1.x, the AmigaDOS portion was based on a TRIPOS port by MetaComCo, written in BCPL. Considerable amounts of functionality was only available to programs written in BCPL and not to developers using other languages. The third-party AmigaDOS Resource Project (arp.library) [1], formerly known as AmigaDOS Replacement Program, provided equivalent functionality to C programmers. ARP also provided one of the first standardized file requesters for the Amiga.

From AmigaOS 2.x onwards, AmigaDOS was rewritten in C and Assembler, retaining full 1.x BCPL program compatibility, and incorporated most of ARP into the OS.

Partitions and physical drives are typically referred to as DF0: (floppy drive 0), DH0: (hard drive 0), etc. However, unlike many operating systems, outside of built-in devices like DF0: these names are totally arbitrary; for example a hard disk partition could be named HARDDISK: or A: or HD0: when it was partitioned. Volume names have the same format as device names, so a disk partition on device DH0: might have the volume name Boot:. In addition, virtual volume names could be set with the "assign" command to any directory or device; for example programs often assigned a virtual volume name to their installation directory; an example might be FooBarWriter assigning FooBar: to DH0:Productivity/FooBarWriter. This allows for easy relocation of installed programs.


Graphics
Up to version 3, AmigaOS only supported the native Amiga graphics chipset, via graphics.library. This led developers to avoid OS functionality for drawing, and go straight for the underlying hardware. Third-party graphics cards were only supported via unofficial solutions. The ideal situation, where the AmigaOS could directly support any graphics system, was termed retargetable graphics (RTG) [2]. Release 3.1 included some support for third party graphics cards, such as the Picasso. With AmigaOS 3.5, some RTG systems were bundled with the OS, allowing the use of common hardware cards other than the native Amiga chipsets. The main RTG systems are CyberGraphX, Picasso 96 and EGS.

The Amiga did not have any official 3D graphics capability, so it had no standard 3D graphics interface. Graphics card manufacturers provided their own standards, which include MiniGL, Warp3D, StormMesa (agl.library) and CyberGL. VideoScape 3D was one of the earliest 3D rendering & animation systems, as well as TrueSpace 3D.

Likewise, while the Amiga is well known for its ability to easily genlock with video, it had no built in video capture interface. Third party interfaces included Digiview, VHI (Video Hardware Interface) by IOSPIRIT GmbH, tv.library by Elbox Computer and tvcard.library by Guido Mersmann.


Audio
Up to version 3.1, AmigaOS only supported the original Amiga chipset's sound capabilities, via audio.device. Support for third-party audio cards was vendor-dependent, until the creation and adoption of AHI [3] as a de facto standard. AmigaOS itself did not support MIDI until 3.1 when Roger Dannenberg's camd.library was adapted as the standard MIDI API. Commodore's version of camd.library also included a built in driver for the serial port. The later open source version of camd.library by Kjetil Matheussen did not provide a built in driver for the serial port, but provided an external driver instead.


Speech synthesis
The original Amiga was launched with speech synthesis software, developed by Softvoice, Inc. [4] This could be broken into three main components: narrator.device, which could play and modulate all phonemes used in American English, translator.library, which could translate English text to American English phonemes, and the SPEAK: handler, which command-line users could redirect output to, to have it spoken.

In the original 1.x releases, a Say program in Utilities and a basic demo was also included with AmigaBASIC programming examples.

The speech synthesiser was occasionally used in third-party programs, often educational software. The word processors Prowrite and Excellence! could read out documents using the synthesiser.

Despite the limitation on the narrator.device's phonemes, Francesco Devitt wrote a new version of translator.library which could translate any language to phonemes, given it had a set of rules for that language, and thus provided multilingual speech synthesis. [5]


ARexx
Main article: ARexx
The Amiga OS had support for the Rexx language. It was called ARexx (short for "Amiga Rexx") and was a script language which allowed for full OS scripting, similar to AppleScript, intra-application scripting, similar to VBA in Microsoft Office, as well as inter-program communication. Having a single scripting language for any application on the operating system was beneficial to users, instead of having to learn a new language for each application.

Programs could listen on an "ARexx port" for string messages. These messages could then be interpreted by the program in a similar fashion to a user pushing buttons. For example, an ARexx script when run in an e-mail program, could save the currently displayed email and invoke an external program which could extract and process information and then invoke a viewer program. This allowed applications to control other applications by sending data back and forth directly with memory handles instead of saving files to disk then reloading.


RAM disk
The Amiga OS has a dynamically-sized RAM disk, which resizes itself automatically to its contents. Starting with AmigaOS 2.x, operating System configuration files were loaded into the RAM disk on boot, greatly speeding operating system usage. Other files could be copied to the RAM disk like any standard device for quick modification and retrieval. Also beginning in AmigaOS 2.x, the RAM disk supported file-change notification, which was mostly used to monitor prefs files for changes.

The Amiga OS also has support for a fixed-capacity recoverable RAM disk, which functions as a standard RAM disk, but can maintain its contents on restart. It was commonly called RAD disk and it can function as a boot disk (with boot sector).


Technical overview
The main modularisation technique in AmigaOS is based on dynamically-loaded shared libraries, either stored as a file on disk with a ".library" filename extension, or stored in the Kickstart ROM. All libraries are accessed via an indirect jump table, which is always stored in RAM. That way, every library function can be patched or hooked at run-time, even if the library is stored in ROM.

The most important library in AmigaOS is exec.library, which can be considered a microkernel, as well as a library. As well as pre-emptive multitasking and access to other libraries, it provides high-level inter-process communication via message passing. (Other microkernels have had performance problems because of the need to copy messages between address spaces. Since the Amiga has only one address space, Exec message passing is quite efficient.) The only fixed memory address in the Amiga software (address 4) is a pointer to exec.library, which programs must use to find other libraries. Exec was designed and implemented by Carl Sassenrath.

Unlike traditional operating systems, the exec kernel does not run "privileged". Contemporary operating systems for the 68000 such as Atari TOS and SunOS used trap instructions for invoking kernel functions. This made the kernel functions run in the 68000's supervisor mode, while user software ran in the unprivileged user mode. By contrast, exec function calls are made with the library jump table, and the kernel code normally executes in user mode. Whenever supervisor mode is needed, either by the kernel or user programs, the library function Supervisor() or SuperState() is used.

Device drivers are also libraries, but they implement a standardised interface. Applications do not usually call devices directly as libraries, but use the exec.library I/O functions to indirectly access them. Like libraries, devices are either files on disk (with the ".device" extension), or stored in the Kickstart ROM.

The higher-level part of device and resource management is controlled by handlers, which are not libraries, but tasks, and communicate by passing messages.

One important type of handler is a filesystem handler. The AmigaOS can make use of any filesystem for which a handler has been written, a possibility that has been exploited by programs like CrossDOS and by a few "alternative" file systems to the standard OFS and FFS. These file systems allow one to add new features like journaling or file privileges, which aren't found in the standard operating system.

Handlers typically expose a device name to the DOS, which can be used to access the peripheral (if any) associated with the handler.

As an example of these concepts, the SPEAK: handler can have text sent to it. The handler makes use of translator.library, which converts text into phonemes, then it writes the phonemes to narrator.device, which translates the phonemes into intoned speech samples and itself uses audio.device to play them through the Amiga's audio hardware.

Device names are case insensitive (uppercase by convention) strings followed by a colon. After the colon a specifier can be added, which gives the handler additional information about what is being accessed and how. In the case of filesystem, the specifier usually consists of a path to a file in the filesystem; for other handlers, specifiers usually set characteristics of the desired input/output channel (for the SER: serial port driver, for example, the specifier will contain bit rate, start and stop bits, etc).

Filesystems expose drive names as their device names. For example, DF0: by default refers to the first floppy drive in the system, while DH0: is the first hard drive.

Filesystems also expose volume names, following the same syntax as device names: these identify the specific medium in the file system-managed drive. If DF0: contains a disk named "Workbench", then Workbench: will be a volume name that can be used to access files in DF0:.

If one wanted to access a file named "Amp" located in directory "Win" of the disk with name "Work" in drive DF0:, one could write

DF0:Win/Amp
or

Work:Win/Amp
However, these are not completely equivalent, since when the latter form is used, the system knows that the wanted volume is "Work" and not just any volume in DF0:. Therefore, whenever a requested file on "Work" is being accessed without volume "Work" being present in any drive, it will say something to the effect of:

Please insert volume Work in any drive
Programs often need to access files without knowing their physical location (either the drive or the volume): they only know the "logical path" of the file, i.e. whether the file is a library, a documentation file, a translation of the program's messages, etc.

This is solved in AmigaOS by the use of assigns. An assign follows, again, the same syntax as a device name; however, it already points to a directory inside the filesystem. The place an assign points to can be changed at any time by the user. Standard assigns that are generally present in an AmigaOS system include

SYS:, which points to the boot drive's root directory; this is the only assign created automatically by the kickstart
LIBS:, pointing to a directory containing the system's libraries, usually SYS:Libs/
DEVS:, pointing to a directory containing the system's devices, usually SYS:Devs/
C:, pointing to a directory containing shell commands, usually SYS:C/

Read More......

RISC iX

RISC iX was a Unix-like operating system designed to run on the Acorn Archimedes. Heavily based on 4.3BSD, it was initially completed in 1988 — a year after Arthur but prior to RISC OS. Its relationship to ARX is unknown

Other features included:

X11 (initially Release 2) with Ardent Window Manager, Tom's Window Manager and Ultrix Window Manager available by default
System V virtual memory extensions, compatible with the System V Interface Definition
C Compiler with ANSI C and pcc (Berkeley) compatibility
Sun Network File System version 3.2
ARM Assembler
Later versions upgraded the X11 server to release 4, and was certified to conform to the X/Open Portability Guide 3 Base profile.

The native file system implemented a transparent file compression mechanism and the console featured a two-cursor text copying mechanism inspired by Acorn's own earlier 8-bit range including the BBC Micro.


Distribution
RISC iX was either supplied preinstalled on new computer hardware or was installed onsite from a portable tape drive by Granada Microcare, who would take the installation tape away with them. The cost of purchase was £1,000.

Once installed a backup of the core operating system to three floppy disks was possible, allowing future reinstallation.


Supported Hardare

Machines

M4
An unreleased machine, built internally by Acorn for the development of RISC iX. Reputedly only two were built and at least one of them has subsequently been destroyed.


A680 Technical Publishing System
Unreleased but widely prototyped, the A680 contained an ARM2 processor, 8 MB RAM (dual MEMCs) and a 67 MB hard drive running from an onboard SCSI controller (no other machine from Acorn Computers included integrated SCSI). It is rumoured that overheating from the SCSI controller was one reason for the machine to never be released.


R140
Based on the A440, the R140 contained an 8 MHz ARM2 processor, 4 MB RAM and a 47 MB, later upgraded to 56 MB, ST506 hard drive. Supplied with RISC OS 2 in ROM, the machine would boot that OS then could either automatically boot RISC iX totally removing RISC OS from memory or continue running RISC OS — optionally being rebooted into RISC iX at any time.

At the time of initial release in 1989, the cost of the R140 was £3,500.

An ordinary A440 with at least 4 MB RAM and a suitable hard drive could run RISC iX. The R140 and A440 were hampered by the memory management system, using 32 KB pages.


R260
Based on the A540, the R260 originally contained a 26 MHz, (later 33 MHz) ARM3 processor, 4 MB RAM (upgradable to 16 MB) SCSI adapter and a 100 MB SCSI hard drive (typically a Conner CP30100). It booted in the same style as the earlier R140. The machine was supplied with an ethernet adapter.

The system was released in 1990 priced £3,500 just as its predecessor had.

A similarly configured A540 could run RISC iX.


R225
The R225 was a discless version of the R260. It required a network file server or an R260 to boot.


Later Machines
RISC iX is not compatible with later Archimedes machines.


Peripherals
As well as industry-standard ethernet, Acorn's own Econet was supported, including an IP over Econet transmission system.

Read More......

RISC OS

RISC OS, which stands for Reduced Instruction Set Computing Operating System, is a British graphical user interface-based operating system for ARM-processor based computers or similar devices.

Features
Stored in ROM - This allows for faster bootup (sub-30 seconds), safety from corruption and security against viruses. Versions 4 and 5 are stored in 4MB of Flash ROM, enabling Flash updates to the ROM.
Module-based - Modules can be freely added and replaced, including soft-loading of modules not present in ROM at boot time. This modular design has lead to developer RISC OS Ltd releasing rolling updates to its version of RISC OS, while third parties are able to write OS replacement modules to add new features. OS modules are accessed via software interrupts (SWIs), similar to API calls in Microsoft Windows.
Single User, Co-Operative Multitasking, Single Threaded - Despite almost all other current desktop operating systems moving towards pre-emtive multitasking (PMT) and multithreading, RISC OS remains a co-operative multitasking system. Although this is preferential for RISC OS' many embedded applications, many desktop developers and users have called for the OS to migrate to PMT. The OS also has only rudimentary memory protection.
Proprietary ADFS filesystem - The OS uses meta-data to determine file type; file extensions are not used. Colons are used to separate the filesystem from the rest of the path; the root is represented by a $ sign and directories by a period (.). Extensions from foreign filesystems are shown using a /. For example: ADFS::HardDisc4.$. is the root of HardDisc4 in ADFS format.
Self contained application view - Applications are contained in a directory, which, if its first character is '!' (pronounced pling) is normally treated by the filer as an application: clicking on such a directory would launch the application, rather than open the directory, and although the application's resources and executable files are contained within the directory, they remain hidden from the user. All application files are stored within this single directory, allowing for drag and drop install and removal.
Intuitive window manager - The RISC OS WIMP incorporates three-buttoned mouse operation, context-sensitive menus, window order control (i.e. send to back) and dynamic window focus (i.e. allows windows to be in focus at any position on the stack, including when not 'on top' and not visible). Launched during the time of Windows 3.0 and Mac OS System 7, the RISC OS WIMP GUI was well ahead of its time.
Drag and Drop - The user is able to copy and move data between application windows and disc locations via the filer by direct manipulation. This includes moving ('cut and paste'), copying and file saving and opening.
Iconbar - Similar to the Windows taskbar and Mac OS dock but released prior to both, RISC OS was a pioneer of this feature. The bar holds icons which represent mounted disc drives and RAM discs, running applications and system utilities. These icons have their own context-sensitive menus and support drag and drop behaviour.
Sub-pixel anti-aliasing - The Outline font manager provides broadcast quality anti-aliasing of fonts, drawn in real time onto the screen. Introduced in 1990, RISC OS was one of the first operating systems to include such a feature
Consistent look and feel across all applications - Introduced by RISC OS developer Acorn with Version 2, the RISC OS Style Guide is a detailed, 130 page document setting out the rules on application appearance and behaviour. This has ensured that applications appear and behave in the same way from the user's perspective, aiding ease of use.

Bundled applications
Applications bundled with RISC OS vary slightly between versions, but usually include the following core apps:

!Paint - a basic bitmap-based drawing program.
!Draw - a surprisingly sophisticated vector-based drawing program (Object Based).
!Calc - a basic calculator application.
!Edit - a text editor.

Early years (Arthur)
Main article: Arthur (operating system)

A screenshot of Arthur's GUI desktop and its bundled accessory applicationsThe OS was designed in Cambridge, England by Acorn for the 32-bit ARM based Acorn Archimedes, and released in its first version in 1987, as the Arthur operating system.

RISC OS 2
RISC OS was a rapid development of Arthur 1.2 after the failure of the ARX project. The first release was to be called Arthur 2, but was renamed to RISC OS 2, and was first sold as RISC OS 2.00 in April 1989. It had co-operative multitasking with some limitations, but was not multithreaded. It used the ADFS filesystem for both floppy and hard discs. It initially ran from a 512 KB ROM module. The WIMP interface offered all the standard features and fixed many of the bugs that had hindered Arthur. It lacked virtual memory and extensive memory protection (applications are protected from each other, but many functions have to be implemented as 'modules' which have full access to the memory). The main advantage of the OS was its ROM; it booted very quickly and while it was easy to crash it was impossible to break. Its high performance was because much of the system was written in ARM assembly language. The OS was organised as a relatively small kernel which defined a standard software interface to which extension modules were required to conform. Much of the system's functionality was implemented in modules coded in the ROM, though these could be supplanted by more evolved versions loaded into RAM. Among the kernel facilities were a general mechanism, named the callback handler, which allowed a supervisor module to perform process multiplexing. This facility was used by a module forming part of the standard editor program to provide a terminal emulator window for console applications. The same approach made it possible for advanced users to implement modules giving RISC OS the ability to do pre-emptive multitasking.

One unusual and innovative feature of the operating system at the time of its release was its support for high-quality, hinted and anti-aliased outline font rendering, a feature that only became widespread in other operating systems much later.

A slightly updated version RISC OS 2.01 was released later to support the ARM3 processor that was shipped with the [[Acorn Archimedes|Archimedes A540, Acorn R225/R260] and Acorn BBC A3000].


RISC OS 3

A typical RISC OS 3.7 sessionRISC OS 3.00 was released with the A5000 in 1991; it was almost four times the size of RISC OS 2 and ran from a 2MB ROM. It improved multitasking and also placed some of the more popular base applications in the ROM.


RISC OS 3.1
RISC OS 3.1 was released later which was sold built-in to the A3010, A3020, A4000, A4 and later A5000 models. It was also made available as replacement ROMs for the A5000 and earlier Archimedes machines, this is the last version suitable for those machines. Three variants were released RISC OS 3.10 the base version, RISC OS 3.11 a slight update that fixed some serial port issues, and RISC OS 3.19 which was a German translation.


RISC OS 3.5
RISC OS 3.50 was sold from 1994 with the first Risc PCs. Due to the very different hardware architecture of the Risc PC, including an ARM 6 processor, 16 and 24bit colour and a different IO chip (IOMD), RISC OS 3.50 was not made available for the older Archimedes and A Series ARM 2 and 3 machines.

RISC OS was the most advanced OS for its time with a drag-and-drop Graphical User Interface (GUI) whereas IBM Compatible PCs were still operating in DOS command line format. RISC OS and indeed Arthur OS were both ahead of their time with the 'It just works' approach to creating an operating system.


RISC OS 3.6
RISC OS 3.60 followed in 1995, the OS was updated and featured much better hard disk access and its networking was enhanced to include TCP/IP as standard in addition to Acorn's existing proprietary Econet system. Also the hardware support was improved; Risc PCs could now use ARM 7 processors and Acorn's A7000 machine with its ARM 7500 processor was also supported.


RISC OS 3.7
RISC OS 3.70 followed in 1996, the primary changes in the OS for this version was supporting the StrongARM processor that was made available as an upgrade for the Risc PC. This required extensive code changes due to StrongARM's split data and instruction cache (Harvard architecture).

RISC OS 3.71 is a small update released to support the hardware in the Acorn A7000+ with its ARM 7500FE (FE offering Floating Point Maths hardware support. This was normally emulated in one of the RISC OS Software modules) processor.

RISC OS provides a very intuitive graphical user interface, with features such as context sensitive menus and pervasive drag and drop, and excellent consistency across applications thanks to Acorn's detailed Style Guide.


Demise of Acorn Computers Ltd
Acorn halted work in all areas except set-top boxes in late 1998, and the company was renamed to Element 14 (the 14th element of the periodic table being silicon). RISC OS development was halted during the development of OS 4.0 for the RISC PC II ("Phoebe"), whose completion was also cancelled. A beta version, OS 3.8 for the original RISC PC, was previously released to developers.

This led to a number of rescue efforts, including the creation of the ROX Desktop to provide a RISC OS-like interface on Unix and Linux systems. Two similar projects, Impulse and Eidos's Phoenix, have both stalled.


RISC OS 4 (RISCOS Ltd)
In 1999 a new company called RISCOS Ltd was founded. They licensed the rights to RISC OS from Element 14 (and eventually from the new owner, Pace Micro) and continued the development of OS 3.8, releasing it as RISC OS 4 in July 1999. According to the company, over 6,400 copies of RISC OS 4.02 were sold up until production was ceased in mid 2005.

In 2002 the company launched RISC OS Select, a subscription scheme allowing users access to the latest OS updates in between major releases. These upgrades are released as soft-loadable patches, separate to the Flash ROM where the main OS is stored, and are loaded at boot time. The scheme was devised to accelerate RISCOS Limited's development cycle by producing extra income in between major releases. It has also allowed the company to subsidise the retail price of ROM releases, which are generally a culmination of the last few Select upgrades with a few extra minor changes.

Released in April 2004, RISCOS Ltd's current version is RISC OS Select Edition 3 (RISC OS 4.39), with the ROM based version being dubbed RISC OS Adjust. RISCOS Ltd sold its 500th Adjust ROM in early 2006.

In 2004, RISCOS Ltd began work on a 32-bit version of RISC OS Adjust (Adjust 32), which is compatible with the latest ARM processors and available in both embedded and desktop form. The first machine to make use of the updated OS, the Advantage6 A9 (Photo of Portable Desktop Version), was released in May 2006 after a 12 month Beta testing process. Matt Edgar of Advantage6 became (in)famous for saying the machine would be released "When it's ready!" Both 26-bit and 32-bit builds of new RISC OS 4 releases will now be compiled from the same source, but will have to be modified to run on each individual machine supported, as the OS has no hardware abstraction layer (HAL) at present. Instead it has a hardware-abstracted kernel, which allows specific code to be substituted for each platform supported.


RISC OS 5 (Castle Technology)
RISC OS 5 is a separate evolution by Castle Technology Ltd based upon work done by Pace Micro Technology for their NCOS based set top boxes. RISC OS 5 was written to support Castle's Iyonix PC Acorn-compatible, which runs on the Intel XScale ARM processor. Although a wealth of software has now been updated, a few older applications can only be run on RISC OS 5 via an emulator, since a minor 26-bit ARM CPU function was removed by Intel from the XScale. Likewise, RISC OS 5 itself had to be ported to run properly on the new CPU, and abstraction of the graphics and other hardware interfaces created, to allow it, for example, to use standard graphics cards, instead of Acorn's own VIDC chip.

In July 2003, Castle Technology Ltd bought the head licence for RISC OS from Pace Micro [2]. RISCOS Ltd and Castle continued maintaining separate development branches of the RISC OS operating system for some time, but as a result of a lengthy dispute over licensing during 2004 the two companies agreed to merge the two competing streams. Whether a unified version will be released is yet to be seen, however, as RISCOS Ltd have continued development of their stream of the OS in preparation to launch Version 6.


Shared Source Initiative (Castle Technology Ltd / RISC OS Open Ltd)
In October 2006, Castle Technology Ltd announced a plan to release elements of RISC OS 5 under a unique source sharing license. The Shared Source Initiative (SSI) is a joint venture between Castle and RISC OS Open Limited (ROOL), a newly formed software development company, which aims to accelerate development and encourage uptake of the OS. Under the custom dual license, released source will be freely available and may be modified and redistributed without royalty for non-commercial use, while commercial usage will incur a per-unit license fee to Castle. The full license has not yet been released.

The SSI will initially make phased releases of the OS, starting with the following components:

RISC OS build environment
Shared C Library
Main bundled applications (!Paint, !Edit, !Draw, etc)
Other disc-based applications (!Boot, !System, !Scrap, !Unicode, !Configure)
Acorn's !Browse (a.k.a. Phoenix) web browser, WebServe and related Fetcher modules
USB Printer Manager, printer drivers and printer dumper modules
Configuration plug-ins, screen savers, and some other development-related modules
In a Drobe forum, ROOL director Andrew Hodgkinson said the SSI would release as many components as possible, but it was too early to say how much of the OS that might be.

He said: "The ultimate goal would be to have a complete OS there - perhaps, for example, you could build yourself an Iyonix ROM. But that's putting the cart before the horse. We cannot promise being able to reach such a position at this stage, so we're not doing so."

ROOL will maintain the shared source tree and build an international developer community on a non-profit basis to support and encourage development. Both ROOL and Castle intend to provide RISC OS consultancy to clients requiring embedded ARM solutions, already a major market for the OS.

At this stage it is unclear whether RISC OS Ltd, developer of RISC OS 4, will co-operate with the SSI.

The company said on their website: "We await the full details of the licensing terms and conditions that will be applicable to RISC OS 5 source code. When these are known we shall be able to review the situation. However the current expectation is that there are very few features that are present in RISC OS 5 that are missing in RISC OS 6, that have a very high priority for inclusion in future releases of RISC OS 6."

ROL managing director Paul Middleton told Drobe News that the company would not be open sourcing its OS code in the same way.

He said: "It is probably worth pointing out that the 'open sourcing' of RISC OS is going to solely cover RISC OS 5 versions. We do not intend to 'open source' RISC OS 4 versions as some people seem to have assumed.

"I would point out though that we have always been happy to work with developers who require source level access to RISC OS, in the same way that Acorn made sources available for particular projects. The difference between us and ROOL is that we do require any changes made to be fed back to us, as we only want one version of RISC OS 4 to be available."


RISC OS 6 (RISCOS Ltd)
Shortly after Castle announced the SSI, ROL announced RISC OS 6, the next generation of their stream of the operating system. Significant portability, stability and internal structure improvements, including full 26/32 bit neutrality, have laid the foundations for the company's future releases, all of which will be based on Version 6.

RISC OS 6 is now highly modularised, with legacy and hardware specific features abstracted, and other code separated for easier future maintenance and development. Teletext support, device interrupt handler, software-based graphics operations, the real-time clock, the mouse pointer, CMOS RAM support, and hardware timer support have been abstracted out of the kernel and into their own separate modules. Legacy components, like the VIDC driver, and obsolete functionality for the BBC Micro have been abstracted too. AIF and transient utility executable checking has been introduced also to protect against rogue software, while graphics acceleration modules are provided for the SM501 graphics chip in the A9home and for ViewFinder AGP podule cards.

A beta-version of RISC OS 6, Preview 1, will be available for free download by subscribers to the Select scheme, both present and those whose subscription was renewed after 30th May 2004 - the last time the company delivered a Select release - but has since lapsed.

Select Edition 4 will be the first product to be based on RISC OS 6. Originally slated for release around mid-2005, it has been subject to lengthy delays due to the company's commitment to porting Adjust 32 to the A9home, which is taking much longer than expected. Many subcribers have signalled their anger with ROL, alleging that customers' Select fees were used to fund the A9home port while they have received nothing since May 2004.

Select 4 will include new user functionality; the details of which are yet to be confirmed. As yet RISCOS Ltd have not announced any release dates for RISC OS 6 products, and have refused to speculate on any development progress.

Preview 1 and Select 4 will initially be compatible with A9home, Acorn Risc PC and A7000 machines. RiscStation R7500, Microdigital Omega and Mico computers will not officially be supported, as the company does not have test machines available and requires proprietary software code to which they don't have the rights.

An Iyonix-compatible version of RISC OS 6 is described as a possibility - From the RISC OS 6 FAQ [3] : "Some people have assumed that because we have not made any definite announcements with respect to Select 4 on the Iyonix, that we are not interested in doing the work. The facts are however that our resources are limited, and priority has been given to working with partners who actively want RISC OS Select features on their products."

Read More......

Acorn MOS

Acorn's Machine Operating System is the computer operating system that powers the Acorn BBC computer range: the BBC Micro (MOS 0.1 to 1.2), the B+ (MOS 2) and the BBC Master Series micro (MOS 3). The article that follows is based on MOS 1.2 for the BBC Micro.

16 kilobytes in size (residing in the upper half of the read-only area of the Beeb's memory map), Acorn MOS is an extensible, single-tasking 8-bit operating system supplied on ROM. It includes support for four-channel sound and graphics, file system abstraction, co-processor support, and digital and analogue I/O including a daisy-chained fast expansion bus.

User interface
The MOS is a command-line OS with no real user interface; applications are expected to forward operating system command lines to the OS on its behalf, and the BBC BASIC ROM supplied with the BBC Micro is the default application used for this purpose. In command-line programs, one typically precedes OS commands with an asterisk (to tell the program to forward the command line to the operating system) and they are thus commonly known as "* commands" and are typically shown with the asterisk as part of the name, e.g. *LOAD, *CAT, *TAPE etc.

Unrecognised commands are offered to any "service" (extension) ROMs; filing system ROMs will often check to see if a file on disc matches that name, the same most other command-line interfaces do. The operating system call OSWORD with accumulator = 0 does however offer programs single line input (with ctrl-U for clear line and the cursor copying keys enabled) with basic character filtering and line length limit.

The MOS command line interpreter features a rather unusual idea: abbreviation of commands. To save typing, use a dot to abbreviate the command as you would in English, such as *L. for *LOAD and *SA. for *SAVE. *SAVE should be *S. but in BBC BASIC – which also supports abbreviations – S. is STEP and SAVE can only be SA, so I imagine that to avoid confusion, the OS's SAVE command obeys the same limit. *CAT, the command to catalogue a cassette or disc, can be abbreviated right down to *. for convenience, with no letters in the command at all!

Service ROMs – which add new commands to the OS – generally also support command abbreviation.


Extension
The lower 16 kB of the read-only memory map is reserved for the active Sideways paged bank. The Sideways system on the BBC Micro allows for one ROM at a time from sockets on the motherboard (or expansion boards) to be switched into the main memory map. Software can be run from ROM this way (leaving the RAM free of user program code, for more workspace) and the OS can be extended by way of such ROMs. The most popular such ROM is the Acorn Disc Filing System used to provide floppy disc support to the machine. During a reset, every paged ROM is switched in and asked how much public and private workspace it needs. Each ROM is allocated a chunk of private workspace that remains allocated at all times, and a single block of public workspace, equal to the size of the largest request, is made available to the active ROM. During operation, the paged area is rapidly switched between ROMs when file system commands are issued and unrecognised commands are put to the OS.

MOS allocates a 3.4 kB block of memory (0x0 to 0xE00) from the bottom of the memory map for operating system and language ROM workspace. On a cassette-only machine, 0xE00 is the start of user program memory. With OS extension ROMs fitted such as the a filing system ROM, more memory is allocated above this point; DFS ROMs generally use another 2.75 kB to cache the disc catalogue and manage random access buffers. A network filing system ROM (for Econet) allocates another half a kilobyte on top of this. This is a serious problem because MOS does not support relocation of machine code, which must be run from the address at which it was assembled.

The OS also maintains a vector table of all its calls which can be updated to hook any OS calls for user extension.


Text, graphics, printing
The MOS permits textual output intended for the screen to be directed instead to the printer, or both at once, allowing for very trivial printing support for plain text. Graphics printing is not supported and has to be written separately.

Graphics and in general all screen output is handled in a very unusual way. The ASCII control characters are almost entirely given new significance under MOS: known as the "VDU drivers", they are interpreted as video control characters. VDU 30 (i.e. ASCII 30) moves the cursor to (0, 0), VDU 4 and 5 select whether text should be drawn at the graphics or text cursor, VDU 12 clears the screen and VDU 14 and 15 turn scroll lock on and off. Thus, pressing ctrl-L will clear the screen and ctrl-N will enable scroll lock. VDU 2 and 3 toggle whether screen output is echoed to the printer.

Many more control characters take parameters: one or more characters that follow are used solely for their bit value as a parameter and not as a control code. VDU 19 handles palette remap; the following five bytes represent the palette entry, the desired colour and three reserve bytes. VDU 31 locates the text cursor to the location held in the following two bytes. VDU 17 sets the text colour and 18 the graphics colour. VDU 25 uses the succeeding five bytes to move the graphics cursor and plot solid and dashed lines, dots and filled triangles, the extent of graphics in MOS 0 and 1. The first byte is the command code, followed by the x and y co-ordinates as two byte pairs.

There is a single operating system command to write a character, OSWRCH, which is responsible for all text and graphics. For example, to move the cursor to (10, 15), you could write:

LDA #31: JSR OSWRCH \ move cursor
LDA #10: JSR OSWRCH \ x-coordinate
LDA #15: JSR OSWRCH \ y-coordinate
On the third OS call, the cursor will move. The following code would draw a line from (0, 0) to (0, +100):

LDA #25: JSR OSWRCH \ begin "PLOT" (ASCII 25) command
LDA #4: JSR OSWRCH \ command k=4, or move absolute
LDA #0: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH
\ send (0, 0) as low, high byte pairs

LDA #25: JSR OSWRCH \ begin PLOT
LDA #1: JSR OSWRCH \ k=1 - draw relative
LDA #0: JSR OSWRCH: JSR OSWRCH \ x = 0
LDA #100: JSR OSWRCH \ y = 100 (low byte)
LDA #0: JSR OSWRCH \ high byte
In BBC BASIC you can perform the above as any of the following:

VDU 25, 4, 0; 0; 25, 4, 100; 0;

PRINT CHR$(25); CHR$(4); CHR$(0); ... etc.

PLOT 4, 0, 0: PLOT 1, 0, 100

MOVE 0, 0: DRAW 0, 100: REM absolute co-ords only!
Graphics in the Acorn MOS use a virtual graphics resolution of 1280x1024, with pixel positions mapped to the nearest equivalent pixel in the current graphics mode. Switching video resolution will not affect the shape, size or position of graphics drawn even with completely different pixel metrics in the new mode, because this is all accounted for by the OS.

There are in fact two other OS calls that handle text output: OSNEWL (write a newline as CR/LF) and OSASCI, which adds a line feed every time it spots a carriage return. These no doubt call on OSWRCH for their own work.


Sound
Sound support is done with another OS call, OSWORD, which handles a variety of tasks enumerated via a task code placed into the accumulator. All OSWORD calls bear a parameter block used to send and receive multiple data, passed into the X and Y registers. There are four buffered sound channels -- three melodic and one noise -- based on the sound chip found in the BBC Micro. There is only one waveform for melodic channels; the supported note parameters are pitch, duration, and amplitude. The amplitude parameter is normally negative; positive values select an envelope to apply to the note. Other meta parameters include flush (the buffer is cleared and the channel silenced before the note is played) and synchronise count (as soon as the same synch count is received for that many channels, all the syncronised notes are played together).


Other I/O and second processor support
The OS has calls to handle reading and writing to all I/O (ports and screen memory) and programmers are strongly advised to use these. The reason for this being is that when a second processor is installed, user software is run from the separate memory map on the far side of the Tube® processor bus, and direct access to memory-mapped I/O registers and video memory is impossible. However, for the sake of performance, many apps including probably all assembled games write directly to main memory for I/O, and hence crash or give you a blank screen if a 6502 second processor is attached. One issue involved here is a lack of sprite support in the OS and a need to handle this manually from user code.

The MOS contains two built-in file systems: cassette and ROM - the ROM filesystem is quite similar to the cassette filesystem (try *ROM, *OPT 1 2, *CAT with a suitable ROM installed).


MOS 3
MOS 3, which shipped with the BBC Master, adds a variety of new features such as a real-time clock and settings in non-volatile RAM, extra graphics commands including rectangles and ellipses, and a proper command line, available for example to reconfigure the machine when the non-volatile RAM is corrupt.

Read More......

ARX

ARX was a Unix-like operating system written in Modula-2 developed by Acorn Computers Ltd in the UK and at the Acorn Research Centre (ARC) at Palo Alto for their new ARM RISC processors. It was a pre-emptive multitasking, multithreading, multi-user operating system. It was not finished in time to be fitted to the Archimedes range of computers, which shipped in 1987 with the Arthur operating system, which was later superseded by RISC OS.

Later, a port of 4.3BSD was released, named RISC iX. Its relationship to ARX is unknown.

The Acorn Research Centre was bought out by Olivetti.

Read More......

Arthur

Arthur is an early graphical user interface (GUI) operating system (OS) that was used on Acorn ARM-cpu-based computers from about 1987 until the much-superior RISC OS 2 was completed and made available in April 1989. It was the operating system of the earliest Archimedes ARM machines.

The desktop is very primitive. It features a colour-scheme typically described as "technicolour". Its earlier revisions were very buggy, and was only really meant to be a placeholder until RISC OS 2 (a name chosen instead of Arthur 2) was completed.

The "Arthur" name was supposedly dropped from version 2 because of the release at the time of a movie called Arthur 2: On the Rocks. Arthur is said to stand for "A Risc-based operating system by THURsday". Supposedly Arthur was put together in break-neck speed because a revolutionary operating system which Acorn had under development (ARX) wasn't going to be ready in time.

Most software made for Arthur can be run under RISC OS. A few titles will not work, however.

Read More......