Commodore‎ > ‎BASIC‎ > ‎Keywords‎ > ‎

DVERIFY

Keyword Abbreviation Token (hex) Version(s) Classification
DVERIFY D{Shift+V} FE 14 7.0 Command and Statement

  Syntax   
DVERIFY fileName [ , D driveNumber ] [ { , | ON } U unitNumber ] ... [ , ItwoChar ] [ , R ] ...
 
Parameters Type Legal Value(s) Default Value Note(s)
fileName String  1~16 characters    Non-literal must be enclosed in parentheses () 
driveNumber Integer  0 or 1  Non-literal must be enclosed in parentheses ()
unitNumber Integer  8 ~ 11  Non-literal must be enclosed in parentheses () 
twoChar Char[2]  any    Must be two literal characters. 
 
 
  Purpose  
File data verification.  Compare a BASIC program in a "disk" file with the one in memory.

 
  Remarks  
DVERIFY is used to check that the BASIC program in RAM has been correctly stored to a device on the IEEE/IEC bus.  The device is identified by unitNumber (default 8) and is typically a disk drive or other mass-storage device.  Although values 0 to 30 are valid for an IEEE/IEC device number, DVERIFY limits unitNumber to the range 8 to 11 (CBM disk drives typically use values in this range).  Note the unitNumber may be given more than once; only the last one is actually used.
 
Some devices may support more than one physical disk (typically floppy disks) or allow multiple partitions on the same disk (typically a hard drive).  These multiple "disks" on the same device are identified by a driveNumber (default 0).  Although several mass-storage devices allow driveNumber to range from 0 to 255, DVERIFY limits the value to either 0 or 1.  Several of the most popular CBM disk devices (1541, 1551, 1571, and 1581) only allow 0.  Note that 1581 partitions are not selected by driveNumber.
 
The fileName is required; it specifies the name of the "disk" file to be tested.  If the fileName has more than 16 characters then STRING TO LONG ERROR will be generated.  If the fileName has zero characters then MISSING FILE NAME ERROR occurs.  The fileName may include wild-card characters like ? and *.  If the fileName begins with an @ character, SYNTAX ERROR occurs.  If the fileName is a single asterisk (*) then most devices will read from the last-referenced fileName (used with that device) or the first file in its directory if no files have been accessed since the device was powered-on or a media change (disk swap) occurred.
 
Most disk devices will only search for PRG files unless fileName ends with ",type" where type is one of the characters "D", "P", "S", or "U" corresponding to DEL, PRG, SEQ, and USR file types respectively.  However there are two problems with this.  The first is the entire fileName string is limited to 16 characters so adding these 2 characters will cause an error if the "real" file name is 15 or 16 characters in length.  Another problem is a bug in the 1571 and 1581 (maybe some CMD devices) which will ignore the ",type" when used with a host computer using fast-serial bus protocol (typically only the C128, but possible with a hacked C64).
 
If a required parameter is omitted, or an expression (enclosed in parentheses) is not valid, or an expression is used without parentheses, SYNTAX ERROR occurs.  If any parameter is not the correct type (string or numeric) a TYPE MISMATCH ERROR will be generated.  Otherwise if a parameter is not a legal value (see table above), an ILLEGAL QUANTITY ERROR is usually generated (except the previosuly described fileName).
 
Like all disk commands and statements, the Syntax is more flexible than shown above.  In particular, the parameters may be given in any order.  The general restrictions are: a comma (,) must not precede the first parameter (the ON presposition may), any non-literal value (a variable name or expression) must be enclosed in parentheses (), and do not supply the same parameter more than once.  Exceptions include the U and R parameters, which may used an unlimited number of times (the R parameter is ignored), and the twoChar parameter which must always be two literal characters (for DLOAD, it is ignored too, but it may not be repeated).
 
Now we'll assume the Syntax is correct.  In direct mode, the message SEARCHING FOR driveNumber:fileName will be printed.  No message is printed when a program is running.
 
If the fileName does not exist, BASIC will generate FILE NOT FOUND ERROR (a similar message reported by the device will be read into DS$).  Otherwise the first two bytes of the file will be read an discarded (the starting address from which it was saved).  The secret variable loadAddress will be set, instead, to the value of another secret variable, "Start of BASIC".  The variable ST is set to zero.  Next, in direct mode, the message VERIFYING will be printed.  No message is printed when a program is running.
 
Internally, each byte read from the file is compared with the one in memory at loadAddress.  If they do not match, bit 4 (value 16) of ST is set.  Regardless, the loadAddress is incremented after every byte is read from the file.  On the C128, if the new value ever reaches the MMU register at 65280 ($ff00 hexadecimal) then verification stops and OUT OF MEMORY ERROR occurs.  The import (well strange) thing to note is the process does not stop when a mis-match is discovered.
 
On most systems, errors generated by the device while trying to read the file will cause BASIC to "freeze" until the user manually presses STOP at which point BREAK ERROR (or STOP KEY DETECTED) would be generated.  On the C128, however, fast-serial devices can report an error to the computer without this kludgy "freeze".  In this case BASIC will continue like nothing was wrong!  In either case, you can then get the specific error from the device with DS or DS$.
 
Now we'll assume all the file data was compared with RAM.  DVERIFY will now check bit 4 of ST.  If it is set, VERIFY ERROR occurs.  Otherwise, if a program is not running, the word OK is printed.  In particular, no other bits of ST or the value of DS/DS$ are considered.  Also the final loadAddress is not tested to be sure it is equal to the current "End of Program" or "Start of Variables" (for machines with more than 64K RAM or less, respectively).  This means an incomplete/partial save will be reported as OK.
 
Another important thing to consider is the program should be verified immediately after it is saved.  If the program in memory has been relocated (relative to the one on disk) then an error will be reported even if the BASIC program is "the same".  This is due to changes to internal line links.  For example, if you save a program to disk on the C64 then use a C128 (in 128 mode) to load the program then BASIC will need to re-link the program for the correct start address of the C128.  Now if you use DVERIFY without changing anything in the program you will get VERIFY ERROR even though the program is "the same" as the one on disk.  A similar thing occurs if you use GRAPHIC to allocate or de-allocate a bitmap: the BASIC program will get shifted in memory and relinked, once again resulting in a "false" VERIFY ERROR.
 
Fortunately, DVERIFY does not mess with any of the secret variables that control variables or perform CLR, like the similar (D)LOAD.
 
Like all disk-based commands, DVERIFY restricts the driveNumber to 0 or 1 which often makes it unusable on a "disk" with multiple partitions.  Like all disk-based commands, DVERIFY restricts the fileName to no more than 16 characters which makes it nearly useless if you want to include a path.
 
Like all disk-based commands, DVERIFY will reset DS$ and set the secret variable "DosFA" to the unitNumber.
 
Examples:
DVERIFY "PROGRAM"     : REM disk unit 8, drive 0
DVERIFY "PROGRAM", U9 : REM unit 9, drive 0
DVERIFY "PROGRAM", D1 : REM unit 8, drive 1
DVERIFY (N$),U(U)     : REM use variables for fileName and unitNumber
 
 
  Compare With  
 
  Contrast With  
  See Also  
DS, DS$, ONST 
© H2Obsession, 2014
Comments