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

VERIFY

Keyword Abbreviation Token (hex) Version(s) Classification
VERIFY V{Shift+E} 95 1.0 to 7.0 Command and Statement

  Syntax   
VERIFY [ fileName [ , deviceNumber  [  , flags ] ] ]
 
Parameters Type Legal Value(s) Default Value Note(s)
fileName String
0 ~ 255 (cassette)
1 ~ 255 (serial bus)
empty string For a disk drive (serial bus) length is generally limited to 16 characters.
deviceNumber Unsigned Byte  1, 2, 4 ~ 255 
1 or 2 for cassette (machine specific).
4 ~ 30 for IEEE or serial bus (IEC).
flags Unsigned Byte 0 ~ 255 
Any even number loads the data to the BASIC's start-of-text.
Any odd number loads the data to the location specified by the first 2 bytes of the file. 
 
 
  Purpose  
Compare the data in a "file" with computer "memory" (and report any error).
 
  Remarks  
For deviceNumber of 4 or greater, the fileName must be one or more characters long or a MISSING FILE NAME ERROR occurs.  Generally only mass-storage devices like disk-drives will work correctly (for example, VERIFYing from a printer usually doesn't work).  Most devices that do support VERIFY generally limit the filename to 16 characters, although the fileName parameter might be longer to allow for additional parameters (such as drive or partition number).
 
For a cassette, the KERNAL will print PRESS PLAY ON TAPE if no buttons are detected as pressed.  For a cassette, fileName is optional.  If not specified, the KERNAL will pause for each program file it finds and report FOUND fileName, at which point the user may press the C= key to verify that file or press the spacebar (or wait a few seconds) to continue searching for a file.  If the fileName is longer than 187 characters, only (!) the first 187 characters will be tested.
 
Most CBM machines allow only 1 cassette in which case specifiying a deviceNumber of 2 will generate ILLEGAL DEVICE NUMBER.  Some modified CBMs (in particular those with JiffyDOS) will give the same error with a deviceNumber of 1 as well.  The same error is generated if a deviceNumber of 0 (keyboard) or 3 (screen) is requested.
 
Otherwise, an ILLEGAL QUANTITY ERROR is generated if either the deviceNumber or flags is less than 0 or greater than 255.
 
If an error has not happened yet, and BASIC is not running a program, the KERNAL will print SEARCHING FOR fileName or simply SEARCHING, depending wether or not the length of the  fileName parameter is greater than zero.
 
Now, if the deviceNumber mod 32 is 31 or greater, the KERNAL will hang the system.  Otherwise, if the deviceNumber is greater or equal to 4 and deviceNumber mod 32 does not respond on the IEEE/IEC bus (withing about 1 millisecond) then a DEVICE NOT PRESENT ERROR occurs.
 
If the an end-of-tape marker is found (cassette) or the IEEE/IEC device does not return a two-byte start address, then a FILE NOT FOUND ERROR is generated.
 
Next, if a program is not running, the message VERIFYING is displayed.  If the flags is an even number, the file will be tested starting at BASIC's start-of-text address (a program that needs any re-linking changes will fail the VERIFY).  If the flags is an odd number, the file will be tested starting at the memory address stored at the beginning of the file (generally, the address it was saved from).
 
While testing the file data, device-specific errors may occur.  For cassette this is generally an unrecoverable parity error, and a VERIFY ERROR will be generated.  For most IEEE/IEC devices there is no error reported, the system just appears to hange until the user presses the STOP key.  In v7.0, a fast-serial device may generate a VERIFY ERROR without the user needing to press STOP.  If the user presses the STOP key while the file is being tested, a BREAK ERROR is generated.
 
On the C128, the KERNAL will abort loading if the next address to be verified after reading a byte from the device would be 65280 (FF00 hexadecimal), and BASIC will report OUT OF MEMORY ERROR.  No other checks on the address are performed on any CBM machine (that I know about).  Thus verifying beyond the "top-of-memory" or past the 64K limit or the CPU stack or the I/O registers is possible (I/O registers and the CPU stack is volitile and will typically fail verification).
 
No production versions of CBM BASIC include BVERIFY, so the only "official" way to verify a machine-language program or raw data with memory (we'll call this a non-BASIC file) is with the VERIFY command and with an odd-numbered flags value.  The un-official way would be calling the KERNAL with SYS.
 
If the "file" data does not match the bytes in computer memory, then VERIFY ERROR is generated.  If verification succeeds, and a program is not running, the word OK is printed.
 
Examples:
VERIFY         : REM any 'BASIC' program file on cassette
VERIFY "",1    : REM any 'BASIC' program file on cassette
VERIFY "*",8   : REM (typically) the first 'BASIC' program on a disk
VERIFY "*",8,1 : REM (typically) the first 'ML' program on a disk
 
For an IEEE/IEC device, the fileName may include device-specific parameters in addition to the "real filename".  Examples:
VERIFY "1:MYFILE",8 : REM read "MYFILE" from drive/partition 1 on device 8
VERIFY "/MYDIR/:MYFILE",8 : REM read "MYFILE" from "MYDIR" on device 8 (default drive/partition)
VERIFY "MYFILE,S",8,1   : REM read a SEQ-type file as a non-BASIC file
Note the last example will fail on the C128 when used with most fast-serial devices (at least the 1571 [in 1571 mode] and 1581), assuming the program is stored on disk as SEQ-type file.  If there happens to be a normal PRG-type file on the disk (in which case it is probably the wrong file), the last example would "succeed" on the C128.  This is due to a bug in the 1571 ROM which was duplicated in the 1581.  My fast-serial upgrade for uIEC does not suffer this problem.  Behavior of CMD devices is not yet tested by me.
 
  Compare With  
 
  Contrast With  
  See Also  
BSAVESAVE
© H2Obsession, 2014
Comments