Information AboutAmigaos |
| CATEGORIES ABOUT AMIGAOS | |
| cbm software | |
| amigaoscbm software | |
| amigaos | |
| amiga software | |
| operating systems | |
|
name = 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 .]] Kickstart is the name given to the Bootstrap ROM. On the first Amiga model, the A1000 , this was loaded from disk, 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 in IBM PC s, 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. Workbench 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 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, 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, 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 standards - 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 consistancy. 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, of providing online help inside applications. It also introducted ''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 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 AmigaDOS provides the Disk Operating System portion of the AmigaOS. This includes Filesystem s, file and directory manipulation, the Command Line Interface , file redirection and so on. In AmigaOS 1.x, the AmigaDOS portion was based on a s for the Amiga. From AmigaOS 2.x onwards, AmigaDOS was rewritten in C , retaining 1.x compatibility where possible. Graphics Up to version 3.1, AmigaOS only supported the , 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 , Storm Mesa (''agl.library'') and CyberGL . Likewise, while the Amiga is well known for its ability to Genlock with video, it had no Video Capture interface. Third party interfaces include 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 , besides the standard serial driver ''serial.device''. David Joiner's ''camd.library'' provides a specific MIDI support library. 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 BASH on Linux, 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 email 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, send data back and forth directly with memory handles, instead of saving files to disk then reloading. Ram Disk The Amiga OS has the only dynamically sized RAM disk, which would resize itself automatically to its contents. 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. The Amiga OS also had support for a fixed-capacity recoverable RAM disk, which functioned as a standard RAM disk, but could maintain its contents on restart. It was commonly called RAD disk and it could function as a start disk (with boot sector). TECHNICAL OVERVIEW The main Modularization 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 is actually a Microkernel as well as a library. As well as preemptive multi-tasking 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 . Device Driver s 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" filesystems to the standard OFS and FFS . These filesystems allow one to add new features like Journaling or File Privilege s, 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 , 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 filesystem-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 "Bar" located in directory "Foo" of the disk with name "Work" in drive ''DF0:'', one could write DF0:Foo/Bar or Work:Foo/Bar 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
AMIGAOS INFLUENCE ON OTHER OPERATING SYSTEMS AmigaOS has spawned at least two "clone" operating systems over time. AROS , or ''Amiga Research Operating System'' is an attempt to clone the AmigaOS API in a portable open-source operating system. Although not binary compatible with AmigaOS (unless running on 68k), users have reported it to be highly source code compatible. MorphOS is a PowerPC native operating system, originally created when the future of the Amiga looked uncertain. It provides binary compatibility with system-friendly AmigaOS applications. A version which runs on Classic Amigas with PPC accelerator cards has been released. Although not strictly Amiga related, a fork of the FreeBSD 4.8 release, called DragonFly BSD , has been created by a former FreeBSD developer and Amiga programmer Matt Dillon. DragonFly BSD aims to make the BSD core more like the Amiga architecturally, featuring a message-passing kernel and allowing for a very efficient and virtually Mutex -free SMP design. TRIVIA Some versions of AmigaOS included Copyright messages as Easter Eggs that required some trickery to access.
SEE ALSO EXTERNAL LINKS
|
|
|