Unix like

Conforming to the basic architecture and principles of the Unix operating system. Unix-like operating systems, such as Linux, may be POSIX compliant, which means that applications communicate with the OS via a standard programming interface (API).

The phrase "Unix-like operating system" is meant to exclude Unix operating systems such as Sun's Solaris and HP's HP-UX because they, as well as others, are compliant with one of the UNIX specifications governed by The Open Group. Any Unix operating system that does not comply is a Unix-like operating system. See Unix, Open Group and Single UNIX Specification.

Read More......

Apple Lisa

The first personal computer to include integrated software and use a graphical interface.

Modeled after the Xerox Star and introduced in 1983 by Apple, it was ahead of its time, but never caught on due to its $10,000 price and slow speed. It gave way to the Macintosh, which was developed by a separate group within Apple. In fact, the final production units of the Lisa were modified into a somewhat-compatible version of the Macintosh.

Read More......

Apple III

An enhanced version of the Apple II that never caught on.

Type rest of the post here

Read More......

Apple II series

The Apple II (sometimes written as Apple ][ or Apple //) was the first popular microcomputer manufactured by Apple. Its direct ancestor was the Apple I, a limited production circuit board computer for electronics hobbyists which pioneered many features that made the Apple II a commercial success. Introduced at the West Coast Computer Faire in 1977, the Apple II was one of the very first and most successful personal computers. A number of different models were sold, and the most popular model was manufactured with relatively minor changes into the 1990s. By the end of its production in 1993, somewhere between five and six million Apple II series computers (including approximately 1.25 million Apple IIgs models) had been produced.

Throughout the 1980s and much of the 1990s, the Apple II was the de facto standard computer in American education; some of them are still operational in classrooms today. The Apple II was popular with business users as well as with families and schools, particularly after the release of the first-ever computer spreadsheet, VisiCalc, which initially ran only on the Apple II.

The Apple II was originally running only the built-in BASIC interpreter contained in ROM. Apple DOS was added to support the diskette drive; the last version was "Apple DOS 3.3". Apple DOS was superseded by ProDOS to support a hierarchical filesystem and larger storage devices. Using a diskette or hard-disk, the Apple II could also load the UCSD Pascal operating system. UCSD binaries are compatible with a large number of other computers, including the IBM-PC. Using a Z80 interface the Apple II could run the popular Wordstar and dBase software under the CP/M operating system.

Apple's Macintosh product line finally eclipsed the Apple II series in the early 1990s. Even after the introduction of the Macintosh, the Apple II had remained Apple's primary source of revenue for years: the Apple II and its associated community of third-party developers and retailers were once a billion-dollar-a-year industry. The IIGS model was sold through to the end of 1992. The IIe model was removed from the product line on October 15, 1993, ending an era.

Design

Unlike any other microcomputer before it, the Apple II looked more like an appliance than a piece of electronic equipment. This was a computer that would not seem out of place in the home, on a manager's desk or in a classroom. The lid popped easily off the beige plastic case, allowing access to the entire internals of the computer, including the motherboard with eight expansion slots and RAM sockets, which could hold up to 48 KiB of memory.

The Apple II had color and high-resolution graphics modes, sound capabilities and two built-in BASIC programming languages, Applesoft and Integer. Compared with earlier microcomputers, these features were well-documented and easy to learn. The Apple II sparked the beginning of the personal computer revolution, as it was targeted for the masses rather than just hobbyists and engineers; its introduction and subsequent popularity also greatly influenced most of the microcomputers that followed it. "VanLOVEs Apple Handbook" and "The Apple Educators Guide" by Gerald VanDiver and Rolland Love reviewed more than 1500 software programs that the Apple II series could use.. The Apple dealer network used this book to emphasize the growing software developer base in education and personal use.The books became part of the Apple program and became the first book on database.

Models

See also the Timeline of computing article.

Apple II

The first Apple II computers went on sale on June 5, 1977 with a MOS Technology 6502 microprocessor running at 1 MHz, 4 KiB of RAM, an audio cassette interface for loading programs and storing data, and the Integer BASIC programming language built into the ROMs. The video controller displayed 24 lines by 40 columns of upper-case-only text on the screen, with NTSC composite video output suitable for display on a monitor, or on a TV set by way of an RF modulator. The original retail price of the computer was US$1298 (with 4 KiB of RAM) and US$2638 (with the maximum 48 KiB of RAM). To reflect the computer's color graphics capability, the Apple logo on the casing was represented using rainbow stripes,[1] which remained a part of Apple's corporate logo until early 1998. The earliest Apple IIs were assembled in Silicon Valley, and later in Texas [2]; printed circuit boards were manufactured in Ireland and Singapore.

In 1978, an external 5¼-inch floppy disk drive, the Disk II, attached via a controller card that plugged into one of the computer's expansion slots (usually slot 6), was used for data storage and retrieval to replace cassettes. The Disk II interface, created by Steve Wozniak, was regarded as an engineering masterpiece at the time for its economy of components. [3] [4] While other controllers had dozens of chips for synchronizing data I/O with disk rotation, seeking the head to the appropriate track, and encoding the data into magnetic pulses, Wozniak's controller card had few chips; instead, the Apple DOS used software to perform these functions. The Group Code Recording used by the controller was simpler and easier to implement in software than the more common MFM. In the end, the low chip count of the controller contributed to making Apple's Disk II the first affordable floppy drive system for personal computers. As a side effect, Woz's scheme made it easy for proprietary software developers to copy-protect the media on which their software shipped by changing the low-level sector format or stepping the drive's head between the tracks; inevitably, other companies eventually sold software to foil this protection. Another Wozniak optimization allowed him to omit Shugart's Track-0 sensor. When the Operating System wants to go to track 0, the controller simply moves toward the next-lower-numbered track, and keeps doing it until it can't go any further: this is presumed to be track 0. This process, called "recallibration", made a loud buzzing (rapid mechanical chattering) sound that often frightened Apple novices.

The approach taken in the Disk II controller was typical of Wozniak's design sensibility. The Apple II was full of clever engineering tricks to save hardware and reduce costs. For example, taking advantage of the way that 6502 instructions only access memory every other clock cycle, the video generation circuitry's memory access on the otherwise unused cycles avoided memory contention issues and also eliminated the need for a separate refresh circuit for the DRAM chips.

Rather than using a complex analog-to-digital circuit to read the outputs of the game controller, Wozniak used a simple timer circuit whose period was proportional to the resistance of the game controller, and used a software loop to measure the timer.

The text and graphics screens had a somewhat outdated arrangement (the scanlines were not stored in sequential areas of memory) which was reputedly due to Woz's realization that doing it that way would save a chip; it was less expensive to have software calculate or look up the address of the required scanline than to include the extra hardware. Similarly, in the high-resolution graphics mode, color was determined by pixel position and could thus be implemented in software, saving Woz the chips needed to convert bit patterns to colors.

The epitome of the Apple II design philosophy was the Apple II sound circuitry. Rather than having a dedicated sound-synthesis chip, the Apple II had a toggle circuit that could only emit a click through a built-in speaker; all other sounds (including two, three and, eventually, four-voice music and playback of audio samples and speech synthesis) were generated entirely by clever software that clicked the speaker at just the right times. Not for nearly a decade would an Apple II be released with a dedicated sound chip. Similar techniques were used for cassette storage: the cassette output worked the same as the speaker, and the input was a simple zero-crossing detector that served as a relatively crude (1-bit) audio digitizer. Routines in the ROM were used to encode and decode data in frequency shift keying for the cassette.

Wozniak's open design and the Apple II's multiple expansion slots permitted a wide variety of third-party devices to expand the capabilities of the machine. Apple II peripheral cards such as Serial controllers, improved display controllers, memory boards, hard disks, and networking components were available for this system in its day. There were emulator cards, such as the Z80 card that permitted the Apple to switch to the Z80 processor and run a multitude of programs developed under the CP/M operating system, including the dBase II database and the WordStar word processor. (At one point in the mid-1980's, more than half the machines running CP/M were Apple II's with Z80 cards.)There was also a third-party 6809 card that would allow OS-9 Level One to be run. The Mockingboard sound card greatly improved the audio capabilities of the Apple, with simple music synthesis and text-to-speech functions. Eventually, Apple II accelerator cards were created to double or quadruple the computer's speed.

Read More......

Amiga Unix

Commodore-Amiga, Inc., in 1990, did a full port of AT&T Unix System V Release 4 for the Amiga computer family (in addition to the proprietary AmigaOS shipping with these systems by default), informally known as Amix. Bundled with the Amiga 3000UX, Commodore's UNIX was one of the first ports of SVR4 to the 68k architecture.

Contrary to the popular belief that Amigas were primarily gaming machines, this port was considered one of the finest Unices of its time by Amiga enthusiasts. The Amiga A3000UX model even got the attention of Sun Microsystems, though ultimately nothing came of it.

Unlike Apple's A/UX, Amiga UNIX contained no compatibility layer to allow AmigaOS applications to run under Unix. With few native applications available to take advantage of the Amiga's significant multimedia capabilities, it failed to find a niche in the quite-competitive Unix workstation market of the early 1990s. The A3000UX's price tag of approximately $7000 was also not very attractive compared to other low-end UNIX systems at the time, such as the NeXTstation ($5000 for a base system, with many times the number of applications available), the SGI Indigo (starting at $8000), or the DECstation 5000/25 (starting at $5000). Sun, HP, and IBM had similarly priced systems. The A3000UX's 68030 was noticibly underpowered compared to most of its RISC-based competitors.

Like many other Unix variants with small market shares, Amiga Unix vanished into the mists of computer history when its vendor, Commodore, went out of business. Today, Unix-like operating systems such as Minix, NetBSD, and Linux are available for the Amiga platform, but the commercial and AT&T-licensed Amiga Unix has not been revived.

Read More......

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......

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......