Previous | Index | Next

Master 512 Forum by Robin Burton
Beebug Vol. 8 No. 4 August / September 1989

Since writing the last Forum I've been busy copying BBC BASIC discs and several points arise which are worth mentioning, so there's a slight change of plan this month.


First I must thank everyone who included a letter with their disc. Even if it was only a note to observe the formalities, the courtesy was much appreciated. It helped to make the job much more pleasant and personal.

The second point is that a number of Forum readers are recent converts to the 512 and/or to BEEBUG. As many said, it's the only magazine to cater for the 512 regularly. And so shall it continue with the enthusiasm you've shown. You might like to know that almost 140 copies of BBCBASIC have been dispatched to date, and more discs are still arriving.

Newer readers might therefore have missed these items which were included about six months ago, so here they are again. Bear with me because I may have another offer in a month or two.

You may not all realise it but I do the disc copying and letter answering myself. I'm not employed by BEEBUG and it makes a difference. If you write to me and expect a direct reply these are the rules. You must supply adequate return postage and packaging. Packaging should either be self addressed, or should include a suitable label, with sufficient postage to cover any items to be returned.

Quite a few will have had excess postage to pay. Sorry, but if I offer free software and a free copying service, I do not pay the postage as well.

Overseas readers can send international postage coupons instead of stamps – get them from your post office. As you don't know our postal rates just send the same value as it cost you to write to me. If it's not exactly right I'm not too worried. As I said last time, all I ask is that you make the effort.

For example Heinrich Lamm generously sent 10 Deutschmarks saying have a drink with the change. I did Heinrich, especially welcome as it was so warm, but the bank also charged me half its value to change it. Adrian van der Veen sent an extra disc instead of postage, which I thought was a reasonable offer. Professor Isaacson sent a sterling bank draft from Capetown, also all right, except it was payable to BEEBUG not to me, so a minor complication there.

In fact the majority of you did things right, for which I thank you. With this number of discs to copy and return anything that simplifies the job is welcome. A minute or two saved on each one, even writing out your address, soon adds up to a considerable amount of time. This leads me nicely to the next point.


This time I'm not complaining, especially since I didn't specify a particular 512 disc format in the article, but after copying a few discs lately I found some of the figures interesting. Perhaps you might think so too – I'd never timed such an operation before.

So as to make the copying operation as fast as possible I created a 300K RAM disc and put all the BBCBASIC files into it, which left 68K of RAM disc unused. Point number one – although the files actually contain 186K or so of real data, the files occupy 232K plus. The minimum DOS file allocation size (one cluster) accounts for the 'missing' 46K.

This is worth remembering if you want to find the amount of space occupied by a directory or a group of files on disc. The normal 'DIR' command gives you only the total free space remaining for the whole disc, not the amount used (or left) by a directory.

'SDIR' will give you the space used by the contents of a directory, but this time it's the total size of the data in the files, not the total disc space allocated to them. As in the BBCBASIC copying exercise, it's easy to 'lose' 50K or so. The more small files there are, the bigger the total discrepancy.

It may seem a small point, but I created a batch file to set up the disc copy, so I allowed 300K for the RAM disc simply because I knew it would be more than big enough. There's just no straightforward way to find out exactly how much space is needed, other than adding together the sizes of all 59 files, rounding up each as appropriate, so I didn't.


A RAM disc is by far the best way to do this sort of mass copying job, because it's several times quicker than a winchester (no tube, you see) and many, many times faster than floppies. The first figure I noted was the time to copy the files to the RAM disc from my 800K master disc. This was the first job for each copy session and it took 48 seconds.

Most of you sent an 800K disc – not very surprising, we all know it's the quickest format, don't we? Well, it seems we don't. I had several 360K discs, two of 720K and perhaps a dozen or more of 640K. Thankfully the rest were 800K.

As I said, I've never bothered to time the different formats before, I know that 800K is the quickest and use nothing else unless there are special reasons. Well, when you've got 15 or 20 discs a day to copy you have to find something else to do, so I timed each of the different formats, especially after coming across the first 640K disc (to be honest at first I thought it was faulty). Here are the results:

800K - 2 mins 12 secs (1)
720K - 3 mins 51 secs (1.75)
360K - 4 mins 52 secs (2.21)
640K - 7 mins 48 secs (3.48)

The figure in brackets is the time as a multiple of the 800K's time. Interesting? I thought so. As an extra experiment I also tried an 800K to 800K copy with the same data but using the disc backup in 'DISK' and it took 4 minutes 48 seconds. Of course I couldn't use this for two different formats. As not everyone labelled their disc with its format, file to file copying was the only method guaranteed to work for all discs.

I suppose if I'd been asked beforehand I would have forecast that 360K would be the slowest, if not by very much. Since the copy was from a RAM disc that accounts for very little time, in fact just about 4 seconds for 200K. The remainder of the time is attributable to the floppy disc. Regardless of the RAM disc's contribution, the differences can be explained only by the different formats.

It really puts things in perspective when you realise it would still be quicker to first re-format 640K discs to 800K and then to copy them. For this reason I didn't time a 640 to 640 file copy. I leave it to you if you want to know; I'm happy to remain ignorant. I know why the 640K time is so poor, but I'd never thought about it before. The only 640K DOS disc I possess is my boot disc.

So why is 640K so slow? The answer is that its the only 512 disc format that uses the ADFS ROM in the Beeb. Whatever the strengths of Acorn's ADFS, speed isn't one of them. A while ago I disassembled 6502.SYS and was interested to see that no IBM or CP/M formats go anywhere near ADFS – obvious really, but as I've said, it's one of those things you never think about until there's a reason.

You'll find the more files on a 640K disc the worse performance becomes. With only a dozen files it's not too bad, with 60 it's abysmal, with a couple of hundred I don't want to know. This is due to the way the (DOS) directories and files are managed in ADFS. ADFS sees the DOS disc as a single file, so reading or updating of files or directories is done (by DOS) using byte access only. This is the way a hard disc is handled too, but with a Winchester's speed it hardly matters; with floppies it does.

You can try these tests yourself if you're curious and you've some spare time. You may get slightly different results, but they'll be close – I don't use Acorn's ADFS because it's so slow. For example, I just loaded Acorn's ADFS into sideways RAM and booted DOS from floppy. The result including executing the 'AUTOEXEC' file was 1 minute 3 seconds for Acorn and 38 seconds using my normal ADFS. 'Acorn formatted' 640K copy times are longer too, but for all the non-ADFS formats the results should be about the same.

What does all this lead to? Two things. First, if you habitually use 640K discs (or the other sizes to a lesser degree) do yourself a big favour and convert your discs to 800K immediately. Not only will you find you have a number of spare discs, DOS applications and files will load very much faster. The second point? If you should have cause to send me a disc, please – only 800K in future.


Thanks to everyone who contributed to this. Overall the view is rather mixed, some are happy with it, some not so. This leaves us more or less where we were in the last Forum. I know that at the rate of one Forum per month, developments appear slowly, so here's a progress update.

I wrote to Shibumi Soft again on June 10th and received a reply yesterday, July 4th. Further correspondence is needed, but with luck there'll be something more final in the next Forum. My advice for now is to hold on, but if you can't wait bear in mind the points most commonly mentioned by Forum readers and (mostly) confirmed by Shibumi Soft:

1. It runs better with DOS+ 1.2, and is decidedly delicate with 2.1 in all machines.


We have included an MS DOS utility by Bernard Hill
on this month's disc called FIND.EXE. This will locate
a specified string within an ASCII file by listing all lines
containing the given string. A documentation file is also
included on the disc.

The files will need to be transferred to the Master 512


The documentation file also describes a second MS DOS
utility which we expect to include on next month's
magazine disc.

2. Use it only with applications that don't work without it. There is a list, not supplied as standard, so you're left with trial and error for problem packages. It can definitely cause problems with programs that do run correctly otherwise.

3. One or two packages (Elite) do run with it, but take about four minutes to start after loading. That's long enough to think it has failed or hung, perhaps it hasn't. Go and make a cup of coffee then see how it's getting on afterwards.

4. It does not work with the PC+, with either DOS+ 1.2 or 2.1.

5. It's copy protected, therefore you can't run it from a hard disc, nor can you make a back up copy.

6. The 'menu' mentioned in the documentation doesn't exist. (They say it's invisible!) Operation is from the DOS prompt and is not confirmed, nor can current settings be interrogated or displayed. This is perhaps the worst point; you're left entirely in the dark even if everything is alright.

7. I still can't get it to run correctly, even with 1.2 (Shibumi Soft say four others are in the same position and they don't know why).

And Finally...

Roger Gelder (who's also had no luck with Problem Solver) writes asking if anyone has information on graphics packages for the 512. He's heard that TURBO CAD V.1 is OK and knows of Ventura, but naturally is mostly impressed by its price. Information please (not on GEM) if you use a graphics package.

Previous | Index | Next