...IBM images... (column) Susan Glinert-Cole.

IBM Images

While it is usually not expressed in quite this way, there is an old proverb about how every silver lining has a cloud firmly attached to it. Writing this column gives me a chance to experiment with new software and peripherals and express my opinion about them (for whatever it's worth). This is very gratifying for someone who is known to express strong opinions and who, among her other positive attributes, likes the smell of burning disk drives. It has been said that the human organism can get used to anything.

We have become acclimated to eating in the kitchen (the dining room is doing a swell imitation of a software department store), and our friends have become very careful of how they sit down lest they evoke the crunching noise associated with crumpled disks. The cloud that has settled on us consists of alien ship debris. I mean, this column practically didn't get done this month, and it was only with the most incredible self control that I managed to emerge long enough to share my problem with you.

Cosmic Crusaders

If anyone tried to tell me that I, a sweet, peace-loving individual who will admit to killing only an occasional mosquito, would get hooked on a game, the purpose of which is to slaughter aliens, I would have replied bushwa (or words to that effect). This game was brought into the house by someone I prefer to forget I ever knew; it is terrific an unbelievably addictive. My husband, who used to sidle furtively past the computer with an air of distaste now hangs onto the back of my chair wondering when I will be finished with this column silliness so he can play Cosmic Crusaders.

Closet frequenters of video games palaces tell me it resembles Galaxian, but it is in a class by itself for the IBM PC (I ought to know, I have been trying out games for weeks). It is from the same company, Funtastic, which publishes Snack Attack--also an excellent game.

Cosmic Crusaders is written in assembler, and the action is fast and responsive. The general objective is to mop up alien vessels which appear in formation and then peel off into dives, all the while merrily dropping pink and green bombs on your ship.

A mother ship appears occasionally; her payload is a bunch of fetching cerise asterisks. The player is allotted five shields to start, and can earn more by hitting the refueling station when it flipflops across the screen. Eliminating one barrage of ships brings on another set which is faster and nastier. As with most games of this type, you can't win.

The game can be successfully played with the keyboard, and it is possible to change the keys around if you don't like the way Funtastic set it up. We played with this configuration for a couple of weeks (until the game board and the joystick arrived from the same unmentionable person who is obviously trying to ruin my life), and we both found the keyboard set-up comfortable.

There is no question that it is easier to play this game with a joystick; we both beat our highest keyboard scores with the joystick on the second try. The six highest scores can be saved to disk or reset to avoid constant humiliation of one's husband (heh heh).

The sound effects are appropriate to galactic devastation, but are not obnoxiously overt; for those who like the concept of silent havoc, the noises can be turned off. The game is copy protected, which gives me a silent clutch lest something happen to it, but Funtastic will replace it free if it fails anytime.

They tell me that two new games are due out soon: Big Top and Master Miner. My irresponsible side awaits their arrival with anticipation usually reserved for things like Christmas bonuses.

Double Sided Disk Drives

I installed a pair of these a few days ago. Their most outstanding feature is their silent operation; with a disk drive cover on, it is barely possible to hear them, and it took a little while to get used to the absence of the grind, grind, grind of the Tandon drives. There were two minor modifications required before installation.

The first was to remove a jumper block from its socket, bend some pins out, an replace it. The second was to remove a resistor network and discard it. Both procedures took a couple of minutes for each drive and the instructions which accompained them were very clear. I have had no trouble with them at all, and if you haven't converted your IBM PC to double-sided drives yet and would prefer some that are easier on the ear, these drives are no more expensive than Tandon drives and are well worth considering.

Le Ribbonizer

A few devices have recently appeared on the market which re-ink printer ribbons. I find it objectionable, both on the pocketbook and New England philosophy, to discard a cartridge after only one use, and anything that would alleviate the boredom of winding the ribbon through by hand after reinking the rollers looked like a good bet.

The machine itself is just a motor mounted under a flimsy plastic shell with two felt rollers on the top of the case. For $39.95 I think the company could have used a sturdier plastic. It isn't that there is a great deal of mechanical stress on the machine, but, because the plastic is so frail, it is necessary to repack it carefully and store it away, because it would not take much to crack the plastic.

Le Ribbonizer comes with a small bottle of ink, printed instructions and a pair of plastic containers in which to store the rollers after use so the ink won't dry out. The first step is to pre-ink the rollers by repeatedly dropping a bead of ink on the tops of the rollers and waiting until the ink has been absorbed.

The instructions promise that the first time is the worst, and I certainly hope so because the process took about half an hour. The cartridge is secured to the top of the reinker by positioning it on a small metal shaft and then snapping a wire bail over the top. At this point, all that is required is to turn on the motor and spend twenty minutes playing Cosmic Crusaders. I can attest to the fact that the motor does not overheat if left unattended for an hour, which was how long the twenty minutes lasted.

The ribbon must incubate overnight in a plastic bag to distribute the ink evenly and that's it, almost. There si one last thing to do, and it was such a frustrating mess that it made me regret that I was ever unfaithful to my bottle of stamp pad ink. Remember the plastic storage containers? Well, you have to pull the rollers off of their shafts to store them in these canisters. There is absolutely no way to do this without getting ink all over everything, and worse, the little rubber sleeves on the top of the rollers fall off and getting them back on distributes additional ink in an extremely inconsiderate manner. I was so aggravated that I disgustedly tossed the whole machine back in its box.

I suspect that putting the entire machine inside a plastic bag might eliminate the need to store the rollers separately. The next time I reink a ribbon, I will give this method a whirl. Ben Torres Ribbon Service also sells new and reloaded ribbons which I might revert to if the above solution doesn't pan out.

DOS 2.0

I finally borrowed a copy of this new operating system a few days ago; there doesn't seem to be an extra copy anywhere at the time of this writing, and I haven't had a chance to delve into it thoroughly. The newest version has so many improvements and enhancements that it would be impossible to cover all the additions in one column, so I will dance across the high spots (and the low ones too).

There are a few gripes I have about DOS 2.0 that are minor, but irritating. The organization of the documentation is appalling. Information on the same subjects, like tree-structured directories, is scattered throughout the notebook. Some of the information is listed under the hard (fixed) disk chapter, some in the chapter on tree structured directories and some in the section on DOS commands.

The organizational problem pales in comparison to a slightly broken ring binder. DOS 2.0 is too big for the binder supplied with it, and, with one of the rings misaligned, it is not possible to flip easily through the book without the pages coming out of the rings; they then get torn and lost, and trying to find anything is a real megillah.

Why IBM cannot supply section dividers is beyond my comprehension. If the documentation is organized (or disorganized) in such a way that you are forced to keep paging through it, a set of dividers would ease that pain considerably. As it stands now, I buy packages of little dividers and make my own but there is probably an enterprising soul out there who could design and print a nice set (there is a ready customer right here). Having griped my gripes, I move right on to some of the high points.

The non-system programmers will find three completely new features immediately appropriate for their use: input/output redirection, filters, and hard disk support (including a new type of directory structure). I will talk primarily about these features this month.

Device redirection, or "piping,' as it is sometimes called, allows a program or batch file to get its input from and direct its output ot any file which can send or receive a stream of data. Suppose, for example, you wish to create a file by using COPY CON:FILEA. Normally, this will take the input you type from the keyboard and write it to FILEA. It is now possible to redirect the output to the printer by typing

COPY CON:FILEA>PRN.

In this manner, it is easy to get a directory listing sent to the printer by typing DIR>PRN or, if a file containing the directory is wanted, DIR IRFILE will send the directory to DIRFILE on the default disk drive. Redirecting input is just as simple.

Suppose in a batch file you wish a program to receive its input from another file insteas of from the keyboard; inserting the command THISPROG <THATPROG causes input to THISPROG to come from THATPROG. This feature eliminates a great deal of file opening and closing from inside a program; the system will do it for you.

There is a slightly different format for piping when using the output of system commands as input for another system command, which I will talk about in the next section.

My favorite additions to DOS are the filters now supplied with it. A filter is a program which takes data from some specified input device, modifies it, and then writes the modified information to an output device. DOS 2.0 now contains three of these very useful programs: FIND, SORT and MORE.

The FIND filter is wonderful. This command takes all lines from the file specified which contain (or do not contain) a specified string and sends them to any specified output file. I had planned, in the next month or so, to write a program which would remove all remarks contained in a Basic program. This project is now unnecessary thanks to FIND. The only caveat in using this filter for this purpose is that all remarks must be on a separate line in the program, since FIND, when used in this way, removes the entire line. Naturally, the program must be saved as an ASCII file. The format of the command is as follows:

FIND [/V] [/C] [/N] "string' [[d:] [path] fileame [ ext] . . .]

This looks pretty terrible, but is not really quite as confusing as it seems. The command FIND "rem' B:TEST 1. BAS will list to the console all the lines in TEST 1.BAS (on drive B) which contain the string "rem.' This is not exactly what is wanted in this case, since we want to remove all lines with this string.

The command FIND/V rem B:TEST 1. BAS will display all the lines that do not contain the string "rem.' This is better, but listing the program to the console is an academic exercise. What is really needed is some way to save the filtered program. A little redirection of the output in the form:

FIND /V "rem' B:TEST1.BAS >B:TEST1.REM

will find all lines which do not contain "rem' and write them to TEST1 REM on drive B. Fantastic! More than one file may be filtered at a time by simply listing the files, separated by a space, after the string parameter. Now suppose you want to locate all of the entries in a file directly which contain the string "txt.' As mentioned above, this type of redirection has a slightly different syntax, as we are dealing with the output form a system command, as opposed to a file.

This format uses the double bar located above the reverse backslash on the keyboard (this is not a colon) and looks like this:

DIR ! FIND "txt' >B:TXT.TXT.

This command would take the entries for the directory on drive A, find all file names that contained "txt' and would write them to file TXT TXT on drive B.

The/C parameter causes FIND to display the number of matches of the string it found in each file without actually displaying the lines containing the string. The /N parameter outputs the relative line number of each match ahead of the line from the file.

Another pleasant feature of DOS 2.0 is the SORT filter. This command will sort lines of data according to the ASCII collating sequence. The format is:

SORT [R] [/+n]

where the /R option will sort in reverse order and the /+n parameter (n is an integer) will begin the sort starting with column n. This feature is most useful in sorting directories. For example:

DIR ! SORT >B:SORTED.DIR

would sort alphabetically the directory on drive A and write the sorted list to SORTED DIR on drive B.

The third filter available is the MORE command. This command will read data from an input file and send one screenful at a time to an output device, pausing with the pregnant message--More--. To display another screenful, press any key. The format looks like this

MORE <B:TEST1.BAS.

This would display one screenful at a time of TEST1 BAS, found on drive B ot the console.

With DOS 2.0 it is now possible to queue files for printing and still be able to do other jobs while the printer is merrily chugging away. Up to ten files can be lined up for outputting at any one time and global file names are allowed in the quene. The format looks like this:

PRINT [[d:] [filename[.ext]] [/T] [/C] [P] . . . ]

The/T parameter is the terminate command and it cancels all files from the print queue. The /C sets the cancel mode and permits selection of the files which you wish to delete from the queue. The/P sets the print mode again.

PRINT FILE1 FILE2 FILE3 B:FILE4 FILE5 FILE6

would put these six files in the print queue and send them to the printer. If you wish to stop the whole process, type PRINT/T. If you want to delete the last two files from the queue, type PRINT FILE5/C. If only FILE5 is to be deleted type PRINT FILE5/C FILE6/P.

The printer is the default device for this command, but files may be queued in this manner to any output device (e.g. COM1, AUX, LPT1).

The most important feature of the new DOS is the fixed disk support, which introduces a new structure for file directories. The old versions of DOS used a linear directory structure in which each disk contained one directory under which all the files on that disk were listed. These directories could hold a maximum of 64 files (for single sided disks) or 112 files (for double sided disks). This scheme worked reasonably well for disks that did not contain many files; I did find it bothersome when the number of files exceeded about 20 per disk, especially if programs, correspondence, and graphics programs were all mixed up.

My backup disks tended to be chaotic, since I would grab anything that had room for a backup on it, promising myself that some rainy Sunday I would carefully reorganize everything. While Maine has enough rainy Sundays to reorganize the Library of Congress, the taks never got finished. With the new DOS however, it is possible to organize groups of related files into their own subdirectories. This is absolutely essential for a hard disk, which may contain thousands of files, but it is very convenient for floppies too, if there are several short files which could be categorized according to type.

DOS 2.0 uses a tree data structure for file organization. The two types of data structures are shown in Figure 1.

In DOS 2.0, when a disk is formatted, a main, or root, directory is created. The main directory may contain files or subdirectories and these subdirectories (which are actually files themselves), may in turn contain files and subdirectories. When DOS is booted, the main directory is always the current one, but any subdirectory may be designated as the default by issuing a CHDIR (Change Directory) command:

A> CHDIR [d:] path

The path is the route to the subdirectory of choice. In the figure above, the path to SUBDIRECTORY1 is:

A> CHDIR/SUBDIRECTORY1

(SUBDIRECTORY1 is now the current directory) and the path to SUBDIRECTORY3 is:

A> CHDIR/SUBDIRECTORY2/ SUBDIRECTORY3

(SUBDIRECTORY3 is now the current directory)

To return the system to the root directory as the default, use CHDIR with no parameters:

A> CHDIR/

Creating subdirectories is done using the MKDIR command. To create the file structure above, three commands are needed. Each command creates one subdirectory and the parent directory must exist before a subdirectory may be created in it.

A> MKDIR/SUBDIRECTORY1

A> MKDIR/SUBDIRECTORY2

A> MKDIR/SUBDIRECTORY2/ SUBDIRECTORY3

The third command could also be SUBDIRECTORY2 the default directory SUBDIRECTORY2 mthe default directory and then specifying any subdirectories:

A> CHDIR/SUBDIRECTORY2

A> MKDIR/SUBDIRECTORY3

Removing subdirectories is a simple matter of using the RMDIR command, but the subdirectory must be empty of all files before it may be removed. Neither ther the root, nor the current directory (if different than the root) may be removed with this command. The format is:

RMDIR[d:] path

where the last subdirectory in the path is the one erased. Thus the command:

A>RMDIR/SUBD1RECTORY2

removes SUBDIRECTORY2 and A> RMDIR/SUBDIRECTORY2/ SUBDIRECTORY3

removes SUBDIRECTORY3.

Well, that's swell, you are all saying, but how do I get files into these directories? This is simply a matter of specifying the appropriate path when the file is created (and I had to explain the idea of a path first, right?) So let's create the file structure in the thoroughly unimaginative figure above.

A> COPY CON:SUBDIRECTORY1 /FILE9

<anything + CONTROL 2>

A> COPY B:FILE10: SUBDIRECTORY1/FILE10

The first command takes FILE9 from the console and puts it into the subdirectory; the second copies FILE10 from drive B to drive A (the default here) and puts it into SUBDIRECTORY1. Files 1, 2 and 3 are placed in the main directory with:

A>COPY B:FILE1

A> COPY B:FILE2

A> COPY B:FILE3

(Or any variation of global specifications, such as FILE or FILE?)

To put files into SUBDIRECTORY3, follow the same procedure as above, but use the appropriate path:

A> COPY CON:SUBDIRECTORY2 /SUBDIRECTORY3/FILE6

A> COPY B:FILE7: SUBDIRECTORY2 /SUBDIRECTORY3/FILE7

A> COPY B:SUBDIR13/FILE8: SUBDIRECTORY2/SUBDIRECTORY3 /FILE8

This last command will copy FILE8, which it will find on drive B in SUBDIR13, to SUBDIRECTORY3 on drive A.

Directory listings for this type of file structure is done a bit confusingly. Typing a simple DIR command gives only the files and subdirectories listed in the root directory, not a listing of all files found on the disk. It is necessary to specify which directory you wish the files to be listed for and only the files in that particular directory are displayed. The accompanying listings show exactly what the outcome is for each request. At this point I think you get the idea of paths, and I intend to take the fastest one back to my joystick.

Table: Route directory.

Table: Directory of subdirectory 1.

Table: Directory of subdirectory 2.

Table: Directory of subdirectory 3.

Photo: Figure 1.