In issue 7, a reader asked "Why don't you report on the bad BBSs out there?"
We replied that we didn't need to point out bad BBSs because traditional media did this so well. We have reconsidered that reply. Recent media reports have demonstrated a continued lack of understanding about common versus illegal BBSs.

A "bad" BBS endorses, supports, or allows illegal activities. A pirate BBS endorses the stealing, "cracking", and sharing of commercial software. This article is primarily about pirate BBSs because they are (by far) the most common type of illegal BBS.

The tiny percentage of bad BBSs should not reflect on BBSs as a whole. Every profession or association has a few bad apples. A typical media message is that BBSs are used for illegal activities. (Imagine the media reporting that automobiles are used to rob banks, or that a group of businesses are suspect because up to 1% of them are criminals.)

Coders are the skilled programmers who write/modify software. At least two BBS software packages have been written to accommodate the special needs of Elite pirates. These pirate BBS packages have "back doors" that let Elite members remotely control the BBS. Elite BBS packages have other special features, including very deeply nested security levels. It is rumored they have "punishments" (such as erasing the hard drive) within some of their BBS software programs to deal with those not authorized to run the BBS software.

Generally, coders do not create viruses. A few coders release some very impressive graphic animations. The work of coders is respected far beyond the pirate community. Their graphical animated programs are amazing to watch and are harmless. Many coders are also very skilled in ANSI animations.

Crackers are the (usually lesser-skilled) programmers who defeat copy protection, remove copyright and product information, and sometimes modify programs to their liking.

Couriers are the people who spread cracked (or just plain illegally copied) software from one pirate BBS to another. Couriers also hand-carry pirated software between computer systems around the world.

Lamers are unauthorized callers of an pirate BBS. Pirates are very careful about who they let into their clan, for obvious reasons. Generally, membership is confined to referrals.

Complicating the effort to find them, pirate BBSs are typically short-lived. Sometimes the short life of a pirate BBS is due to the age or instability of the Sysop. Other times the boards rotate locations to add another layer of safety. This invisible network of pirates keep each other updated. Of course, if a pirate BBS goes down or gets busted, another one soon springs up to take its place.

The biggest pirate-induced risk to the average modem user is that they might become an inadvertent courier. Some pirated software looks like shareware or a demo of a commercial program. It is a good habit to look at a file before you upload it anywhere. If you upload pirate software to a BBS, the Sysop might take an appropriate action. (As files get transferred between BBS systems, they are typically checked repeatedly for viruses and pirated software.)

• 1) The files are intended to benefit only the legitimate owners of the targeted software programs.

• 2) The targeted application is never located on the BBS. Although game cracks are controversial, they are not in the same league as pirated software.

Warning Signs - be suspicious of these warning signs:

• The file is commercial software. If you see Lotus 123 or WordPerfect, you know you have stolen software!

• The file is cracked commercial software. If the program is named FREECALC.EXE, but it looks very much like Lotus 123 - and it displays something like "Cracked by the Grand Warrior at BBS: 709-PRI-VATE", you know you have cracked software.

• The file contains bragging text files that claim allegiance to the Elite or say Courier to the Elite, or Cracked or Hacked or broken or whatever. (This is not foolproof as many legitimate graphic animation programs and files are written by crackers - and pose no danger.) Sometimes would-be crackers take false credit for a legitimate demo of a commercial program.

IBM invented the floppy disk. Allen Shugart was quick to see the market for floppy disk drives outside of IBM. To fulfill his vision, Shugart surrounded himself with some of the finest minds around and called the company Shugart Associates (SA). Allen Shugart is a mechanical engineer. It's not too surprising the key people at SA tended to be mechanical engineers too. At SA, mechanical engineering projects competed with electrical projects for development funds and usually won.

Designing the electrical circuits of the floppy drive was not particularly difficult. The first designs used standard "glue" (off-the-shelf) chips. When the focus shifted from 8 inch floppies to 5-inch floppies, the electrical engineers said "Big deal". The 5-inch drive was designed to be cheaper, not better. Electrically, its circuits were inferior to the existing 8-inch drives. The challenge of designing floppy drives was in the electro-mechanical (E/M) and read/write head designs. Here, the engineers scrambled because none of the existing commodity E/M parts were really adequate. They cost too much, and their quality severely limited performance.

Allen continued to watch IBM's technology. At that time, the industry was starting to focus on Winchester hard disk technology. While nobody really agreed exactly what Winchester technology was or meant, they did agree it was the future technology for hard drives and was hot stuff. Winchester technology focused on providing comparable storage capacity in a much smaller sized drive.

Allen started developing hard drives at Shugart Associates. It's difficult to say which drive model was first because several had a high rate of infant mortality. There was the model SA604, the 606, followed by the 612. By then, the new half-height technology had taken over the floppy market. The half height idea was quickly transferred to the hard disks and the 612 model became the 712.

Hard drives offered a few technical challenges to the electrical engineer, but mostly the challenges were still how to make the circuits cheaper, not better. At this time hard drives were not used much for PCs. Rather, they were system components in mainframe computing.

SASI was not immediately accepted. Some argued is was needed, while others did not see the need in the newly emerging PC market. What value was SASI when mainframes were becoming less popular, they argued. The existing MFM hard drives used a speeded up version of the serial floppy interface. SASI was a parallel interface! It couldn't even talk to a floppy or a regular hard drive. Some argued that SASI was just a project to keep the electrical engineers happy.

By then, SASI was just one of Shugart's many problems. Many other companies had figured out how to make floppy drives - SA's bread and butter. Profits were eroding. Layoffs started. Head hunters found SA easy pickings as they raided some of the best talent. Then Xerox stepped up and offered to buy SA. Shugart and his investors accepted.

Part of the buy out agreement stipulated Allen Shugart couldn't start another floppy drive company. That was fine with Allen. He wanted no part of this profit-starved field. Instead, he headed for Scotts Valley and with his mechanical engineers, started Seagate. Their initial product looked an awful lot like an old SA606. They called it the ST506.

NCR had been one of the few companies that seriously investigated the SASI interface. NCR and Adaptec learned from HP's experience. Rather than propose an Adaptec or NCR bus, these two companies encouraged the formulation of an ANSI committee for small computer interfaces. The committee made several important changes to the SASI interface. First they made sure the interface had all the necessary elements to become a multi-threaded bus. Second, they added command set functions to allow devices to talk directly to other bus devices. This allowed devices (other than disks) to temporary master and utilize the bus. Now a tape drive, CD-ROM, disk drive and printer could all exchange information, without passing that information through the CPU.

Even with ANSI endorsement, Adaptec found SCSI a hard sell. The drive manufacturers were the biggest problem. Until someone made a SCSI drive, what good was a SCSI bus? The Adaptec applications engineers began designing SCSI applications to give away to anyone that would buy their chips. One of their first designs was the ACB4000. The ACB4000 was an intelligent SCSI interface for "dumb" disk drives like the ST506. Now any manufacturer that could design a simple parallel interface could utilize Winchester drives, without knowing how the drives themselves operated.

Meanwhile, the drive manufacturers realized the old ST506 transfer rate of 625K bytes per second wasn't going work for larger systems. There was another problem too. While the disk controller and the disk drive could pass data back and forth, the drive couldn't tell the controller anything about itself.

It did little good to have an intelligent controller if it didn't have any information about the disk it controls. For instance, the hard drive couldn't tell the controller its capacity or worse, where its bad tracks were located. Some drives were shipped with a printout of bad tracks, while others shipped the information on floppy disks. This did little to solve the problem.

The manufacturers generally agreed the intelligence belonged in the drive itself, rather than in the controller. However, the drive community was split on what to do about the problem. One sector argued that the existing ST506 interface could be upgraded. Another sector argued the ST506 interface should be junked, and a new interface designed. A third sector argued that the SCSI interface (or SCSI bus) should be used.

The SCSI advocates cried foul. They argued the SCSI command set is open and permits adding any commands needed. Furthermore, the SCSI bus permitted the coexistence of dissimilar devices that can intercommunicate at much faster data rates (and modes) than the IDE interface. The argument between SCSI and IDE advocates has raged ever since, with IDE usually winning on economic issues, and SCSI winning on performance issues.

Today the battle is almost finished. Low-end entry systems still use the IDE interface, but their number is dwindling. Middle to high end systems (such as graphics, file servers, UNIX, Macintosh, and mainframe computers) all use SCSI buses. The command set has been enriched to include commands for tape drives, printers, and multimedia, as well as a very rich set of commands for hard drives. Today, it's usually cheaper to use one SCSI interface rather than separate interfaces for disk and multimedia, and thus the single advantage of IDE is disappearing.

SCSI has evolved so much in the last decade that it barely resembles SASI. The original SASI document was a couple of dozen pages. SCSI-1 was a couple hundred pages. SCSI-2 is nearly 500 pages. If this progression continues, SCSI-3, when released, will be several thousand pages.

Next month, the SCSI bus in detail.

X00 allows PC communication ports to be swapped. The serial port that DOS calls COM1 can be mapped (reassigned) to any other port that X00 supports. X00 may also be used to lock the speed of communication between the modem and computer.

X00 only works with 8250 type UART chips such as the 8250A, 16450, 16550, 16550A, 16552, and the 82510. If your IBM or compatible has a serial communication port, your serial card more than likely contains one of these supported UART chips. XU.EXE is a utility distributed with X00 to help you identify the existence of compatible serial I/O devices.

Although X00 is usually used as a device driver (see Quick Install), X00 may also be used as a normal DOS program, called from the DOS prompt. This requires changing the program name from X00.SYS to X00.EXE. Here we will discuss using X00 as a device driver. The X00 documentation explains how to use it as a DOS program.

If you use QEMM386, EMM386, or some other memory manager, X00 can be loaded into high memory. Check your memory manager manual for details on loading device drivers into high memory.

Who should use X00? You may need X00 if:

• Your computer's COM ports are set to use non-standard port and/or IRQ settings.

• You use more than 2 serial ports on your computer, as is the case of a multi-line DOS-based BBS system. (An equivalent FOSSIL driver by the same author is available for OS/2 systems.)

• You are having CRC errors when you download files from your favorite BBS.

• Your BBS has a "mailer" front-end, such as FrontDoor which requires a FOSSIL driver.

It's as simple as that! The lucky ones with simple requirements can stop here and go on to other things. If your setup is more complex, however, you must read the more complex setup instructions:

COM1 and COM2 are the same for the PC, XT, AT, and PS/2. Hardware specifications for COM3 through COM8 became available only when IBM released the PS/2. X00 attempts to determine the hardware architecture on which it is being executed. If a PS/2 is detected the default serial I/O port addresses will be set to match the PS/2.

X00's default is to assign PORT0 through PORT7, to COM1 through COM8. Mapping ports can be the most complicated X00 command line option. By default, X00 maps up to 8 serial I/O ports (PORTS 0 through 7).

PORTn is the X00 port number, and must be 0 through 7. COMn is a standard DOS port and must be COM1 through COM8. IRQn is the IRQ used by the serial port, and must be IRQ0 through IRQ15.

HEXADDRESS is a hexadecimal I/O port address for a serial I/O device. IRQ addressing information is usually available in the documentation that comes with serial cards.

When the serial port transfer rate is locked, the computer-to-modem speed is usually faster than the modem-to-modem speed. When the serial port transfer rate is locked, the modem must support RTS/CTS (Ready To Send/Clear To Send) hardware handshaking, and the feature must be enabled on the modem. Check your modem manual.

The B command line option requires 2 parameters but allows an optional third parameter. The option is specified in the form:
B, PORTn, BAUD RATE, PARITY
(The PARITY parameter is rarely required because most BBSs use 8-N-1.)

C:\DOS\DEVICE= X00.SYS B_a, 0_b,2400_c B_d, 1_e,19200_f

• a & d: Lock the baud rate.
  
• b: Port number (X00's 0, DOS's 1).
  
• c & f: Baud rate to lock at.
  
• e: Port number.

If you do not have a 16550A UART, there are no FIFO buffers available to you. The only thing you can do to add FIFO buffers is to upgrade your hardware. Some serial cards have a socketed UART chip, these serial cards can be upgraded for under $20. Non-socketed UART serial cards should generally be replaced.

The default size of the receive buffer is 512 bytes. Valid buffer sizes are: 256, 512, 1024, 2048, 4096, 8192, 16384 and 32768. If an invalid buffer size is specified, the next lower correct buffer size is used.
Examples of usage: DEVICE=X00.SYS R=1024 (or) DEVICE=X00.SYS R=2048

C:\DOS\X00.SYS E_a 1_b T=4096_c R=4096_d B_e, 1_f, 38400_g F=12_h

• a: Stops The X00 advertisement from displaying.
  
• b & f: Port numbers (DOS ports 1, 2)
  
• c: Transmit buffer size.
  
• d: Receive buffer size.
  
• e: Lock the baud rate.
  
• g: Baud rate to lock at.
  
• h: Set FIFO buffer size.