Microsoft Office Access, previously known as Microsoft Access, is a relational database management system from Microsoft that combines the relational Microsoft Jet Database Engine with a graphical user interface and software development tools. It is a member of the 2007 Microsoft Office system.
Access can use data stored in Access/Jet, Microsoft SQL Server, Oracle, or any ODBC-compliant data container (including MySQL and PostgreSQL). Skilled software developers and data architects use it to develop application software. Relatively unskilled programmers and non-programmer "power users" can use it to build simple applications. It supports some object-oriented techniques but falls short of being a fully object-oriented development tool.
Access was also the name of a communications program from Microsoft, meant to compete with ProComm and other programs. This proved a failure and was dropped.[1] Years later Microsoft reused the name for its database software.
History
Access version 1.0 was released in November 1992, followed in May of 1993 by an Access 1.1 release to improve compatibility with other Microsoft products.
Microsoft specified the minimum operating system for Version 2.0 as Microsoft Windows v3.0 with 4 MB of RAM. 6 MB RAM was recommended along with a minimum of 8 MB of available hard disk space (14 MB hard disk space recommended). The product was shipped on seven 1.44 MB diskettes. The manual shows a 1993 copyright date.
The software worked well with small recordsets but testing showed some circumstances caused data corruption. For example, file sizes over 10 MB were problematic (note that most hard disks were smaller than 500 MB at the time this was in wide use). The Getting Started manual warns about a number of circumstances where obsolete device drivers or incorrect configurations can cause data loss.
Access's initial codename was Cirrus; the forms engine was called Ruby. This was before Visual Basic - Bill Gates saw the prototypes and decided that the BASIC language component should be co-developed as a separate expandable application, a project called Thunder. The two projects were developed separately as the underlying forms engines were incompatible with each other; however, these were merged together again after VBA.
Uses
Access is used by small businesses, within departments of large corporations, and by hobby programmers to create ad hoc customized desktop systems for handling the creation and manipulation of data.
Microsoft has strongly recommended for the past decade that Jet databases are inappropriate for basic web based applications hosted on Microsoft's Internet Information Services and utilizing Microsoft Active Server Pages ASP.
Some professional application developers use Access for rapid application development, especially for the creation of prototypes and standalone applications that serve as tools for on-the-road salespeople. Access does not scale well if data access is via a network, so applications that are used by more than a handful of people tend to rely on Client-Server based solutions.[citation needed] However, an Access "front end" (the forms, reports, queries and VB code) can be used against a host of database backends, including JET (file-based database engine, used in Access by default), Microsoft SQL Server, Oracle, and all other ODBC-compliant product.
In addition to traditional ODBC methods, Access also offers "Access Data Projects" for accessing SQL Server data, which provides a number of advantages over linked tables. Unfortunately, there are also several bugs with the technology, and after years of promoting it, Microsoft now appears to be downplaying its use.[citation needed]
Features
One of the benefits of Access from a programmer's perspective is its relative compatibility with SQL (structured query language) — queries can be viewed graphically or edited as SQL statements, and SQL statements can be used directly in Macros and VBA Modules to manipulate Access tables. Users can mix and use both VBA and "Macros" for programming forms and logic and offers object-oriented possibilities.
MSDE (Microsoft SQL Server Desktop Engine) 2000, a scaled down version of Microsoft SQL Server 2000, has been a free download for a decade and may be used with Access as an alternative to the Jet Database Engine.
Unlike other RDBMS, Microsoft Access does not implement database triggers or stored procedures.
Starting in Access 2000 (Jet 4.0), there is a new syntax for creating queries with parameters, in a way that looks like creating stored procedures, but these procedures are still limited to one statement per procedure.[2]
In ADP files (supported in Access 2000 and later), the database-related features are geared more towards a client-server architecture with MSDE or Microsoft SQL Server serving as the back-end instead of using the Jet Engine. Thus, it supports the creation of nearly all objects in the underlying server (tables with constraints and triggers, views, stored procedures and UDF-s). However, only forms, reports, macros and modules are stored in the ADP file (the other objects are stored in the back-end database). This centralization of queries and tables in the database server provides a more reliable development environment for most businesses.
Development
Access allows relatively quick development because of very good GUI design tools, and high level integration of GUI design and data objects. All database tables, queries, forms, and reports are stored in the database. For query development, Access utilizes the Query Design Grid, a graphical user interface that allows users to create queries without knowledge of the SQL programming language. In the Query Design Grid, users can "show" the source tables of the query and select the fields they want returned by clicking and dragging them into the grid. Joins can be created by clicking and dragging fields in tables to fields in other tables. Access allows users to view and manipulate the SQL code if desired.
The programming language available in Access is, as in other products of the Microsoft Office suite, Microsoft Visual Basic for Applications. Two database access libraries of COM components are provided: the obsolete Data Access Objects (DAO), which has not been included in Office, Windows or MDAC for most of the past decade.
ADO has been much more widespread; and this is why it is recommended to upgrade all DAO to ADO (but still accessible) by ActiveX Data Objects (ADO); however (DAO) has been reintroduced as an option in the latest version, Microsoft Access 2007.
Beside DAO and ADO, developers can also use OLE DB and ODBC for developing native C/C++ programs for Access.[3]
Many developers who use Access use the Leszynski naming convention, though this is not universal; it is a programming convention, not a DBMS-enforced rule.[4] Except in VBA, it is also made redundant by the fact that Access categorises each object automatically and always shows the object type, by prefixing Table: or Query: before the object name when referencing a list of different database objects.
Microsoft Access can be applied to small projects (the Access 97 speed characterization was done for 32 users)[5]but scales poorly to larger projects with more than several 10MB of data or many users because of the way indexing and locking are handled. As a Microsoft Access database can be cached locally when used on network, processing speed may be substantially better when there is only a single user. Because of the effect of packet latency on the record locking system, Access databases are effectively too slow to be used on a Virtual Private Network or a Wide Area Network. Access Data Projects work great over VPN and WAN.
Access includes an Upsizing Wizard that allows users to upsize their database to Microsoft SQL Server if they want to move to an ODBC client-server database.
One recommended technique is to migrate to SQL Server and utilize Access Data Projects. This allows stored procedures, views, and constraints using standard SQL. Additionally this full client-server design significantly reduces maintenance and availability problems.
Access allows no relative paths when linking, so the development environment should have the same path as the production environment (though it is possible to write a "dynamic-linker" routine in VBA). This technique also allows the developer to divide the application among different files.
Protection
If the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to an .MDE file. All changes to the VBA project (forms or reports) need to be made to the original MDB and then reconverted to MDE.
Some tools are available for unlocking and 'decompiling', although certain elements including original VBA comments and formatting are normally irretrievable.
NOTE:
2008年10月30日星期四
Scoop (software)
Scoop is a content management system originally developed by Rusty Foster. Scoop's focus is on collaborative publishing, and its feature set is geared toward encouraging user contributions and participation. Scoop is written in Perl and runs via mod_perl on Apache web servers with a MySQL database backend. Distributed under the GNU General Public License, Scoop is free software. As of mid-2007, the current stable version of Scoop is 1.1.8.
Overview
Scoop was originally developed for use on Kuro5hin and was designed to allow user submissions of content much like Slash, another somewhat similar CMS. But where Slash and its flagship site, Slashdot, relied on a small group of editors to decide what content was actually published, Kuro5hin and Scoop aimed to allow moderation by the users themselves. Scoop's solution was to introduce a "moderation queue" where submitted stories would be visible to registered users, and where users could vote on whether a story should be published; a story which garners enough positive votes to cross a (configurable) "posting threshold" will become publicly visible, and a story which collects too many negative votes will be deleted.
Scoop takes the same broad, collaborative approach to comment moderation as well; where other systems only allow a particular group of superusers to moderate comments, or allocate temporary moderation privileges among users, Scoop allows all registered users to moderate comments.
Scoop is configurable, allowing nearly any feature to be activated or deactivated; and extensible, new features can be written in Perl and integrated into Scoop as "boxes" which are stored in the database and editable from Scoop's web-based administration interface or from a specialized "boxtool".
Although Scoop was originally designed and deployed for kuro5hin, it has since been put into much broader use. Although many Scoop-powered sites today are oriented toward political discussion (for example, the American left-wing on-line community Daily Kos is a prominent Scoop site), Scoop can be found in use in a variety of areas, but improvements to the software appear to have ceased in 2006. Specialized Scoop hosting is available from a number of companies.
Features
Scoop's has a story- and comment-moderation system, a and other features are available. For users, Scoop offers a number of features:
Individual weblogs or "diaries" which bypass story moderation and post to a separate section of the site.
Polls which may be attached to stories and diaries.
Per-user "hotlists" allowing users to keep an eye on particular items of interest to them.
Per-user file uploads and sharing.
Per-user calendars, both public and private.
User submission of RSS feeds from other sites, which can be viewed from Scoop's built-in news aggregator.
Configurable views; users may choose to display or hide certain page elements (such as lists of users online, new diaries, RSS feeds, etc.), and have a number of options for how stories and comments are displayed.
Submission of stories and comments in plain text, in HTML, or using a simple text-to-HTML "autoformat" system.
For site administrators, Scoop is customizable; Scoop can be configured to use any, all or none of the following features:
Moderation of stories and comments by users, with configurable values and thresholds for posting or deleting stories and for hiding negatively-rated comments.
An optional "edit queue" which allows stories to be discussed and modified before proceeding to voting.
A configurable "autopost" algorithm which determines whether to post or delete a story which remains in moderation beyond a set period of time.
Syndication of site content via RSS.
Delegation of responsibilities via a user permission system, allowing the definition of single users or groups of users with any desired level of access.
Site subscriptions with configurable feature incentives (using built-in payment processing), allowing users to support the site.
User-submitted advertisements.
Site themes which allow an administrator to change both a site's look and feel and the content it offers.
Caching of content to reduce server loads.
Automatic archiving of older content and closing of comments on out-of-date stories.
Built-in spam control, and throttles to prevent malicious flooding of content.
Configurable macros for use in stories and comments.
Fine-grained control over what HTML elements may be used in user submissions.
Templating system for page design and layout.
Reuse of code and content via "blocks" which can be included in any part of any page.
Administrative logging for accountability purposes.
Web-based administrative interface which can be themed to match user-visible areas of the site and offers control over all site features and configuration.
Extensibility via the box system.
Documentation including installation procedures (though this is no longer maintained, see external links).
Criticisms
Scoop has not been internationalized.
Failure to keep pace with modern Web/CMS technologies, such as those represented by the term Web 2.0.
It has a poor level of maintenance and community support: the last change to its code base was made in 2006, and it's administration guide and community help area haven't been updated since 2005.
NOTE:
Overview
Scoop was originally developed for use on Kuro5hin and was designed to allow user submissions of content much like Slash, another somewhat similar CMS. But where Slash and its flagship site, Slashdot, relied on a small group of editors to decide what content was actually published, Kuro5hin and Scoop aimed to allow moderation by the users themselves. Scoop's solution was to introduce a "moderation queue" where submitted stories would be visible to registered users, and where users could vote on whether a story should be published; a story which garners enough positive votes to cross a (configurable) "posting threshold" will become publicly visible, and a story which collects too many negative votes will be deleted.
Scoop takes the same broad, collaborative approach to comment moderation as well; where other systems only allow a particular group of superusers to moderate comments, or allocate temporary moderation privileges among users, Scoop allows all registered users to moderate comments.
Scoop is configurable, allowing nearly any feature to be activated or deactivated; and extensible, new features can be written in Perl and integrated into Scoop as "boxes" which are stored in the database and editable from Scoop's web-based administration interface or from a specialized "boxtool".
Although Scoop was originally designed and deployed for kuro5hin, it has since been put into much broader use. Although many Scoop-powered sites today are oriented toward political discussion (for example, the American left-wing on-line community Daily Kos is a prominent Scoop site), Scoop can be found in use in a variety of areas, but improvements to the software appear to have ceased in 2006. Specialized Scoop hosting is available from a number of companies.
Features
Scoop's has a story- and comment-moderation system, a and other features are available. For users, Scoop offers a number of features:
Individual weblogs or "diaries" which bypass story moderation and post to a separate section of the site.
Polls which may be attached to stories and diaries.
Per-user "hotlists" allowing users to keep an eye on particular items of interest to them.
Per-user file uploads and sharing.
Per-user calendars, both public and private.
User submission of RSS feeds from other sites, which can be viewed from Scoop's built-in news aggregator.
Configurable views; users may choose to display or hide certain page elements (such as lists of users online, new diaries, RSS feeds, etc.), and have a number of options for how stories and comments are displayed.
Submission of stories and comments in plain text, in HTML, or using a simple text-to-HTML "autoformat" system.
For site administrators, Scoop is customizable; Scoop can be configured to use any, all or none of the following features:
Moderation of stories and comments by users, with configurable values and thresholds for posting or deleting stories and for hiding negatively-rated comments.
An optional "edit queue" which allows stories to be discussed and modified before proceeding to voting.
A configurable "autopost" algorithm which determines whether to post or delete a story which remains in moderation beyond a set period of time.
Syndication of site content via RSS.
Delegation of responsibilities via a user permission system, allowing the definition of single users or groups of users with any desired level of access.
Site subscriptions with configurable feature incentives (using built-in payment processing), allowing users to support the site.
User-submitted advertisements.
Site themes which allow an administrator to change both a site's look and feel and the content it offers.
Caching of content to reduce server loads.
Automatic archiving of older content and closing of comments on out-of-date stories.
Built-in spam control, and throttles to prevent malicious flooding of content.
Configurable macros for use in stories and comments.
Fine-grained control over what HTML elements may be used in user submissions.
Templating system for page design and layout.
Reuse of code and content via "blocks" which can be included in any part of any page.
Administrative logging for accountability purposes.
Web-based administrative interface which can be themed to match user-visible areas of the site and offers control over all site features and configuration.
Extensibility via the box system.
Documentation including installation procedures (though this is no longer maintained, see external links).
Criticisms
Scoop has not been internationalized.
Failure to keep pace with modern Web/CMS technologies, such as those represented by the term Web 2.0.
It has a poor level of maintenance and community support: the last change to its code base was made in 2006, and it's administration guide and community help area haven't been updated since 2005.
NOTE:
Remanufactured Inkjet Cartridge
Document management system
A document management system (DMS) is a computer system (or set of computer programs) used to track and store electronic documents and/or images of paper documents. The term has some overlap with the concepts of Content Management Systems and is often viewed as a component of Enterprise Content Management Systems (ECM) and related to Digital Asset Management, Document imaging, Workflow systems and Records Management systems. Contract Management and Contract Lifecycle Management (CLM) can be viewed as either components or implementations of ECM..
Overview
In the broadest sense, document management systems can range from a shoebox all the way to an Enterprise Content Management system. There are several common issues that are involved in managing documents, whether the system is an informal, ad-hoc, paper-based method for one person or if it is a formal, structured, computer enhanced system for many people across multiple offices.
History
Beginning in the 1980s, a number of vendors began developing systems to manage paper-based documents. These systems managed paper documents, which included not only printed and published documents, but also photos, prints, etc.
Later, a second system was developed, to manage electronic documents, i.e., all those documents, or files, created on computers, and often stored on local user file systems. The earliest electronic document management (EDM) systems were either developed to manage proprietary file types, or a limited number of file formats. Many of these systems were later referred to as document imaging systems, because the main capabilities were capture, storage, indexing and retrieval of image file formats. These systems enabled an organization to capture faxes and forms, save copies of the documents as images, and store the image files in the repository for security and quick retrieval (retrieval was possible because the system handled the extraction of the text from the document as it was captured, and the text indexer provided text retrieval capabilities).
EDM systems evolved to where the system was able to manage any type of file format that could be stored on the network. The applications grew to encompass electronic documents, collaboration tools, security, and auditing capabilities.
Components
Document management systems commonly provide storage, versioning, metadata, security, as well as indexing and retrieval capabilities. Here is a description of these components:
Metadata
Metadata is typically stored for each document. Metadata may, for example, include the date the document was stored and the identity of the user storing it. The DMS may also extract metadata from the document automatically or prompt the user to add metadata. Some systems also use optical character recognition on scanned images, or perform text extraction on electronic documents. The resulting extracted text can be used to assist users in locating documents by identifying probable keywords or providing for full text search capability, or can be used on its own. Extracted text can also be stored as a component of metadata, stored with the image, or separately as a source for searching document collections.
Integration
Many document management systems attempt to integrate document management directly into other applications, so that users may retrieve existing documents directly from the document management system repository, make changes, and save the changed document back to the repository as a new version, all without leaving the application. Such integration is commonly available for office suites and e-mail or collaboration/groupware software. Integration often uses open standards such as ODMA, LDAP, WebDAV and SOAP to allow integration with other software and compliance with internal controls.[citation needed]
Capture
Images of paper documents using scanners or multifunction printers. Optical Character Recognition (OCR) software is often used, whether integrated into the hardware or as stand-alone software, in order to convert digital images into machine readable text.
Indexing
Track electronic documents. Indexing may be as simple as keeping track of unique document identifiers; but often it takes a more complex form, providing classification through the documents' metadata or even through word indexes extracted from the documents' contents. Indexing exists mainly to support retrieval. One area of critical importance for rapid retrieval is the creation of an index topology.
Storage
Store electronic documents. Storage of the documents often includes management of those same documents; where they are stored, for how long, migration of the documents from one storage media to another (Hierarchical storage management) and eventual document destruction.
Retrieval
Retrieve the electronic documents from the storage. Although the notion of retrieving a particular document is simple, retrieval in the electronic context can be quite complex and powerful. Simple retrieval of individual documents can be supported by allowing the user to specify the unique document identifier, and having the system use the basic index (or a non-indexed query on its data store) to retrieve the document. More flexible retrieval allows the user to specify partial search terms involving the document identifier and/or parts of the expected metadata. This would typically return a list of documents which match the user's search terms. Some systems provide the capability to specify a Boolean expression containing multiple keywords or example phrases expected to exist within the documents' contents. The retrieval for this kind of query may be supported by previously-built indexes, or may perform more time-consuming searches through the documents' contents to return a list of the potentially relevant documents. See also Document retrieval.
Distribution
A published document for distribution has to be in a format that can not be easily altered. As a common practice in law regulated industries, an original master copy of the document is usually never used for distribution other than archiving. If a document is to be distributed electronically in a regulatory environment, then the equipment tasking the job has to be quality endorsed AND validated. Similarly quality endorsed electronic distribution carriers have to be used. This approach applies to both of the systems by which the document is to be inter-exchanged, if the integrity of the document is highly in demand.
Security
Document security is vital in many document management applications. Compliance requirements for certain documents can be quite complex depending on the type of documents. For instance the Health Insurance Portability and Accountability Act (HIPAA) requirements dictate that medical documents have certain security requirements. Some document management systems have a rights management module that allows an administrator to give access to documents based on type to only certain people or groups of people.
Workflow
Workflow is a complex problem and some document management systems have a built in workflow module. There are different types of workflow. Usage depends on the environment the Electronic Document Management System (EDMS) is applied to. Manual workflow requires a user to view the document and decide who to send it to. Rules-based workflow allows an administrator to create a rule that dictates the flow of the document through an organization: for instance, an invoice passes through an approval process and then is routed to the accounts payable department. Dynamic rules allow for branches to be created in a workflow process. A simple example would be to enter an invoice amount and if the amount is lower than a certain set amount, it follows different routes through the organization.
Collaboration
Collaboration should be inherent in an EDMS. Documents should be capable of being retrieved by an authorized user and worked on. Access should be blocked to other users while work is being performed on the document.
Versioning
Versioning is a process by which documents are checked in or out of the document management system, allowing users to retrieve previous versions and to continue work from a selected point. Versioning is useful for documents that change over time and require updating, but it may be necessary to go back to a previous copy.
Publishing
Publishing a document is sometime tedious and involves the procedures of proofreading, peer or public reviewing, authorizing, printing and approving etc. Those steps endure prudence and logic thinking. Any careless handling may result in the inaccuracy of the document and therefore misleading or upset its users and readers. In law regulated industries, some of the procedures have to be completed with the evidences of their corresponding signatures and the dates on which the document is signed. Refer to the ISO divisions of ICS 01.140.40 and 35.240.30 for further information .
Standardization
Currently, the availability of the standards is perhaps scattered all over industries and it is not hard to adopt some of those for each business interest. The following is the list of some of the relevant ISO documents. Divisions ICS 01.140.10 and 01.140.20 . The ISO has also published a series of standards regarding the technical documentation, covered by the division of 01.110 .
NOTE:
Overview
In the broadest sense, document management systems can range from a shoebox all the way to an Enterprise Content Management system. There are several common issues that are involved in managing documents, whether the system is an informal, ad-hoc, paper-based method for one person or if it is a formal, structured, computer enhanced system for many people across multiple offices.
History
Beginning in the 1980s, a number of vendors began developing systems to manage paper-based documents. These systems managed paper documents, which included not only printed and published documents, but also photos, prints, etc.
Later, a second system was developed, to manage electronic documents, i.e., all those documents, or files, created on computers, and often stored on local user file systems. The earliest electronic document management (EDM) systems were either developed to manage proprietary file types, or a limited number of file formats. Many of these systems were later referred to as document imaging systems, because the main capabilities were capture, storage, indexing and retrieval of image file formats. These systems enabled an organization to capture faxes and forms, save copies of the documents as images, and store the image files in the repository for security and quick retrieval (retrieval was possible because the system handled the extraction of the text from the document as it was captured, and the text indexer provided text retrieval capabilities).
EDM systems evolved to where the system was able to manage any type of file format that could be stored on the network. The applications grew to encompass electronic documents, collaboration tools, security, and auditing capabilities.
Components
Document management systems commonly provide storage, versioning, metadata, security, as well as indexing and retrieval capabilities. Here is a description of these components:
Metadata
Metadata is typically stored for each document. Metadata may, for example, include the date the document was stored and the identity of the user storing it. The DMS may also extract metadata from the document automatically or prompt the user to add metadata. Some systems also use optical character recognition on scanned images, or perform text extraction on electronic documents. The resulting extracted text can be used to assist users in locating documents by identifying probable keywords or providing for full text search capability, or can be used on its own. Extracted text can also be stored as a component of metadata, stored with the image, or separately as a source for searching document collections.
Integration
Many document management systems attempt to integrate document management directly into other applications, so that users may retrieve existing documents directly from the document management system repository, make changes, and save the changed document back to the repository as a new version, all without leaving the application. Such integration is commonly available for office suites and e-mail or collaboration/groupware software. Integration often uses open standards such as ODMA, LDAP, WebDAV and SOAP to allow integration with other software and compliance with internal controls.[citation needed]
Capture
Images of paper documents using scanners or multifunction printers. Optical Character Recognition (OCR) software is often used, whether integrated into the hardware or as stand-alone software, in order to convert digital images into machine readable text.
Indexing
Track electronic documents. Indexing may be as simple as keeping track of unique document identifiers; but often it takes a more complex form, providing classification through the documents' metadata or even through word indexes extracted from the documents' contents. Indexing exists mainly to support retrieval. One area of critical importance for rapid retrieval is the creation of an index topology.
Storage
Store electronic documents. Storage of the documents often includes management of those same documents; where they are stored, for how long, migration of the documents from one storage media to another (Hierarchical storage management) and eventual document destruction.
Retrieval
Retrieve the electronic documents from the storage. Although the notion of retrieving a particular document is simple, retrieval in the electronic context can be quite complex and powerful. Simple retrieval of individual documents can be supported by allowing the user to specify the unique document identifier, and having the system use the basic index (or a non-indexed query on its data store) to retrieve the document. More flexible retrieval allows the user to specify partial search terms involving the document identifier and/or parts of the expected metadata. This would typically return a list of documents which match the user's search terms. Some systems provide the capability to specify a Boolean expression containing multiple keywords or example phrases expected to exist within the documents' contents. The retrieval for this kind of query may be supported by previously-built indexes, or may perform more time-consuming searches through the documents' contents to return a list of the potentially relevant documents. See also Document retrieval.
Distribution
A published document for distribution has to be in a format that can not be easily altered. As a common practice in law regulated industries, an original master copy of the document is usually never used for distribution other than archiving. If a document is to be distributed electronically in a regulatory environment, then the equipment tasking the job has to be quality endorsed AND validated. Similarly quality endorsed electronic distribution carriers have to be used. This approach applies to both of the systems by which the document is to be inter-exchanged, if the integrity of the document is highly in demand.
Security
Document security is vital in many document management applications. Compliance requirements for certain documents can be quite complex depending on the type of documents. For instance the Health Insurance Portability and Accountability Act (HIPAA) requirements dictate that medical documents have certain security requirements. Some document management systems have a rights management module that allows an administrator to give access to documents based on type to only certain people or groups of people.
Workflow
Workflow is a complex problem and some document management systems have a built in workflow module. There are different types of workflow. Usage depends on the environment the Electronic Document Management System (EDMS) is applied to. Manual workflow requires a user to view the document and decide who to send it to. Rules-based workflow allows an administrator to create a rule that dictates the flow of the document through an organization: for instance, an invoice passes through an approval process and then is routed to the accounts payable department. Dynamic rules allow for branches to be created in a workflow process. A simple example would be to enter an invoice amount and if the amount is lower than a certain set amount, it follows different routes through the organization.
Collaboration
Collaboration should be inherent in an EDMS. Documents should be capable of being retrieved by an authorized user and worked on. Access should be blocked to other users while work is being performed on the document.
Versioning
Versioning is a process by which documents are checked in or out of the document management system, allowing users to retrieve previous versions and to continue work from a selected point. Versioning is useful for documents that change over time and require updating, but it may be necessary to go back to a previous copy.
Publishing
Publishing a document is sometime tedious and involves the procedures of proofreading, peer or public reviewing, authorizing, printing and approving etc. Those steps endure prudence and logic thinking. Any careless handling may result in the inaccuracy of the document and therefore misleading or upset its users and readers. In law regulated industries, some of the procedures have to be completed with the evidences of their corresponding signatures and the dates on which the document is signed. Refer to the ISO divisions of ICS 01.140.40 and 35.240.30 for further information .
Standardization
Currently, the availability of the standards is perhaps scattered all over industries and it is not hard to adopt some of those for each business interest. The following is the list of some of the relevant ISO documents. Divisions ICS 01.140.10 and 01.140.20 . The ISO has also published a series of standards regarding the technical documentation, covered by the division of 01.110 .
NOTE:
Remanufactured Toner Cartridge
Weblog software
Weblog software (also called blog software or blogware) is a category of software which consists of a specialised form of Content Management Systems specifically designed for creating and maintaining weblogs.
Server models
Many weblog applications are available for users to download and install on their own systems. A wide variety of licenses are used by user hosted weblog software. Some of these are free and open-source that can be used, modified, and redistributed freely under free-software and open-source licenses. Others are proprietary software that may be licensed for a fee or have versions available free of charge.
Other weblog applications are offered only through their developers' hosts, either free of charge or for a fee. These typically include hosting service for the published blog itself, but some offer the option of using this hosted software to update a blog published
Clients
Maintenance through the Internet is a nearly universal feature of weblog software. This is usually done through a browser-based interface, enabling authors to create and update content on the site. Most software supports the use of external client software to update content using common APIs such as the MetaWeblog API and the Atom Publishing Protocol. Third party developers have created such clients, allowing bloggers to publish entries using desktop software rather than the web-based interface. WordPress Codex Wiki: Weblog Client has an extensive list of clients that support most APIs (not just WordPress). Examples include ecto and MarsEdit.
Comments are a way to provide discussion on blog entries. Readers can leave a comment on a post, which can correct errors or contain their opinion on the post or the post's subject. Services like coComment aim to ease discussion through comments, by allowing tracking of them.
Other applications
Most weblogs have features such as facilitating authoring and editing of blog posts or articles, various linking and web syndication features, and the ability to easily publish the blog to the world wide web. Some services or organizations are also creating weblog applications with extended features to aid communication, such as the wiki capabilities in Socialtext and Traction TeamPage.
Many weblog applications allow the user to define static pages of content which can often be placed into a hierarchy or tree. Pages differ from blog posts in that the content is largely static and not time related. Pages are often used to present information about the blog and its authors. Extensive use of pages can result in a blog that looks more like a website.
Most weblog applications support English and many other languages. The user selects a language during installation.
Weblog applications usually offer web syndication service either in the form of RSS or Atom. This allows for other software such as feed aggregators to maintain a current summary of the blog's content.
Post moderation requires the people who want to comment on articles that are posted on a blog to be approved before the comments are visible to the world. It could also mean in some cases where multiple people have accounts and the ability to post new items to the blog that new content must be approved by a moderator or administrator before it shows up on the main page. Weblog applications use various user account systems that allow readers to post comments to a particular blog. For instance, users with Blogger accounts may comment on any Blogger blog. Other weblog applications allow users to post content or comments only to blogs where they have an account.
The Post API can vary greatly depending on the system in use. Some types of blogware have plugins for Firefox that integrate into the browser's menus so that right-clicking on selected text on any given webpage will bring up a small window that allows the user to post to their blog. Other types of blogware that do not have this type of interface require a person to fill out a form online. The form that is required for posting material to a blog depends on the type of blogware. Some types such as Movable Type contain a greater number of form fields and choices than ones such as Blogger.
Most types of blogware support adding thumbnail images within blog posts. Photo blogging is a separate genre of blogging that deals primarily with images.
A new trend in blogging software is drag and drop WYSIWYG editing which allows a user to easily modify page elements on the fly. A few companies who pioneering this effort include Squarespace and Weebly.
Documentation and support
Different blogware packages feature varying levels of community support and documentation. Because the installation of some types of software requires an advanced knowledge of computer administration, community support and documentation can be very helpful. The web servers and database software can be more difficult to install than the blogware itself. Also a strong and active community surrounding the blogware gives advice on integrating the blogware into a personal site.
NOTE:
Server models
Many weblog applications are available for users to download and install on their own systems. A wide variety of licenses are used by user hosted weblog software. Some of these are free and open-source that can be used, modified, and redistributed freely under free-software and open-source licenses. Others are proprietary software that may be licensed for a fee or have versions available free of charge.
Other weblog applications are offered only through their developers' hosts, either free of charge or for a fee. These typically include hosting service for the published blog itself, but some offer the option of using this hosted software to update a blog published
Clients
Maintenance through the Internet is a nearly universal feature of weblog software. This is usually done through a browser-based interface, enabling authors to create and update content on the site. Most software supports the use of external client software to update content using common APIs such as the MetaWeblog API and the Atom Publishing Protocol. Third party developers have created such clients, allowing bloggers to publish entries using desktop software rather than the web-based interface. WordPress Codex Wiki: Weblog Client has an extensive list of clients that support most APIs (not just WordPress). Examples include ecto and MarsEdit.
Comments are a way to provide discussion on blog entries. Readers can leave a comment on a post, which can correct errors or contain their opinion on the post or the post's subject. Services like coComment aim to ease discussion through comments, by allowing tracking of them.
Other applications
Most weblogs have features such as facilitating authoring and editing of blog posts or articles, various linking and web syndication features, and the ability to easily publish the blog to the world wide web. Some services or organizations are also creating weblog applications with extended features to aid communication, such as the wiki capabilities in Socialtext and Traction TeamPage.
Many weblog applications allow the user to define static pages of content which can often be placed into a hierarchy or tree. Pages differ from blog posts in that the content is largely static and not time related. Pages are often used to present information about the blog and its authors. Extensive use of pages can result in a blog that looks more like a website.
Most weblog applications support English and many other languages. The user selects a language during installation.
Weblog applications usually offer web syndication service either in the form of RSS or Atom. This allows for other software such as feed aggregators to maintain a current summary of the blog's content.
Post moderation requires the people who want to comment on articles that are posted on a blog to be approved before the comments are visible to the world. It could also mean in some cases where multiple people have accounts and the ability to post new items to the blog that new content must be approved by a moderator or administrator before it shows up on the main page. Weblog applications use various user account systems that allow readers to post comments to a particular blog. For instance, users with Blogger accounts may comment on any Blogger blog. Other weblog applications allow users to post content or comments only to blogs where they have an account.
The Post API can vary greatly depending on the system in use. Some types of blogware have plugins for Firefox that integrate into the browser's menus so that right-clicking on selected text on any given webpage will bring up a small window that allows the user to post to their blog. Other types of blogware that do not have this type of interface require a person to fill out a form online. The form that is required for posting material to a blog depends on the type of blogware. Some types such as Movable Type contain a greater number of form fields and choices than ones such as Blogger.
Most types of blogware support adding thumbnail images within blog posts. Photo blogging is a separate genre of blogging that deals primarily with images.
A new trend in blogging software is drag and drop WYSIWYG editing which allows a user to easily modify page elements on the fly. A few companies who pioneering this effort include Squarespace and Weebly.
Documentation and support
Different blogware packages feature varying levels of community support and documentation. Because the installation of some types of software requires an advanced knowledge of computer administration, community support and documentation can be very helpful. The web servers and database software can be more difficult to install than the blogware itself. Also a strong and active community surrounding the blogware gives advice on integrating the blogware into a personal site.
NOTE:
Black Duck Software
Black Duck Software pioneered the automation of mixed-origin software component reuse management. The company’s products and services allow organizations to analyze the composition of software source code and binary files, search for reusable code, manage open source and third-party code approval, honor the legal obligations associated with mixed-origin code, and monitor related security vulnerabilities. Black Duck is considered a technology industry leader and often cited in media articles about open source.
Black Duck Software maintains an extensive KnowledgeBase (or knowledge base) of open source and third party components - most of which are available on the Internet. In the KnowledgeBase, each component is characterized by metadata such as license, language, version, author, and known security vulnerabilities. Black Duck products use this information to facilitate search, selection, approval, validation and tracking of software components. Black Duck Software maintains the open source search engine Koders.
The availability of open source software code on the Internet enables software developers to download open source code and incorporate it into run-time environments and new software under development. Since the code is obtained without being purchased, this practice can bypass traditional procurement management and legal review.
The use and redistribution of open source code is governed by a variety of software licenses, specifically open source licenses, some of which are quite complex. The terms and obligations of these licenses can conflict with one another or with an organization’s goals. The most common open source license is the GNU General Public License, or GPL, which includes obligations to credit the original author and copyright holder and to distribute the source code along with any derivative work.[5] The Black Duck Software website includes a free service providing information and analysis about open source licenses.
Open source software creates an efficient business model, incorporating a collaborative software development model. [7] However, modifying or redistributing open source while failing to honor open source license obligations creates legal liability for corporations and their officers. [8] In 2007, open source license infringement litigation went to court in the U.S. for the first time in a suit filed by the Software Freedom Law Center. [9] According to Mark Radcliffe, Deputy General Counsel for the Open Source Initiative, as current and future suits are decided, important case law precedents will be established about the remedies available to open source plaintiffs.
This is the context in which a niche market has developed for products and services from companies such as Black Duck Software that provide automation and information to manage the complexity of emergent composite software development models while avoiding business and legal risks.
History
Former President and CEO, Douglas Levin (Doug Levin), founded Black Duck in 2002, at a time when litigation over open source and software intellectual property began in the United States, including the high-profile SCO v. IBM case. The idea struck him that there should be an automated way to keep track of and verify software code origins.
Black Duck Software began shipping its first product, Protex, in 2004. In July 2004, the company had its first round of venture capital funding for $5 million, with investments from Flagship Ventures and General Catalyst Partners.
In March 2005, the company announced a hosted service, Black Duck Transact. In June 2005, a second round of funding added $12 million in investment capital led by Fidelity Ventures of Boston and including Intel Capital (a division of Intel Corporation (Nasdaq: INTC)) , SAP Ventures (a division of SAP AG) and Red Hat (Nasdaq: RHAT), along with existing investors Flagship Ventures and General Catalyst Partners.[15] Throughout 2005, the company created partnerships with other open source organizations, including Red Hat, the Open Source Software Institute, Sourceforge, and Olliance Group.
During 2006 Black Duck integrated Protex with the IBM Rational [34] management platform and released the Black Duck Export product.[17] Also in 2006, the company expanded its distribution network to include resellers in Australia, New Zealand, the UK, Israel, and Korea.
In February 2007, Black Duck Software completed a third round of venture capital investment for $12 million, led by Focus Ventures and also including existing investors. The company joined the Open Solutions Alliance in April 2007, received IBM SOA Specialty acceptance in October and, in November 2007, added distribution partners in Hong Kong. Also in November 2007, the company began a distribution partnership with NEC in Japan.
On January 28, 2008, Black Duck introduced Black Duck Code Center, a role-based management system for mixed-origin software development. On April 28th 2008, it was announced that Black Duck Software would acquire the assets and technologies of open source code search engine Koders. The Koders search engine will remain free of charge.
Products
Black Duck Software products include Protex, Transact, Export, and Code Center. Each application uses the Black Duck KnowledgeBase to identify and manage the reuse of open source and third party code. The Black Duck KnowledgeBase is continuously updated with downloadable code from Internet sites and software vendors, including development kits, proprietary applications, operating systems, and the associated proprietary and open source licenses.
Services
Black Duck Professional Services offer consulting about software compliance, open source software use and creating code reuse policies and procedures using Black Duck products. Black Duck also offers training and customer support services. [31]
Partners & Alliances
Black Duck Software collaborates in various ways with other companies and organizations in the open source sphere.
Technological integration with IBM Rational adds Black Duck functionality to executive-level software management. Open source consultancies work with Black Duck Software to help their clients adopt and implement open source policies that honor licenses while capturing the cost savings of open source software reuse.[32] Similarly, Black Duck has established partnerships with a number of law firms to provide accurate determination of software pedigree—especially helpful when preparing software asset valuation for mergers and acquisitions.[33]
Black Duck is a member of the Eclipse Foundation, the Open Solutions Alliance, and the Open Source Software Institute. Black Duck initiated the Compliance Vanguard Alliance to work with other open source technology firms by providing educational events and information to encourage best practices in managed open source adoption.
Trivia
The company was named after a pet duck that founder, Doug Levin, found and nursed back to health when he was seven years old. [35] In the Wikipedia article on American Black Duck we read it has long been considered a prize game bird, as it is “fast on the wing.”
NOTE:
Black Duck Software maintains an extensive KnowledgeBase (or knowledge base) of open source and third party components - most of which are available on the Internet. In the KnowledgeBase, each component is characterized by metadata such as license, language, version, author, and known security vulnerabilities. Black Duck products use this information to facilitate search, selection, approval, validation and tracking of software components. Black Duck Software maintains the open source search engine Koders.
The availability of open source software code on the Internet enables software developers to download open source code and incorporate it into run-time environments and new software under development. Since the code is obtained without being purchased, this practice can bypass traditional procurement management and legal review.
The use and redistribution of open source code is governed by a variety of software licenses, specifically open source licenses, some of which are quite complex. The terms and obligations of these licenses can conflict with one another or with an organization’s goals. The most common open source license is the GNU General Public License, or GPL, which includes obligations to credit the original author and copyright holder and to distribute the source code along with any derivative work.[5] The Black Duck Software website includes a free service providing information and analysis about open source licenses.
Open source software creates an efficient business model, incorporating a collaborative software development model. [7] However, modifying or redistributing open source while failing to honor open source license obligations creates legal liability for corporations and their officers. [8] In 2007, open source license infringement litigation went to court in the U.S. for the first time in a suit filed by the Software Freedom Law Center. [9] According to Mark Radcliffe, Deputy General Counsel for the Open Source Initiative, as current and future suits are decided, important case law precedents will be established about the remedies available to open source plaintiffs.
This is the context in which a niche market has developed for products and services from companies such as Black Duck Software that provide automation and information to manage the complexity of emergent composite software development models while avoiding business and legal risks.
History
Former President and CEO, Douglas Levin (Doug Levin), founded Black Duck in 2002, at a time when litigation over open source and software intellectual property began in the United States, including the high-profile SCO v. IBM case. The idea struck him that there should be an automated way to keep track of and verify software code origins.
Black Duck Software began shipping its first product, Protex, in 2004. In July 2004, the company had its first round of venture capital funding for $5 million, with investments from Flagship Ventures and General Catalyst Partners.
In March 2005, the company announced a hosted service, Black Duck Transact. In June 2005, a second round of funding added $12 million in investment capital led by Fidelity Ventures of Boston and including Intel Capital (a division of Intel Corporation (Nasdaq: INTC)) , SAP Ventures (a division of SAP AG) and Red Hat (Nasdaq: RHAT), along with existing investors Flagship Ventures and General Catalyst Partners.[15] Throughout 2005, the company created partnerships with other open source organizations, including Red Hat, the Open Source Software Institute, Sourceforge, and Olliance Group.
During 2006 Black Duck integrated Protex with the IBM Rational [34] management platform and released the Black Duck Export product.[17] Also in 2006, the company expanded its distribution network to include resellers in Australia, New Zealand, the UK, Israel, and Korea.
In February 2007, Black Duck Software completed a third round of venture capital investment for $12 million, led by Focus Ventures and also including existing investors. The company joined the Open Solutions Alliance in April 2007, received IBM SOA Specialty acceptance in October and, in November 2007, added distribution partners in Hong Kong. Also in November 2007, the company began a distribution partnership with NEC in Japan.
On January 28, 2008, Black Duck introduced Black Duck Code Center, a role-based management system for mixed-origin software development. On April 28th 2008, it was announced that Black Duck Software would acquire the assets and technologies of open source code search engine Koders. The Koders search engine will remain free of charge.
Products
Black Duck Software products include Protex, Transact, Export, and Code Center. Each application uses the Black Duck KnowledgeBase to identify and manage the reuse of open source and third party code. The Black Duck KnowledgeBase is continuously updated with downloadable code from Internet sites and software vendors, including development kits, proprietary applications, operating systems, and the associated proprietary and open source licenses.
Services
Black Duck Professional Services offer consulting about software compliance, open source software use and creating code reuse policies and procedures using Black Duck products. Black Duck also offers training and customer support services. [31]
Partners & Alliances
Black Duck Software collaborates in various ways with other companies and organizations in the open source sphere.
Technological integration with IBM Rational adds Black Duck functionality to executive-level software management. Open source consultancies work with Black Duck Software to help their clients adopt and implement open source policies that honor licenses while capturing the cost savings of open source software reuse.[32] Similarly, Black Duck has established partnerships with a number of law firms to provide accurate determination of software pedigree—especially helpful when preparing software asset valuation for mergers and acquisitions.[33]
Black Duck is a member of the Eclipse Foundation, the Open Solutions Alliance, and the Open Source Software Institute. Black Duck initiated the Compliance Vanguard Alliance to work with other open source technology firms by providing educational events and information to encourage best practices in managed open source adoption.
Trivia
The company was named after a pet duck that founder, Doug Levin, found and nursed back to health when he was seven years old. [35] In the Wikipedia article on American Black Duck we read it has long been considered a prize game bird, as it is “fast on the wing.”
NOTE:
Outbound Laptop
The Outbound Laptop was an Apple Macintosh-compatible laptop computer. It was powered by a 15-MHz Motorola 68000 processor. Later versions increased the clock speed to 20 MHz.
Introduced in 1989, at over 4 kg the Outbound Laptop was significantly lighter and easier to carry than Apple's own Macintosh Portable, which became available at around the same time. However, due to Apple's refusal to license its software in read-only memory (ROM), Outbound users had to install a Mac ROM to make the computer work. The ROM was typically removed from an older Mac, a process that would render the donor Mac unusable. Even with this additional cost, a typical price of US $4,000 compared favorably to that of the Mac Portable.
The Outbound featured a built-in pointing device located below the keyboard; it was a cylinder that scrolled up and down and slid left and right.
Another popular feature is that the Outbound ran on standard camcorder batteries, rather than expensive custom batteries, as was common for most portable computers.
The Outbound Laptop was succeeded by the Outbound Notebook in 1991. Apple's introduction of the PowerBook later that year led to the demise of the Mac-compatible laptop market. Probably more significant than the increased competition, was the fact that the Outbound was using ROMs under a licensing agreement with Apple. Apple refused to license the use of subsequent proprietary ROMs to Outbound and so the company's ability to manufacture laptops ended when the 68000 processors became too difficult to obtain. For a short time after Outbound went out of business a small group of former employees set up a company to handle service and warranty issues.
The company, Outbound Systems, was located at 4840 Pearl East Circle, Boulder, CO 80301; (303) 786-9200, (800) 444-4607. Due to the kangaroo logo, many believed that it was an Australian firm.
NOTE:
Super Expander
The VIC-1211 Super Expander was a cartridge for the Commodore VIC-20 home computer. It was designed to provide several extensions to the BASIC interpreter on the computer, mostly to help with programming graphics and sound. It also provided approximately 3KB of extra RAM. The cartridge was created by Commodore Business Machines (CBM) and released in 1981.
Description
The dialect of BASIC bundled with the VIC-20, Commodore BASIC V2.0, was notorious for its sparse functionality. It didn't even match the features of Commodore's older line of computers, the PET which featured Commodore BASIC version 4.0. As a result it was outdated by the VIC-20's release and seemed quite primitive compared to BASIC dialects available on other microcomputers. To be fair, the decision by Commodore to recycle the old BASIC, and the fact that it could fit in just 16K ROM (including the KERNAL), helped keep the VIC-20's price to a minimum and so contributed to its huge success. Plus it was stable and almost entirely bug-free.
Nevertheless, not only did "VIC BASIC" lack commands considered fundamental to the BASIC language, such as "else" and "renum", but graphics and sound effects were completely unsupported. To use VIC-20's graphics and sound programmers had to "PEEK and POKE" bytes directly from/to the VIC-20's graphics/sound hardware, the 6560 Video Interface Chip (VIC). This made programming quite tedious and error prone since cryptic memory addresses and codes had to be used constantly, and many statements were required to do even simple tasks. As a result these programs tended to bloat, which in turn blew out efficiency and execution times. Such a thing was death in the tiny RAM and slow interpreted BASIC paradigm of the day.
Programmers could mitigate these problems by using machine code, to an extent, but this in itself was a tedious process. So to address these shortcomings Commodore created the Super Expander cartridge. It provided extra BASIC commands to facilitate using graphics and sound on the VIC-20. It also had commands to read the joystick and lightpen, and unlocked the use of function keys.
Graphics
The VIC-20 did not support high resolution graphics directly. Hi-res graphics were implemented by "painting" the display with characters, and "redefining" the character bitmaps on the fly. This was a complex and long-winded process; implementing it in a BASIC program was virtually useless due to the execution time required to draw anything.
The Super Expander took care of all the hard work. It allowed the programmer to draw points, lines, ellipses and arcs, and to paint enclosed regions, with one-line statements. All the VIC-20's 16 colours could be used, although with restrictions due to limitations of the 6560 chip. Display resolution was 160×160 pixels, throttled down from 192×200 allowed by the 6560 chip, probably to minimise the amount of RAM required. Multicolor hi-res was supported (with a resolution of 80×160) and could be mixed with normal hi-res. Graphics and plain text could also be mixed on-screen.
Sound
The VIC-20's sound capability was uncomplicated, so programming sound effects using "PEEK and POKE" was not so much of a chore as programming graphics. Even so the Super Expander provided a command to play simple tones on the VIC-20's four voice channels, and to control the volume.
Music playback was unsupported on the VIC-20; the usual way of implementing a musical note was to play a tone inside a for loop time delay. In contrast, with Super Expander musical scores could played by simply PRINTing a string of characters. (Music strings were distinguished from regular strings using a special reverse-control-character, familiar to anyone who has used colours or cursor controls in VIC-20 programs.) Each of the VIC-20's four voice channels could play their own scores simultaneously, giving harmonious effects which could be striking by the standards of the time.
Other devices
Super Expander provided commands to read the status of the joystick and paddles, and the position of the lightpen. In the case of the joystick, since it was the "digital" or "switch" type, further bit-fiddling was required to decode its position.
Function keys
Ordinarily the VIC-20's function keys could only be used in a program, by scanning for the appropriate key code when reading the keyboard. In the VIC-20's "immediate" (or "calculator") mode they were not available to do anything. With the Super Expander the function keys could be assigned to execute commands in immediate mode. By default they came pre-programmed with the most common BASIC commands, in a similar fashion to GW-BASIC on the IBM PC. The user could then assign their own commands, or any arbitrary string in fact, to the function keys.
Drawbacks
Commodore designed the Super Expander to map the graphics display to a 1024×1024 coordinate system. Under this scheme, each "virtual" pixel was 6.4 (or 12.8) video pixels in size. This meant that in order to place pixels in exact positions on the screen a further scaling operation had to be coded in. Similar functionality was provided on BASIC 3.5 and 7.0 via the SCALE command, but in these versions of BASIC, scaling was optional and could be done to any arbitrary user-specified size.
The aspect ratio of the output device (i.e. television set) was not taken into account by the coordinate system. So a circle sized, say, 300×300 would appear elliptical. Similarly, a line drawn from (0,0) to (300,300) would not be displayed as 45°.
When drawing circle arcs, the starting and ending angles had to be specified in "gradians". In this "metric" angular system there are 400 gradians (also called "grads" or "gons") to the circle, as opposed to the familiar 360 degrees. (One can use gradians on most scientific calculators and even with Microsoft Calculator.) It is a mystery why Commodore chose this obscure and unconventional unit of measure—perhaps at the time there was a push by academia to supersede the unmetric and homophonous degree with something "better". Commodore did not implement it properly, dividing the circle into 100 gradians rather than 400.
The Super Expander had no capability to put a bitmap to the display. This meant arbitrary bitmaps, as might be used in a hi-res game, had to drawn pixel-by-pixel. The slowness of the BASIC interpreter made this unsuitable for applications like arcade-style games. As a result Super Expander’s usefulness was really hamstrung, consigning it to shape-centric drawings such as charts and simple pictures, or adventure-style games.
Programs written using the extra Super Expander commands were not portable. A user needed to own the cartridge and have it installed before a program written with the additional commands would run. Loading the program onto an unexpanded VIC-20 gave errors. Therefore the range of software released to take advantage of the Super Expander’s capabilities, including type-in programs published in magazines, was very small. This limited the Super Expander’s appeal and usefulness.
In spite of the above, the Super Expander’s features filled many of the gaps in the VIC-20's programming environment. It must also be remembered that similar microcomputers on the market suffered the same, or equivalent, shortcomings.
NOTE:
Description
The dialect of BASIC bundled with the VIC-20, Commodore BASIC V2.0, was notorious for its sparse functionality. It didn't even match the features of Commodore's older line of computers, the PET which featured Commodore BASIC version 4.0. As a result it was outdated by the VIC-20's release and seemed quite primitive compared to BASIC dialects available on other microcomputers. To be fair, the decision by Commodore to recycle the old BASIC, and the fact that it could fit in just 16K ROM (including the KERNAL), helped keep the VIC-20's price to a minimum and so contributed to its huge success. Plus it was stable and almost entirely bug-free.
Nevertheless, not only did "VIC BASIC" lack commands considered fundamental to the BASIC language, such as "else" and "renum", but graphics and sound effects were completely unsupported. To use VIC-20's graphics and sound programmers had to "PEEK and POKE" bytes directly from/to the VIC-20's graphics/sound hardware, the 6560 Video Interface Chip (VIC). This made programming quite tedious and error prone since cryptic memory addresses and codes had to be used constantly, and many statements were required to do even simple tasks. As a result these programs tended to bloat, which in turn blew out efficiency and execution times. Such a thing was death in the tiny RAM and slow interpreted BASIC paradigm of the day.
Programmers could mitigate these problems by using machine code, to an extent, but this in itself was a tedious process. So to address these shortcomings Commodore created the Super Expander cartridge. It provided extra BASIC commands to facilitate using graphics and sound on the VIC-20. It also had commands to read the joystick and lightpen, and unlocked the use of function keys.
Graphics
The VIC-20 did not support high resolution graphics directly. Hi-res graphics were implemented by "painting" the display with characters, and "redefining" the character bitmaps on the fly. This was a complex and long-winded process; implementing it in a BASIC program was virtually useless due to the execution time required to draw anything.
The Super Expander took care of all the hard work. It allowed the programmer to draw points, lines, ellipses and arcs, and to paint enclosed regions, with one-line statements. All the VIC-20's 16 colours could be used, although with restrictions due to limitations of the 6560 chip. Display resolution was 160×160 pixels, throttled down from 192×200 allowed by the 6560 chip, probably to minimise the amount of RAM required. Multicolor hi-res was supported (with a resolution of 80×160) and could be mixed with normal hi-res. Graphics and plain text could also be mixed on-screen.
Sound
The VIC-20's sound capability was uncomplicated, so programming sound effects using "PEEK and POKE" was not so much of a chore as programming graphics. Even so the Super Expander provided a command to play simple tones on the VIC-20's four voice channels, and to control the volume.
Music playback was unsupported on the VIC-20; the usual way of implementing a musical note was to play a tone inside a for loop time delay. In contrast, with Super Expander musical scores could played by simply PRINTing a string of characters. (Music strings were distinguished from regular strings using a special reverse-control-character, familiar to anyone who has used colours or cursor controls in VIC-20 programs.) Each of the VIC-20's four voice channels could play their own scores simultaneously, giving harmonious effects which could be striking by the standards of the time.
Other devices
Super Expander provided commands to read the status of the joystick and paddles, and the position of the lightpen. In the case of the joystick, since it was the "digital" or "switch" type, further bit-fiddling was required to decode its position.
Function keys
Ordinarily the VIC-20's function keys could only be used in a program, by scanning for the appropriate key code when reading the keyboard. In the VIC-20's "immediate" (or "calculator") mode they were not available to do anything. With the Super Expander the function keys could be assigned to execute commands in immediate mode. By default they came pre-programmed with the most common BASIC commands, in a similar fashion to GW-BASIC on the IBM PC. The user could then assign their own commands, or any arbitrary string in fact, to the function keys.
Drawbacks
Commodore designed the Super Expander to map the graphics display to a 1024×1024 coordinate system. Under this scheme, each "virtual" pixel was 6.4 (or 12.8) video pixels in size. This meant that in order to place pixels in exact positions on the screen a further scaling operation had to be coded in. Similar functionality was provided on BASIC 3.5 and 7.0 via the SCALE command, but in these versions of BASIC, scaling was optional and could be done to any arbitrary user-specified size.
The aspect ratio of the output device (i.e. television set) was not taken into account by the coordinate system. So a circle sized, say, 300×300 would appear elliptical. Similarly, a line drawn from (0,0) to (300,300) would not be displayed as 45°.
When drawing circle arcs, the starting and ending angles had to be specified in "gradians". In this "metric" angular system there are 400 gradians (also called "grads" or "gons") to the circle, as opposed to the familiar 360 degrees. (One can use gradians on most scientific calculators and even with Microsoft Calculator.) It is a mystery why Commodore chose this obscure and unconventional unit of measure—perhaps at the time there was a push by academia to supersede the unmetric and homophonous degree with something "better". Commodore did not implement it properly, dividing the circle into 100 gradians rather than 400.
The Super Expander had no capability to put a bitmap to the display. This meant arbitrary bitmaps, as might be used in a hi-res game, had to drawn pixel-by-pixel. The slowness of the BASIC interpreter made this unsuitable for applications like arcade-style games. As a result Super Expander’s usefulness was really hamstrung, consigning it to shape-centric drawings such as charts and simple pictures, or adventure-style games.
Programs written using the extra Super Expander commands were not portable. A user needed to own the cartridge and have it installed before a program written with the additional commands would run. Loading the program onto an unexpanded VIC-20 gave errors. Therefore the range of software released to take advantage of the Super Expander’s capabilities, including type-in programs published in magazines, was very small. This limited the Super Expander’s appeal and usefulness.
In spite of the above, the Super Expander’s features filled many of the gaps in the VIC-20's programming environment. It must also be remembered that similar microcomputers on the market suffered the same, or equivalent, shortcomings.
NOTE:
Word (computing)
In computing, "word" is a term for the natural unit of data used by a particular computer design. A word is simply a fixed-sized group of bits that are handled together by the machine. The number of bits in a word (the word size or word length) is an important characteristic of a computer architecture.
The size of a word is reflected in many aspects of a computer's structure and operation. The majority of the registers in the computer are usually word-sized. The typical numeric value manipulated by the computer is probably word sized. The amount of data transferred between the processing part of the computer and the memory system is most often a word. An address used to designate a location in memory often fits in a word.
Modern computers usually have a word size of 16, 32, or 64 bits. Many other sizes have been used in the past, including 8, 9, 12, 18, 24, 36, 39, 40, 48, and 60 bits; the slab is an example of an early word size. Some of the earliest computers were decimal rather than binary, typically having a word size of 10 or 12 decimal digits, and some early computers had no fixed word length at all.
Sometimes the size of a word is defined to be a particular value for compatibility with earlier computers. The most common microprocessors used in personal computers (for instance, the Intel Pentiums and AMD Athlons) are an example of this. Their IA-32 architecture is an extension of the original Intel 8086 design which had a word size of 16 bits. The IA-32 processors still support 8086 (x86) programs, so the meaning of "word" in the IA-32 context was kept the same, and is still said to be 16 bits, despite the fact that they at times (especially when the default operand size is 32-bit) operate largely like a machine with a 32 bit word size. Similarly in the newer x86-64 architecture, a "word" is still 16 bits, although 64-bit ("quadruple word") operands may be more common.
Uses of words
Depending on how a computer is organized, units of the word size may be used for:
Integer numbers – Holders for integer numerical values may be available in one or in several different sizes, but one of the sizes available will almost always be the word. The other sizes, if any, are likely to be multiples or fractions of the word size. The smaller sizes are normally used only for efficient use of memory; when loaded into the processor, their values usually go into a larger, word-sized holder.
Floating point numbers – Holders for floating point numerical values are typically either a word or a multiple of a word.
Addresses – Holders for memory addresses must be of a size capable of expressing the needed range of values, but not be excessively large. Often the size used is that of the word, but it can also be a multiple or fraction of the word size.
Registers – Processor registers are designed with a size appropriate for the type of data they hold, e.g. integers, floating point numbers, or addresses. Many computer architectures use "general purpose" registers that can hold any of several types of data; those registers are sized to allow the largest of any of those types, and typically that size is the word size of the architecture.
Memory-processor transfer – When the processor reads from the memory subsystem into a register, or writes a register's value to memory, the amount of data transferred is often a word. In simple memory subsystems, the word is transferred over the memory data bus, which typically has a width of a word or half word. In memory subsystems that use caches, the word-sized transfer is the one between the processor and the first level of cache; at lower levels of the memory hierarchy larger transfers (which are a multiple of the word size) are normally used.
Unit of address resolution – In a given architecture, successive address values designate successive units of memory; this unit is the unit of address resolution. In most computers, the unit is either a character (e.g. a byte) or a word. (A few computers have used bit resolution.) If the unit is a word, then a larger amount of memory can be accessed using an address of a given size. On the other hand, if the unit is a byte, then individual characters can be addressed (i.e. selected during the memory operation).
Instructions – Machine instructions are normally fractions or multiples of the architecture's word size. This is a natural choice since instructions and data usually share the same memory subsystem. In Harvard architectures the word sizes of instructions and data need not be related.
Word size choice
When a computer architecture is designed, the choice of a word size is of substantial importance. There are design considerations which encourage particular bit-group sizes for particular uses (e.g. for addresses), and these considerations point to different sizes for different uses. However, considerations of economy in design strongly push for one size, or a very few sizes related by multiples or fractions (submultiples) to a primary size. That preferred size becomes the word size of the architecture.
Character size is one of the influences on a choice of word size. Before the mid-1960s, characters were most often stored in six bits; this allowed no more than 64 characters, so alphabetics were limited to upper case. Since it is efficient in time and space to have the word size be a multiple of the character size, word sizes in this period were usually multiples of 6 bits (in binary machines). A common choice then was the 36-bit word, which is also a good size for the numeric properties of a floating point format.
After the introduction of the IBM System/360 design which used eight-bit characters and supported lower-case letters, the standard size of a character (or more accurately, a byte) became eight bits. Word sizes thereafter were naturally multiples of eight bits, with 16, 32, and 64 bits being commonly used.
Variable word architectures
Early machine designs included some that used what is often termed a variable word length. In this type of organization, a numeric operand had no fixed length but rather its end was detected when a character with a special marking was encountered. Such machines often used binary coded decimal for numbers. This class of machines included the IBM 702, IBM 705, IBM 7080, IBM 7010, UNIVAC 1050, IBM 1401, and IBM 1620.
Most of these machines work on one unit of memory at a time and since each instruction or datum is several units long, each instruction takes several cycles just to access memory. These machines are often quite slow because of this. For example, instruction fetches on an IBM 1620 Model I take 8 cycles just to read the 12 digits of the instruction (the Model II reduced this to 6 cycles, but reduced the fetch times to 4 cycles if both address fields were not needed by the instruction). Instruction execution took a completely variable number of cycles, depending on the size of the operands.
Word and byte addressing
The memory model of an architecture is strongly influenced by the word size. In particular, the resolution of a memory address, that is, the smallest unit that can be designated by an address, has often been chosen to be the word. In this approach, address values which differ by one designate adjacent memory words. This is natural in machines which deal almost always in word (or multiple-word) units, and has the advantage of allowing instructions to use minimally-sized fields to contain addresses, which can permit a smaller instruction size or a larger variety of instructions.
When byte processing is to be a significant part of the workload, it is usually more advantageous to use the byte, rather than the word, as the unit of address resolution. This allows an arbitrary character within a character string to be addressed straightforwardly. A word can still be addressed, but the address to be used requires a few more bits than the word-resolution alternative. The word size needs to be an integral multiple of the character size in this organization. This addressing approach was used in the IBM 360, and has been the most common approach in machines designed since then.
The power of 2
Data values may occupy differing sizes of memory, because, for instance, some numbers need to be capable of having greater precision than others. The commonly used sizes are usually chosen to be a power of 2 multiple of the unit of address resolution (byte or word). This is convenient because converting the index of an item in an array into the address of the item then requires only a shift operation (which is just a conductor routing in hardware) rather than a multiplication. In some cases this relationship can also avoid the use of division operations. As a result, most modern computer designs have word sizes (and other operand sizes) that are a power of 2 times the size of a byte.
Size families
As computer designs have grown more complex, the central importance of a single word size to an architecture has decreased. Although more capable hardware can use a wider variety of sizes of data, market forces exert pressure to maintain backward compatibility while extending processor capability. As a result, what might have been the central word size in a fresh design has to coexist as an alternative size to the original word size in a backward compatible design. The original word size remains available in future designs, forming the basis of a size family.
In the mid-1970s, DEC designed the VAX to be a successor of the PDP-11. Perhaps for conceptual compatibility, they used "word" for a 16-bit quantity while they used the term "longword" to refer to a 32-bit quantity. This is in contrast to earlier machines, where something that is one word would be called a word, while a quantity that is one half a word would be called, if anything, a halfword. This is a terminological quirk, since the VAX is clearly a 32-bit machine in all important respects. As well, a "quadword" is 64 bits.
A major example of this can be seen in the x86 designs. The original 8086 architecture clearly used a word size of 16 bits. The significantly-enhanced design of the 80386 added to the 8086 base an organization which was based around units of 32 bits. If it were an unencumbered design, it would have had a 32-bit "word", but as an extension of the 8086, its "word" continued to be considered to be 16 bits.
Part of the confusion, the 8086 has methods to access more than 64 KiB with a 16-bit address, while the 286 extended it to some byzantine methods. The 386 extended it more. More important, the 386 provided a mode where one can have a "flat" 32-bit address space. The segmented addressing was always, at best, troublesome, while mixing 16- and 32-bit was more or less a nightmare. Programmers desired to move to 32-bit addressing as quickly as possible. This took a long time because of 286 compatibility issues. But that's what happened. Therefore, the 386 (et seq) as used is no different from the earlier VAX and machines at the same time such as the 68K and SPARC.
This same situation has recently recurred in the same line, as the AMD64 architectural extensions bring the 64-bit size into a major position without dropping any of the 16- and 32-bit support.
Thus one sees that today a computer architecture is based on a family of closely related sizes more than on a single omnipresent word size. The sizes are intimately related to one another by integral factors, usually a power of two. Calling any one of them the architecture's word size may be somewhat arbitrary, and a size may be so designated due to the history of the architecture's evolution rather than the properties of the size itself in a recent design.
Dword, Qword, and Oword
In computer science, a dword (double word) is a unit of data that is twice the size of a word. On the x86 platforms, which have a word size of 16 bits, a dword unit of data is 32 bits long.
A qword (or quadword, or quadruple word) is a unit of data that is four times the size of a word. On the common x86 platforms, this unit of data is 64 bits because the size of a word on an x86 system is defined to be 16 bits (whether the particular machine works primarily with 16, 32, or 64 bit items).
Finally, Intel uses the term double quadruple word, or DQWord, to denote a 128-bit datum, found in the implementation of Streaming SIMD Extensions and its ancestors. Microsoft Macro Assembler uses oword (octuple word) for the same data size.
NOTE:
The size of a word is reflected in many aspects of a computer's structure and operation. The majority of the registers in the computer are usually word-sized. The typical numeric value manipulated by the computer is probably word sized. The amount of data transferred between the processing part of the computer and the memory system is most often a word. An address used to designate a location in memory often fits in a word.
Modern computers usually have a word size of 16, 32, or 64 bits. Many other sizes have been used in the past, including 8, 9, 12, 18, 24, 36, 39, 40, 48, and 60 bits; the slab is an example of an early word size. Some of the earliest computers were decimal rather than binary, typically having a word size of 10 or 12 decimal digits, and some early computers had no fixed word length at all.
Sometimes the size of a word is defined to be a particular value for compatibility with earlier computers. The most common microprocessors used in personal computers (for instance, the Intel Pentiums and AMD Athlons) are an example of this. Their IA-32 architecture is an extension of the original Intel 8086 design which had a word size of 16 bits. The IA-32 processors still support 8086 (x86) programs, so the meaning of "word" in the IA-32 context was kept the same, and is still said to be 16 bits, despite the fact that they at times (especially when the default operand size is 32-bit) operate largely like a machine with a 32 bit word size. Similarly in the newer x86-64 architecture, a "word" is still 16 bits, although 64-bit ("quadruple word") operands may be more common.
Uses of words
Depending on how a computer is organized, units of the word size may be used for:
Integer numbers – Holders for integer numerical values may be available in one or in several different sizes, but one of the sizes available will almost always be the word. The other sizes, if any, are likely to be multiples or fractions of the word size. The smaller sizes are normally used only for efficient use of memory; when loaded into the processor, their values usually go into a larger, word-sized holder.
Floating point numbers – Holders for floating point numerical values are typically either a word or a multiple of a word.
Addresses – Holders for memory addresses must be of a size capable of expressing the needed range of values, but not be excessively large. Often the size used is that of the word, but it can also be a multiple or fraction of the word size.
Registers – Processor registers are designed with a size appropriate for the type of data they hold, e.g. integers, floating point numbers, or addresses. Many computer architectures use "general purpose" registers that can hold any of several types of data; those registers are sized to allow the largest of any of those types, and typically that size is the word size of the architecture.
Memory-processor transfer – When the processor reads from the memory subsystem into a register, or writes a register's value to memory, the amount of data transferred is often a word. In simple memory subsystems, the word is transferred over the memory data bus, which typically has a width of a word or half word. In memory subsystems that use caches, the word-sized transfer is the one between the processor and the first level of cache; at lower levels of the memory hierarchy larger transfers (which are a multiple of the word size) are normally used.
Unit of address resolution – In a given architecture, successive address values designate successive units of memory; this unit is the unit of address resolution. In most computers, the unit is either a character (e.g. a byte) or a word. (A few computers have used bit resolution.) If the unit is a word, then a larger amount of memory can be accessed using an address of a given size. On the other hand, if the unit is a byte, then individual characters can be addressed (i.e. selected during the memory operation).
Instructions – Machine instructions are normally fractions or multiples of the architecture's word size. This is a natural choice since instructions and data usually share the same memory subsystem. In Harvard architectures the word sizes of instructions and data need not be related.
Word size choice
When a computer architecture is designed, the choice of a word size is of substantial importance. There are design considerations which encourage particular bit-group sizes for particular uses (e.g. for addresses), and these considerations point to different sizes for different uses. However, considerations of economy in design strongly push for one size, or a very few sizes related by multiples or fractions (submultiples) to a primary size. That preferred size becomes the word size of the architecture.
Character size is one of the influences on a choice of word size. Before the mid-1960s, characters were most often stored in six bits; this allowed no more than 64 characters, so alphabetics were limited to upper case. Since it is efficient in time and space to have the word size be a multiple of the character size, word sizes in this period were usually multiples of 6 bits (in binary machines). A common choice then was the 36-bit word, which is also a good size for the numeric properties of a floating point format.
After the introduction of the IBM System/360 design which used eight-bit characters and supported lower-case letters, the standard size of a character (or more accurately, a byte) became eight bits. Word sizes thereafter were naturally multiples of eight bits, with 16, 32, and 64 bits being commonly used.
Variable word architectures
Early machine designs included some that used what is often termed a variable word length. In this type of organization, a numeric operand had no fixed length but rather its end was detected when a character with a special marking was encountered. Such machines often used binary coded decimal for numbers. This class of machines included the IBM 702, IBM 705, IBM 7080, IBM 7010, UNIVAC 1050, IBM 1401, and IBM 1620.
Most of these machines work on one unit of memory at a time and since each instruction or datum is several units long, each instruction takes several cycles just to access memory. These machines are often quite slow because of this. For example, instruction fetches on an IBM 1620 Model I take 8 cycles just to read the 12 digits of the instruction (the Model II reduced this to 6 cycles, but reduced the fetch times to 4 cycles if both address fields were not needed by the instruction). Instruction execution took a completely variable number of cycles, depending on the size of the operands.
Word and byte addressing
The memory model of an architecture is strongly influenced by the word size. In particular, the resolution of a memory address, that is, the smallest unit that can be designated by an address, has often been chosen to be the word. In this approach, address values which differ by one designate adjacent memory words. This is natural in machines which deal almost always in word (or multiple-word) units, and has the advantage of allowing instructions to use minimally-sized fields to contain addresses, which can permit a smaller instruction size or a larger variety of instructions.
When byte processing is to be a significant part of the workload, it is usually more advantageous to use the byte, rather than the word, as the unit of address resolution. This allows an arbitrary character within a character string to be addressed straightforwardly. A word can still be addressed, but the address to be used requires a few more bits than the word-resolution alternative. The word size needs to be an integral multiple of the character size in this organization. This addressing approach was used in the IBM 360, and has been the most common approach in machines designed since then.
The power of 2
Data values may occupy differing sizes of memory, because, for instance, some numbers need to be capable of having greater precision than others. The commonly used sizes are usually chosen to be a power of 2 multiple of the unit of address resolution (byte or word). This is convenient because converting the index of an item in an array into the address of the item then requires only a shift operation (which is just a conductor routing in hardware) rather than a multiplication. In some cases this relationship can also avoid the use of division operations. As a result, most modern computer designs have word sizes (and other operand sizes) that are a power of 2 times the size of a byte.
Size families
As computer designs have grown more complex, the central importance of a single word size to an architecture has decreased. Although more capable hardware can use a wider variety of sizes of data, market forces exert pressure to maintain backward compatibility while extending processor capability. As a result, what might have been the central word size in a fresh design has to coexist as an alternative size to the original word size in a backward compatible design. The original word size remains available in future designs, forming the basis of a size family.
In the mid-1970s, DEC designed the VAX to be a successor of the PDP-11. Perhaps for conceptual compatibility, they used "word" for a 16-bit quantity while they used the term "longword" to refer to a 32-bit quantity. This is in contrast to earlier machines, where something that is one word would be called a word, while a quantity that is one half a word would be called, if anything, a halfword. This is a terminological quirk, since the VAX is clearly a 32-bit machine in all important respects. As well, a "quadword" is 64 bits.
A major example of this can be seen in the x86 designs. The original 8086 architecture clearly used a word size of 16 bits. The significantly-enhanced design of the 80386 added to the 8086 base an organization which was based around units of 32 bits. If it were an unencumbered design, it would have had a 32-bit "word", but as an extension of the 8086, its "word" continued to be considered to be 16 bits.
Part of the confusion, the 8086 has methods to access more than 64 KiB with a 16-bit address, while the 286 extended it to some byzantine methods. The 386 extended it more. More important, the 386 provided a mode where one can have a "flat" 32-bit address space. The segmented addressing was always, at best, troublesome, while mixing 16- and 32-bit was more or less a nightmare. Programmers desired to move to 32-bit addressing as quickly as possible. This took a long time because of 286 compatibility issues. But that's what happened. Therefore, the 386 (et seq) as used is no different from the earlier VAX and machines at the same time such as the 68K and SPARC.
This same situation has recently recurred in the same line, as the AMD64 architectural extensions bring the 64-bit size into a major position without dropping any of the 16- and 32-bit support.
Thus one sees that today a computer architecture is based on a family of closely related sizes more than on a single omnipresent word size. The sizes are intimately related to one another by integral factors, usually a power of two. Calling any one of them the architecture's word size may be somewhat arbitrary, and a size may be so designated due to the history of the architecture's evolution rather than the properties of the size itself in a recent design.
Dword, Qword, and Oword
In computer science, a dword (double word) is a unit of data that is twice the size of a word. On the x86 platforms, which have a word size of 16 bits, a dword unit of data is 32 bits long.
A qword (or quadword, or quadruple word) is a unit of data that is four times the size of a word. On the common x86 platforms, this unit of data is 64 bits because the size of a word on an x86 system is defined to be 16 bits (whether the particular machine works primarily with 16, 32, or 64 bit items).
Finally, Intel uses the term double quadruple word, or DQWord, to denote a 128-bit datum, found in the implementation of Streaming SIMD Extensions and its ancestors. Microsoft Macro Assembler uses oword (octuple word) for the same data size.
NOTE:
Game port
The game port is the traditional connector for video game input devices on x86-based PCs. Since about 1990, the game port is usually integrated with a PC I/O or sound card, either ISA or PCI, or as an on-board feature of some motherboards; before that, it was usually on a dedicated ISA card. Microsoft has discontinued game port support with Windows Vista, so it is probable that manufacturers will cease to produce boards with this connector. However, it's still entirely possible to provide third-party drivers that will work with the gameport, and some companies that have produced game port cards in the past do so.
Analog interface
Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. Early IBM-PC manuals describe this port as suitable for connecting two analog paddles rather than joysticks. This approach has historically given the IBM-PC an advantage in simulation games, especially flight simulators, but on the other hand, rendered the design and use of simpler arcade or console joysticks more complex and needlessly convoluted, apart from being essentially incompatible with any existing joystick interface, most notably the de facto standard DE-9 connector Atari joysticks.
Acquisition and programming
Also, while other joystick standards (such as Atari or NES joysticks) are very easy and straightforward to use by programmers, the game port requires careful programming and well-timed software interrupt triggering in order to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port.
Circuits
The typical implementation of a gameport uses a capacitor and a simple voltage comparator, which together form a sort of crude ramp-compare ADC, which needs to be periodically polled and reset at precise moments in order to read an input, something that needs to be done several times (generally above 30) per second in order to provide a responsive game input, and the actual acquisition frequency and value typically depend on the joystick's internal resistance, noise, CPU speed and the total joystick-capacitor's RC time constant.
Known issues
Its analog nature has also been the cause of many problems e.g. all kinds of joysticks needed "calibration", even arcade-style ones since no game controller and no joystick produced the same measurements each time, but they were dependent on the exact way acquisition was made and even on the CPU's speed in some rather poor designs. Also, all kinds of PC Gameports suffer from electrical noise.
The calibration procedure is still required at some phase, even under modern operating systems such as Windows XP and usually consists of moving the joystick around all of its axes in order to measure the maximum axis excursion values, no matter if the joystick uses analog signals (from potentiometers) or digital signals (using microswitches or contacts). USB joysticks do not require calibration, in general.
In the days of DOS, each game using the gameport(s) had to do its own calibration, often each time the game started, and some poorly coded calibration routines even failed to work consistently and properly, rendering some joysticks unusable with some games. With Windows XP, only one calibration per joystick is enough, which is assumed "valid" until a joystick is unplugged.
Certain applications and games were (and are) however able to use some analog joysticks without explicit calibration, under certain restricted conditions. In general, if only a purely directional input with no precise intensity information is required, an analog joystick can be "self calibrated" just by leaving the joystick in the middle position and taking a measurement, and then using some arbitrary or adaptive threshold in order to detect movement and excursion from the middle position. The limitation of this method is that the reading of the same joystick over the same gameport can change over time, and some joysticks cannot work at all with this method. Also, the joystick must be in the middle position at least once when the implicit "self calibration" takes place, even if not explicitly stated.
Recently, Microsoft has announced that it will no longer include support for gameports in operating systems beginning with Windows XP Professional x64 edition, reasoning that USB-based gaming equipment is now more common. This leaves gameport support up to the manufacturer of the device (i.e. Sound card or USB converters) the gameport ships on.
Extensions of the gameport capabilities
Some advanced gameport joysticks support more than 4 buttons (e.g. 6 or 8) but typically require a special device driver for the additional buttons to work properly, since the gameport doesn't have actual hardware support for more than 4 distinct buttons.
This can be overcome by either using pins and input meant for the second joystick (i.e. button 5 through 8 are mapped to the signals to the axis pins meant for the second joystick - resulting in the issue of the two buttons mapped to the same axis being not simultaneously usable), using some normally "unused" pins or changing the joystick's circuits (and related software) in order to read a 4-bit state code from the 4 button inputs, thus giving up to 16 button combinations (albeit with some limitations e.g. some buttons may not be held down) or a combination of both techniques.
High-end gameport joysticks such as the Microsoft Sidewinder rely on multiplexing a proprietary data stream through the 4 standard button inputs and sometimes through the "unused" pins, achieving full support for a rather high number of buttons (e.g. 16 or 20) while special features such as daisychaining multiple joysticks, force feedback or joystick programming become possible in some cases.
The obvious drawback here is the need for using a special device driver in order to interpret the joystick input, and making its usage rather time consuming and operating system dependent, while the joystick is usually unusable without a special driver (unless multiple operating modes are supported).
Some hardware and DIY enthusiasts have found ways to connect a wide array of input devices to the gameport and even found other applications for it, such as voltage or current measurement or simple interfacing and data acquisition.
History and variants
The original gameport design by IBM (released in 1981 as a separate expansion card for the first IBM PC[1]) initially allowed four analog axes and four buttons on one port, allowing two joysticks or four paddles to be connected, although this required a special "Y-splitter" cable and isn't fully supported by some combined midi/game ports usually found on sound cards.
Some poorly implemented game ports (usually built-in on old motherboards and I/O cards) didn't fully support either 4 axes or 4 buttons, making only the use of a single 2-axis and 2-button joystick possible.
The 15-pin gameport is no longer provided on presently manufactured PCs. However, adapters exist that allow older joysticks and controllers to connect via USB. However, Microsoft's Vista operating system natively lacks all gameport support, even for USB adapters.
MIDI connectors
Game ports use DA-15 connectors (also incorrectly called DB-15). Since the gameport moved from dedicated expansion cards to sound cards about 1990, these connectors usually double as connectors for MIDI instruments; two of the redundant +5V and GND pins of the original standard were rededicated to MIDI input and output to make this possible. To use a game port with MIDI instruments, one requires a cable with a male and a female DA-15 and two male 5-pin DIN connectors. The drivers and hardware for the game port midi capabilities are based around the now standard Roland MPU-401 MIDI interface (in UART mode only), and support most MPU-401 standard applications for Windows and DOS. The official proper design for a gameport-MIDI adaptor can be found at this MIDI page.
Other types of game controller connectors on the IBM-PC
The game port has been replaced by the Universal Serial Bus, which allows for better plug-and-play support. Earlier attempts to replace game port based controllers with e.g. parallel port, serial port or PS/2 ones had little success, until the introduction of the USB standard.
NOTE:
Analog interface
Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. Early IBM-PC manuals describe this port as suitable for connecting two analog paddles rather than joysticks. This approach has historically given the IBM-PC an advantage in simulation games, especially flight simulators, but on the other hand, rendered the design and use of simpler arcade or console joysticks more complex and needlessly convoluted, apart from being essentially incompatible with any existing joystick interface, most notably the de facto standard DE-9 connector Atari joysticks.
Acquisition and programming
Also, while other joystick standards (such as Atari or NES joysticks) are very easy and straightforward to use by programmers, the game port requires careful programming and well-timed software interrupt triggering in order to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port.
Circuits
The typical implementation of a gameport uses a capacitor and a simple voltage comparator, which together form a sort of crude ramp-compare ADC, which needs to be periodically polled and reset at precise moments in order to read an input, something that needs to be done several times (generally above 30) per second in order to provide a responsive game input, and the actual acquisition frequency and value typically depend on the joystick's internal resistance, noise, CPU speed and the total joystick-capacitor's RC time constant.
Known issues
Its analog nature has also been the cause of many problems e.g. all kinds of joysticks needed "calibration", even arcade-style ones since no game controller and no joystick produced the same measurements each time, but they were dependent on the exact way acquisition was made and even on the CPU's speed in some rather poor designs. Also, all kinds of PC Gameports suffer from electrical noise.
The calibration procedure is still required at some phase, even under modern operating systems such as Windows XP and usually consists of moving the joystick around all of its axes in order to measure the maximum axis excursion values, no matter if the joystick uses analog signals (from potentiometers) or digital signals (using microswitches or contacts). USB joysticks do not require calibration, in general.
In the days of DOS, each game using the gameport(s) had to do its own calibration, often each time the game started, and some poorly coded calibration routines even failed to work consistently and properly, rendering some joysticks unusable with some games. With Windows XP, only one calibration per joystick is enough, which is assumed "valid" until a joystick is unplugged.
Certain applications and games were (and are) however able to use some analog joysticks without explicit calibration, under certain restricted conditions. In general, if only a purely directional input with no precise intensity information is required, an analog joystick can be "self calibrated" just by leaving the joystick in the middle position and taking a measurement, and then using some arbitrary or adaptive threshold in order to detect movement and excursion from the middle position. The limitation of this method is that the reading of the same joystick over the same gameport can change over time, and some joysticks cannot work at all with this method. Also, the joystick must be in the middle position at least once when the implicit "self calibration" takes place, even if not explicitly stated.
Recently, Microsoft has announced that it will no longer include support for gameports in operating systems beginning with Windows XP Professional x64 edition, reasoning that USB-based gaming equipment is now more common. This leaves gameport support up to the manufacturer of the device (i.e. Sound card or USB converters) the gameport ships on.
Extensions of the gameport capabilities
Some advanced gameport joysticks support more than 4 buttons (e.g. 6 or 8) but typically require a special device driver for the additional buttons to work properly, since the gameport doesn't have actual hardware support for more than 4 distinct buttons.
This can be overcome by either using pins and input meant for the second joystick (i.e. button 5 through 8 are mapped to the signals to the axis pins meant for the second joystick - resulting in the issue of the two buttons mapped to the same axis being not simultaneously usable), using some normally "unused" pins or changing the joystick's circuits (and related software) in order to read a 4-bit state code from the 4 button inputs, thus giving up to 16 button combinations (albeit with some limitations e.g. some buttons may not be held down) or a combination of both techniques.
High-end gameport joysticks such as the Microsoft Sidewinder rely on multiplexing a proprietary data stream through the 4 standard button inputs and sometimes through the "unused" pins, achieving full support for a rather high number of buttons (e.g. 16 or 20) while special features such as daisychaining multiple joysticks, force feedback or joystick programming become possible in some cases.
The obvious drawback here is the need for using a special device driver in order to interpret the joystick input, and making its usage rather time consuming and operating system dependent, while the joystick is usually unusable without a special driver (unless multiple operating modes are supported).
Some hardware and DIY enthusiasts have found ways to connect a wide array of input devices to the gameport and even found other applications for it, such as voltage or current measurement or simple interfacing and data acquisition.
History and variants
The original gameport design by IBM (released in 1981 as a separate expansion card for the first IBM PC[1]) initially allowed four analog axes and four buttons on one port, allowing two joysticks or four paddles to be connected, although this required a special "Y-splitter" cable and isn't fully supported by some combined midi/game ports usually found on sound cards.
Some poorly implemented game ports (usually built-in on old motherboards and I/O cards) didn't fully support either 4 axes or 4 buttons, making only the use of a single 2-axis and 2-button joystick possible.
The 15-pin gameport is no longer provided on presently manufactured PCs. However, adapters exist that allow older joysticks and controllers to connect via USB. However, Microsoft's Vista operating system natively lacks all gameport support, even for USB adapters.
MIDI connectors
Game ports use DA-15 connectors (also incorrectly called DB-15). Since the gameport moved from dedicated expansion cards to sound cards about 1990, these connectors usually double as connectors for MIDI instruments; two of the redundant +5V and GND pins of the original standard were rededicated to MIDI input and output to make this possible. To use a game port with MIDI instruments, one requires a cable with a male and a female DA-15 and two male 5-pin DIN connectors. The drivers and hardware for the game port midi capabilities are based around the now standard Roland MPU-401 MIDI interface (in UART mode only), and support most MPU-401 standard applications for Windows and DOS. The official proper design for a gameport-MIDI adaptor can be found at this MIDI page.
Other types of game controller connectors on the IBM-PC
The game port has been replaced by the Universal Serial Bus, which allows for better plug-and-play support. Earlier attempts to replace game port based controllers with e.g. parallel port, serial port or PS/2 ones had little success, until the introduction of the USB standard.
NOTE:
construction accounting software
PC speaker
The PC speaker is the most primitive sound system used in IBM PC compatibles. It was the only source of sound available to PC games before more technologically advanced sound cards such as AdLib and Sound Blaster were introduced as ISA plug-in cards in the late 1980s. However, even some years after these sound cards became mainstream and widely used, game manufacturers continued to support speaker sound/music in their games in order to maximise their customer base. This was in part due to the fact that sound cards did not originally follow any commonly agreed-upon standard and were largely incompatible with each other, whereas the PC speaker was the only sound system that could be regarded as universally present.
The PC speaker is best characterized by its inability to play more than one tone at once, the waveform being generated by the Programmable Interval Timer. Because of this, it was often nicknamed a PC beeper or PC squeaker, especially when sound cards became widely available. In spite of its limited nature, the PC speaker was often used in very innovative ways to create the impression of polyphonic music or sound effects within computer games of its era, such as the LucasArts series of adventure games from the mid-1990s, using swift arpeggios. Several programs, including MP (Module Player, 1989), ScreamTracker, Fast Tracker, Impulse Tracker, and even a Microsoft Windows device driver, could play pulse-code modulation (PCM) sound through the PC speaker using special techniques explained later in this article. Several games such as Space Hulk and Pinball Fantasies were noted for their elaborate sound effects; Space Hulk in particular even had full speech. However, because the method used to reproduce PCM was very sensitive to timing issues, these effects either caused noticeable sluggishness on slower PCs, or sometimes failed completely on faster PCs (that is, significantly faster than the program was originally developed for).
All modern operating systems include a generic sound API, so that applications no longer need to know the specifics of each sound card. Correspondingly, the use of high-quality sound hardware has become commonplace. As a result, the PC speaker today deals mainly with low-level warning signals such as start-up errors. Regardless, the speaker's interface has remained the same and as such can still be utilized (as long as it hasn't been reduced to an onboard miniature piezo speaker, whose acoustic properties are significantly different from the older paper cone speakers such that most of the more complex sound generation techniques no longer work).
Pulse-width modulation
The PC speaker is normally meant to reproduce a square wave via only 2 levels of output, driven by channel 2 of the Intel 8253 (PC, XT) or 8254 (AT and later) Programmable Interval Timer operating in mode three (square wave signal). The speaker hardware itself is directly accessible via PC I/O port 61H (61 hexadecimal) via bit 1 and can be physically manipulated for 2 levels of output (i.e. 1-bit sound). However, by carefully timing a short pulse (i.e. going from one output level to the other and then back to the first), it is possible to drive the speaker to various output levels in between the two defined levels. This effectively allows the speaker to function as a crude DAC, thereby enabling approximate playback of PCM audio. This technique is called pulse-width modulation (PWM) and is notably used in class D audio amplifiers.
Getting a high fidelity sound output out of this technique requires the switching frequency between the minimum and maximum sound levels to be much higher than the audio frequencies meant to be reproduced (typically with a ratio of 10:1 or more), and the output voltage to be bipolar in order to make better use the output devices' dynamic range and power (e.g. by making a loudspeaker vibrate in both directions). On the PC speaker, however, the output voltage is either zero or TTL level (unipolar). As a result, the precision of this technique when used on the PC speaker is comparable at best to a 6-bit PCM DAC, while the final audio results will depend on precise timing and the nature of the reproduced sound.
The audio fidelity of this technique will be further decreased by the lack of a properly sized dynamic loudspeaker, typical of modern machines and particularly laptops, that use a piezoelectric speaker. The reason for this is that PWM-produced audio requires a low-pass filter before the final output in order to suppress switching noise and high harmonics, something that a normal dynamic loudspeaker can do on its own right, while a piezoelectric speaker will let most switching noise pass, as will many direct couplings (though there are exceptions to this, e.g. filtered "speaker in" ports on some motherboards and sound cards).
NOTE:
The PC speaker is best characterized by its inability to play more than one tone at once, the waveform being generated by the Programmable Interval Timer. Because of this, it was often nicknamed a PC beeper or PC squeaker, especially when sound cards became widely available. In spite of its limited nature, the PC speaker was often used in very innovative ways to create the impression of polyphonic music or sound effects within computer games of its era, such as the LucasArts series of adventure games from the mid-1990s, using swift arpeggios. Several programs, including MP (Module Player, 1989), ScreamTracker, Fast Tracker, Impulse Tracker, and even a Microsoft Windows device driver, could play pulse-code modulation (PCM) sound through the PC speaker using special techniques explained later in this article. Several games such as Space Hulk and Pinball Fantasies were noted for their elaborate sound effects; Space Hulk in particular even had full speech. However, because the method used to reproduce PCM was very sensitive to timing issues, these effects either caused noticeable sluggishness on slower PCs, or sometimes failed completely on faster PCs (that is, significantly faster than the program was originally developed for).
All modern operating systems include a generic sound API, so that applications no longer need to know the specifics of each sound card. Correspondingly, the use of high-quality sound hardware has become commonplace. As a result, the PC speaker today deals mainly with low-level warning signals such as start-up errors. Regardless, the speaker's interface has remained the same and as such can still be utilized (as long as it hasn't been reduced to an onboard miniature piezo speaker, whose acoustic properties are significantly different from the older paper cone speakers such that most of the more complex sound generation techniques no longer work).
Pulse-width modulation
The PC speaker is normally meant to reproduce a square wave via only 2 levels of output, driven by channel 2 of the Intel 8253 (PC, XT) or 8254 (AT and later) Programmable Interval Timer operating in mode three (square wave signal). The speaker hardware itself is directly accessible via PC I/O port 61H (61 hexadecimal) via bit 1 and can be physically manipulated for 2 levels of output (i.e. 1-bit sound). However, by carefully timing a short pulse (i.e. going from one output level to the other and then back to the first), it is possible to drive the speaker to various output levels in between the two defined levels. This effectively allows the speaker to function as a crude DAC, thereby enabling approximate playback of PCM audio. This technique is called pulse-width modulation (PWM) and is notably used in class D audio amplifiers.
Getting a high fidelity sound output out of this technique requires the switching frequency between the minimum and maximum sound levels to be much higher than the audio frequencies meant to be reproduced (typically with a ratio of 10:1 or more), and the output voltage to be bipolar in order to make better use the output devices' dynamic range and power (e.g. by making a loudspeaker vibrate in both directions). On the PC speaker, however, the output voltage is either zero or TTL level (unipolar). As a result, the precision of this technique when used on the PC speaker is comparable at best to a 6-bit PCM DAC, while the final audio results will depend on precise timing and the nature of the reproduced sound.
The audio fidelity of this technique will be further decreased by the lack of a properly sized dynamic loudspeaker, typical of modern machines and particularly laptops, that use a piezoelectric speaker. The reason for this is that PWM-produced audio requires a low-pass filter before the final output in order to suppress switching noise and high harmonics, something that a normal dynamic loudspeaker can do on its own right, while a piezoelectric speaker will let most switching noise pass, as will many direct couplings (though there are exceptions to this, e.g. filtered "speaker in" ports on some motherboards and sound cards).
NOTE:
订阅：
博文 (Atom)