home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CP/M
/
CPM_CDROM.iso
/
cpm
/
news
/
jan86.mag
< prev
next >
Wrap
Text File
|
1994-07-13
|
45KB
|
1,020 lines
=================================================================
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 <RETURN>
3. At the U#=prompt enter: VJM11953,GEnie <RETURN>
(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 <H> 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 <U> 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 <P> 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 <RETURN> 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 <RETURN>.
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
<ESC> 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 <ESC> will switch to unpaged output (for fast
scrolling), while typing any other key brings up the next page.
While output is unpaged typing <ESC> 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 <C>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
<C>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