8bitfiles.net/archives/archives.tar/archives/genie-commodore-file-library/C128CPM/PIPMAG-4.ARC/SAVDISK2.PIP

Text File | 2019-04-13 | 9.1 KB | 187 lines

                              The Perils of Peggy
                                   (Part 2)

                                      by

                                   D.FOWLER2


        When last we saw our hero, he was diddling Faithful Nurse Stella,
    while her erstwhile paramour, Dr. Jameson was dallying with her half-
    sister...

        Ooops, wrong plot line.

        Let's see.  In our last, suspense laden episode Peggy, the Light of
    my Life, had lost her camp alumnae newsletter in a litter of tumbled
    bits and bytes.  Our dauntless disk diver had descended into the
    dolorous deeps in a desperate dip to discern the dimensions of the
    disastrous debacle.

        Oh oh.  Watch that alliteration.

        Anyway, it turned out, at the very least, that the directory track
    was succotash.

        Reentering the data was feasible, but not practical.  Much of it
    had been painstakingly extracted from letters and journals sent to
    Peggy by her Faithful Friends.  Time, for our delectable heroine, was
    in short supply.  The deadline was bearing down on her like a runaway
    D&H locomotive.  She was in the midst of three big projects.

        It was all up to me.  I was going to have to troll the briney deeps
    for those files.

        The first thing I had to do was to see if they were still there.
    Using DU, unrolling a metaphorical string behind me so I could find my
    way back out, I tip-toed delicately through the disk to see what lurked
    in the labyrinth.

        A few spot checks revealed that (so far) the damage was limited to
    the directory track.  Everything else looked sound.

        But the files were scattered in bits and pieces all over the place.
    That, of course, is the way a computer works.  It looks for the first
    free space in which to put a file.  If the space isn't big enough to
    take the whole file, it'll stick a bit there, another piece in the next
    available slot, and log in the directory where the bits and pieces are
    located.

        Complicating the hunt, Peggy's single largest file had been worked
    on several times.  Pieces of old versions lurked as decoys amongst the
    new.  To DU and me they all looked the same.  Adding to the confusion
    were fragments of even older files mouldering like the mummies in
    Raiders of the Lost Ark, files that had long ago been erased (marked on
    the directory track as no longer needed, freeing up the space for re-
    use) but still on the disk.  Well, I consoled myself, at least the data
    was still there.

        So, I dug out a rusty old spear from my armory called DOCTOR.COM.
    (I think I got it from a buddy way back in his TRS 80 days.  And we
    know how long ago THAT was!)  The Old Physician was supposed to be able
    to copy, track by track, from a damaged disk to a fresh one.  He was
    not supposed to unscramble the scrambled track, but it would (I hoped)
    give me a backup disk to muck around in without risking the main disk.

        Sadly, either senility had weakened his healing skills, or else a
    Grue got the good DOCTOR.  He plodded along until he hit Track 28 and
    then started myopically insisting he was getting "Hard Errors."  DU had
    already told me track 28 was in perfect shape.  So much for DOCTOR.

        Obviously it was time to update my armament.  Trashed disks being a
    common hazard, the CP/M software library on GEnie had a half dozen
    utilities to deal with the problem.  I took a chance on a couple, and
    added the updated version (8.9) of DU to my shopping list.

        After downloading, un-librarying and uncrunching and the like,
    I studied what I had.

        DIRREP21, it turned out, was useful only if you had made a backup
    copy of your directory ahead of time.  So much for THAT one.

        REPAIR.COM's documentation said it could be used to recover from a
    trashed directory by allowing me to assemble the file fragments and
    move them to a new disk under new names.  Just what I needed!  So, I
    printed out its documentation (only 2 pages, and reasonably lucid),
    cranked it up and told it to go to work on the disk in drive B.

        Over the years I have heard my TEAC disk drives make many different
    sounds.  They whir.  They purr softly.  They grunt, chuckle and clack.
    Sometimes I get a disk that ticks.  Nice, workman-like sounds.

        Drive B sounded off like a coffee grinder encountering a pound of
    rivets.  I dislocated my elbow reaching for the reset button.

        So much for THAT program.  I frisbeed the disk across the room.  If
    the window had been open it would have wound up in the pond.

        I was left with only that one copy of the lost files to work on,
    and my new, improved, turbo-charged, tail-finned and chrome trimmed
    version of DU.  Like it or not, I was being upgraded from the band-aid
    and iodine division into open skull neuro-surgery.

        DU has a raft of talents in addition to showing what is in each
    sector on a disk.  A list, with minimal explanation, of DU's commands
    would take up two single spaced pages.

        For one thing, you can use it to change individual bytes.  Just for
    fun I've used it to change WordStar's opening menu to be more cheery on
    a bleary morning.  Hacker fun.

        Theoretically, by plugging the right bytes in, I could re-construct
    the ruined Directory Track that was the source of all our problems.
    All I needed was an intimate understanding of how addresses are coded,
    and to determine the address of every piece of every needed file on the
    disk.

        Now, the former I understand (I think).  Files are stored in Groups
    (identified by hexadecimal numbers) of eight Sectors.  There are ten
    sectors per track, and 40 tracks on a single sided disk (which this
    was).  And then there's something called Logical Extents, and ....
    Well, you get the idea.  And hey, we're talking getting addresses for
    fragments of files scattered in 128 (hexadecimal) groups over only 400
    (decimal) sectors.  And of course, if I messed up ....

        I didn't waste much time on that approach.

        An alternative was to suck a sector of file at a time up into RAM
    (another of DU's talents) and then unload it on to a new disk.  A
    sector holds 128 bytes, about one long sentence.  Of course, I had no
    idea just how big any of the files were supposed to be.  Fortunately,
    files are stored in a logical numerical sequence.  DU's (M)ap command
    gave me a chart of the group numbers under which the files might be
    stored, but the map came from the bad directory track.

        Ah hmmm.  And I thought Exxon had trouble in Prince William Sound.

        Well, there seemed nothing to do but to go for it.  I could tell DU
    to go to a Group (the G command), (Y)ank it Sector by Sector into
    memory, then (L)og on to a new disk in drive A and (S)ave it.  Tedious
    and painstaking, but feasible.

        And anyway, it was the only avenue still open to me.

        I automated the pickup stage by stacking DU's commands: D (to
    display one sector); Z20 (take a nap for two seconds, Turkey, so I can
    read the display); then, unless I stop you, (Y)ank it into RAM; + (step
    forward one sector); and repeat (/).  The whole command looked like
    this:

                  D;Z20;Y;+;/.

        As you've no doubt acutely observed, DU uses the semi-colon to
    separate commands.  To speed the process up I tried Z10, but things
    moved by too fast, making me dizzy.

        By keeping track of the sectors before they were slurped up, I
    hoped to hit "C" to stop the process when I reached the end of that
    section of the file and before I ran out of runway.

        Once I got a chunk of file in RAM, I would give it a name and
    unload it on to a brand new disk.  Since not all the groups holding the
    file were contiguous, I would wind up with each one of Peggy's files in
    several little heaps, but, if I was lucky, at least it would all be
    there - I hoped.  I was still flying partly blind, thanks to the
    unreliable map off the directory track.

        Well, there was nothing to do but take a deep breath, and go
    for it.

        Mirabile Dictu!  It worked!  I looked on the new disk and, Captain,
    there be files here!

        The battle was more than half won.  Next I simply used my text
    editor (VDE, of course) to check the heaps out and reassemble them in
    the right order.

        The patient was in surgery for about 6 hours, but after a full data
    transplant he made a complete recovery.

        Backing up your data is like fastening your seat belt when you get
    behind the wheel -- you should always do it.  Two minutes spent backing
    up those files in the first place would have avoided the whole problem.
    But then, I wouldn't have had anything to write about for the last two
    months, either.

                             Keep the Faith, fans.