Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 2 June 1992
This month I thought we'd start to investigate one of the most complex, but potentially one of the most useful of the 512's utilities. So far as I recall it's never been a Forum topic before.
In fact this program is common to all DOS systems, is easy to use and is capable of rescuing you from potential disaster in certain circumstances. In spite of that, it's probably one of if not the least understood of DOS's utilities.
DISC PHILOSOPHIES
Before we get on to the program in question, a reminder about how DOS discs are structured is in order, along with a mention of the sort of problems that can afflict anyone. If you have the 512 Technical Guide from Dabs Press you can find more about the subject of disc organisation in chapter nine, but for the rest of you here's the short version.
Just like most microcomputer filing systems, the contents of DOS discs are stored in a hierarchical directory structure. As you know, if you issue a *INFO in either DFS or ADFS, one of the pieces of information given for each object is the physical location on the disc where the object is stored. Since there are no other pointers to a file or directory in these systems, the whole of the data must naturally follow the indicated startpoint on the disc.
There's a problem with this simplistic approach to disc storage though. The entire file or directory must be able to fit onto the disc in one 'chunk', otherwise you get the "Disc full" message in DFS or ADFS, or alternatively "Compaction required" in ADFS if there's space but it's not in big enough pieces.
Likewise, if you extend an existing DFS file there's always the risk of a "Can't extend" error if another file physically follows the one being updated. ADFS sometimes avoids this by moving a file if it can, but that's slow and still requires a large enough free area elsewhere on the disc. If there isn't one you're back to the previous problem. Added to these limitations, the number of files you can have in a directory is also fixed.
DOS DISCS
DOS doesn't suffer from any of these difficulties, because its disc organisation is more sophisticated. It doesn't store the physical address of an object with its name in the directory, but instead each directory entry, for files and subdirectories, has only a pointer into a table. This table, called the file allocation table, or FAT for short, is where the physical location of the data is stored.
To explain the FAT we need to look at one more piece of the puzzle. Physically DOS discs are formatted into tracks and sectors of course, but for the purposes of data storage a number of sectors (always 1, 2, 4 or 8) are grouped together into a notional unit called a cluster, and a cluster is the unit of disc space that is allocated or added to a file or a directory. That's why clusters are also called allocation units.
Since every cluster on a disc has a FAT entry of its own, the number of the FAT entry directly yields the cluster number by simple addition, while a further simple calculation on the cluster number gives the physical start sector of the cluster on the disc.
Since the actual number of the FAT entry tells the filing system where the data is physically located, the contents of the FAT entry are free to be used for another purpose. Specifically, the content of a FAT entry is either the number of the next FAT entry used by the object, or is an 'end of chain' marker in the last cluster. Clusters can also be marked as faulty, but that needn't concern us here.
Of course, sector sizes vary from disc type to disc type, as can cluster sizes, but the basic method of storing data remains constant. All you need is the location of the FAT, the number of sectors per cluster and the size of a sector, and you can work out where everything is. On DOS discs this information is stored in the first data sector of the disc.
DOS can therefore allocate files or subdirectories (not the root, which is always present and of a fixed specified size) one cluster at a time, so the minimum size for any object or an extension to an object is one cluster. If, for example, a file is to be extended, DOS simply looks for the next free FAT entry, places its number in the old 'last' one and makes the new one the end of file cluster. On DOS discs therefore, when you get a disc full message it really does mean that the data will not fit.
It's easy to see that over time, as new files are added, old ones grow and others contract or are deleted, a file or a subdirectory might well consist of numerous clusters dotted all over the disc. This is exactly what happens and when it does you might notice, particularly on floppies, that disc performance deteriorates. However, this is part the price to be paid for avoiding the more frequent, more annoying and occasionally disastrous problems of the BBC's simpler filing systems.
The problem of fragmented files, as this situation is usually referred to, is easily fixed by copying the files, one at a time, to an empty disc. As each file is copied to the new disc it is allocated consecutive clusters, so the files become defragmented. Copy the new disc back to the working disc and the problem is removed.
POTENTIAL PROBLEMS
Of course most of the time discs and drives are pretty reliable, but trouble can strike, so is the system inherently unreliable?
No it isn't, but failures can be caused by a hardware problem or more simply by power failure. Unfortunately in some cases, even a minor power fluctuation might be enough to cause problems for the 512, particularly if yours is housed in an external co-processor adaptor like mine is. Perhaps I'd better explain that remark.
All models of BBC micro employ a switched-mode power supply. These are quite sophisticated devices and are also quite expensive, but using one means that the machine will withstand quite serious power drops or surges without difficulty. In fact my local dealer once tested a model B and found it ran perfectly at less than 180 volts!
If your 512 is fitted into a Master it naturally shares the Master's switched-mode power supply, hence it is reasonably immune to the vagaries of the electricity supply.
However, for cost reasons the power supplies used in co-processor adaptors are the much cheaper and simpler linear type. These are no more than a transformer, so any input power fluctuation is passed on, albeit at reduced voltage, in its original proportions. If the mains voltage drops by 10% momentarily, the output power drops 10% too. This is more than sufficient to crash a 512.
Where I live the mains supply becomes highly unreliable at the least suggestion of bad weather. On many occasions over the years I've found the BBC host appears fine, the screen looks OK and the BBC's interrupts are still running (verified by pressing either Caps Lock or Shift Lock and watching the lights), but the 512 has crashed. I know this is a power problem, because frequently I've noticed the lights dim for a moment when the problem appears. The BBC is quite happy, but it's too much for the 512. Nine times out of ten a re-boot is all that's needed, plus a few minutes to catch up from where the last automatic save had protected my data. At the same time I also usually mutter a few words to the lords of National Power wishing they could hear me, but perhaps it's just as well that they can't.
Of course the problem is that, inevitably, from time to time one of these power glitches occurs just when a disc is being updated. The results depend on precisely when the fluctuation occurs, since although physical disc updates take place in the BBC micro, the instructions for them are issued from the 512.
If problems happen after the file data has been written but before the FAT is updated, all the file data can be on the disc, but the FAT knows nothing about the changes. Alternatively, if the glitch occurs during the issuing of instructions for a physical disc write, almost anything can happen. The file data or the FAT can be corrupted. Worse, though thankfully not too often, the data for either the file or the FAT can be written to the wrong place on the disc.
Whatever happens, if you have a disc problem you encounter the major disadvantage of DOS's more sophisticated method of storing disc data. If all else fails it's quite easy to recover data from DFS or ADFS discs by reading sectors. After all, even without the directory information, if you can find the start of a file you automatically know where the rest of it is.
By contrast, on DOS discs it's extremely difficult and very slow and tedious to decode the FAT 'by hand', even if you assume that its information is accurate. Having found the first part of a file you must reverse calculate the FAT entry number, then try to find out where the next piece of the file is.
Of course, if the FAT is corrupt you could consider searching an entire disc, sector by sector, but remember that a file's logical clusters can have been allocated in any physical order. You might just attempt this job with a floppy if you were absolutely desperate and the data was life or death, but on a hard disc the idea is utterly out of the question. As a guide and to justify that statement, my own hard disc's DOS partition consists of over 100,000 sectors.
Even using floppies, in practical terms it's nearly impossible to recover a file of any reasonable length from a DOS disc successfully by manual means, so what do you do?
ENTER CHKDSK
CHKDSK is a utility program supplied on disc one of the 512's DOS PLUS issue disc set. It's supplied in both versions, 1.2 and 2.1, and is also issued with all current PC versions of DOS.
As its name suggests, the basic function is to check a disc, but in fact it can also repair some of the types of damage to files and directories mentioned above.
The syntax of the command is:
CHKDSK [DRIVE] [/OPTION]
where DRIVE is any valid drive, supplied in the usual format (A:, B: etc) but it may be omitted when the current drive is assumed. OPTION, which we'll come to later, may also be omitted, in which case CHKDSK will simply check the disc concerned and report its findings.
The checking process involves reading all the entries in the root directory and following up the FAT entries, making sure they are all valid and that each of the linked list of clusters are correctly assigned and terminated. This sort of operation is easy for a program, but is a nightmare if attempted by hand. After the root directory, any sub-directories are read and similarly checked until all the directories and the FAT have been verified as looking sensible.
Assuming no errors, CHKDSK will just report the organisation of the disc and its free and used space. Alternatively, you can request more information by using the '/V' (verbose) option switch, which makes CHKDSK tell you what it's doing as it does it. Try, for example:
CHKDSK A: /V
with a disc in drive A: that contains several sub-directories with a number of files in each. The program can take quite a few seconds to run, but at least with the verbose option you can see what it's doing.
By the way, should CHKDSK find any problems it will report them and ask if you want them fixed, but unless you've specified the fix option (more of which next month) it won't actually rewrite anything, so it doesn't matter what you reply.
We're out of space again, so the other five option switches and what they do will have to wait until next month.