| |
(This article was first published in the ICPUG
Journal MARCH/APRIL 1989 issue.
Permission from Joe Griffin to republish on the Internet has been
received.)
Before I get underway, let me reiterate the advice I gave in my first 'Pet
Prattle' Column. The 'bible' for PET users is:
'Programming the PET/CBM' by Raeto West, published by level Ltd.
Disk Drives
Shortly after the development of the PET, Chuck Peddle's design team
evolved the first Commodore disk drive. There were a number of fairly
radical departures from established practice, which have remained with us
through the Commodore range up to the latest drives. Most disk drives used
Modified Frequency Modulation (MFM) for the actual recording method. The
number of sectors/track was constant throughout the disk and most
importantly the Disk Operating System (DOS) was usually stored in the
computer's RAM. By using an alternative recording method (known as Group
Code Recording, GCR) and by varying the number of sectors/track K was
possible to store larger amounts of data on the disks. Commodore also
produced the intelligent disk-drive. Unlike the 'dumb' drives used in old
fashioned computers (like the Apple and Amiga), the PET drives contained
their own microprocessor which accessed a built in DOS, contained in ROM
chips. This approach has the major advantage that there is no loss of
computer memory to the DOS but does have the drawback that the DOS cannot
be modified by the user.
An alternative drive available at the same time was the
Computhink drive which used a ROM chip in the PET to hold Its DOS. (Rae
West devotes some space to these drives.)
The first drive released to PET users was the 2040, a twin
single sided drive, holding about 170 kbytes/disk. There were a number of
teething problems with this drive, including a fairly severe overheating
problem. The drive was revised slightly and reissued as the 3040, with
ventilation slots cut into the case. Although there have been a number of
changes to CBM drives over the years, much of the disk structure of those
early 2040's is still with us. This has the great advantage that those of
us who want to hack about on the disk can apply similar principles to
almost any Commodore disk. For details of the structure of the PET drives,
I refer you to Chapter 6 of Rae West's book.
As an example, the 2040 used one sector for the disk
header, containing the disk name and ID code. The Block Availability Map
(BAM) which tells which sectors on the disk are free and which are in use
was also held in that first sector. The next sector was the first block of
the directory, holding 8 entries at 32 bytes / entry. Although some of the
later drives have needed more blocks for the BAM (the 8250 uses 4), the
same principles apply. On those early drives, the user had a choice of
three file types - Program (PRG), Sequential (SEQ) or User (USR). DOS used
the first two bytes in each sector of the file to form a pointer to the
next sector, establishing a file chain. Direct access files were possible
but BAM management was in the hands of the user, it was not supported by
DOS. One of the other problems with these drives is that the disk must be
initialised before it can be used. If a DOS wedge or BASIC-Aid utility is
in use, the user can send the command 'I0' to the drive, if no such utility
is in place, then the user must issue the command:
OPEN 15,8,15,"10" :CLOSE 15
When the 4040 drive appeared, it was fitted with DOS 2, which not only gave
auto-initialisation of disks, but also allowed Relative (REL) files. These
allow the user to maintain direct access files from within DOS. There was
also a small change to the number of blocks on the disk. On the 2040 or
3040 a freshly formatted disk had 670 blocks free. For the 4040 this
reduced to 664 blocks free.
This drive used the same track for the directory, placing
this halfway across the disk (track 18 of 35) and positioning flies on
either side, gradually working out to the edge tracks. Commodore stayed
with this idea; the 77 track 8050 uses track 39 for the header and
directory (and two blocks on 38 for the BAM) and their 1581 3.5'' drive for
the 128 (an 80 track device) puts the header, BAM and directory on track
40.
The disk can be very easily modified, down at the structure
level, by using a good disk editor. Being an intelligent drive, it does no
more work than is absolutely necessary (in fact the drive in my 128D
doesn't even do that much, see elsewhere in this issue for the sorry tale)
When a file is deleted from the directory, all that is done is the file
type in the directory entry is marked as
deleted and the blocks used by the file are marked as unused in the BAM.
The actual file blocks are not touched. Thus, provided nothing more has
been written to disk, by restoring the file type byte and validating the
disk, the file could be unscratched. One disadvantage of the way CBM drives
always place files as near the centre as possible is that a scratched file
is likely to be overwritten almost immediately. (By contrast, on the IBM
hard disks, new files are always placed further along on the disk and free
space is not reused until it is needed.)
Similarly, if a used disk is re-headered, using the short form of
the header command (ie: without the disk ID), then all that happens is the
header block, SAM and first directory block are rewritten; the actual data
blocks are not modified. Although it is not all that easy to do, it is
possible (I've done it) to bypass the first directory block and re-validate
the disk, which restores all but the first 8 files. If the blocks which the
BAM says are unused are then examined, file chains can be found and these
will include the eight missing flies. The program 'FILE RECOVERY.4' on
utilities disk U1 can be used to locate and print these file chains.
Every time the disk contents are modified in any way, the
directory track is changed. Thus it is not surprising that this is often
the first track to fail. Usually it is the first sector of the track which
becomes unreadable and without this sector, the disk cannot be initialised
or read. On two or three occasions now I have been given disks with this
problem, where the user does not have a backup. By a certain amount of
fiddling, it has been possible to copy the rest of the disk and recreate
the directory, using the file recovery program. If you want to learn about
the structure of disks, I can recommend this as a learning course. I would
however recommend that you try it on a backup disk, not a master!
For this type of work a good disk editor program is
essential. I have used both 'Disk Revealed' and Precision's 'Super Discdoc'
which 1 find slightly easier to use.
Reading Programs as data files
One of the advantages of the disk drives is that although the program flies
are stored in binary image form, they can be read byte by byte, just like a
normal sequential data file. With a suitable knowledge of the way BASIC
tokenises the keywords, the program can be translated back to a readable
form. This has been used in a number of programs. Notably programs such as
'LISTER', MERGER', 'COMPACTOR' and 'CROSS-REF' on utilities disk U2 allow
the user to manipulate program files.
|
