8-bit Software Disc Magazine (c) Duncan Webster DEC 1991
Issue 17 December 1991
Watford Single / Double Density Mk II DFS
About a year ago I changed my Watford Single Density DFS (1.44) for
the latest Watford Double Density DDFS Mk II (1.54T). In general I
believe this is one of the best DFS's i've used (as far as features go
etc) even though shortly after I noticed files strangely corrupting
for no apparent reason.
Originally when my files used to apparently corrupt I put it down to
disk quality and just bad luck but I also noticed that these
corruptions always happened on certain programs in the same places etc
(which does tend to eliminate my original theory). Anyway due to this
I decided to investigate these problems and have found what I consider
to be a fairly significant bug in the DDFS ROM which I feal other
people should be aware of.
To demonstrate the bug type the following in using a blank disk:-
*ENABLE
*FORM80 0
You can use double or single density with either a 31 or 62 file
catalogue (doesn't make any difference). Now type in the following
BASIC program:-
10 file%=OPENOUT("TEMP")
20 PTR#file%=256
30 time%=TIME+500
40 REPEAT UNTIL TIME>=time%
50 PTR#file%=257
60 CLOSE#file%
While still using the disk formatted a moment ago, RUN the program
(will take about 10 seconds). For those people who want an explanation
of the program, all it does is create a file called "TEMP", moves the
file pointer (PTR) to 256, waits 5 seconds, moves the pointer to 257
and finally closes the file.
If you now *DUMP TEMP, what you should obtain if your DFS is working
correctly is the following:-
0000 00 00 00 00 00 00 00 00 ........
0008 00 00 00 00 00 00 00 00 ........
0010 00 00 00 00 00 00 00 00 ........
0018 00 00 00 00 00 00 00 00 ........
0020 00 00 00 00 00 00 00 00 ........
0028 00 00 00 00 00 00 00 00 ........
0030 00 00 00 00 00 00 00 00 ........
0038 00 00 00 00 00 00 00 00 ........
0040 00 00 00 00 00 00 00 00 ........
0048 00 00 00 00 00 00 00 00 ........
0050 00 00 00 00 00 00 00 00 ........
0058 00 00 00 00 00 00 00 00 ........
0060 00 00 00 00 00 00 00 00 ........
0068 00 00 00 00 00 00 00 00 ........
0070 00 00 00 00 00 00 00 00 ........
0078 00 00 00 00 00 00 00 00 ........
0080 00 00 00 00 00 00 00 00 ........
0088 00 00 00 00 00 00 00 00 ........
0090 00 00 00 00 00 00 00 00 ........
0098 00 00 00 00 00 00 00 00 ........
00A0 00 00 00 00 00 00 00 00 ........
00A8 00 00 00 00 00 00 00 00 ........
00B0 00 00 00 00 00 00 00 00 ........
00B8 00 00 00 00 00 00 00 00 ........
00C0 00 00 00 00 00 00 00 00 ........
00C8 00 00 00 00 00 00 00 00 ........
00D0 00 00 00 00 00 00 00 00 ........
00D8 00 00 00 00 00 00 00 00 ........
00E0 00 00 00 00 00 00 00 00 ........
00E8 00 00 00 00 00 00 00 00 ........
00F0 00 00 00 00 00 00 00 00 ........
00F8 00 00 00 00 00 00 00 00 ........
0100 00 ** ** ** ** ** ** ** ........
Basically an empty file, filled with NULL bytes. In reality what
you'll get with the DDFS is:-
0000 E5 E5 E5 E5 E5 E5 E5 E5 ........
0008 E5 E5 E5 E5 E5 E5 E5 E5 ........
0010 E5 E5 E5 E5 E5 E5 E5 E5 ........
0018 E5 E5 E5 E5 E5 E5 E5 E5 ........
0020 E5 E5 E5 E5 E5 E5 E5 E5 ........
0028 E5 E5 E5 E5 E5 E5 E5 E5 ........
0030 E5 E5 E5 E5 E5 E5 E5 E5 ........
0038 E5 E5 E5 E5 E5 E5 E5 E5 ........
0040 E5 E5 E5 E5 E5 E5 E5 E5 ........
0048 E5 E5 E5 E5 E5 E5 E5 E5 ........
0050 E5 E5 E5 E5 E5 E5 E5 E5 ........
0058 E5 E5 E5 E5 E5 E5 E5 E5 ........
0060 E5 E5 E5 E5 E5 E5 E5 E5 ........
0068 E5 E5 E5 E5 E5 E5 E5 E5 ........
0070 E5 E5 E5 E5 E5 E5 E5 E5 ........
0078 E5 E5 E5 E5 E5 E5 E5 E5 ........
0080 E5 E5 E5 E5 E5 E5 E5 E5 ........
0088 E5 E5 E5 E5 E5 E5 E5 E5 ........
0090 E5 E5 E5 E5 E5 E5 E5 E5 ........
0098 E5 E5 E5 E5 E5 E5 E5 E5 ........
00A0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00A8 E5 E5 E5 E5 E5 E5 E5 E5 ........
00B0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00B8 E5 E5 E5 E5 E5 E5 E5 E5 ........
00C0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00C8 E5 E5 E5 E5 E5 E5 E5 E5 ........
00D0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00D8 E5 E5 E5 E5 E5 E5 E5 E5 ........
00E0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00E8 E5 E5 E5 E5 E5 E5 E5 E5 ........
00F0 E5 E5 E5 E5 E5 E5 E5 E5 ........
00F8 E5 E5 E5 E5 E5 E5 E5 E5 ........
0100 00 ** ** ** ** ** ** ** ........
As you can probably see, it doesn't work very well. For people not in
the know, the &E5 bytes are placed there by the formatter. The
significance of the &E5 is fairly small, if you had not formatted the
disk before hand the file would have contained whatever was on the
disk before etc.
For people who use this DDFS and want to keep their files intact the
basic rules are that you will only get this problem with random access
data files where you use OSBPUT, OSGBPB etc which rules out use of
BASIC PRINT#,PTR#,BPUT# etc. Programs which use OSFILE (*SAVE etc)
seem to operate properly and should give you no problems.
I might just point out that I have tried this with my old Single
Density DFS (1.44), Acorn 1770 DFS and Acorn ADFS (using same FDC) and
the problem does not occur.
I have also written to Watford pointing this problem out, and they
promptly replied saying that this is an old bug which was known to
them and since the writer of the DDFS was no longer under contract to
them there was nothing they could do. I might just point out that they
did offer to replace the DDFS ROM with an Acorn 1770 DFS free of
charge.
As it happens I recently stumbled across another bug with the DDFS if
you try to *SPOOL the output from a *DUMP command ie:-
*SPOOL TEXT
*DUMP <file>
*SPOOL
You get some very strange effects (definitely not what should happen).
Anyway, anyone using this DDFS consider yourself warned and I hope
this explains any files which you have suddenly lost for no reason. I
would be interested to hear from anyone who has suffered from this
problem, and anyone who has anything to say about the fact that
Watford are continuing to sell this DDFS without a prior warning. With
a bit of luck someone somewhere may be able to provide a solution.
Gary Davies 348.