It's the start of a new decade so I'll first wish you all a happy new year. I also wonder what's in store in the world of computing, both for Acorn and in DOS.
Both the Beeb and DOS are products of the 80s and both will soon be 10 years old. BEEBUG was on the Acorn scene very early, (note the fact that we're almost into volume 9), and while some Acorn publications have come and gone BEEBUG not only flourishes but remains faithful to our trusty 6502 machines. In fact it seems likely BEEBUG will soon be the only magazine catering for the 8 bit BBC micro at all, let alone exclusively.
I know for certain that one 'BBC micro' publication will be wholly Archimedes based very shortly. The rest may not be so formal or so forthright about their intentions, but it's obvious from their contents that only lipservice is now being paid to to the trusty Beeb (I, at least, will continue to refuse to call the A3000 a BBC micro).
"What's he going on about?" you're wondering. Advertisements actually. Many of your letters are complimentary and encouraging about the Forum, but at the same time quite a few express concern that 512 Forum may not continue for much longer.
Let me put your mind at rest. Mike Williams, in 'Editor's Jottings' in the last issue, said BEEBUG magazine intends to continue so long as there's a demand. Let me add to that by saying there are no plans to end 512 Forum, and as far as I'm concerned it will continue as long as there's a BEEBUG magazine. Given that other magazines are catering less and less for our machine, I'd hope that the future is secure for the faithful for some time and that brings me to my second point: some of you can help.
Recent issues have, as usual, carried readers' hardware ads., most of it sold, presumably, as users move to the Archimedes. Of more concern to me, however, is that there seem to have been rather more 512s on offer lately too. Perhaps some of them were purchased in Acorn's 'too good to miss' sale a year ago and their owners failed to get to grips with DOS, but that can't account for all of them.
My point is, if you sell your hardware make sure you remind its new owner about BEEBUG and 512 Forum, and definitely do so if the sale isn't through BEEBUG's Personal Ads. It might seem obvious to you, but gone are the days when you could walk into a newsagent's and pick up any of several magazines containing interesting or helpful articles and programs. Bear in mind that Beebug is on subscription, so if new (to Acorn) users receive no guidance from those in the know they might soon wonder what they've let themselves in for these days.
Surely all 512 users remember what it's like to be without support and information, so if you do sell your hardware, do the purchaser (and the remaining Beeb and 512 users) a favour and spread the word.
I'm indebted to Cliff Bowman of TCS (see 512 Forum in BEEBUG Vol. 8 No.7) for bringing my attention to the following. Until he phoned me I hadn't seen the article myself.
You may have noticed the appearance of that extremely rare creature, (previously thought extinct) a 512 item in another magazine. Dave Atherton of Dabs Press (who else?) included an item in his column recently about changing the size of DOS hard disc partitions. I trust that after reading the following you'll excuse this Forum being given over to hard disc owners, even if you aren't one of them.
Most ideas in Dave's column are supplied by readers, and I'm not being condescending when I say that I sympathise with anyone who writes a specialised monthly column. It's utterly impossible to test or verify every idea or program submitted. There simply isn't time, even if the correct hardware and software combination can be produced, which of course is often impossible. I have the same difficulties with suggestions or queries about DOS software – there's just no way that I can lay my hands on every package, much less be familiar with them all even if I do have a copy. Some things have to be taken on trust.
Now to the important point. The procedure outlined is fairly involved and there's plenty of opportunity to get it wrong since it involves editing your hard disc at sector level. Assuming that you get it all right your problems aren't over. The method outlined might work for some combinations of sizes (of the hard disc total capacity and both the initial and resulting partitions), but for most you'll be heading for disaster. Unhappily it's also a time bomb, in some cases it will be sooner, in others later!
By the way, Cliff warns that you MUST NOT use 'CHKDSK' (and probably many other DOS disc utilities), or disaster might not be sooner or later, it could be immediate.
If you tried the exercise and are using a modified partition I suggest you read the rest of the Forum, then ensure that all your hard disc files, ADFS and DOS Plus, are safe before you do anything else. If you back up any more files check their contents first, then copy the files separately. Even if you have the tools, don't copy entire partitions or even entire directories, you'll see why shortly.
Danger lurks in several areas. To understand, bear in mind that the DOS partition isn't just seen by DOS as a hard disc, it's also seen by ADFS as a file, and that's part, though not all of the problem. If you read the previous Forum about how DOS files are stored on disc you will I hope, excuse this repetition for any who might have missed it.
The first point is that the size of a DOS partition relies on two separate pieces of data, not just one as suggested in the article. This means that inconsistencies can arise where ADFS thinks its usable disc area is of one size, while DOS disagrees. Which way round this argument occurs depends on the total size of your Winchester, the original (standard) partition size and the new size produced by the editing exercise.
The second point is that in DOS, files become fragmented as mentioned a few issues ago. While a file written to an empty disc will occupy a contiguous area (i.e. sequential sectors and clusters), over time, as files are deleted or re-written with new lengths and new files are added, the physical areas of disc used by any file (i.e. the clusters) can become literally scattered all over the disc. Unlike DFS or ADFS, DOS doesn't delete a file and re-write it in one piece when it expands, even if the existing location is no longer big enough (which is why there's no 'COMPACT' command).
DOS uses the existing area, then adds extra (unused) clusters as required at the logical 'end' of the old file area, but from wherever it happens to physically find clusters on the disc. Conversely, when a file contracts or is deleted newly freed clusters are marked available, and may be used immediately by anything else. When looking for empty clusters, whether for a new directory, a new file, or to extend an existing one, DOS simply starts at the beginning of the disc area and uses extra clusters in the order it finds them.
You can envisage that, when a disc has been used for some time any file can consist of a collection of clusters, each physically separated from its logical neighbour. Although processed in a logical sequence when you access the file, the clusters needn't be in any kind of sequence, physical, logical or otherwise.
This happens on all DOS discs except RAM discs which are freshly created every time you use them anyway. Floppies are easy to sort out because they're of limited size. Although smaller than a Winchester, they're also much slower, so you tend to notice extended access times more. It's then time to re-organise the files by backing up (at file level, i.e. file by file). Do this to a completely empty disc, then copy the resulting disc back to an empty working disc. This ensures that all the files occupy physically (as well as logically) sequential clusters on disc. Of course you'll need to deal with directories one at a time.
Hard discs suffer the same problem, but as they're very much larger there are more files and there's more scope for fragmenting. Unfortunately it's also less noticeable because of the higher speed, so re-organising tends to be overlooked. Remember that the intermingling of logical sections of data isn't limited to files in one directory, it applies to everything on the disc, including the actual directories themselves.
Without getting too involved in details you can see that if DOS and ADFS disagree over precisely where their usable areas of disc start and finish an extremely serious problem is virtually unavoidable. Of course DOS and ADFS will disagree on their areas if the data on which they base decisions has been changed in any way inconsistently. The result can be that ADFS files overwrite areas which DOS thinks it owns, or vice-versa, and it doesn't only depend on which partition is extended.
I should warn you that if you amended your hard disc in the manner suggested in the Acorn User article and think it's OK, you might not discover problems immediately. You'll probably only become aware of it when EITHER of the two areas, DOS or ADFS, has been used for some time, in other words, when you've lots of data to lose. Bear in mind that neither the ADFS command '*FREE' nor the DOS command 'DIR' helps, because the free space given by both is the total, and the free space can be anywhere, like the files. Although both partitions may show lots of free space, it's quite possible that areas towards the end of the allocation have been used, and that's where disaster awaits.
When it happens there are two possible results. The first and least harmful is that you'll find that some DOS files actually contain data from ADFS, or that ADFS files contain data from DOS.
The second, and worse, possibility is that if the 'other' filing system has overwritten either a directory or, for DOS, any part of the free space data for the partition, whole directories, or even the whole partition, could be totally inaccessible. In this case the data is completely irrecoverable, except perhaps by editing and recovering sectors. Bearing in mind file fragmentation and that only text is readily identifiable, I'd rather look for a needle in a haystack!
As I said, which way round things happen depends on several factors, but unless the invading data is easily identifiable you'll probably never know. What turns disaster into catastrophe, especially if you're diligent about backups, is the fact that when you discover it you may also find that your backups are in the same state. If so the data in the affected areas is gone forever.