diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index e272d71130..45a4acbf27 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,157 +1,157 @@ - + %authors; %sections; ]> FreeBSD Handbook <author> <name>The FreeBSD Documentation Project</name> </author> - <date>December 21, 1995</date> + <date>February 27, 1996</date> <abstract>Welcome to FreeBSD! This handbook covers the installation and day to day use of <bf>FreeBSD Release 2.1.0</bf>. This manual is a <bf>work in progress</bf> and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the FreeBSD Documentation Project mailing list <tt><htmlurl url="mailto:doc@freebsd.org" name="<doc@freebsd.org>"></tt>. The latest version of this document is always available from the <url url="http://www.freebsd.org/" name="FreeBSD World Wide Web server">. </abstract> <toc> <!-- ************************************************************ --> <part><heading>Basics</heading> <chapt><heading>Introduction</heading> <p>FreeBSD is a 4.4 BSD Lite based operating system for Intel architecture (x86) based PCs. For an overview of FreeBSD, see <ref id="nutshell" name="FreeBSD in a nutshell">. For a history of the project, read <ref id="history" name="a brief history of FreeBSD">. To see a description of the latest release, read <ref id="relnotes" name="about the current release">. If you're interested in contributing something to the FreeBSD project (code, equipment, sacks of unmarked bills), please see about <ref id="submitters" name="contributing to FreeBSD">. &nutshell; &history; &goals; &relnotes; &install; &basics; <chapt><heading>Installing applications</heading> <sect><heading>* Installing packages</heading> &ports; <!-- ************************************************************ --> <part><heading>System Administration</heading> &kernelconfig; <chapt><heading>Users, groups and security</heading> &crypt; &skey; &kerberos; &firewalls; &printing; <chapt><heading>The X-Window System</heading> <p>Pending the completion of this section, please refer to documentation supplied by the <url url="http://www.xfree86.org/" name="The XFree86 Project, Inc">. &hw; <!-- ************************************************************ --> <part><heading>Network Communications</heading> <chapt><heading>Basic Networking</heading> <sect><heading>* Ethernet basics</heading> <sect><heading>* Serial basics</heading> <sect><heading>* Hardwired Terminals</heading> &dialup; <chapt><heading>PPP and SLIP</heading> <p>If your connection to the Internet is through a modem, or you wish to provide other people with dialup connections to the Internet using FreeBSD, you have the option of using PPP or SLIP. Furthermore, two varieties of PPP are provided: <em>user</em> (sometimes referred to as iijppp) and <em>kernel</em>. The procedures for configuring both types of PPP, and for setting up SLIP are described in this chapter. &userppp; &ppp; &slipc; &slips; <chapt><heading>Advanced networking</heading> &routing; &nfs; &diskless; <sect><heading>* Yellow Pages/NIS</heading> <sect><heading>* ISDN</heading> <chapt><heading>* Mail</heading> <!-- ************************************************************ --> <part><heading>Advanced topics</heading> ¤t; &stable; &synching; &submitters; &troubleshooting; &kerneldebug; <chapt><heading>FreeBSD internals</heading> &booting; &memoryuse; &dma; <!-- ************************************************************ --> <part><heading>Appendices</heading> &mirrors; &bibliography; &eresources; &contrib; <!-- &glossary; --> </book> </linuxdoc> diff --git a/handbook/hw.sgml b/handbook/hw.sgml index 97e9656e35..6257e984c8 100644 --- a/handbook/hw.sgml +++ b/handbook/hw.sgml @@ -1,270 +1,270 @@ -<!-- $Id: hw.sgml,v 1.16 1996-02-16 13:28:20 jkh Exp $ --> +<!-- $Id: hw.sgml,v 1.17 1996-02-27 15:57:47 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN"> --> <chapt><heading>PC Hardware compatibility<label id="hw"></heading> <p>Issues of hardware compatibility are among the most troublesome in the computer industry today and FreeBSD is by no means immune to trouble. In this respect, FreeBSD's advantage of being able to run on inexpensive commodity PC hardware is also its liability when it comes to support for the amazing variety of components on the market. While it would be impossible to provide a exhaustive listing of hardware that FreeBSD supports, this section serves as a catalog of the device drivers included with FreeBSD and the hardware each drivers supports. Where possible and appropriate, notes about specific products are included. As FreeBSD is a volunteer project without a funded testing department, we depend on you, the user, for much of the information contained in this catalog. If you have direct experience of hardware that does or does not work with FreeBSD, please let us know by sending email to <tt>doc@freebsd.org</tt>. Questions about supported hardware should be directed to <tt>questions@freebsd.org</tt> (see <ref id="eresources:mail" name="Mailing Lists"> for more information). When submitting information or asking a question, please remember to specify exactly what version of FreeBSD you are using and include as many details of your hardware as possible. <sect><heading>Sample Configurations<label id="hw:configs"></heading> <p>The following list of sample hardware configurations by no means constitutes an endorsement of a given hardware vendor or product by <em>The FreeBSD Project</em>. This information is provided only as a public service and merely catalogs some of the experiences that various individuals have had with different hardware combinations. Your mileage may vary. Slippery when wet. Beware of dog. <sect1><heading>Jordan's Picks</heading> <p>I have had fairly good luck building workstation and server configurations with the following components. I can't guarantee that you will too, nor that any of the companies here will remain "best buys" forever. I will try, when I can, to keep this list up-to-date but cannot obviously guarantee that it will be at any given time. <sect2><heading>Motherboards</heading> <p>The <htmlurl url="http://asustek.asus.com.tw/" name="ASUS"> <htmlurl url="http://asustek.asus.com.tw/FTP/ASUS/Info/Spec/pi-p55tp4xe.txt" name="P55TP4XE"> motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems. If you're really looking for performance, be also sure to get the <htmlurl url="http://asustek.asus.com.tw/Products/TB/mem-0002.html" name="pipelined burst cache module">. I feel that it's worth the extra cost. If you're looking for a 486 class motherboard, you might also investigate ASUS's <htmlurl url="http://asustek.asus.com.tw/FTP/ASUS/Info/Spec/pvi-486sp3.txt" name="486SP3G"> offering. NOTE: The Intel <htmlurl url="http://asustek.asus.com.tw/Products/TB/triton-intro.html" name="Triton"> chipset based motherboards do not offer memory parity logic, making it almost impossible to detect when a memory error has occurred. Those wishing to build highly fault-tolerant systems may therefore want to wait for Intel's newest generation of motherboards based on the Orion chipset or investigate ASUS's SiS chipset based motherboard, the <htmlurl url="http://asustek.asus.com.tw/FTP/ASUS/Info/Spec/pi-p55sp4.txt" name="P55SP4">. I have no personal experience with this motherboard and have heard mixed reports - some say it's a fine MB, others say that it's measurably slower than the Triton. The only undisputed advantage it offers is being available <em>now</em>. <sect2><heading>Disk Controllers</heading> <p>This one is a bit trickier, and while I used to recommend the <htmlurl url="http://www.buslogic.com" name="Buslogic"> controllers unilaterally for everything from ISA to PCI, now I tend to lean towards the <htmlurl url="http://www.adaptec.com" name="Adaptec"> 1542CF for ISA, Buslogic Bt747c for EISA and Adaptec 2940 for PCI. <sect2><heading>Disk drives</heading> <p>In this particular game of Russian roulette, I'll make few specific recommendations except to say "SCSI over IDE whenever you can afford it." Even in small desktop configurations, SCSI often makes more sense since it allows you to easily migrate drives from server to desktop as falling drive prices make it economical to do so. If you have more than one machine to administer then think of it not simply as storage, think of it as a food chain! <p>I do not currently see SCSI WIDE drives as a necessary expense unless you're putting together an NFS or NEWS server that will be doing a lot of multiuser disk I/O. <sect2><heading>CDROM drives</heading> <p>My SCSI preferences extend to SCSI CDROM drives as well, and the <htmlurl url="http://www.toshiba.com" name="Toshiba"> XM-3501B (now released in a caddy-less model called the XM-5401B) drive has always performed well for me. Generally speaking, most SCSI CDROM drives I've seen have been of pretty solid construction (probably because they don't occupy the lower end of the market, due to their higher price) and you probably won't go wrong with an HP or NEC SCSI CDROM drive either. <sect2><heading>Tape drives</heading> <p>I've had pretty good luck with both <htmlurl url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html" name="8mm drives"> from <htmlurl url="http://www.exabyte.com" name="Exabyte"> and <htmlurl url="http://www-dmo.external.hp.com:80/tape/_cpb0001.htm" name="4mm (DAT)"> drives from <htmlurl url="http://www.hp.com" name="HP">. <p>For backup purposes, I'd have to give the higher recommendation to the Exabyte due to the more robust nature (and higher storage capacity) of 8mm tape. <sect2><heading>Video Cards</heading> - <p>If you can also afford to buy a commercial X server for $99 from + <p>If you can also afford to buy a commercial X server for US$99 from <htmlurl url="http://www.xinside.com/" name="X Inside"> then I can heartily recommend the <htmlurl url="http://www.matrox.com/" name="Matrox"> <htmlurl url="http://www.matrox.com/mgaweb/brochure.htm" name="Millenium"> card. If free X servers are more to your liking, you certainly can't go wrong with one of <htmlurl url="http://www.nine.com/" name="Number 9's"> cards - their S3 Vision 868 and 968 based cards (the 9FX series) are pretty fast cards as well, and are supported by <htmlurl url="http://www.xfree86.org" name="XFree86">'s S3 server. <sect2><heading>Monitors</heading> <p>I have had very good luck with the <htmlurl url="http://cons3.sel.sony.com/SEL/ccpg/display/ms17se2.html" name="Sony Multiscan 17SE monitors">, as have I with the Viewsonic offering in the same (trinitron) tube. For larger than 17", all I can recommend at the time of this writing is to not spend - any less than U.S. $2,500 for a 21" monitor if that's what you really + any less than U.S. $2,500 for a 21" monitor if that's what you really need. There are good monitors available in the >=20" range and there are also cheap monitors in the >=20" range. Unfortunately, none are both cheap and good! <sect2><heading>Networking</heading> <p>I can recommend the <htmlurl url="http://www.smc.com/" name="SMC"> Ultra 16 controller for any ISA application and the SMC EtherPower or Compex ENET32 cards for any serious PCI based networking. Both of the PCI cards are based around DEC's DC21041 Ethernet controller chip and other cards using it, such as the Zynx ZX342 or DEC DE435, will generally work as well. <sect2><heading>Serial</heading> <p>If you're looking for high-speed serial networking solutions, then <htmlurl url="http://www.digiboard.com/" name="Digi International"> makes the <htmlurl url="http://www.digiboard.com/prodprofiles/profiles-prices/arnetprofiles/sync570i.html" name="SYNC 570i"> series, with drivers now in FreeBSD-current. <htmlurl url="http://www.etinc.com" name="Emerging Technologies"> also manufactures a board with T1/E1 capabilities, using software they provide. <p>Multiport card options are somewhat more numerous, though it has to be said that FreeBSD's support for <htmlurl url="http://www.cyclades.com/" name="Cyclades">'s products is probably the tightest, primarily as a result of that company's committment to making sure that we are adequately supplied with evaluation boards and technical specs. I've heard that the Cyclom-16Ye offers the best price/performance, though I've not checked the prices lately. Other multiport cards I've heard good things about are the BOCA and AST cards, and <htmlurl url="http://www.stallion.com/" name="Stallion Technologies"> apparently offers an unofficial driver for their cards at <htmlurl url="ftp://ftp.stallion.com/drivers/unsupported/freebsd/stalbsd-0.0.4.tar.gz" name="this"> location. <sect2><heading>Audio</heading> <p>I currently use the <htmlurl url="http://www.gravis.com/" name="Gravis"> Ultrasound MAX due to its high sound quality and full-duplex audio capabilities (dual DMA channels). Support for Windows NT and OS/2 is fairly anemic, however, so I'm not sure that I can recommend it as an all-around card for a machine that will be running both FreeBSD and NT or OS/2. In such a scenario, I might recommend the <htmlurl url="http://www.creaf.com/" name="Creative Labs"> AWE32 instead. <sect2><heading>Video</heading> <p>For video capture, there's really only once choice - the <htmlurl url="http://www.matrox.com/" name="Matrox"> <htmlurl url="http://www.matrox.com/imgweb/meteor.htm" name="Meteor"> card. FreeBSD also supports the older video spigot card from Creative Labs, but those are getting somewhat difficult to find and the Meteor is a more current generation frame-grabber with a higher-speed PCI interface. I use one for broadcasting video on the MBONE and it works quite well! <sect><heading>Core/Processing<label id="hw:core"></heading> <sect1><heading>Motherboards, busses, and chipsets</heading> <sect2><heading>* ISA</heading> <sect2><heading>* EISA</heading> <sect2><heading>* VLB</heading> <sect2><heading>PCI</heading> <p><em>Contributed by &a.rgrimes;.<newline>25 April 1995.</em></p> <p>Of the Intel PCI chip sets, the following list describes various types of known-brokenness and the degree of breakage, listed from worst to best. </p> <p><descrip> <tag>Mercury:</tag> Cache coherency problems, especially if there are ISA bus masters behind the ISA to PCI bridge chip. Hardware flaw, only known work around is to turn the cache off. <tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or 2)</em>:</tag> Write back cache coherency problems. Hardware flaw, only known work around is to set the external cache to write-through mode. Upgrade to Saturn-II. <tag>Saturn-II <em>(ie, 82424ZX at rev 3 or 4)</em>:</tag> Works fine, but many MB manufactures leave out the external dirty bit SRAM needed for write back operation. Work arounds are either run it in write through mode, or get the dirty bit SRAM installed. (I have these for the ASUS PCI/I-486SP3G rev 1.6 and later boards). <tag>Neptune:</tag> Can not run more than 2 bus master devices. Admitted Intel design flaw. Workarounds include do not run more than 2 bus masters, special hardware design to replace the PCI bus arbiter (appears on Intel Altair board and several other Intel server group MB's). And of course Intel's official answer, move to the Triton chip set, we ``fixed it there''. <tag>Triton:</tag> No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue. Wait for Triton-II. <tag>Triton-II:</tag> Unknown, not yet shipping. </descrip> </p> <sect1><heading>* CPUs/FPUs</heading> <sect1><heading>* Memory</heading> <sect1><heading>* BIOS</heading> <sect><heading>Input/Output Devices<label id="hw:io"></heading> <sect1><heading>* Video cards</heading> <sect1><heading>* Sound cards</heading> <sect1><heading>Serial ports and multiport cards</heading> &uart; &sio; <sect1><heading>* Parallel ports</heading> <sect1><heading>* Modems</heading> <sect1><heading>* Network cards</heading> <sect1><heading>* Keyboards</heading> <sect1><heading>* Mice</heading> <sect1><heading>* Other</heading> <sect><heading>Storage Devices<label id="hw:storage"></heading> &esdi; &scsi; <sect1><heading>* Disk/tape controllers</heading> <sect2><heading>* SCSI</heading> <sect2><heading>* IDE</heading> <sect2><heading>* Floppy</heading> <sect1><heading>* Hard drives</heading> <sect1><heading>* Tape drives</heading> <sect1><heading>* CD-ROM drives</heading> <sect1><heading>* Other</heading> <sect1><heading>* Adding and reconfiguring disks</heading> <sect1><heading>* Tapes and backups</heading> <sect1><heading>* Serial ports</heading> <sect1><heading>* Sound cards</heading> <sect1><heading>* PCMCIA</heading> <sect1><heading>* Other<label id="hw:other"></heading> diff --git a/handbook/install.sgml b/handbook/install.sgml index 23db9c43a1..2d77fcf8fb 100644 --- a/handbook/install.sgml +++ b/handbook/install.sgml @@ -1,877 +1,877 @@ -<!-- $Id: install.sgml,v 1.23 1996-01-31 19:02:58 mpp Exp $ --> +<!-- $Id: install.sgml,v 1.24 1996-02-27 15:57:49 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> --> <chapt><heading>Installing FreeBSD<label id="install"></heading> <p>So, you would like to try out FreeBSD on your system? This section is a quick-start guide for what you need to do. FreeBSD can be installed from a variety of media including CD-ROM, floppy disk, magnetic tape, an MS-DOS partition, and if you have a network connection, via anonymous ftp or NFS. Regardless of the installation media you choose, you can get started by downloading the <bf>installation disk</bf> as described below. Booting your computer with disk will provide important information about compatibility between FreeBSD and your hardware which could dictate which installation options are possible. It can also provide early clues to compatibility problems that could prevent FreeBSD running on your system at all. If you plan on installing via anonymous FTP, then this installation disk is all you need to download. For more information on obtaining the FreeBSD distribution itself, please see <ref id="mirrors" name="Obtaining FreeBSD"> in the Appendix. So, to get the show on the road, follow these steps: <enum> <item>Review the <ref id="install:hw" name="supported configurations"> section of this installation guide to be sure that your hardware is supported by FreeBSD. It may be helpful to make a list of any special cards you have installed, such as SCSI controllers, Ethernet adapters or sound cards. This list should include relevant configuration parameters such as interrupts (IRQ) and IO port addresses. </item> <item>Download the <url url="ftp://ftp.freebsd.org/pub/FreeBSD/2.1.0-RELEASE/floppies/boot.flp" name="installation boot disk image"> file to your hard drive, and be sure to tell your browser to <em>save</em> rather than <em>display</em>. <bf>Note:</bf> This disk image can be used for <em>both</em> 1.44 megabyte 3.5 inch floppy disks and 1.2 megabyte 5.25 inch floppy disks.</item> <item>Make the installation boot disk from the image file: <itemize> <item>If you are using MS-DOS download <url url="ftp://ftp.freebsd.org/pub/FreeBSD/tools/dos-tools/rawrite.exe" name="rawrite.exe">, then run it: <tscreen><verb> C:\> rawrite </verb></tscreen> The program will prompt you for the floppy drive containing the disk you want to write to (A: or B:) and the name of the file to put on disk (boot.flp). </item> <item>If you are using a UNIX system: <tscreen> % dd if=boot.flp of=<em>disk_device</em> </tscreen> where <em>disk_device</em> is the <tt>/dev</tt> entry for the floppy drive. On FreeBSD systems, this is <tt>/dev/fd0</tt> for the A: drive and <tt>/dev/fd1</tt> for the B: drive. </item> </itemize> </item> <item>With the installation disk in the A: drive, reboot your computer. You should get a boot prompt something like this: <tscreen> >> FreeBSD BOOT ...<newline> Use hd(1,a)/kernel to boot sd0 when wd0 is also installed.<newline> Usage: [[hd(1,a)]/kernel][-abcCdhrsv]<newline> Use ? for file list or press Enter for defaults<newline> Boot: </tscreen> If you do <em>not</em> type anything, FreeBSD will automatically boot with its default configuration after a delay of about five seconds. As FreeBSD boots, it probes your computer to determine what hardware is installed. The results of this probing is displayed on the screen. </item> <item>When the booting process is finished, The main FreeBSD installation menu will be displayed.</item> </enum> <p><bf>If something goes wrong...</bf> <p>Due to limitations of the PC architecture, it is impossible for probing to be 100 percent reliable. In the event that your hardware is incorrectly identified, or that the probing causes your computer to lock up, first check the <ref id="install:hw" name="supported configurations"> section of this installation guide to be sure that your hardware is indeed supported by FreeBSD. <p>If your hardware is supported, reset the computer and when the <tt>Boot:</tt> prompt comes up, type <bf>-c</bf>. This puts FreeBSD into a configuration mode where you can supply hints about your hardware. The FreeBSD kernel on the installation disk is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses and DMA channels. If your hardware has been reconfigured, you will most likely need to use the <bf>-c</bf> option at boot to tell FreeBSD where things are. <p>It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled. <p>In the configuration mode, you can: <itemize> <item>List the device drivers installed in the kernel.</item> <item>Disable device drivers for hardware not present in your system.</item> <item>Change the IRQ, DRQ, and IO port addresses used by a device driver.</item> </itemize> <p>While at the <tt>config></tt> prompt, type <tt>help</tt> for more information on the available commands. After adjusting the kernel to match how you have your hardware configured, type <tt>quit</tt> at the <tt>config></tt> prompt to continue booting with the new settings. After FreeBSD has been installed, changes made in the configuration mode will be permanent so you do not have to reconfigure every time you boot. Even so, it is likely that you will want to build a custom kernel to optimize the performance of your system. See <ref id="kernelconfig" name="Kernel configuration"> for more information on creating custom kernels. <sect><heading>Supported Configurations<label id="install:hw"></heading> <p>FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. A minimum of five megabytes of RAM is required to run FreeBSD. To run the X-window system, eight megabytes of RAM is the recommended minimum. Following is a list of all disk controllers and Ethernet cards currently known to work with FreeBSD. Other configurations may very well work, and we have simply not received any indication of this. <sect1><heading>Disk Controllers</heading> <p> <itemize> <item>WD1003 (any generic MFM/RLL) <item>WD1007 (any generic IDE/ESDI) <item>IDE <item>ATA <item>Adaptec 152x series ISA SCSI controllers <item>Adaptec 154x series ISA SCSI controllers <item>Adaptec 174x series EISA SCSI controller in standard and enhanced mode. <item>Adaptec 274x/284x/2940/3940 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers <item>Adaptec <!-- AIC-6260 and - actually not working, joerg --> AIC-6360 based boards, which includes the AHA-152x and SoundBlaster SCSI cards. <bf>Note:</bf> You cannot boot from the SoundBlaster cards as they have no on-board BIOS, which is necessary for mapping the boot device into the system BIOS I/O vectors. They are perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset. Check your system/board documentation for more details. <item>Buslogic 545S & 545c <bf>Note:</bf> that Buslogic was formerly known as "Bustek". <item>Buslogic 445S/445c VLB SCSI controller <item>Buslogic 742A/747S/747c EISA SCSI controller. <item>Buslogic 946c PCI SCSI controller <item>Buslogic 956c PCI SCSI controller <item>NCR 53C810/53C815/53C825/53C860/53C875 PCI SCSI controller. <item>NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI controller. <item>DTC 3290 EISA SCSI controller in 1542 emulation mode. <item>UltraStor 14F/24F/34F SCSI controllers. <item>Seagate ST01/02 SCSI controllers. <item>Future Domain 8xx/950 series SCSI controllers. <item>WD7000 SCSI controllers. </itemize> With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: <itemize> <item>SoundBlaster SCSI and ProAudio Spectrum SCSI (<tt>cd</tt>) <item>Mitsumi (all models) proprietary interface (<tt>mcd</tt>) <item>Matsushita/Panasonic (Creative) CR-562/CR-563 proprietary interface (<tt>matcd</tt>) <item>Sony proprietary interface (<tt>scd</tt>) <item>ATAPI IDE interface (experimental and should be considered ALPHA quality!) (<tt>wcd</tt>) </itemize> <sect1><heading>Ethernet cards</heading> <p> <itemize> <item>Allied-Telesis AT1700 and RE2000 cards <item>SMC Elite 16 WD8013 Ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. <item>DEC EtherWORKS III NICs (DE203, DE204, and DE205) <item>DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) <item>DEC DC21140/DC21141 based NICs: <itemize> <item>ASUS PCI-L101-TB <item>Accton ENI1203 <item>Cogent EM960PCI <item>Compex CPXPCI/32C <item>D-Link DE-530 <item>DEC DE435 <item>Danpex EN-9400P3 <item>JCIS Condor JC1260 <item>Linksys EtherPCI <item>Mylex LNP101 <item>SMC EtherPower 10/100 (Model 9332) <item>SMC EtherPower (Model 8432) <item>Zynx ZX342 </itemize> <item>DEC FDDI (DEFPA/DEFEA) NICs <item>Fujitsu FMV-181 and FMV-182 <item>Intel EtherExpress <item>Isolan AT 4141-0 (16 bit) <item>Isolink 4110 (8 bit) <item>Novell NE1000, NE2000, and NE2100 ethernet interface. <item>3Com 3C501 cards <item>3Com 3C503 Etherlink II <item>3Com 3c505 Etherlink/+ <item>3Com 3C507 Etherlink 16/TP <item>3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III <item>Toshiba ethernet cards <item>PCMCIA ethernet cards from IBM and National Semiconductor are also supported. </itemize> <p><em>Note:</em> FreeBSD does not currently support PnP (plug-n-play) features present on some ethernet cards. If your card has PnP and is giving you problems, try disabling its PnP features. <sect1><heading>Miscellaneous devices</heading> <p> <itemize> <item>AST 4 port serial card using shared IRQ. <item>ARNET 8 port serial card using shared IRQ. <item>BOCA IOAT66 6 port serial card using shared IRQ. <item>BOCA 2016 16 port serial card using shared IRQ. <item>Cyclades Cyclom-y Serial Board. <item>STB 4 port card using shared IRQ. <item>SDL Communications Riscom/8 Serial Board. <item>Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX and Roland MPU-401 sound cards. </itemize> FreeBSD currently does not support IBM's microchannel (MCA) bus, but support is apparently close to materializing. Details will be posted as the situation develops. <sect><heading>Preparing for the installation</heading> <p>There are a number of different methods by which FreeBSD can be installed. The following describes what preparation needs to be done for each type. <sect1><heading>Before installing from CDROM</heading> <p>If your CDROM is of an unsupported type, such as an IDE CDROM, then please skip to <ref id="install:msdos" name="MS-DOS Preparation">. There is not a lot of preparatory work that needs to be done to successfully install from one of Walnut Creek's FreeBSD CDROMs (other CDROM distributions may work as well, though we cannot say for certain as we have no hand or say in how they're created). You can either boot into the CD installation directly from DOS using Walnut Creek's supplied ``install.bat'' batch file or you can make a boot floppy with the ``makeflp.bat'' command [NOTE: If you're using an IDE CDROM, use the inst_ide.bat or atapiflp.bat batch files instead]. For the easiest interface of all (from DOS), type ``view''. This will bring up a DOS menu utility that leads you through all the available options. If you are creating the boot floppy from a UNIX machine, see <ref id="install" name="the beginning of this guide"> for examples. of how to create the boot floppy. Once you have booted from DOS or floppy, you should then be able to select CDROM as the media type in the Media menu and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted from the hard disk, you can mount the cdrom at any time by typing: <tt>mount /cdrom</tt> Before removing the CD again, also note that it's necessary to first type: <tt>umount /cdrom</tt>. Don't just remove it from the drive! <quote><bf>Special note:</bf> Before invoking the installation, be sure that the CDROM is in the drive so that the install probe can find it. This is also true if you wish the CDROM to be added to the default system configuration automatically during the install (whether or not you actually use it as the installation media). </quote> Finally, if you would like people to be able to FTP install FreeBSD directly from the CDROM in your machine, you will find it quite easy. After the machine is fully installed, you simply need to add the following line to the password file (using the vipw command): <tscreen><verb> ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent </verb></tscreen> Anyone with network connectivity to your machine (and permission to log into it) can now chose a Media type of FTP and type in: <tt>ftp://<em>your machine</em></tt> after picking ``Other'' in the ftp sites menu. <sect1><heading>Before installing from Floppy</heading> <p>If you must install from floppy disks, either due to unsupported hardware or just because you enjoy doing things the hard way, you must first prepare some floppies for the install. The first floppy that you will need in addition to the boot.flp image is ``floppies/root.flp'', which is somewhat special in that it's not a DOS filesystem floppy at all, but rather a floppy "image" (it's actually a gzip'd cpio file). You can create this floppy in the same way that you created the boot floppy <ref id="install" name="the beginning of this guide">. Once this floppy is made, you can go on to make the distribution set floppies using ordinary DOS or UFS (if you're preparing the floppies on another FreeBSD machine) formatted diskettes. You will need, at minimum, as many 1.44MB or 1.2MB floppies as it takes to hold all files in the bin (binary distribution) directory. If you're preparing these floppies under DOS, then THESE floppies *must* be formatted using the MS-DOS FORMAT command. If you're using Windows, use the Windows File Manager format command. Do <em>not</em> trust Factory Preformatted floppies! Format them again yourself, just to make sure. Many problems reported by our users in the past have resulted from the use of improperly formatted media, which is why I'm taking such special care to mention it here! If you're creating the floppies from another FreeBSD machine, a format is still not a bad idea though you don't need to put a DOS filesystem on each floppy. You can use the `disklabel' and `newfs' commands to put a UFS filesystem on them instead, like so: <tscreen><verb> disklabel -w -r fd0 floppy3 (use floppy5 for 1.2MB disks) newfs /dev/rfd0 </verb></tscreen> Then you can mount and write to them like any other file system. After you have DOS formatted the floppies, you will need to copy the files onto them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you have got all the distributions you want packed up in this fashion. Each distribution should go into a subdirectory on the floppy, e.g.: <bf>a:\bin\bin.aa</bf>, <bf>a:\bin\bin.ab</bf>, and so on. Once you come to the Media screen of the install, select ``Floppy'' and you will be prompted for the rest. <sect1><heading>Before installing from a MS-DOS partition<label id="install:msdos"></heading> <p>To prepare for installation from an MS-DOS partition, copy the files from the distribution into a directory called <tt>C:\FREEBSD</tt>. The directory tree structure of the CDROM must be partially reproduced within this directory so we suggest using the DOS <tt>xcopy</tt> command. For example, to prepare for a minimal installation of FreeBSD: <tscreen><verb> C> MD C:\FREEBSD C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\ C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\ </verb></tscreen> assuming that <tt>C:</tt> is where you have free space and <tt>E:</tt> is where your CDROM is mounted. Note that you need the <tt>FLOPPIES</tt> directory because the <tt>root.flp</tt> image is needed during an MS-DOS installation. For as many `DISTS' you wish to install from MS-DOS (and you have free space for), install each one under <tt>C:\FREEBSD</tt> - the <tt>BIN</tt> dist is only the minimal requirement. If you have room on your MS-DOS partition for all the distributions, you could replace the last line above with: <tscreen><verb> C> XCOPY /S E:\DISTS C:\FREEBSD\ </verb></tscreen> which would copy all the subdirectories of <tt>E:\DISTS</tt> to <tt>C:\FREEBSD</tt>. <sect1><heading>Before installing from QIC/SCSI Tape</heading> <p>Installing from tape is probably the easiest method, short of an on-line install using FTP or a CDROM install. The installation program expects the files to be simply tar'ed onto the tape, so after getting all of the files for distribution you are interested in, simply tar them onto the tape with a command like: <tscreen> cd /freebsd/distdir<newline> tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2 </tscreen> Make sure that the `floppies/' directory is one of the ``dists'' given above, since the installation will look for `floppies/root.flp' on the tape. When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you will be allowed to choose) to accommodate the <bf>full</bf> contents of the tape you have created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage. You should expect to require as much temporary storage as you have stuff written on tape. <quote><bf>Note:</bf> When going to do the installation, the tape must be in the drive <em>before</em> booting from the boot floppy. The installation probe may otherwise fail to find it.</quote> <sect1><heading>Before installing over a network</heading> <p>You can do network installations over 3 types of communications links: <descrip> <tag>Serial port</tag> SLIP or PPP <tag>Parallel port</tag> PLIP (laplink cable) <tag>Ethernet</tag> A standard ethernet controller (includes some PCMCIA). </descrip> SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation does not currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you are using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you will need to know it fairly soon in the installation process. You will need to know, at the minimum, your service provider's IP address and possibly your own (though you can also leave it blank and allow PPP to negotiate it with your ISP). You also need to know how to use the various ``AT commands'' to dial the ISP with your particular modem as the PPP dialer provides only a very simple terminal emulator. If a hard-wired connection to another FreeBSD (2.0R or later) machine is available, you might also consider installing over a ``laplink'' parallel port cable. The data rate over the parallel port is much higher than what is typically possible over a serial line (up to 50k/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adaptor is always a good choice! FreeBSD supports most common PC ethernet cards, a table of supported cards (and their required settings) is provided in <ref id="install:hw" name="Supported Hardware">. If you are using one of the supported PCMCIA ethernet cards, also be sure that it is plugged in <em>before</em> the laptop is powered on! FreeBSD does not, unfortunately, currently support hot insertion of PCMCIA cards. You will also need to know your IP address on the network, the netmask value for your address class, and the name of your machine. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you will also need a name server and possibly the address of a gateway (if you are using PPP, it is your provider's IP address) to use in talking to it. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator <em>first</em> before trying this type of installation. Once you have a network link of some sort working, the installation can continue over NFS or FTP. <sect2><heading>Preparing for NFS installation</heading> <p>NFS installation is fairly straight-forward: Simply copy the FreeBSD distribution files you want onto a server somewhere and then point the NFS media selection at it. If this server supports only ``privileged port'' access (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support subdir mounts, e.g., if your FreeBSD 2.1 distribution directory lives on: <bf>ziggy:/usr/archive/stuff/FreeBSD</bf> Then ziggy will have to allow the direct mounting of <bf>/usr/archive/stuff/FreeBSD</bf>, not just <bf>/usr</bf> or <bf>/usr/archive/stuff</bf>. In FreeBSD's <bf>/etc/exports</bf> file, this is controlled by the ``<tt>-alldirs</tt>'' option. Other NFS servers may have different conventions. If you are getting `Permission Denied' messages from the server then it is likely that you do not have this enabled properly. <sect2><heading>Preparing for FTP Installation</heading> <p>FTP installation may be done from any mirror site containing a reasonably up-to-date version of FreeBSD 2.1. A full menu of reasonable choices from almost anywhere in the world is provided by the FTP site menu. If you are installing from some other FTP site not listed in this menu, or you are having troubles getting your name server configured properly, you can also specify your own URL by selecting the ``Other'' choice in that menu. A URL can also be a direct IP address, so the following would work in the absence of a name server: <tscreen><verb> ftp://192.216.222.4/pub/FreeBSD/2.1.0-RELEASE </verb></tscreen> There are two FTP installation modes you can use: <descrip> <tag>FTP Active</tag> For all FTP transfers, use ``Active'' mode. This will not work through firewalls, but will often work with older ftp servers that do not support passive mode. If your connection hangs with passive mode (the default), try active! <tag>FTP Passive</tag> For all FTP transfers, use ``Passive'' mode. This allows the user to pass through firewalls that do not allow incoming connections on random port addresses. </descrip> - <quote><bf>Note:</bf> ACTIVE AND PASSIVE MODES ARE - NOT THE SAME AS A `PROXY' CONNECTION, WHERE A PROXY - FTP SERVER IS LISTENING ON A DIFFERENT PORT!</quote> + <quote><bf>Note:</bf> Active and passive modes are + not the same as a `proxy' connection, where a proxy + ftp server is listening on a different port!</quote> In such instances, you should specify the URL as something like: <tscreen><verb> ftp://foo.bar.com:1234/pub/FreeBSD </verb></tscreen> Where ``1234'' is the port number of the proxy ftp server. <sect><heading>Installing FreeBSD</heading> <p>Once you have taken note of the appropriate preinstallation steps, you should be able to install FreeBSD without any further trouble. Should this not be true, then you may wish to go back and re-read the relevant preparation section above for the installation media type you are trying to use, perhaps there is a helpful hint there that you missed the first time? If you are having hardware trouble, or FreeBSD refuses to boot at all, read the Hardware Guide provided on the boot floppy for a list of possible solutions. The FreeBSD boot floppy contains all the on-line documentation you should need to be able to navigate through an installation and if it does not then we would like to know what you found most confusing. Send your comments to <htmlurl url="mailto:doc@freebsd.org" name="doc@freebsd.org">. It is the objective of the FreeBSD installation program (sysinstall) to be self-documenting enough that painful ``step-by-step'' guides are no longer necessary. It may take us a little while to reach that objective, but that is the objective! Meanwhile, you may also find the following ``typical installation sequence'' to be helpful: <enum> <item>Boot the boot floppy. After a boot sequence which can take anywhere from from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the floppy does not boot at all, or the boot hangs at some stage, go read the Q&A section of the Hardware Guide for possible causes. <item>Press F1. You should see some basic usage instructions on the menu system and general navigation. If you have not used this menu system before then PLEASE read this thoroughly! <item>Select the Options item and set any special preferences you may have. <item>Select a Custom or Express install, depending on whether or not you would like the installation to give you a high degree of control over each step of the installation or simply lead you through it, choosing reasonable defaults when possible. See details on both installation types below. <item>The Configure menu choice allows you to further configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM/Tape/Floppy installation and have not yet configured your network interfaces (assuming you have any). Properly configuring such interfaces here will allow FreeBSD to come up on the network when you first reboot from the hard disk. </enum> <sect1><heading>Express installation</heading> <p>The express installation is not too much different than the Custom one except that it leads you through the required stages in the proper order and presents you with various helpful prompts along the way. <enum> <item>The first step is the `Partition Editor', which allows you to chose how your drives will be used for FreeBSD. If you are dedicating an entire drive to FreeBSD, the `A' command is probably all you need to type here. <item>Next, with the `Label Editor', you can specify how the space in any allocated FreeBSD partitions should be used by FreeBSD, or where to mount a non-FreeBSD partition (such as DOS). If you want the standard layout, simply type `A' here. <item>Next, the `Distributions' menu allows you to specify which parts of FreeBSD you wish to load. A good choice is ``User'' for a small system or ``Developer'' for someone wanting a bit more out of FreeBSD. If none of the existing collections sound applicable, select Custom. <item>Next, the `Media' menu allows you to specify what kind of media you wish to install from. If a desired media choice is found and configured automatically then this menu will simply return, otherwise you will be asked for additional details on the media device type. <item>Finally, you will be prompted to commit all of these actions at once (nothing has been written to your disk so far, nor will it until you give the final confirmation). All new or changed partition information will be written out, file systems will be created and/or non-destructively labeled (depending on how you set their newfs flags in the Label Editor) and all selected distributions will be extracted. </enum> At this point, you are generally done with the sysinstall utility and can select the final `Quit'. If you are running it as an installer (e.g., before the system is all the way up) then the system will now reboot after you press return one last time. If you selected the boot manager option, you will see a small boot menu with an `F?' prompt. Press the function key for BSD (it will be shown) and you should boot up into FreeBSD off the hard disk. If this fails to happen for some reason, see the Q&A section of the Hardware Guide for possible clues! <sect1><heading>Custom installation</heading> <p>You can do anything you like in this menu without altering your system <em>except</em> for ``Commit'', which will perform any requests to alter your system you may have made. Some of the menu options will also have direct `Write' commands available for committing an operation immediately, but they should only be used if you are absolutely sure it is necessary. It is generally better to make your changes and then commit them all at once so that you are left with the option of changing your mind up to the very last minute. If you are confused at any point, the F1 key usually pulls up the right information for the screen you are in. <sect><heading>MS-DOS user's Questions and Answers</heading> <p>Many FreeBSD users wish to install FreeBSD on PCs inhabited by MS-DOS. Here are some commonly asked questions about installing FreeBSD on such systems. <p><bf>Help! I have no space! Do I need to delete everything first?</bf> If your machine is already running MS-DOS and has little or no free space available for FreeBSD's installation, all is not lost! You may find the FIPS utility, provided in the <tt>tools</tt> directory on the FreeBSD CDROM or on the various FreeBSD ftp sites, to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton Disk tools, then run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the <em>Distributions</em> menu for an estimation of how much free space you will need for the kind of installation you want. <bf>Can I use compressed MS-DOS filesystems from FreeBSD?</bf> No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/dblspaced file!). <bf>Do not remove that file!</bf> You will probably regret it greatly! It is probably better to create another uncompressed MS-DOS primary partition and use this for communications between MS-DOS and FreeBSD. <!-- XXX Status??? <bf>Can I mount my MS-DOS extended partitions?</bf> This feature is not in FreeBSD 2.0.5 but should be in 2.1. We have laid all the groundwork for making this happen, now we just need to do the last 1 percent of the work involved. --> <bf>Can I run MS-DOS binaries under FreeBSD?</bf> Not yet! We would like to add support for this someday, but are still lacking anyone to actually do the work. Ongoing work with Linux's DOSEMU utility may bring this much closer to being a reality sometime soon. Send mail to hackers@freebsd.org if you're interested in joining this effort! However, there is a nice application available in the <ref id="ports" name="The Ports Collection"> called pcemu, that allows you to run many basic MS-DOS text-mode binaries by entirely emulating an 8088 CPU. diff --git a/handbook/submitters.sgml b/handbook/submitters.sgml index f07034e45b..589eadc1dc 100644 --- a/handbook/submitters.sgml +++ b/handbook/submitters.sgml @@ -1,500 +1,500 @@ -<!-- $Id: submitters.sgml,v 1.20 1996-02-06 03:35:16 jkh Exp $ --> +<!-- $Id: submitters.sgml,v 1.21 1996-02-27 15:57:50 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <chapt><heading>Contributing to FreeBSD<label id="submitters"></heading> <p><em>Contributed by &a.jkh;.</em> <p>So you want to contribute something to FreeBSD? That's great! We can always use the help, and FreeBSD is one of those systems that <em>relies</em> on the contributions of its user base in order to survive. Your contributions are not only appreciated, they're vital to FreeBSD's continued growth! <p>Contrary to what some people might also have you believe, you don't need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors who's ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. <p>Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our "TODO" list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there's almost certainly something you can do to help the project! <p>Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You'll find us receptive to your requests, given that they aren't too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. <sect><heading>What's needed</heading> <p>The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we've collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you're interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you'd like to volunteer? <sect1><heading>High priority tasks</heading> <p>The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: <enum> <item>3-stage boot issues. Overall coordination: <tt><htmlurl url="mailto:hackers@freebsd.org" name="Hackers"></tt> <p><itemize> <item>Autodetect memory over 64MB properly. <item>Move userconfig (-c) into 3rd stage boot. <item>Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. </itemize> <item>Filesystem problems. Overall coordination: <tt><htmlurl url="mailto:freebsd-fs@freebsd.org" name="File Systems Group"></tt>. <itemize> <item>Fix the MSDOS file system. <item>Clean up and document the nullfs filesystem code. Coordinator: <tt><htmlurl url="mailto:gibbs@freebsd.org" name="Justin Gibbs"></tt> <item>Fix the union file system. Coordinator: <tt><htmlurl url="mailto:dyson@freebsd.org" name="John Dyson"></tt> <item>Fix the LFS file system. Coordinator: <tt><htmlurl url="mailto:dyson@freebsd.org" name="John Dyson"></tt> </itemize> -<item>Implement kernel & user vm86 support. Coordinator: <tt><htmlurl +<item>Implement kernel and user vm86 support. Coordinator: <tt><htmlurl url="mailto:hackers@freebsd.org" name="Hackers"></tt>. <item>Implement Int13 vm86 disk driver. Coordinator: <tt><htmlurl url="mailto:hackers@freebsd.org" name="Hackers"></tt>. <item>SCSI driver issues. Overall coordination: <tt><htmlurl url="mailto:freebsd-scsi@freebsd.org" name="SCSI Group"></tt>. <p><itemize> <item>Support tagged queuing generically. Requires a rewrite of how we do our command queing, but we need this anyway to for prioritized I/O (CD-R writers/scanners). <item>Better error handling (Busy status and retries). <item>Merged Scatter-Gather list creation code. </itemize> <item>Kernel issues. Overall coordination: <tt><htmlurl url="mailto:freebsd-hackers@freebsd.org" name="Hackers"></tt>. <p><itemize> <item>Complete the eisaconf conversion of all existing drivers. <item>Change all interrupt routines to take a (void *) instead of using unit numbers. <item>Merge EISA/PCI/ISA interrupt registration code. <item>Split PCI/EISA/ISA probes out from drivers like bt742a.c (WIP) <item>Fix the syscons ALT-TAB/vt switching hangs. Coordinator: <tt><htmlurl url="mailto:sos@freebsd.org" name="Soren Schmidt"></tt>. <item>Mouse support for syscons. <item>Merged keyboard code for all console drivers. <item>Rewrite the Intel Etherexpress 16 driver. <item>Merge the 3c509 and 3c590 drivers (essentially provide a PCI probe for ep.c). <item>Support Adaptec 3985 (first as a simple 3 channel SCSI card) Coordinator: <tt><htmlurl url="mailto:gibbs@freebsd.org" name="Justin Gibbs"></tt>. <item>Support Advansys SCSI controller products. Coordinator: <tt><htmlurl url="mailto:gibbs@freebsd.org" name="Justin Gibbs"></tt>. </itemize> </enum> <sect1><heading>Medium priority tasks</heading> <p>The following tasks need to be done, but not with any particular urgency: <enum> <item>DOS emulator (for DOS executables) Coordinator: <tt><htmlurl url="mailto:jr@jrw.org" name="J.R. Westmoreland"></tt> <item>Port AFS (Andrew File System) to FreeBSD Coordinator: <tt><htmlurl url="mailto:ajones@ctron.com" name="Alexander Seth Jones"></tt> <item>MCA support? This should be finalized one way or the other. <item>Full LKM based driver support/Configuration Manager. <p><itemize> <item>Devise a way to do all LKM registration without ld. This means some kind of symbol table in the kernel. <item>Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the LKMs required for your hardware, etc. </itemize> <item>PCMCIA/PCCARD. Coordinator: <tt><htmlurl url="mailto:phk@freebsd.org" name="Poul-Henning Kamp"></tt> <itemize> <item>Reliable operation of the pcic driver. -<item>Recognizer & handler for sio.c -<item>Recognizer & handler for ed.c -<item>Recognizer & handler for ep.c -<item>User-mode recognizer & handler. +<item>Recognizer and handler for sio.c +<item>Recognizer and handler for ed.c +<item>Recognizer and handler for ep.c +<item>User-mode recognizer and handler. </itemize> <item>Advanced Power Management. Coordinator: <tt><htmlurl url="mailto:phk@freebsd.org" name="Poul-Henning Kamp"></tt> <itemize> <item>APM sub-driver. <item>IDE/ATA disk sub-driver. <item>syscons/pcvt sub-driver. </itemize> </enum> <sect1><heading>Low priority tasks</heading> <p>The following tasks are purely cosmetic or represent such an investment of work that it's not likely that anyone will get them done anytime soon: <p>The first 20 items are from Terry Lambert <terry@lambert.org> <enum> <item>Ability to make BIOS calls from protected mode using V86 mode on the processor and return the results via a mapped interrupt IPC mechanism to the protected mode caller. <item>Drivers built into the kernel that use the BIOS call mechanism to allow them to be independent of the actual underlying hardware the same way that DOS is independent of the underlying hardware. This includes NetWork and ASPI drivers loaded in DOS prior to BSD being loaded by a DOS-based loader program, which means potential polling, which means DOS-not-busy interrupt generation for V86 machines by the protected mode kernel. <item>An image format that allows tagging of such drivers data and text areas in the default kernel executable so that that portion of the kernel address space may be recovered at a later time, after hardware specific protected mode drivers have been loaded and activated. This includes separation of BIOS based drivers from each other, since it is better to run with a BIOS based driver in all cases than to not run at all. <item>Abstraction of the bus interface mechanism. Currently, PCMCIA, EISA, and PCI busses are assumed to be bridged from ISA. This is not something which should be assumed. <item>A configuration manager that knows about PNP events, including power management events, insertion, extraction, and bus (PNP ISA and PCMCIA bridging chips) vs. card level event management. <item>A topological sort mechanism for assigning reassignable addresses that do not collide with other reassignable and non-reassignable device space resource usage by fixed devices. <item>A registration based mechanism for hardware services registration. Specifically, a device centric registration mechanism for timer and sound and other system critical service providers. Consider Timer2 and Timer0 and speaker services as one example of a single monolithic service provider. <item>A kernel exported symbol space in the kernel data space accessible by an LKM loader mechanism that does relocation and symbol space manipulation. The intent of this interface is to support the ability to demand load and unload kernel modules. <item>NetWare Server (protected mode ODI driver) loader and subservices to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. <item>An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. <item>Splitting of the console driver into abstraction layers, both to make it easier to port and to kill the X and ThinkPad and PS/2 mouse and LED and console switching and bouncing NumLock problems once and for all. <item>Other kernel emulation environments for other foreign drivers as opportunity permits. SCO and Solaris are good candidates, followed by UnixWare, etc. <item>Processor emulation environments for execution of foreign binaries. This is easier than it sounds if the system call interface doesn't change much. <item>Streams to allow the use of commercial streams drivers. <item>Kernel multithreading (requires kernel preemption). <item>Symmetric Multiprocessing with kernel preemption (requires kernel preemption). <item>A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal vs. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). <item>Reorganization of the source tree for multiple platform ports. <item>A "make world" that "makes the world" (rename the current one to "make regress" if that's all it is good for). <item>A 4M (preferably smaller!) memory footprint. </enum> <sect><heading>How to contribute</heading> <p>Contributions to the system generally fall into one or more of the following 6 categories: <sect1><heading>Bug reports and general commentary</heading> <p>If you have a bug to report or a suggestion to make: <itemize> <item>An idea or suggestion of general technical interest should be mailed to <tt><htmlurl url="mailto:hackers@freebsd.org" name="<hackers@freebsd.org>"></tt>. Likewise, people with an interest in such things (and a tolerance for a <em>high</em> volume of mail!) may subscribe to the hackers mailing list by sending mail to <tt><htmlurl url="mailto:majordomo@freebsd.org" name="<majordomo@freebsd.org>"></tt>. See <ref id="eresources:mail" name="mailing lists"> for more information about this and other mailing lists. <item>An actual bug report should be filed by using the <tt>send-pr(1)</tt> program. This will prompt you for various fields to fill in. Simply go to the fields surrounded by <tt><></tt>'s and fill in your own information in place of what's suggested there. You should receive confirmation of your bug report and a tracking number. Keep this tracking number and use it in any subsequent correspondence. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the <tt>send-pr(1)</tt> command, then you may also file a bug report by sending mail to <tt><htmlurl url="mailto:bugs@freebsd.org" name="<bugs@freebsd.org>"></tt>. </itemize> <sect1><heading>Changes to the documentation</heading> <p>Changes to the documentation are overseen by the FreeBSD Documentation Project, which can be reached at <tt><htmlurl url="mailto:doc@freebsd.org" name="<doc@freebsd.org>"></tt>. This does not generally include changes to manual pages, which should be considered under the category of "changes to existing source code." <sect1><heading>Changes to existing source code</heading> <p>An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as ``FreeBSD-current'' which is made available in a variety of ways for the convenience of developers working actively on the system. See <ref id="current" name="Staying current with FreeBSD"> for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the <tt><announce@freebsd.org></tt> and <tt><current@freebsd.org></tt> mailing lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the <tt>diff(1)</tt> command, with the `context diff' form being preferred. For example: <tscreen><verb> diff -c oldfile newfile </verb></tscreen> or <tscreen><verb> diff -c -r olddir newdir </verb></tscreen> would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for <tt>diff(1)</tt> for more details. Once you have a set of diffs (which you may test with the <tt>patch(1)</tt> command), you should bundle them up in an email message and send it, along with a brief description of what the diffs are for, to <tt><htmlurl url="mailto:hackers@freebsd.org" name="<hackers@freebsd.org>"></tt>. Someone will very likely get back in touch with you in 24 hours or less, assuming of course that your diffs are interesting! :-) If your changes don't express themselves well as diffs alone (e.g. you've perhaps added, deleted or renamed files as well) then you may be better off bundling any new files, diffs and instructions for deleting/renaming others into a <tt>tar</tt> file and running the <tt>uuencode(1)</tt> program on it before sending the output of that to <tt><htmlurl url="mailto:hackers@freebsd.org" name="<hackers@freebsd.org>"></tt>. See the man pages on <tt>tar(1)</tt> and <tt>uuencode(1)</tt> for more information on bundling files this way. If your change is of a potentially sensitive nature, e.g. you're unsure of copyright issues governing its further distribution or you're simply not ready to release it without a tighter review first, then you should send it to <tt><htmlurl url="mailto:core@freebsd.org" name="<core@freebsd.org>"></tt> rather than <tt><hackers@freebsd.org></tt>. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also <em>very busy</em> and so you should only send mail to them in cases where mailing to hackers is truly impractical. <sect1><heading>Contributions of new code</heading> <p>In the case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as uuencoded tar files or upload them to our ftp site <url url="ftp://ftp.freebsd.org/pub/FreeBSD/incoming">. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: <enum> <item>The BSD copyright. This copyright is most preferred due to its ``no strings attached'' nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. <item>The GNU Public License, or ``GPL''. This license isn't quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being <tt>/sys/gnu</tt> or <tt>/usr/src/gnu</tt>, and is therefore easily identifiable to anyone for whom the GPL presents a problem. </enum> <p>Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a ``BSD-style'' copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the `<tt>%%</tt>' with the appropriate information. <tscreen><verb> Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: This product includes software developed by %%your_name_here%%. 4. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - $Id: submitters.sgml,v 1.20 1996-02-06 03:35:16 jkh Exp $ + $Id: submitters.sgml,v 1.21 1996-02-27 15:57:50 jfieber Exp $ </verb></tscreen> For your convenience, a copy of this text can be found in <tt>/usr/share/examples/etc/bsd-style-copyright</tt>. &porting; <sect1><heading>Contributions of money, hardware or Internet access</heading> <p>We're always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <sect2><heading>Donating funds</heading> <p>While the FreeBSD Project is not a 501(C3) (non-profit) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. <p>FreeBSD, Inc. was founded in early 1995 by &a.jkh and &a.davidg with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address: <tscreen><verb> FreeBSD, Inc. 246 Park St. Clyde CA, 94520 </verb></tscreen> Wire transfers may also be sent directly to: <tscreen><verb> Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.) </verb></tscreen> If you do not wish to be listed in our `donors' section, please specify this in a note accompanying your donation. Thanks! <sect2><heading>Donating hardware</heading> <p>Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: <itemize> <item>General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the <em>donating funds</em> section. <item>Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you'd like to make such a donation, please contact &a.davidg for information on which items are still required. <item>Hardware currently unsupported by FreeBSD for which you'd like to see such support added. Please contact the <htmlurl url="mailto:core@freebsd.org" name="FreeBSD Core Team"> before sending such items as we'll need to find a developer willing to take on the task before we can accept delivery of them. </itemize> <sect2><heading>Donating Internet access</heading> <p>We can always use new mirror sites for FTP, WWW or sup. If you'd like to be such a mirror, please contact <htmlurl url="mailto:admin@freebsd.org" name="the FreeBSD project administrators"> for more information. diff --git a/handbook/uart.sgml b/handbook/uart.sgml index 547ed4ba17..1db38b5973 100644 --- a/handbook/uart.sgml +++ b/handbook/uart.sgml @@ -1,1107 +1,1108 @@ -<!-- $Id: uart.sgml,v 1.1 1996-02-16 13:28:22 jkh Exp $ --> +<!-- $Id: uart.sgml,v 1.2 1996-02-27 15:57:51 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [ <!ENTITY % authors SYSTEM "authors.sgml"> %authors; ]> --> <sect2><heading>The UART: What it is and how it works<label id="uart"></heading> <p><em>Copyright © 1996 &a.uhclem;, All Rights Reserved.<newline> 13 January 1996.</em> <!-- Version 1(2) 13-Jan-96 --> The Universal Asynchronous Receiver/Transmitter (UART) controller is the key component of the serial communications subsystem of a computer. The UART takes bytes of data and transmits the individual bits in a sequential fashion. At the destination, a second UART re-assembles the bits into complete bytes. Serial transmission is commonly used with modems and for non-networked communication between computers, terminals and other devices. There are two primary forms of serial transmission: Synchronous and Asynchronous. Depending on the modes that are supported by the hardware, the name of the communication sub-system will usually include a "A" if it supports Asynchronous communications, and a "S" if it supports Synchronous communications. Both forms are described below. Some common acryonyms are: <quote>UART Universal Asynchronous Receiver/Transmitter</quote> <quote>USART Universal Synchronous-Asynchronous Receiver/Transmitter</quote> <sect3><heading>Synchronous Serial Transmission</heading> <p>Synchronous serial transmission requires that the sender and receiver share a clock with one another, or that the sender provide a strobe or other timing signal so that the receiver knows when to "read" the next bit of the data. In most forms of serial Synchronous communication, if there is no data available at a given instant to transmit, a fill character must be sent instead so that data is always being transmitted. Synchronous communication is usually more efficient because only data bits are transmitted between sender and receiver, and synchronous communication can be more more costly if extra wiring and circuits are required to share a clock signal between the sender and receiver. A form of Synchronous transmission is used with printers and fixed disk devices in that the data is sent on one set of wires while a clock or strobe is sent on a different wire. Printers and fixed disk devices are not normally serial devices because most fixed disk interface standards send an entire word of data for each clock or strobe signal by using a separate wire for each bit of the word. In the PC industry, these are known as Parallel devices. The standard serial communications hardware in the PC does not support Synchronous operations. This mode is described here for comparison purposes only. <sect3><heading>Asynchronous Serial Transmission</heading> <p>Asynchronous transmission allows data to be transmitted without the sender having to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters in advance and special bits are added to each word which are used to synchronize the sending and receiving units. When a word is given to the UART for Asynchronous transmissions, a bit called the "Start Bit" is added to the beginning of each word that is to be transmitted. The Start Bit is used to alert the receiver that a word of data is about to be sent, and to force the clock in the receiver into synchronization with the clock in the transmitter. These two clocks must be accurate enough to not have the frequency drift by more than 10% during the transmission of the remaining bits in the word. (This requirement was set in the days of mechanical teleprinters and is easily met by modern electronic equipment.) After the Start Bit, the individual bits of the word of data are sent, with the Least Significant Bit (LSB) being sent first. Each bit in the transmission is transmitted for exactly the same amount of time as all of the other bits, and the receiver "looks" at the wire at approximately halfway through the period assigned to each bit to determine if the bit is a "1" or a "0". For example, if it takes two seconds to send each bit, the receiver will examine the signal to determine if it is a "1" or a "0" after one second has passed, then it will wait two seconds and then examine the value of the next bit, and so on. The sender does not know when the receiver has "looked" at the value of the bit. The sender only knows when the clock says to begin transmitting the next bit of the word. When the entire data word has been sent, the transmitter may add a Parity Bit that the transmitter generates. The Parity Bit may be used by the receiver to perform simple error checking. Then at least one Stop Bit is sent by the transmitter. When the receiver has received all of the bits in the data word, it may check for the Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed to, the UART considers the entire word to be garbled and will report a Framing Error to the host processor when the data word is read. The usual cause of a Framing Error is that the sender and receiver clocks were not running at the same speed, or that the signal was interrupted. Regardless of whether the data was received correctly or not, the UART automatically discards the Start, Parity and Stop bits. If the sender and receiver are configured identically, these bits are not passed to the host. If another word is ready for transmission, the Start Bit for the new word can be sent as soon as the Stop Bit for the previous word has been sent. Because asynchronous data is "self synchronizing", if there is no data to transmit, the transmission line can be idle. <sect3><heading>Other UART Functions</heading> <p>In addition to the basic job of converting data from parallel to serial for transmission and from serial to parallel on reception, a UART will usually provide additional circuits for signals that can be used to indicate the state of the transmission media, and to regulate the flow of data in the event that the remote device is not prepared to accept more data. For example, when the device connected to the UART is a modem, the modem may report the presence of a carrier on the phone line while the computer may be able to instruct the modem to reset itself or to not take calls by asserting or deasserting one more more of these extra signals. The function of each of these additional signals is defined in the EIA RS232-C standard. <sect3><heading>The RS232-C and V.24 Standards</heading> <p>In most computer systems, the UART is connected to circuitry that generates signals that comply with the EIA RS232-C specification. There is also a CCITT standard named V.24 that mirrors the specifications included in RS232-C. <sect4><heading>RS232-C Bit Assignments (Marks and Spaces)</heading> <p>In RS232-C, a value of "1" is called a "Mark" and a value of "0" is called a "Space". When a communication line is idle, the line is said to be "Marking", or transmitting continuous "1" values. The Start bit always has a value of "0" (a Space). The Stop Bit always has a value of "1" (a Mark). This means that there will always be a Mark (1) to Space (0) transition on the line at the start of every word, even when multiple word are transmitted back to back. This guarantees that sender and receiver can resynchronize their clocks regardless of the content of the data bits that are being transmitted. The idle time between Stop and Start bits does not have to be an exact multiple (including zero) of the bit rate of the communication link, but most UARTs are designed this way for simplicity. In RS232-C, the "Marking" signal (a "1") is represented by a voltage between -2 VDC and -12 VDC, and a "Spacing" signal (a "0") is represented by a voltage between 0 and +12 VDC. The transmitter is supposed to send +12 VDC or -12 VDC, and the receiver is supposed to allow for some voltage loss in long cables. Some transmitters in low power devices (like portable computers) sometimes use only +5 VDC and -5 VDC, but these values are still acceptable to a RS232-C receiver, provided that the cable lengths are short. <sect4><heading>RS232-C Break Signal</heading> <p>RS232-C also specifies a signal called a "Break", which is caused by sending continuous Spacing values (no Start or Stop bits). When there is no electricity present on the data circuit, the line is considered to be sending "Break". The "Break" signal must be of a duration longer than the time it takes to send a complete byte plus Start, Stop and Parity bits. Most UARTs can distinguish between a Framing Error and a Break, but if the UART cannot do this, the Framing Error detection can be used to identify Breaks. In the days of teleprinters, when numerous printers around the country were wired in series (such as news services), any unit could cause a "Break" by temporarily opening the entire circuit so that no current flowed. This was used to allow a location with urgent news to interrupt some other location that was currently sending information. In modern systems there are two types of Break signals. If the Break is longer than 1.6 seconds, it is considered a "Modem Break", and some modems can be programmed to terminate the conversation and go on-hook or enter the modems' command mode when the modem detects this signal. If the Break is smaller than 1.6 seconds, it signifies a Data Break and it is up to the remote computer to respond to this signal. Sometimes this form of Break is used as an Attention or Interrupt signal and sometimes is accepted as a substitute for the ASCII CONTROL-C character. Marks and Spaces are also equivalent to "Holes" and "No Holes" in paper tape systems. Note that Breaks cannot be generated from paper tape or from any other byte value, since bytes are always sent with Start and Stop bit. The UART is usually capable of generating the continuous Spacing signal in response to a special command from the host processor. <sect4><heading>RS232-C DTE and DCE Devices</heading> <p>The RS232-C specification defines two types of equipment: the Data Terminal Equipment (DTE) and the Data Carrier Equipment (DCE). Usually, the DTE device is the terminal (or computer), and the DCE is a modem. Across the phone line at the other end of a conversation, the receiving modem is also a DCE device and the computer that is connected to that modem is a DTE device. The DCE device receives signals on the pins that the DTE device transmits on, and vice versa. When two devices that are both DTE or both DCE must be connected together without a modem or a similar media translater between them, a NULL modem must be used. The NULL modem electrically re-arranges the cabling so that the transmitter output is connected to the receiver input on the other device, and vice versa. Similar translations are performed on all of the control signals so that each device will see what it thinks are DCE (or DTE) signals from the other device. The number of signals generated by the DTE and DCE devices are not symmetrical. The DTE device generates fewer signals for the DCE device than the DTE device receives from the DCE. <sect4><heading>RS232-C Pin Assignments</heading> <p>The EIA RS232-C specification (and the ITU equivalent, V.24) calls for a twenty-five pin connector (usually a DB25) and defines the purpose of most of the pins in that connector. In the IBM Personal Computer and similar systems, a subset of RS232-C signals are provided via nine pin connectors (DB9). The signals that are not included on the PC connector deal mainly with synchronous operation, and this transmission mode is not supported by the UART that IBM selected for use in the IBM PC. Depending on the computer manufacturer, a DB25, a DB9, or both types of connector may be used for RS232-C communications. (The IBM PC also uses a DB25 connector for the parallel printer interface which causes some confusion.) Below is a table of the RS232-C signal assignments in the DB25 and DB9 connectors. <verb> DB25 DB9 EIA CCITT Common Signal Description RS232-C IBM PC Circuit Circuit Name Source Pin Pin Symbol Symbol 1 - AA 101 PG/FG --- Frame/Protective Ground 2 3 BA 103 TD DTE Transmit Data 3 2 BB 104 RD DCE Receive Data 4 7 CA 105 RTS DTE Request to Send 5 8 CB 106 CTS DCE Clear to Send 6 6 CC 107 DSR DCE Data Set Ready 7 5 AV 102 SG/GND --- Signal Ground 8 1 CF 109 DCD/CD DCE Data Carrier Detect 9 - - - - - Reserved for Test 10 - - - - - Reserved for Test 11 - - - - - Unassigned 12 - CI 122 SRLSD DCE Sec. Recv. Line Signal Detector 13 - SCB 121 SCTS DCE Secondary Clear To Send 14 - SBA 118 STD DTE Secondary Transmit Data 15 - DB 114 TSET DCE Trans. Sig. Element Timing 16 - SBB 119 SRD DCE Secondary Received Data 17 - DD 115 RSET DCE Receiver Signal Element Timing 18 - - 141 LOOP DTE Local Loopback 19 - SCA 120 SRS DTE Secondary Request to Send 20 4 CD 108.2 DTR DTE Data Terminal Ready 21 - - - RDL DTE Remote Digital Loopback 22 9 CE 125 RI DCE Ring Indicator 23 - CH 111 DSRS DTE Data Signal Rate Selector 24 - DA 113 TSET DTE Trans. Sig. Element Timing 25 - - 142 - DCE Test Mode </verb> <sect3><heading>Bits, Baud and Symbols</heading> <p>Baud is a measurment of transmission speed in asynchronous communication. Because of advances in modem communication technology, this term is frequently misused when describing the data rates in newer devices. Traditionally, a Baud Rate represents the number of bits that are actually being sent over the media, not the amount of data that is actually moved from one DTE device to the other. The Baud count includes the overhead bits Start, Stop and Parity that are generated by the sending UART and removed by the receiving UART. This means that seven-bit words of data actually take 10 bits to be completely transmitted. Therefore, a modem capable of moving 300 bits per second from one place to another can normally only move 30 7-bit words if Parity is used and one Start and Stop bit are present. If 8-bit data words are used and Parity bits are also used, the data rate falls to 27.27 words per second, because it now takes 11 bits to send the eight-bit words, and the modem still only sends 300 bits per second. The formula for converting bytes per second into a baud rate and vice versa was simple until error-correcting modems came along. These modems receive the serial stream of bits from the UART in the host computer (even when internal modems are used the data is still frequently serialized) and converts the bits back into bytes. These bytes are then combined into packets and sent over the phone line using a Synchronous transmission method. This means that the Stop, Start, and Parity bits added by the UART in the DTE (the computer) were removed by the modem before transmission by the sending modem. When these bytes are received by the remote modem, the remote modem adds Start, Stop and Parity bits to the words, converts them to a serial format and then sends them to the receiving UART in the remote computer, who then strips the Start, Stop and Parity bits. The reason all these extra conversions are done is so that the two modems can perform error correction, which means that the receiving modem is able to ask the sending modem to resend a block of data that was not received with the correct checksum. This checking is handled by the modems, and the DTE devices are usually unaware that the process is occurring. By striping the Start, Stop and Parity bits, the additional bits of data that the two modems must share between themselves to perform error-correction are mostly concealed from the effective transmission rate seen by the sending and receiving DTE equipment. For example, if a modem sends ten 7-bit words to another modem without including the Start, Stop and Parity bits, the sending modem will be able to add 30 bits of its own information that the receiving modem can use to do error-correction without impacting the transmission speed of the real data. The use of the term Baud is further confused by modems that perform compression. A single 8-bit word passed over the telephone line might represent a dozen words that were transmitted to the sending modem. The receiving modem will expand the data back to its original content and pass that data to the receiving DTE. Modern modems also include buffers that allow the rate that bits move across the phone line (DCE to DCE) to be a different speed than the speed that the bits move between the DTE and DCE on both ends of the conversation. Normally the speed between the DTE and DCE is higher than the DCE to DCE speed because of the use of compression by the modems. Because the number of bits needed to describe a byte varied during the trip between the two machines plus the differing bits-per-seconds speeds that are used present on the DTE-DCE and DCE-DCE links, the usage of the term Baud to describe the overall communication speed causes problems and can misrepresent the true transmission speed. So Bits Per Second (bps) is the correct term to use to describe the transmission rate seen at the DCE to DCE interface and Baud or Bits Per Second are acceptable terms to use when a connection is made between two systems with a wired connection, or if a modem is in use that is not performing error-correction or compression. Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality still operate at or below 2400 baud, or more accurately, 2400 Symbols per second. High speed modem are able to encode more bits of data into each Symbol using a technique called Constellation Stuffing, which is why the effective bits per second rate of the modem is higher, but the modem continues to operate within the limited audio bandwidth that the telephone system provides. Modems operating at 28,800 and higher speeds have variable Symbol rates, but the technique is the same. <sect3><heading>The IBM Personal Computer UART</heading> <p>Starting with the original IBM Personal Computer, IBM selected the National Semiconductor INS8250 UART for use in the IBM PC Parallel/Serial Adapter. Subsequent generations of compatible computers from IBM and other vendors continued to use the INS8250 or improved versions of the National Semiconductor UART family. <sect4><heading>National Semiconductor UART Family Tree</heading> <p>There have been several versions and subsequent generations of the INS8250 UART. Each major version is described below. <verb> INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D </verb> <descrip> <tag>INS8250</tag>This part was used in the original IBM PC and IBM PC/XT. The original name for this part was the INS8250 ACE (Asynchronous Communications Element) and it is made from NMOS technology. The 8250 uses eight I/O ports and has a one-byte send and a one-byte receive buffer. This original UART has several race conditions and other flaws. The original IBM BIOS includes code to work around these flaws, but this made the BIOS dependent on the flaws being present, so subsequent parts like the 8250A, 16450 or 16550 could not be used in the original IBM PC or IBM PC/XT. <tag>INS8250-B</tag>This is the slower speed of the INS8250 made from NMOS technology. It contains the same problems as the original INS8250. <tag>INS8250A</tag>An improved version of the INS8250 using XMOS technology with various functional flaws corrected. The INS8250A was used initially in PC clone computers by vendors who used "clean" BIOS designs. Because of the corrections in the chip, this part could not be used with a BIOS compatible with the INS8250 or INS8250B. <tag>INS82C50A</tag>This is a CMOS version (low power consumption) of the INS8250A and has similar functional characteristics. <tag>NS16450</tag>Same as NS8250A with improvements so it can be used with faster CPU bus designs. IBM used this part in the IBM AT and updated the IBM BIOS to no longer rely on the bugs in the INS8250. <tag>NS16C450</tag>This is a CMOS version (low power consumption) of the NS16450. <tag>NS16550</tag>Same as NS16450 with a 16-byte send and receive buffer but the buffer design was flawed and could not be reliably be used. <tag>NS16550A</tag>Same as NS16550 with the buffer flaws corrected. The 16550A and its successors have become the most popular UART design in the PC industry, mainly due it its ability to reliably handle higher data rates on operating systems with sluggish interrupt response times. <tag>NS16C552</tag>This component consists of two NS16C550A CMOS UARTs in a single package. <tag>PC16550D</tag>Same as NS16550A with subtle flaws corrected. This is revision D of the 16550 family and is the latest design available from National Semiconductor. </descrip> <sect4><heading>The NS16550AF and the PC16550D are the same thing</heading> <p>National reorganized their part numbering system a few years ago, and the NS16550AFN no longer exists by that name. (If you have a NS16550AFN, look at the date code on the part, which is a four digit number that usually starts with a nine. The first two digits of the number are the year, and the last two digits are the week in that year when the part was packaged. If you have a NS16550AFN, it is probably a few years old.) The new numbers are like PC16550DV, with minor differences in the suffix letters depending on the package material and its shape. (A description of the numbering system can be found below.) It is important to understand that in some stores, you may pay - $15(US) for a NS16550AFN made in 1990 and in the next bin are the + $15(US) for a NS16550AFN made in 1990 and in the next bin are the new PC16550DN parts with minor fixes that National has made since the AFN part was in production, the PC16550DN was probably made in the - past six months and it costs half (as low as $5(US) in volume) as + past six months and it costs half (as low as $5(US) in volume) as much as the NS16550AFN because they are readily available. As the supply of NS16550AFN chips continues to shrink, the price will probably continue to increase until more people discover and accept that the PC16550DN really has the same function as the old part number. <sect4><heading>National Semiconductor Part Numbering System</heading> <p>The older NS<em>nnnnnrqp</em> part numbers are now of the format PC<em>nnnnnrgp</em>. The "<em>r</em>" is the revision field. The current revision of the 16550 from National Semiconductor is "D". The "<em>p</em>" is the package-type field. The types are: <verb> "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type</verb> The "<em>g</em>" is the product grade field. If an "I" preceeds the package-type letter, it indicates an "industrial" grade part, which has higher specs than a standard part but not as high as Miltary Specification (Milspec) component. This is an optional field. So what we used to call a NS16550AFN (DIP Package) is now called a PC16550DN or PC16550DIN. <sect3><heading>Other Vendors and Similar UARTs</heading> <p>Over the years, the 8250, 8250A, 16450 and 16550 have been licensed or copied by other chip vendors. In the case of the 8250, 8250A and 16450, the exact circuit (the "megacell") was licensed to many vendors, including Western Digital and Intel. Other vendors reverse-engineered the part or produced emulations that had similar behavior. In internal modems, the modem designer will frequently emulate the 8250A/16450 with the modem microprocessor, and the emulated UART will frequently have a hidden buffer consisting of several hundred bytes. Because of the suze of the buffer, these emulations can be as reliable as a 16550A in their ability to handle high speed data. However, most operating systems will still report that the UART is only a 8250A or 16450, and may not make effective use of the extra buffering present in the emulated UART unless special drivers are used. Some modem makers are driven by market forces to abandon a design that has hundreds of bytes of buffer and instead use a 16550A UART so that the product will compare favorably in market comparisons even though the effective performance may be lowered by this action. A common misconception is that all parts with "16550A" written on them are identical in performance. There are differences, and in some cases, outright flaws in most of these 16550A clones. When the NS16550 was developed, the National Semiconductor obtained several patents on the design and they also limited licensing, making it harder for other vendors to provide a chip with similar features. Because of the patents, reverse-engineered designs and emulations had to avoid infringing the claims covered by the patents. Subsequently, these copies almost never perform exactly the same as the NS16550A or PC16550D, which are the parts most computer and modem makers want to buy but are sometimes unwilling to pay the price required to get the genuine part. Some of the differences in the clone 16550A parts are unimportant, while others can prevent the device from being used at all with a given operating system or driver. These differences may show up when using other drivers, or when particular combinations of events occur that were not well tested or considered in the Windows driver. This is because most modem vendors and 16550-clone makers use the Microsoft drivers from Windows for Workgroups 3.11 and the Microsoft MSD utility as the primary tests for compatibility with the NS16550A. This over-simplistic criteria means that if a different operating system is used, problems could appear due to subtle differences between the clones and genuine components. National Semiconductor has made available a program named COMTEST that performs compatibility tests independent of any OS drivers. It should be remembered that the purpose of this type of program is to demonstrate the flaws in the products of the competition, so the program will report major as well as extremely subtle differences in behavior in the part being tested. In a series of tests performed by the author of this document in 1994, components made by National Semiconductor, TI, StarTech, and CMD as well as megacells and emulations embedded in internal modems were tested with COMTEST. A difference count for some of these components is listed below. Because these tests were performed in 1994, they may not reflect the current performance of the given product from a vendor. It should be noted that COMTEST normally aborts when an excessive number or certain types of problems have been detected. As part of this testing, COMTEST was modified so that it would not abort no matter how many differences were encountered. <verb>Vendor Part number Errors aka "differences" reported National (PC16550DV) 0 * National (NS16550AFN) 0 National (NS16C552V) 0 * TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra modem with an internal 16550 (SC11951/SC11351) 91</verb> <p>It is important to understand that a simple count of differences from COMTEST does not reveal a lot about what differences are important and which are not. For example, about half of the differences reported in the two modems listed above that have internal UARTs were caused by the clone UARTs not supporting five- and six-bit character modes. The real 16550, 16450, and 8250 UARTs all support these modes and COMTEST checks the functionality of these modes so over fifty differences are reported. However, almost no modern modem supports five- or six-bit characters, particularly those with error-correction and compression capabilities. This means that the differences related to five- and six-bit character modes can be discounted. Many of the differences COMTEST reports have to do with timing. In many of the clone designs, when the host reads from one port, the status bits in some other port may not update in the same amount of time (some faster, some slower) as a <em>real</em> NS16550AFN and COMTEST looks for these differences. This means that the number of differences can be misleading in that one device may only have one or two differences but they are extremely serious, and some other device that updates the status registers faster or slower than the reference part (that would probably never affect the operation of a properly written driver) could have dozens of differences reported. * To date, the author of this document has not found any non-National parts that report zero differences using the COMTEST program. It should also be noted that National has had five versions of the 16550 over the years and the newest parts behave a bit differently than the classic NS16550AFN that is considered the benchmark for functionality. COMTEST appears to turn a blind eye to the differences within the National product line and reports no errors on the National parts (except for the original 16550) even when there are official erattas that describe bugs in the A, B and C revisions of the parts, so this bias in COMTEST must be taken into account. COMTEST can be used as a screening tool to alert the administrator to the presence of potentially incompatible components that might cause problems or have to be handled as a special case. If you run COMTEST on a 16550 that is in a modem or a modem is attached to the serial port, you need to first issue a ATE0&W command to the modem so that the modem will not echo any of the test characters. If you forget to do this, COMTEST will report at least this one difference: <quote>Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61</quote> <sect3><heading>8250/16450/16550 Registers</heading> <p>The 8250/16450/16550 UART occupies eight contiguous I/O port addresses. In the IBM PC, there are two defined locations for these eight ports and they are known collectively as COM1 and COM2. The makers of PC-clones and add-on cards have created two additional areas known as COM3 and COM4, but these extra COM ports conflict with other hardware on some systems. The most common conflict is with video adapters that provide IBM 8514 emulation. <verb> COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ 4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3 COM3 is located from 0x3e8 to 0x3ef and has no standardized IRQ COM4 is located from 0x2e8 to 0x2ef and has no standardized IRQ </verb> <p>A description of the I/O ports of the 8250/16450/16550 UART is provided below. <verb> I/O Access Description Port Allowed +0x00 write Transmit Holding Register (THR) (DLAB==0) Information written to this port are treated as data words and will be transmitted by the UART. +0x00 read Receive Buffer Register (RBR) (DLAB==0) Any data words received by the UART from the serial link are accessed by the host by reading this port. +0x00 write/read Divisor Latch LSB (DLL) (DLAB==1) This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 0 thru 7 of the divisor. +0x01 write/read Divisor Latch MSB (DLH) (DLAB==1) This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 8 thru 15 of the divisor. +0x01 write/read Interrupt Enable Register (IER) (DLAB==0) The 8250/16450/16550 UART classifies events into one of four categories. Each category can be configured to generate an interrupt when any of the events occurs. The 8250/16450/16550 UART generates a single external interrupt signal regardless of how many events in the enabled categories have occurred. It is up to the host processor to respond to the interrupt and then poll the enabled interrupt categories (usually all categories have interrupts enabled) to determine the true cause(s) of the interrupt. Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Enable Modem Status Interrupt (EDSSI) Setting this bit to "1" allows the UART to generate an interrupt when a change occurs on one or more of the status lines. Bit 2 Enable Receiver Line Status Interrupt (ELSI) Setting this bit to "1" causes the UART to generate an interrupt when the an error (or a BREAK signal) has been detected in the incoming data. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has room for one or more additional characters that are to be transmitted. Bit 0 Enable Received Data Available Interrupt (ERBFI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has received enough characters to exceed the trigger level of the FIFO, or the FIFO timer has expired (stale data), or a single character has been received when the FIFO is disabled. +0x02 write FIFO Control Register (FCR) (This port does not exist on the 8250 and 16450 UART.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0 These two bits control at what point the receiver is to generate an interrupt when the FIFO is active. 7 6 How many words are received before an interrupt is generated. 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 DMA Mode Select If Bit 0 is set to "1" (FIFOs enabled), setting this bit changes the operation of the -RXRDY and -TXRDY signals from Mode 0 to Mode 1. Bit 2 Transmit FIFO Reset When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being transmitted will be sent intact. This function is useful in aborting transfers. Bit 1 Receiver FIFO Reset When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being assembled in the shift register will be received intact. Bit 0 16550 FIFO Enable When set, both the transmit and receive FIFOs are enabled. Any contents in the holding register, shift registers or FIFOs are lost when FIFOs are enabled or disabled. +0x02 read Interrupt Identification Register (IIR) Bit 7 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 6 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Interrupt ID Bit #2 On the 8250/16450 UART, this bit is zero. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0 These three bits combine to report the category of event that caused the interrupt that is in progress. These categories have priorities, so if multiple categories of events occur at the same time, the UART will report the more important events first and the host must resolve the events in the order they are reported. All events that caused the current interrupt must be resolved before any new interrupts will be generated. (This is a limitation of the PC architecture.) 2 1 0 Priority Description 0 1 1 First Receiver Error (OE, PE, BI or FE) 0 1 0 Second Received Data Available 1 1 0 Second Trigger level identification (Stale data in receive buffer) 0 0 1 Third Transmitter has room for more words (THRE) 0 0 0 Fourth Modem Status Change (-CTS, -DSR, -RI, or -DCD) Bit 0 Interrupt Pending Bit If this bit is set to "0", then at least one interrupt is pending. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB) When set, access to the data transmit/receive register (THR/RBR) and the Interrupt Enable Register (IER) is disabled. Any access to these ports is now redirected to the Divisor Latch Registers. Setting this bit, loading the Divisor Registers, and clearing DLAB should be done with interrupts disabled. Bit 6 Set Break When set to "1", the transmitter begins to transmit continuous Spacing until this bit is set to "0". This overrides any bits of characters that are being transmitted. Bit 5 Stick Parity When parity is enabled, setting this bit causes parity to always be "1" or "0", based on the value of Bit 4. Bit 4 Even Parity Select (EPS) When parity is enabled and Bit 5 is "0", setting this bit causes even parity to be transmitted and expected. Otherwise, odd parity is used. Bit 3 Parity Enable (PEN) When set to "1", a parity bit is inserted between the last bit of the data and the Stop Bit. The UART will also expect parity to be present in the received data. Bit 2 Number of Stop Bits (STB) If set to "1" and using 5-bit data words, 1.5 Stop Bits are transmitted and expected in each data word. For 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. When this bit is set to "0", one Stop Bit is used on each data word. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) Together these bits specify the number of bits in each data word. 1 0 Word Length 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Loop-Back Enable When set to "1", the UART transmitter and receiver are internally connected together to allow diagnostic operations. In addition, the UART modem control outputs are connected to the UART modem control inputs. CTS is connected to RTS, DTR is connected to DSR, OUT1 is connected to RI, and OUT 2 is connected to DCD. Bit 3 OUT 2 An auxillary output that the host processor may set high or low. In the IBM PC serial adapter (and most clones), OUT 2 is used to tri-state (disable) the interrupt signal from the 8250/16450/16550 UART. Bit 2 OUT 1 An auxillary output that the host processor may set high or low. This output is not used on the IBM PC serial adapter. Bit 1 Request to Send (RTS) When set to "1", the output of the UART -RTS line is Low (Active). Bit 0 Data Terminal Ready (DTR) When set to "1", the output of the UART -DTR line is Low (Active). +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO On the 8250/16450 UART, this bit is zero. This bit is set to "1" when any of the bytes in the FIFO have one or more of the following error conditions: PE, FE, or BI. Bit 6 Transmitter Empty (TEMT) When set to "1", there are no words remaining in the transmit FIFO or the transmit shift register. The transmitter is completely idle. Bit 5 Transmitter Holding Register Empty (THRE) When set to "1", the FIFO (or holding register) now has room for at least one additional word to transmit. The transmitter may still be transmitting when this bit is set to "1". Bit 4 Break Interrupt (BI) The receiver has detected a Break signal. Bit 3 Framing Error (FE) A Start Bit was detected but the Stop Bit did not appear at the expected time. The received word is probably garbled. Bit 2 Parity Error (PE) The parity bit was incorrect for the word received. Bit 1 Overrun Error (OE) A new word was received and there was no room in the receive buffer. The newly-arrived word in the shift register is discarded. On 8250/16450 UARTs, the word in the holding register is discarded and the newly- arrived word is put in the holding register. Bit 0 Data Ready (DR) One or more words are in the receive FIFO that the host may read. A word must be completely received and moved from the shift register into the FIFO (or holding register for 8250/16450 designs) before this bit is set. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD) Reflects the state of the DCD line on the UART. Bit 6 Ring Indicator (RI) Reflects the state of the RI line on the UART. Bit 5 Data Set Ready (DSR) Reflects the state of the DSR line on the UART. Bit 4 Clear To Send (CTS) Reflects the state of the CTS line on the UART. Bit 3 Delta Data Carrier Detect (DDCD) Set to "1" if the -DCD line has changed state one more more times since the last time the MSR was read by the host. Bit 2 Trailing Edge Ring Indicator (TERI) Set to "1" if the -RI line has had a low to high transition since the last time the MSR was read by the host. Bit 1 Delta Data Set Ready (DDSR) Set to "1" if the -DSR line has changed state one more more times since the last time the MSR was read by the host. Bit 0 Delta Clear To Send (DCTS) Set to "1" if the -CTS line has changed state one more more times since the last time the MSR was read by the host. +0x07 write/read Scratch Register (SCR) This register performs no function in the UART. Any value can be written by the host to this location and read by the host later on. </verb> <sect3><heading>Beyond the 16550A UART</heading> <p>Although National Semiconductor has not offered any components compatible with the 16550 that provide additional features, various other vendors have. Some of these components are described below. It should be understood that to effectively utilize these improvements, drivers may have to be provided by the chip vendor since most of the popular operating systems do not support features beyond those provided by the 16550. <descrip> <tag>ST16650</tag>By default this part is similar to the NS16550A, but an extended 32-byte send and receive buffer can be optionally enabled. Made by Startech. <tag>TIL16660</tag>By default this part behaves similar to the NS16550A, but an extended 64-byte send and receive buffer can be optionally enabled. Made by Texas Instruments. <tag>Hayes ESP</tag>This proprietary plug-in card contains a 2048-byte send and receive buffer, and supports data rates to 230.4Kbit/sec. Made by Hayes. </descrip> <p>In addition to these "dumb" UARTs, many vendors produce intelligent serial communication boards. This type of design usually provides a microprocessor that interfaces with several UARTs, processes and buffers the data, and then alerts the main PC processor when necessary. Because the UARTs are not directly accessed by the PC processor in this type of communication system, it is not necessary for the vendor to use UARTs that are compatible with the 8250, 16450, or the 16550 UART. This leaves the designer free to components that may have better performance characteristics. -601131 +<!-- 601131 ? --> +