DragonDOS NX01 and DragonDOS 64 NX01 are copies of DragonDOS 1.0 and DragonDOS 64 V1.0 which I have modified by carefully applying all of Philip G. Scott's bugfix patches from the May and July (1985) editions of Dragon User magazine.
Link to my DragonDOS 64 post viewtopic.php?f=7&t=11238
Link to my ROM (in RAM) Reset Patch post viewtopic.php?f=7&t=11230
Correcting the faults and problems with Dragondos v1.0
Dragon User, May 1985
The patches in this publication have been updated by Steve Evans (Zephyr) with corrections provided by Philip Scott in the July 1985 edition of Dragon User magazine.
P G Scott solves the problems that face unwary users of Dragon DOS.
For some time it has been known that there are a number of faults and problems associated with DRAGONDOS 1.0, over and above the documentation. This article is intended to identify and highlight most of these problems and propose solutions (which have been running successfully on my own system). While l do not advocate "patching" object code, in this instance, without the source, there is no alternative.
The rest of the article has been separated into three areas:
Faults, where the system performs erroneously and it is not possible to overcome the error without manual interaction,
Problems, where it is possible to program around the problem or there is need of infomation not provided in the manual, and lack of information, where facilities exist that are not documented.
In what follows, a single sentence description of the error is given followed by amplification of the cause and effects of the error together with a simple test, if applicable, and a patch to correct the error.
Within the patches, the format is:
+xxxx yy zz
Where +xxxx is the location address in the EPROM and corresponds to run-time address &HC000+&Hxxxx and yy zz are the Hex values to be programmed into consecutive locations.
FAULTS
Fault 1: USR09 address is corrupted and Drive 4 is not set to "unused" at RESET.
These two faults have no apparent link, but are actually caused by a single erroneous byte in the RESET initialisation sequence. As a result of the error. any attempt to use the USR09 function before setting the address will cause program corruption rather than ?FC error, while a change of disk format (from single sided to double sided for example) will not be detected for drive 4, but will be for the other drives (see hints).
It is possible to issue commands to cancel this fault, but it requires the sequence:
POKE &H69A,0 : DEF USR9=&H8B8D to be obeyed after EVERY reset.
Test: A=USR09(A)
Patch: +00BF 97
Fault 2: System "hangs" if in graphics mode and drive not ready.
This error occurs because the system tests for graphics mode (for some unknown reason) and, if set, waits for an interrupt which cannot occur. This can be avoided by ensuring a disk is always available when in graphics mode.
Test: SCREEN 1,1 :DIR
Patch: +02EB 21
+0316 21
Fault 3: Directory track 18 update faiIure - results are not predictable.
After writing to disk, directory track 16 has to be updated to match track 20. The effect of this fault is that a failure while reading track 20 or writing track 16 will cause the processor to return to a random address as the stack is not reset properly. This can only be fully overcome by applying the specified patch.
Test: POKE &H6AB,1 : EXEC &HC734
with a) no disk, and b) disk write protected
Patch: +0771 26 21
+0793 5F 32 48
+07A8 32 48
Fault 4: Track 19 sector 38 is corrupted when files are killed.
This fault is only encountered when using double-sided 80 track disks. Directory sectors 1 and 2 contain a "bit map" showing whether a disk sector is in use or free. When a file using sectors on tracks 40 to 79 is "KILLed", the sectors allocated to it are returned for re-use, but track 19 sector 36 is written instead of track 20 sector 2. This can only be corrected by applying the patch.
Test: DIR : CREATE "FILE",400000 : KlLL "FILE.DAT" : DlR
Patch: +1027 21
Fault 5: Filename validation exits to the BASIC error routine.
This error only affects machine code users, as calling the file specification validation routine will exit to BASIC If a ?DN error occurs, instead of returning the error code in the B accumulator (the method of using this and the other 17 routines available to machine code users will need to be the subject of a later article). This is only correctable by applying the patch.
Patch: +0802 23 04 81 04 23 04 C6 28 39 12
Fault 6: BASIC file protection and rename routines addressed instead of the machine code routines.
This error only affects machine code users, as the routines referenced in DRAGONDOS 1.0 use the "character getter" routine at &H9F to get a file specification and return to BASIC if a file protection or rename error occurs. The routines that are called by the BASIC commands which should be called from machine code can be used after applying the patch.
Patch: +001C D0 9D D0
Fault 7: Errors in freeing a disk buffer cause random effects.
As there are only four disk buffers available, accessing more than four files requires these buffers to be re-allocated.
This fault occurs when writing to a file to free a disk buffer for re-use. If a failure occurs, the stack is not reset properly and
the command returns to a random address. Only patching the EPROM will correct the fault.
Patch: +1297 27 02 E7 61
Fault 8: Only five files may be opened by a BASIC program.
The manual states that 10 files may be open at one time, clearly in conflict with the actual situation.
It is caused by allocating file control blocks to ".BAK" files (whether a ".BAK" file is created or not) and not freeing them when no longer required. Without a re-write of DOS, it is not possible to totally eliminate this fault, but the patch described will allow 10 files to be referenced (note that "KILLing" or "PROTECTing" a file counts as a file reference, while "CREATEing" a file with backup counts as two file references).This patch also has the effect of removing one carriage return from the end of the DRAGONDOS sign-on message, in order to gain sufficient space in the EPROM.
Test: FOR l=1 To 10 : PRINT l : CREATE "FILE"+CHR$(64+I) : NEXT I
Patch: +0F3C 6D 03
+0F45 27 0A
+0F4F 30 0C 6F 14 BD DF CA 27 11
+1FC9 00 B6 06 7D 6D 9F 06 78 39
Fault 9: CLOSE always closes all files.
This fault also contradicts the manual. Indeed CLOSE #-1 closes all disk files as well as the cassette file.
The facility for selective closure was partially programmed and never implemented, however.
Patch a (which requires correction of problem 2 first) will permit the CLOSE command to operate as described in the manual. ln addition, the patch uses &HF7 as a control and if this is set to a non-zero value the patch will close the last file referenced, provided CLOSE has a parameter in the range 1 to 4. Patch b ensures that CLOSE operates as described in the manual after a reset or "DSKINIT".
The suggested method of closing individual files is as follows. Use POKE &HF7,1 to turn on the facility (and POKE &HF7,0 to turn it off), then in the enabled state use:
CLOSE EOF ("file1"),EOF("file2") to close the files only when the end of file is reached (CLOSE 0 is ignored), or CLOSE 1+EOF ("file1"),1 +EOF("fiIe2") to close the files independent of the EOF condition (note that more than one parameter may be specified with CLOSE).
The use of EOF here ensures that the required file is the last accessed. This method has to be used as CLOSE will only accept numeric parameters.
Test: FREAD "FILE";A$ : PRINT A$ : CLOSE #-1 : FREAD "FILE", A$ : PRINT A$
Patch a:
Correct problem 2
+0EBC 09
+16FC 09
+170B 5D 2F FC 0F 6F 32 62 0D F7 26 0A
+1720 BD CE D3 20 F6
+1EA3 D6 FB D7 oB
Patch b:
+00C0 DC 8A ED 84 ED 02 DD F6
+00D4 12 12
Fault 10: Disk motor control assumes DP set to zero.
This fault affects machine code users, where use is made of direct pages other than page zero. The motor countdown routine assumes that the Direct Page register is set to zero for tests on the flag, and can cause data or disk corruption if it is not set to zero.
Patch: +0700 20 22
+71E 20 0D
+724 34 04 4F 1F 8B 0D F6 20 D5 35 04 7E 9D 3D
===================================================================================================
PROBLEMS
Problem 1: LOC/LOF/FREE functions sometimes return a negative value.
All three functions use the same routine to convert a 24 bit integer to BASIC numeric format. Because the sign is not cleared, this routine returns a value with the sign of the value calculated immediately before calling the function.
It can be corrected by applying the patch supplied or using the ABS function to ensure a positive value is returned.
Test: PRINT #-2,FREE or I=-1 : PRINT FREE
Patch: +1D94 12 5F
+1D98 DD 53
+1D9E DD
Problem 2: INPUT/LINEINPUT cause all disk files to be closed.
lf you have tried writing a simple file edit program, you will have met this problem. It is caused by the need to ensure all files are closed at the end of a program. The problem can be overcome by using LOC and FREAD FROM to reset the read pointers (FWRITE does not suffer from this problem), or by applying the patch to correct problem 1 above and then applying patch a.
Alternatively, without applying the problem 1 patch, memory can be reserved (from &H7FEF for example) containing patch b and the hook vector changed by using: POKE &H182,&H39 : POKE &H184,&HEF : POKE &H183,&H7F : POKE &H182,&H7E
This patch is position independent, so can be put anywhere in memory, provided locations &H183/4 are set accordingly.
This change will remain effective until a cold start occurs.
Test: FREAD "FlLE",A$ : PRINT A$ : INPUT B$ : FREAD "FILE",A$ : PRINT A$
Patch a:
Correct problem 1
+1AB7 BD DD 95 7E 95 82 34 56 8E 83 7D AC 68 26
+1AC5 05 BD D6 FB 20 5E 35 D6
+1EAD DA BD
Patch b:
+7FEF 34 56 8E 83 7D AC 68 26 06 BD D6 FB 7E DB 29 35 D6
Problem 3: "SAVE" can create a file entry which cannot be "KILLed".
This is an avoidable problem, but can occur if ENTER is hit instead of -. The remedy is to alter the directory entry for the file (by using SREAD and SWRITE) to a name that will allow the file to be killed. The altemative of marking the directory entry as killed is not recommended as this does not return any sectors allocated to the file. The patch listed rejects a null file specification as ?FS error.
Test: SAVE ""
Patch: +07BE 7E DF F3
+1FF3 5D 26 03 C6 96 39 B6 06 0A 7E C7 C1
Problem 4: Files "KILLed" within a program are left open, causing data written immediately after "KILL" to be lost.
This problem can be overcome by inserting extra program statements around the "KILL" either to create a zero length file for the same name before or after "KlLL" (provided a ".BAK" file does not exist that is still required. as this action causes the ".BAK" file to be killed), or to close all files after "KlLL" is used (remembering to retain any input file pointers through LOC).
Alternatively, the patch listed can be applied (after correction problem 2 above). This patch also prevents sectors being "lost" due to a ?PE error occuring when attempting to write to a zero length file after it is "KlLLed" in a program. It also returns the file control block for re-use on completion of the "KILL" command (see also fault 8).
Test: A$="FILE.DAT" : FWRITE A$,"TEST" : KILL A$ : FWRITE A$ : "NEXT LINE"
Patch:
Correct problem 2
+1720 BD CE D3 20 F6
+177C 27 A2
+1795 20 E5 12
+17BF 20 BB 12
Problem 5: Drives (other than drive 1) incorrectly assumed to be restored to track zero at first access.
With this problem, the first drive access after startup assumes the head is at track zero and steps on 20 tracks to read the disk format from the directory, then corrects by issuing a restore and stepping correctly to track 20. This can cause the drive to attempt to step beyond its last track. The patch described restores the drive to track 0 the first time it is accessed after startup.
In order to insert this patch, some reset features have been changed - Drive 1 no longer restores to track zero at switch on, the copyright and DRAGONDOS messages all remain on screen and the system becomes ready more quickly.
Test: DIR 2
Patch: +009E 8E DF BA BD 90 E5 7E 83 71 A7 C8 10 6D 44 26 07
+00AE BD C1 65 24 02 32 62 39
+1197 BD C0 A7