Master 512
Forum by Robin Burton
Beebug Vol. 10 No. 2 June 1991
Before going on to other topics, I'd like to thank those of you who have written in response to my request for your feelings and ideas about the content of the Forum.
No-one seems to have any major complaints and it appears that the overall feeling is that I should carry on much as before. In other words, each month's Forum will continue to be almost as much of a surprise to me as it is to you.
WHO-DUNNIT?
This month I've decided to tell you about something I recently discovered, and how I came to find out. There's also a lesson in this about how much time you can waste if you make assumptions about other people's software (clue, Acorn's).
Over the last couple of months I've been writing and testing a new program. Nothing unusual, I spend a good deal of my time doing that, but it proves its never too late to learn something new. I've found some interesting limitations (that's the polite way of saying bugs) in the 512's XIOS.
As I've said previously, I won't advertise in the Forum, so I'll just say enough for you to understand what I was doing and why I was doing it. The program is for setting up variable hard disc partitions, so let's leave it at that. Even if you don't have a hard disc I think you'll still find the following item interesting and who knows, it might possibly also apply to some floppies. I don't know because I haven't tried it. By the time I'd sorted the problem out I'd had enough of this sort of thing.
You'll realise that I didn't find testing this program much fun. Basically, the first part of the exercise was to secure the contents of my entire hard disc, because creating a new partition always destroys all existing DOS files. In addition, if the size of the partition is to increase from the previous one, you almost certainly have to remove (or move) your ADFS files as well to free sufficient disc space.
So far so good, but having created a new partition how do you go about testing it? The answer of course is that you must first load it with data, and what could be better than real files? In my case this consisted of roughly twenty or thirty directories containing about 15 megabytes of data in several hundred files, plus about another five megabytes in ADFS.
You'll also guess without much effort that after the basic testing of the first few different partition sizes the novelty of this job began to wear a bit thin, even though I'd only had to secure the files once when I started. Still, this direct method was all right to establish that the program seemed to be working before investing more effort in setting up specific tests.
A further consideration was that although I had about 15 megabytes of DOS data which I could load, this would leave me somewhat short of both data and files for testing partitions of between 15 and 32 megabytes. I could have recovered the same files to extra, new directories with names like test1, test2 and so on, but the time taken to do this would be enormous for the larger partitions (as you'll know if you've ever had to recover a large 512 hard disc).
There had to be a better way, and so there was, but (very) indirectly this led to my discoveries. Of course, to start each partition off I had to recover my DOS utilities and one or two other items needed during the tests, but this did reduce the basic recovery job to about five minutes. With a bit of work I was then able to carry out the most lengthy tests in a much more automated fashion. These are filling directories and filling the disc. The beauty of automating the process, of course, was that I could just set it off and then go and do something else.
THE EVIDENCE
The first test, checking what happens when a directory becomes full, is pretty basic stuff, but even so it had to be done, both for the root and then for sub-directories. There are several ways to tackle filling a directory with files, but the most obvious was to use BBCBASIC. The program was simple, using nested FOR-NEXT loops to increment the last two characters of a filename, opening the file, printing its name to the file then closing it. I duly set the program going and went away.
You'd probably expect, as I did, to come back to the machine some time later to find a 'Dir full' message, and naturally a directory full of files. If that's what you'd expect you'd have been as surprised as I was to find that the system had crashed. There was just a non-stop scrolling 'Invalid opcode' display on the screen.
I rebooted and checked the root directory. It was indeed full, but why had it crashed? I (manually) deleted one file and tried to copy one – instant hang-up! On rebooting I found that the directory should have held the extra file, but it wouldn't. I deleted a dozen files and copied new ones until it crashed again, this time finding that the 509th file hung the system. Obviously the directory was somehow damaged!
My first reaction was the obvious one, the hard disc partitioner was at fault. After all I'd been changing the number of root directory entries from standard amongst various other things. I therefore next created another partition, but with the standard number of 512 root entries. I then re-ran the test.
Same result! What next? Could it be BBCBASIC? It didn't take long to write a machine code program to do exactly the same as the BBCBASIC program. I then created another (standard root) partition and tried again. Guess what! The same result!
I was pretty confident that my partition program was all right, particularly using standard settings, so I persisted. The next step was to fill the directory using standard DOS COPY commands in a short batch file. This took ages to run, because each new entry now involved both reading and writing a file, but a couple of hours later I came back to find the machine had hung with no display. I rebooted and sure enough the directory was full again.
It now looked as though there was something wrong in my partitioning program after all, so to eliminate that I created yet another new partition, this time using the standard Acorn program. This limits the range of partition sizes to four and it doesn't mess about with the configuration, so surely I'd now get to the bottom of the problem.
THE GUILTY PARTY
Yes I did. Maybe I should have realised sooner and perhaps you have already. My excuse is that by this stage I'd been creating partitions, filling the root directory and crashing the system for nearly a day. The answer, it turns out, is the simple one (of course!).
If you fill the root directory of a 512 hard disc partition the system crashes.
I hope that little gem saves somebody some trouble, it took most of a day for me to prove it beyond doubt. Of course I'd had plenty of 'red-herrings' to chase in the form of more likely candidates for the cause, and proving it when you know the answer is much easier. I wasn't too pleased as you might expect. I'd spent all day chasing a bug which Acorn built into the system.
My conclusion, for what it's worth, is that Acorn knew about the problem and decided on 512 entries for the hard disc root directory simply because it's such a large number (no-one was ever likely to find the bug). It must be said that in normal use performance degrades so badly after the first few dozen files that the urge to create a new subdirectory does become overpowering, but it's hardly satisfactory.
BATCH TECHNIQUES
As part of the testing above I used batch files and they reminded me of a couple of questions I've been asked.
The first one is how can you prevent the output from a batch file being written to the screen? Using 'ECHO OFF' stops all the commands being displayed as they're executed (except the echo off itself) but everything else, such as files being copied, is displayed. There are only two methods I can think of and they both involve some restrictions.
The simplest technique is to set the screen foreground colour to the same as the background using the 'COLOUR' command at the start of the file; then include a 'CLS' before you reset the foreground colour at the end of the batch job (otherwise all the output will re-appear). This doesn't actually prevent screen output, so you'll see the COLOUR command for a moment, but it does hide the rest of the output. The disadvantage is that anything previously displayed is also lost.
An alternative method is to use two batch files, redirecting the screen output of the second one (the one that does the work) to a file in the call to it, then deleting this file at the end of the job.
An example will make this clearer, let's call the files 'BATCH1' and 'BATCH2'. Here's how BATCH1 looks:
BATCH2 >TEMPFILE
DEL TEMPFILE
That's all there is to it. It simply calls the second file and redirects any console output from it to the file 'TEMPFILE'. On return from BATCH2 the file is deleted. BATCH2 can do anything you like, but for illustration, just catalogue the disc with a 'DIR'. If you create these two files and try them you'll soon get the idea.
The disadvantages this time are also twofold. First, as before this method doesn't hide the initial command in BATCH1. Secondly, anything which should affect the screen, such as a PCSCREEN command, a COLOUR command and so on are actually implemented in the BBC as VDU strings. Because the VDU output (from the DOS program) is being redirected it never gets to the BBC micro and so such commands won't work during redirection. On the other hand, it is a technique which can be 'switched on and off' as many times as you like within any batch file, so you can largely get round the problem.
So far as I know, there isn't a perfect answer to this problem in the 512, but by using these two methods and ECHO OFF in various combinations you can certainly tidy up your batch file displays if you don't want someone to see everything that they're doing as they execute.
As a final point, if either (or both) of these techniques are used in your AUTOEXEC file the initial command doesn't appear on screen anyway, so if you want a totally invisible start-up when you boot the 512 here are two ways in which you can do it.
SHARED INFORMATION
You'll remember I offered to include addresses in the Forum if anyone would like to correspond with other 512 users. Well one member, Ron Thompson, has taken up the offer. I've known Ron (by letter) for a couple of years or so and I can tell you that he's a very keen 512 user.
In fact I met Ron late last year in North Devon. I was there visiting relatives, but Ron had to drive for three hours from the far South-West of Cornwall, which might tell you why he's keen to correspond with 512 users.
|
Living where he does, Ron is very much isolated from fellow users, computer clubs and even from Acorn dealers and (PC) software shops. I know he writes to one other user already and he tells me that exchanging information about applications, shareware and the 512 in general has proved very valuable. Not surprising, after all, 512 Forum readers together represent a vast reservoir of information about using the 512 – why not share it. If anyone would like to join in write to:
Mr. R. Thompson, *******
Who knows, it might be the start of a 512 users club by mail.