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 *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.