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


Keyword Abbreviation Token (hex) Version(s) Classification
BOOT B{Shift+O} FE 1B 7.0 Command and Statement

BOOT [ fileName ] [ , D driveNumber ] [ { , | ON } U unitNumber ] ... [ , loadAddress ] [ { , | ON loadBank ] [ , 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 () 
loadAddress Unsigned Integer  0 ~ 65535  from first 2 bytes of file  Non-literal must be enclosed in parentheses ().
Ignored if fileName is omitted.
loadBank Unsigned Byte 0 to 15  most recent BANK  Non-literal must be enclosed in parentheses ().
Ignored if fileName is omitted.
twoChar Char[2]  any    Must be two literal characters; ignored
Run a machine language program (which may launch a BASIC program).

BOOT is used to start a machine-language program stored on "disk device" (unitNumber 8 to 11).  Without a fileName it will call the KERNAL Boot routine which reads track 1 sector 0 (the first block on a CBM disk) into BANK 0 address 2816~3071 ($B00).  Without a filename, any loadAddress or loadBank will be ignored.  Eventually machine-language code located somewhere in the region will be executed (which can do anything, like start a BASIC program); see the Commodore 128 Programmer's Reference Guide for details of the boot sector.
If the fileName is omitted, then the KERNAL will print BOOTING message if a valid boot sector was found (the message is stored somewhere in the boot sector); this happens regardless of BASIC running any program.  If no valid boot sector was found, BASIC will continue without error.  There may be an error available from the device by checking DS$.  If a valid boot sector was found, control will usually not return to BASIC.  Consult the documentation for a specific boot sector to see what happens if it does return to BASIC.
With a fileName, BASIC will BLOAD the file and then, in theory, SYS to the loadAddress.  In the original C128 ROMs (start-up message says copyright 1985) there is a bug with slow-serial devices which causes the default loadAddress to never be set.  You should specify a loadAddress to avoid this bug (other possibilities would be some guarantee the C128 has updated ROMs or the device uses fast-serial).
The nice thing about BOOT is you can run a machine-language program as easily as a BASIC program (assuming you aren't afflicted with buggy ROMs).  Unfortunately, BOOT doesn't work with cassette!  In fact it only works with devices (unitNumber) 8 to 11.
If the fileName has more than 16 characters then STRING TO LONG ERROR will be generated instead.  If the fileName has zero characters then MISSING FILE NAME ERROR occurs (this is not the same as completely omitting the fileName parameter).  The fileName may include wild-card characters like ? and *.  If the fileName begins with an @ character, SYNTAX ERROR occurs.
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" filename 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".
If a fileName is given, and BASIC is 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, in direct mode, the message LOADING will be printed.  No message is printed when a program is running.
Errors generated by most slow-serial devices while trying to load the file will cause BASIC to "freeze" until the user manually presses STOP at which point BREAK ERROR would be generated.  Fast-serial devices can report an error to the computer without this kludgy "freeze".  In this case BASIC will report FILE DATA ERROR.  In either case, you can then get the specific error from the device with DS or DS$.
If a fileName is given, then internally 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 OUT OF MEMORY ERROR is generated and the operation aborts (leaving special internal drive channel open; use DCLEAR or read DS$ to clear this condition).  There are many other addresses that could be reached while loading that could cause the system to "crash" in one way or another.  If everything goes okay, BASIC will finish by SYS'ing to the (presumably correct) initial loadAddress to begin the machine-language program.  The ML-program can do whatever it wants to the system.  It may not return to BASIC, if it does return, and BASIC was running a program, the program should continue (consult the documentation for your specific program).  Once (if) BASIC regains control, you may be able to find out the ML-program's loadAddress and endAddress + 1 by PEEK'ing some secret variables (assuming the ML-program didn't change them).
Unlike the similar LOAD and DLOAD commands and statements, BOOT does not cause a running program to re-start from the first line number after the load completes; internal BASIC pointers (i.e., secret variables) are not updated either (by BASIC... the ML-program can do whatever it wants).
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).
Any omitted parameter will take the default value shown above; in particular, unitNumber 8, driveNumber 0.  The default bankValue will be the value used in the last BANK command/statement... not the last bankValue used in a prior disk-command.
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 (R is ignored and the last unitNumber is used), and the twoChar parameter which must always be two literal characters (it is ignored too, but it may not be repeated).
Like all disk-based commands, BOOT restricts the driveNumber to 0 or 1 which often makes it unusable on a "disk" with multiple partitions.  Like all disk-based commands, BOOT 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, BOOT will reset DS$ and set the secret variable "DosFA" to the unitNumber.  It also indirectly updates ST.
BOOT : REM load and execute code from boot sector of unit 8, drive 0
BOOT ON U9 : REM the same, but unit 9
BOOT "PROGRAM.BIN", P 4864, B0 : REM load file to address 4864, bank 0 from unit 8 drive 0
BOOT (N$),U(U) : REM use variables for fileName and unitNumber (hope the ROMs are good)
  Compare With  
  Contrast With  
  See Also  
© H2Obsession, 2014