================================================================= The $ R / O R E A D O N L Y -={ January 1986 }=- The monthly news magazine of the Tampa Bay Kaypro User's Group and the DataCOM Super Systems(tm) ================================================================= News and reviews of programs, hardware, and peripherals for users of microcomputers with CP/M, MP/M, MS-DOS, PC-DOS, or TurboDOS operating systems. ================================================================= Steven L. Sanders - Editor (Sysop) ================================================================= The DataCOM Super Systems(tm) is a "state of the art" multi-user remote database with 40mb of files online. An annual fee of $35.00 is required for access, an application may be downloaded by calling (813) 791-1454 at 300/1200/2400 baud or send a SASE along with your request to: TBKUG / DataCOM Super Systems(tm) 2643 Cedar View Court Clearwater, FL 33519 -==( DISCLAIMER )==- Articles and reviews of microcomputers, hardware, software, and other peripherals reflect currently advertised prices as released by the distributors and are included here for YOUR INFORMATION ONLY. The TBKUG/DataCOM Super Systems(tm) is NOT being paid to advertise these products and we cannot be held accountable for the actual retail price and/or performance of said products. ================================================================= -==( Advent's TURBOROM for Kaypros )==- by Bridger Mitchell Subj: TURBOROMs for Kaypros -- Product Announcement Replacement boot roms for original Kaypro and MicroCornucopia roms, from Plu*Perfect Systems. IMPROVED DISK PERFORMANCE STOCK ROM TURBOROM Kaypro Kaypro Advent task drive format format format SAVE floppy 55 sec. 14 11 64k file hard 11 4 3.5 LOAD floppy 7 6 4.5 32K file hard 3 2 2 (Speedup gained by optimized sector interleaving, improved error handling, elimination of read-after-write. Advent format uses 1K physical sectors.) INCREASED CAPACITY - up to 63.25K system size for Kaypro 10s - adds 2 MB to most "10 megabyte" hard drives (Most of the bios is located in the rom. Bad-track map permits use of all good cylinders on hard drives.) MULTIPLE FORMATS - automatic detection and read/write of: Kaypro SSDD, DSDD Advent SSDD, DSDD, DSDD-96tpi MicroCornucopia 96tpi Osborne SSDD Xerox SSSD, Osborne SSSD, Epson QX-10 DSDD (in '84 only) - nearly all soft-sector CP/M formats settable with MULTICOPY utility package (extra), permitting full-speed logical drive in foreign format OTHER FEATURES - 32-character type-ahead buffer - built-in screen dump - cursor configuration - automatic screen blanking when idle - 25th line time display ('84 with clocks) HARDWARE SUPPORT - mix up to 4 SS, DS and 96 tpi floppy drives - 2 Advent Product ramdisks - 2 hard drives, up to 56 MB each UTILITIES - system generation: to/from system tracks and to/from file - versatile system configuration & relocation in 1/4K incre ments - full-disk high-speed format/copy verify - drive remapping AVAILABILITY 83 TURBOROM - $79.95 -- for 1983 Kaypro II's and 4's 84 TURBOROM - $79.95 -- for 1984 and later Kaypros, and all Kaypro 10s Early Kaypro II's and early Kaypro 10's require a 4K/8K rom adaptor board ($8/$15). Plu*Perfect Systems Box 1494 Idyllwild CA 92349 (714)-659-4432 {Editor's note: Bridger Mitchell is a partner in Plu*Perfect Systems} -==( Software Review: dMANAGER )==- by Ben Silverstein For those of you who read my review of Jim Gronek's dTUNE program, try to recall those famous words of wisdom from the former Saturday Night Live sage, Roseann Rosannadanna. In other words, never mind. Lest you think that this is a retraction of that favorable review, possibly based on some heretofore undetected super bug that has the potential to reduce your storage media to so many megabytes of guacamole, rest assured that it is not. Often in the software arena, as with the personal computing industry's hardware technology, by the time an article on a product can reach print, it is obsolete. This was the case with dTUNE. It is good for computer users when software authors are continually improving their products. Sometimes it seems hard to keep up with the latest version, but it is almost always worth the effort. dMANAGER is the latest installation in the continuing saga of the dTUNE program, complete with many new features, as you will see. dMANAGER is written in Borland International's popular Turbo Pascal, and utilizes two chain (.CHN) files and five overlay (.00x) files, making an eight-module system. The support files may reside on a different drive than the main .COM file. In operation, you make your choices from one of two separate menus, the Main Menu and the Command File Mode Menu. (Common to both menus are the ability to change working drive, and view a directory of the currently logged drive.) THE MAIN MENU The Main Menu offers the following choices: - View a file This command allows viewing of an ASCII file on the screen. - File Compression/Decompression This is the equilivant of the popular Huffman-algorithm based SQueeze/UNSQueeze programs, allowing squeezing or unsqueezing of disk files from within dMANAGER. - Database Structure/Contents This function will list the structure or records of a .DBF file to the screen. (Modification of either the structure or records is not allowed.) - HEX File Conversion After entering the name of a .HEX file (such as is created by ASM before LOADing to a .COM file), dMANAGER will process it to a .CMD file containing POKE statements with the appropriate values and with the SET CALL address set. This works well with small hex files, as it is faster to POKE them than to LOAD them with dBase. - CMD File Conversion This command sends the operator to the Command File Mode Menu. COMMAND FILE PROCESSING MENU The choices from the Command File Mode Menu are set up as toggles, with their selection by letter changing the function on or off, regulating which file(s) are to be created from the original dBase .CMD file. The file types themselves are as follows: - Indented and Nested file This file will be a reproduction of your source file, with all IF/ENDIF, DO WHILE/ENDDO, etc. structures properly indented. Comments are left in the file, and it is saved with the extension of .TXT. - Trimmed command file Like its predecessor dTUNE, this is the program's raison d'etre. All comments, tabs and unneccessary spaces are removed from the file, and reserved command words are shortened to their 4-character minimum representations. The size of the resulting file is much smaller than the original, and this speeds up interpretation by dBase greatly. The source file is renamed to type .SCR, and the trimmed file receives the type .CMD. - Nested and Indented trimmed file This is a combination of the above two functions. The trimmed file is reproduced in the indented format to facilitate following the logic and for debugging purposes. This file is saved as type .STR, and, if the "Pipes" option is selected, will delineate logic loops with a vertical bar character, thusly: original listing with pipes DO WHILE DO WHILE IF... | IF... DO CASE | | DO CASE CASE | | | CASE ... | | | | ... OTHERWISE | | | OTHERWISE ... | | | | ... ENDCASE | | | ENDCASE ELSE | ELSE DO WHILE | | DO WHILE ... | | | ... ENDDO | | ENDDO ENDIF | ENDIF ENDDO ENDDO It is easy to see how errors in logic loops can be quickly found, saving the programmer much time. - Cross Reference file Two files are produced by this option. One is a source listing with line numbers, and the other is an alphabetic listing of memory variables (and all other non-reserved words as well) with the numbers of the lines where they appear. The first has a file type of .PRN, while the second is typed as .XRF. - Logic Tree file This file (given the type .TRE), lists all the DO or USE commands encountered in the source file. This can be very useful as a refresher when reviewing a program you haven't looked at in some time. OTHER OPTIONS An additional option offered is case alteration of the files produced by dMANAGER. You are prompted as to whether you would like the output in all lower or upper case letters. If you have more than one file that you would like to process, dMANAGER will take input from a batch file containing all the names of the files that you would like to process (without the type; .CMD is assumed). The options chosen from the menu will be performed on each file in the list. In addition to the above functions, any combination of processed files may be listed on the printer by means of a toggle for each one. In this way you may produce listings for any or all of the resulting files. I should stress at this point that your original source file is never altered in any way, except for the renaming of the type by the trimmed output option. dMANAGER maintains a status window that keeps you informed as to what is going on at any given time. Displayed are the name of the source file, the file currently being prepared, and the line number that is being processed. This is a nice touch, and much better than having to wonder just how much longer the program has to run. SUMMARY dMANAGER requires a Z-80 processor and CP/M 2.2 or greater. In that the program is written in Turbo, and that there was a PC version of dTUNE, I suspect that the program is or will soon be available for PC/MS-DOS. In use, dMANAGER functions rapidly and well. Everything is as is expected, with no rude surprises. This program is probably the most useful all-around tool for the dBase programmer available at a reasonable price. I hope that Jim hasn't upgraded the program again; I'd like to think that I have provided an up-to-date review this time. To order dMANAGER: Contact Jim Gronek at: UCS, Inc. P.O. Box 23866 Phoenix, AZ 85063 Then do up a batch file of your dBase command filenames, sit back and break out the nachos. (That's where the guacamole belongs!) {Editor's note: Jim is also the Sysop of The Lost Dutchman's Gold Mine RCP/M Systems in Phoenix, Arizona. You can find many other fantastic dBase goodies online there.} -==( Communications Forum )==- by Steve Sanders One of the most frequently asked questions is why I don't favor Irv Hoff's new IMP modem program. Basically only one reason; I don't like any modem program that automatically selects file transfer protocols regardless of line conditions. According to the documentation, IMP has a superior "user interface" to MEX or any of the other readily available commercial modem packages. This statement refers to IMP's forced 1k packet protocol for XMODEM file transfers versus the universally-accepted procedures used by MEX and YAM. XMODEM, CHECKSUM, and CRC A little history lesson: Keith Petersen's original XMODEM program was written to support the CHECKSUM file transfer protocol and became the accepted standard. A protocol is simply the process used by both ends of a telecommunications link to transfer ASCII or binary files with error-checking. CHECKSUM used an alogrythm that gave you either an odd or even parity check on the block of data sent versus the block that was received. If the received CHECKSUM did not match the transmitted CHECKSUM value then XMODEM was told to re-send the block. This process is usually attempted up to 10 times before an automatic abort condition was encountered and the transfer was terminated. Without getting to technical, the newer method of error-checking is called CRC and does a bit more complicated process of checking the received block versus the transmitted block and has become the defacto standard used by almost every remote system in the country today. 1K PACKET PROTOCOL With the advent of the new higher speed 2400, 4800, and 9600 baud modems, it became apparent that this stop-and-go error-checking was really slowing the transfer down. The original XMODEM was designed with a 110 to 610 baud modem in mind and was never designed to handle this high speed throughput. Chuck Forsberg, the author of the YAM (Yet Another Modem) and ProYAM programs along with Ward Christensen and a host of others devised the new 1k packet protocol which sends a "packet" consisting of eight 128-byte blocks before error-checking. This is a real God-send for users at 1200 baud or faster speeds especially those coming through a satellite or microwave long distance network where frequent delays are experienced. For users running the new 2400 baud modems the error-checking was taking longer then the actual transmission of each 128-byte block with CHECKSUM or CRC protocols. The only problem with 1k protocol versus 128-byte protocol is that when you encounter an error you must re-send 8 blocks of data rather then only one block. If you are using MCI, SPRINT, or even Ma Bell and run into excessive line noise the 1k protocol can cost you more time in re-sends then it gains by sending larger blocks of data. Armed with this info we now return you to the story... To transfer a file using the 1k packet protocol the user enters the following command to XMODEM: XMODEM SK filename.typ and then escapes terminal mode and enters the "RT filename.typ" command to MEX to receive the file. MEX (version 1.14) is always ready to receive in 1k packet protocol and will automatically shift to CRC protocol depending on the initial handshake characters received before the transfer begins. IMP and KMD Now Irv Hoff thinks this is asking to much of the user to have to enter "XMODEM SK" instead of the usual "XMODEM S" to begin the transfer. Enter the KMD program, this is a hacked-up version of XMODEM that Irv has devised to allow an IMP user to issue a simple "KMD S filename.typ" command instead of the complicated "XMODEM SK" command to initiate a 1k transfer. The only problem with IMP's auto-selection of 1k protocol is that IMP itself is not smart enough to know whether line conditions warrant the use of the 1k protocol. It takes a given number of consecutive errors in 1k protocol before it automatically downshifts to regular CRC (128-byte block) protocol for the duration of the transfer. This is true with either MEX or IMP but at least MEX gives you (the user) the option of picking the most desirable method of file transfer because only you know what the current line conditions are like. Okay Irv, you make IMP "smart" enough to detect current line conditions and I'll give it another try. Until then, as the NRA and pro-gun people say, "until they pry my cold clammy fingers from it...", I'll continue to use and enjoy the power of MEX. -==( GE Introduces GEnie(tm) )==- Imagine having access to quality personal computing SIGs, software, CB simulation, E-Mail and games at 1200 baud. But paying only a 300 baud rate. Here's GEnie(tm) GEnie stands for the General Electric Network for Information Exchange. It's a part of General Electric Information Services - the world's largest commercial teleprocessing network. And now the power of GEnie is available to the home computer user. The High Speed GEnie GEnie can take you to new highs in speed and keep you there. Because our non-prime time rate for 300 or 1200 baud is only $5.00* an hour. That's up to 60% less than you're paying now. So when you're wrapped up in a computer group, or heavily into serious conversation, you can keep your eyes on the screen, not on the clock. (More good news: no minimum monthly charges, the sign up fee is just $18.00 and new subscribers get three free hours until December 31, 1985.) What wishes Can GEnie grant? GEnie has most everything. Including LiveWire(tm) CB simulator, RoundTable(tm) SIGs, bulletin boards, GE Mail(tm), classic games like CastleQuest(tm) and BlackDragon(tm), conference rooms, newsletters and more. Sign up from your keyboard: 1-800-638-8369 Just have your VISA, MasterCard or checking account number ready. 1. Set your modem for half duplex, 300 or 1200 baud. 2. Upon connection enter: HHH 3. At the U#=prompt enter: VJM11953,GEnie (For additional information or assistance call 1-800-638-9636, ext. 21) General Electric Information Services Company, U.S.A. {*Rate applies to 300 or 1200 baud, Mon.-Fri., 6 PM to 8AM local time, all day Sat., Sun. and national holidays. Subject to service availability.} -==( PD Software: FATCAT v2.0 )==- Program and Documentation by Steven M. Cohen (c) 1985 FATCAT20.LBR is a new multi-featured disk cataloguing system for Z-80 CP/M and ZCPR3 systems. It was designed with the user's convenience foremost in mind. It builds upon the foundation of earlier cataloguing systems like FMAP, UCAT, NCAT, and LCAT, but improves upon them by eliminating many inconveniences that these early programs inflicted on their users. Many users, once the catalog got too big, began finding it hard to justify the time spent waiting for the disk drive to do its thing, grew lazier about cataloguing and, after awhile, stopped altogether. FATCAT FEATURES * Rapid-fire insertion of diskettes. The filenames are simply appended sequentially to a temporary file. Very fast. Then when you are done, the computer does the tedious work of sorting, inserting, deleting, without making you share it's tedium. * Full library file support. Simple, bug-free. The name of the library is stored with the name of the library file -- not just the disk number. * Hard-Disk mode for cataloguing a hard drive user-area by user area, as well as a more conventional floppy-disk mode that catalogs a whole disk at once. * Clean-Up mode lets you erase files, rename files and add those zero-length disk name files -- without leaving FATCAT. No more "SAVE 0 -DISK.094". Also displays file size. * Attractive Catalog Output module -- outputs to printer, CRT, or both simultaneously. CRT display can be either paged or continuous, switchable back and forth. Scans the whole catalog or "wildcards" for specific grouped filenames, either by filename or disk number. * Disk Information module keeps track of disk names and free space. * Easily configurable for different modes of operation, e.g. placement of catalog files, name of catalog files, etc. Configurations effortlessly saved to disk for quick loading on subsequent sessions. Equipment Requirements: Any computer with a Z-80 microprocessor, at least 43k TPA (that is a 50k CP/M system), & two floppy drives of 180k or more. (Preferably drives of 350+ k) Like many other catalog programs FATCAT uses the convention that the file that sorts to the top of the list of files is the name file of the disk. Usually, this is a 0-length file which is nothing more than a directory entry. It has a unique name which differentiates it from any other file on any other disk. Most particularly its "type" (the three characters following the period) must absolutely be unique, such as "-DISK.001". Hard Disk Cataloguing What happens under option is that you move sequentially user area by user area through the directory, in exactly the manner as cataloguing a floppy disk. The important thing to remember here is that there must be a name file in each user area in which there are files. If you aren't sure, it might be well to choose this option with the Clean-Up Mode on. If you have user areas without name files, they simply won't be catalogued and you'll have to do it again. Update Catalog After you are through cataloguing in Multiple mode, you must return to the main menu and select the option to actually update the catalog. (This is done automatically in single mode). This is where you should get up from the computer and let it do it's thing. It could take anywhere from a few seconds to an hour or two depending on the size of the catalog and your disk configuration. At the very beginning of the Update, FATCAT first prompts you to please make sure the proper disks are loaded in the proper drives. Do check. Stupid disk full errors will not be fun here. Once you have indicated that all is well, FATCAT tries to open all the necessary files, asking you if it should create them, if it cannot find them. If this happens, answering 'N' will abort the update for yet another margin of safety. If you are creating new index files, you will also see a screen which asks you whether there are any files you DON'T want in the catalog -- i.e. files that you may have on nearly every disk, utilities on which you don't want to waste precious catalog space. This is another full-screen data entry screen like that in the

option. You move about in the same way and can modify these file names to your heart's content. Now that the preliminaries are out of the way, FATCAT gets down to the brass tacks of updating. First, the disk name is entered into the disk name index file. (.DNX). Second, the program scans the index files (.RIX and .LIX) against the temporary file, adding all those files in the temporary which aren't in the index and deleting those which are in the index but not in the temporary file. Third, an entirely new pair of catalog files (.RCX and .LCX) is created and filled from the index files. Output Catalog This is a nice, flexible, catalog output with many features, enabling it to perform both as a printout program and as an online Scanner. It lists file name, user area, disk name and, if a library member, the library file name. You access these functions by answering three questions: 1> You are first asked: Enter Search Mask: If you want FATCAT to conduct the search by FILENAME (most likely) then you should respond with a single parameter giving the file name you want. Standard CP/M wildcards are acceptable here. Thus, for example *.* will find all files in the catalog Z*.* will find all files whose names start with Z *.?Q? will find all squeezed files If you want FATCAT to conduct the search by DISK NAME then you must first type in a parameter as above, followed by a space, and optionally followed by another space and a third parameter, denoting the low and high disk numbers comprising the range of the search. Leading zeroes need not be included. If you only want to search one disk then only the first and second parameters need be given. Examples: *.* 034 will find all files on disk 034 *.* 34 300 will find all files on disks 034 through 300 *.?Q? 50 099 will find all squeezed files on disks 050 through 099 There is a default search which is simply to search for all files on all disks. You can select this by simply typing at the initial prompt. This is the same as typing "*.*". Note however, that if you want to search all files on specific disks then you must type *.* before the disk numbers, otherwise FATCAT will see the number as a filename, not a diskname. Also note that should you enter 0 as a disk number, FATCAT will assume that you meant 1. (You remember, of course that FATCAT will reject any disk whose disk name file has a type of .000) 2> The second question you are asked is: Output to: S)creen / P)rinter / B)oth This is very straightforward. The default here is 'S' so this will also be selected if you type . 3> If you chose 'P' or 'B' at number 2 you will be asked for a header to be printed at the top of each page, along with the page number which will be printed regardless. Once output has begun the following controls are available: Cntl-C will abort the output whether to Screen, Printer or Both in Screen mode only toggles between paged and unpaged output. At the beginning paged output is the default and the output comes up a screenful at a time. While paged output is selected, typing will switch to unpaged output (for fast scrolling), while typing any other key brings up the next page. While output is unpaged typing reverts back to paged output and stops the display. Of course typing Ctrl-C aborts either paged or unpaged output. {Editor's notes: I have as you can well imagine, used all the current and past versions of CAT, UCAT, FMAP, NCAT, MCAT, and LCAT to catalog the massive number of files in the TBKUG master library (14,000+ at press time), and FATCAT is a real god-send. The master library at present consists of 359 5-1/4" diskettes and can take forever to re-catalog with MCAT which is the fastest of the current utilities. FASTCAT also does all the internal library files and does an un-attended update at session end.} -==( FASTBACK FIX )==- by John Stensvaag 12/2/85 (TBKUG) FASTBACK, by Philip Becker, is a splendid hard-disk backup program for the Kaypro 10. Its combination of speed and flexibility has been justifiably praised by reviewers. (See, for example, 2 Profiles 66 (Feb. 1985)). There is one potential problem in using the program, however, that can lead to distressing results: upon attempting to FASTREST one or more files, a user may occasionally discover to his or her horror that "the file integrity has been lost" and "FASTREST will forever try to recover a particular file until hard drive space runs out." (Quotation from Chris DeBracy, in the MAR85.MAG, The $R/O Read Only Magazine published by Steve Sanders.) Upon closer examination, the user will discover the the backup copy's directory/file relationship seems to have gotten out of synch; contents of one file will spill over into the next file in the directory in a cascading way, so that all files are damaged. This is bad enough with text files, but at least such files can be fixed with a word processor, after stripping out 1Ah end of file markers. (Even so, that would be a laborious process on the entire contents of a hard drive!) When you realize that software files are intermingled in the directory with text files, it becomes clear that the out-of-synch corruption phenomenon is even more difficult to unravel. This problem is especially pernicious, because the FASTBACK step proceeds smoothly, and the user has no idea that the neatly prepared floppies are garbled. The other night, for example, when I first encountered the out-of-synch corruption problem, I discovered that all three of my hard drive backup sets were corrupted; if I had needed to restore a crashed drive, I would have been in for quite a shock. Chris DeBracy speculated that this quirk might be caused by some intermittent bug in FASTBACK's formatting function; he suggested that it could be cured by periodically reformatting the FASTBACK backup disks using FASTCOPY, UNIFORM, or FORMAT. Such standard operating procedure would diminish the value of FASTBACK, but would be worth it, if it worked. Unfortunately, I was unable to cure the out-of-synch corruption problem by reformatting the floppies. Philip Becker graciously responded to my frantic phone call, and I now pass along his advice, along with a few tips about how to implement that advice in a routine manner. Although the thrust of this memo is to suggest a different cause and cure that those suggested by DeBracy, I would have been lost without his original discussion of this problem, and appreciate his help. The "bug" is not so much a problem of FASTBACK, but the consequence of our own ineptness as CP/M users. According to Becker, FASTBACK may be "fooled" by an illegal, duplicate directory entry for a single file. You may have discovered, in the past, that you "RENamed" a file, mistakenly giving it the same name as an existing file, and that D.COM, SD.COM, or some other directory utility thereafter displayed the file with a kilobyte size two times larger than its original size. CP/M does not like identical directory entries in the same user area, and they should be prohibited by the system, but the prohibition is not idiot-proof. Some UNERASE programs, for example, merrily restore duplicate copies of files; Eric Gans' XRASE.COM utility prevents this, and should be obtained to replace other unerase programs. STAT.COM does its best to give a "true" size for files that have been doubled in this manner; thus, if you compare the kilobytes displayed by STAT.COM with those displayed by D.COM and discover a discrepancy, you may have put your finger on an identical-file- name problem. Becker explains that FASTBACK may be "fooled" into thinking that the doubled file has a different number of records (bytes) than is actually the case, and that the result is to throw the directory/file correlation out of synch on the backed-up floppies. Okay. If you have any identical filename entries in a single user area on your hard disk, you must track the problem down and correct it, or your FASTBACK floppies will be fouled up, and the restored files will be a shocking mess. How can you implement this knowledge to protect against such a disaster, especially since FASTBACK will not give you any warning of the glitch during the backup phase? The solution requires two steps: (1) detecting when you have identical entries, confusing FASTBACK; and (2) isolating the offending file or files. Detecting the Identical Entry Flaw in Backup Copies You will sleep better if you know to a certainty that your backup copies have not become corrupted. The best way to do this is to routinely restore one or two text files near the end of your backup set (i.e., near the end of the alphabetical directory displayed by FASTREST), "type" them on your console, and visually inspect them for integrity, especially at the beginning and end of each file. You will know when the out-of-synch problem strikes: ordinary text files will frequently contain machine-language garbage from adjacent software programs, or will display text that should be in a different file. If you have a fair number of short, *.SUB files on each hard disk drive, this is an excellent choice; simply restore (with FASTREST) *.SUB to the urrent User Area, and eyeball them. (It is even easier to do this, if you use TYPE109.COM to display *.SUB, after you have restored them, because it jumps from file to file, without any need to remember file names or reenter them.) If the *.SUB files have not lost their integrity, you are almost certainly okay, at least up to the point of the last *.SUB file in the backup set. To be extra certain, you can create a "dummy" ZZZ.SUB file (containing a single line: "This is the only line") on each hard disk drive, so that it will be dumped and restored as essentially the last directory entry; if files have not gotten out of synch by that point, you are safe. If you find no out-of-synch symptoms, your backup set is fine. Isolating the Offending Duplicate Filename Entry If you do find an out-of-synch glitch in any restored file, you must isolate the offending duplicate entry on your hard disk. There are certainly easier ways to do this for computer whizzes, but the following technique will help you narrow the search: (1) Create 26 single-line text files, containing the sentence "This should be the only line." Name those files A.CHK, B.CHK, C.CHK . . . . Z.CHK. (It's not much fun to create these, but you obviously only need to write the text once. Once you have created the complete alphabetic set, tuck them into a library, such as FB-CHK.LBR, and save that library in a safe place, so that you need never go through the exercise again; the library file only takes 6K, but A.CHK through Z.CHK occupy 4K x 26 on the hard drive.) Temporarily copy a complete set of these files into a spare user area on the offending logical drive (e.g., A15: or B15:). (2) FASTBACK the entire contents of the offending logical drive. (3) FASTREST *.CHK from the backup set to an empty urrent User Area. Eyeball *.CHK at the console (preferably, with something like TYPE109.COM). When you find the first instance of a messed up file--a file including something other than the single text line that you originally wrote--you have isolated the problem to the set of files beginning with the letter preceding the first garbled *.CHK file. (E.g., if F.CHK is garbled, a file beginning with the letter E probably has an identical entry defect.) (4) Use STAT.COM and D.COM on X*.* (where X = the letter that you isolated in step 3), and compare the kilobyte values. A discrepancy indicates a flawed, identical filename entry. There are no doubt easier ways to routinely detect, isolate, and correct identical filename entry errors, and I hope that some knowledgeable souls will provide a simpler technique. In the interim, however, the standard operating procedure of immediately FASTRESToring short text files throughout the alphabet, such as *.SUB (including an end of directory entry, such as ZZZ.SUB) takes almost no time at all, and provides a welcome assurance that the backup set resting so splendidly on the shelf is not actually a garbled mess. Finally, Philip Becker informs me that he can see no reason whatsoever to periodically format or reformat FASTBACK floppies with any other programs; he is convinced that the problem referred to in this memo is not caused by FASTBACK's formatting feature, but by illegal identical filename entries on the hard disk. This is good news for those of us who have been periodically reformatting all those floppies. -==( Kaypro 10 Hard Disk Tips )==- by Steve Sanders At least once a month some semi-frustrated Kaypro 10 owner calls me up to find out how to use the hard disk check or format programs as supplied by Kaypro. I have been told that some of the newer machines do not have some of these utilities, if this is the case for you just call up the remote system and get them from the KAYPRO section. You'll find them inside of the library file called K10-UTIL.LBR, just be sure to get the 'right' ones as there are two different versions. The FORMAT-O and CHECK-O programs are for pre-2.2F models with the 1.9e (small E) ROM, the FORMAT-F and CHECK-F are for all newer 2.2F, 2.2G, and 2.2u version machines with the 1.9E (big E) ROMs. CHECK.COM CHECK is used to verify a pre-formatted hard disk drive to be sure the controller can actually read the sector headers placed there by the FORMAT utility. Kaypro 10mb Hard Disk Allocation: * Hard disk is addressed as drive 1 * The operating system sees it as logical drives A and B * Four read-write heads are used; Heads 0 and 1 access drive A Heads 2 and 3 access drive B * Cylinder 0 contains the operating system (CP/M), the BIOS, error messages, and overlays for screen graphics. * Cylinder 1 is reserved * Cylinders 2 thru 6 contain the directories for drives A and B * Cylinders 6 thru 305 contain the data for your programs (files). CHECK asks 3 questions before it starts doing the validation operation: FIRST DISK, LAST DISK? (0, 3) 1,1 <-- you type 1,1 FIRST HEAD, LAST HEAD? (0, 7) 0,3 <-- you type 0,3 FIRST CYLINDER, LAST CYLINDER (0, 305) 0,305 <-- you type 0,305 This will now start a complete check of the entire hard drive, any errors will be reported inside paratheses to the right of the display. ERROR CODES ABC Aborted Command. Controller unable to complete test of this area BBD Bad Block Detect. Attempted to access a sector with a BAD BLOCK marker in it. This is a SERIOUS ERROR. COR Correctable error. Error in data field, but correctable. IDC CRC error in ID field. The sector was found but the ID field contained an error and couldn't be trusted. IDC ID not found. The sector could not be found at all. NID same as IDC TRO Track Zero. Track zero not asserted when expected. UND Undefined Error. Similar to ???. VERY SERIOUS - CONTACT THE DEALER UNC Uncorrectable Error. The controller found an error and was unable to correct it. WFT Write Fault. A fault condition occurred during a write attempt and the write was aborted. ??? Error detected, but no flag set by the controller. This error is theoretically impossible. DO NOT USE THE COMPUTER - CONTACT THE DEALER IMMEDIATELY FORMAT.COM NOTE: FORMAT SHOULD BE USED WITH E X T R E M E CARE!! FORMAT will destroy any data residing on your hard disk, be sure you have backed up your programs BEFORE using this utility. FORMAT must be run on a newly installed hard disk drive before any data may be transferred to it. The FORMAT utility installs the data sector header information that all CP/M programs rely upon to locate data residing on the disk surface. To format the "A" drive only: FIRST DISK, LAST DISK? 1,1 <-- Kaypro only has disk 1 FIRST HEAD, LAST HEAD? 0,1 <-- Heads 0 and 1 are for drive A FIRST CYLINDER, LAST CYLINDER? 0,305 <-- All cylinders 0-305 To format the "B" drive only: FIRST DISK, LAST DISK? 1,1 FIRST HEAD, LAST HEAD? 2,3 FIRST CYLINDER, LAST CYLINDER? 0,305 To format the ENTIRE hard drive: FIRST DISK, LAST DISK? 1,1 FIRST HEAD, LAST HEAD? 0,3 FIRST CYLINDER, LAST CYLINDER? 0,305 As soon as the FORMAT program is done, first run CHECK to verify all the sector headers as readable, then run FINDBAD (supplied with all Kaypros) and lock-out any "bad" spots. After all this you can now begin to fill the hard disk drive up with your program files. Use PIP, NSWP, or FASTREST (if you used FASTBACK) to restore your files to their respective drive/user areas and enjoy your "solid" Kaypro 10! Another highly useful utility that should be in every Kaypro 10 owner's bag of tricks is Dave Rand's program called SORTDIR, it can be found in the CPMUTIL section in a file called SRTDIR31.LBR. This program will clean-up your directory tracks by moving all erased entries to the end of the directory area and clears the data area by inserting "E5" bytes into all the old locations. It then alphabetizes the active directory entries in ascending order and you will notice a marked improvement in the execution of programs like D or SD or any sorted directory utility. SORTDIR should be run frequently, I use it about once every three to four days but once a week should be fine for most Kaypro 10 owners. I use FASTBACK religiously once every two weeks to do a complete back-up of the Kaypro 10's hard disk. I use the following steps to insure a GOOD back-up: 1. Run CHECK, validate all sector headers 2. Run FINDBAD, validate all data areas 3. Run SORTDIR, clean-up the directories 4. Use NSWP207 and log into EVERY user area with files and check for duplicate filenames and erase any found 5. Run FASTBACK and do seperate back-ups for Drive A and B It may be faster to do an entire (Drive AB) back-up, but it makes it impossible to restore files by restoring the drive A files to drive B and then moving over only the ones you want to replace. You now do a restore of the entire B drive from your floppies and you're back in business ASAP. -==( That's All Folks )==- Hope you enjoy this month's magazine, don't know when if ever there has been this much info jammed in between the first and last pages. Many thanks to all the contributing editors for their fine copy and words of wisdom. If you have recently bought any software packages or hardware for your computer and have become an "expert" or at least a very knowledegable neophyte, give us the benefit of your experiences and write a short review. You do not have to be a professional writer, I certainly don't claim to be one. Please submit your reviews or other literary masterpieces in the form of a Wordstar formatted diskfile on a soft-sectored 5-1/4" diskette (just be sure to tell me what machine it was formatted for if not in Kaypro SS or DS format.) Or you can upload your text files via XMODEM to one of the remote systems. Until next month... Steve Sanders