One of the easiest methods, is to modify the error printing routine, to do our processing instead. So what you want to do is create BASIC commands that would ordinarily cause an error, have the error print routine check if its our new command. If so, handle it..if not, continue with the error processing. Here's how:

  cea4    lda $0300 ; get the lo-byte addr of the error routine
          sta $cexx ; store it somewhere for later processing
          lda $0301 ; get the hi-byte addr of the error routine
          sta $cexy ; store it somwhere + 1
          lda #$bb  ; put the new handler lo-byte in its place
          sta $0300 ; store it at the error vector
          lda #$ce  ; put the new handler hi-byte in its place
          sta $0301 ; store it at the error vector
           rts      ; done changing the vector
  cebb    ... start new handler code here

$E38B is the normal ROM error routine, so you will want to JMP here if the error is not of the type you want.

How Do I Know What Error Im Looking For?

When your code is called, the X register will contain the ID of the error, so the first thing you want to do is compare it to make sure its the error you want.

  cebb    cpx #$11    ; is it 17 (Undefined statement error)
      beq $cec9
      cpx #$0B        ; is it 11 (syntax error)
      bne $cec6       ; go to normal error processing
      jmp $cfc6       ; unknown
  cec6    jmp $e38b   ; go to normal error processing
  cec9    ...

Why Are We Looking for $11?

11, or $0B represents to the error handler that this is a syntax error. In the normal error handling routine at $E38B, this value is multiplied by two, and then this becomes a pointer offset of the 2 byte message, starting at $A326. The routine takes this value (11×2=22), adds it to $A326 (start of basic error message address table), which equals $A33C ($A326+$16). The value at $A33C and $A33C+1 is $35 and $A2… you guessed it - the actual ASCII error message for “syntax error” starts at $A235. If you're thinking all sorts of weird addressing modes, you're right! Now you see why you should learn them!

The undefined statement error in the fist cpx is from a BASIC Labels code addition that lets you add BASIC labels to programs. That particular code also should check for this error message as well. Here are some other bytes you might need to check for:

  1 - Too many files
  2 - File open
  3 - File not open
  4 - File not found
  5 - Device not present
  6 - Not input file
  7 - Not output file
  8 - Missing file name
  9 - Illegal Device Number
  10 - Next Without For
  11 - Syntax
  12 - Return without Gosub
  13 - Out of Data
  14 - Illegal Quanity
  15 - Overflow
  16 - Out of Memory
  17 - Undefd Statement
  18 - Bad subscript
  19 - Redimd Array
  20 - Division by zero
  21 - Illegal Direct
  22 - Type mismatch
  23 - String too long
  24 - File dat
  25 - Forumla too Complex
  26 - Cant Continue
  27 - Undefd Function
  28 - Verify
  29 - Load

The thing to remember is that if its not the error you are looking for, be sure to pass it in the X register before you return to the normal error handling processor, so that it can pick up from there.

The next thing is to check the current BASIC line for the character that caused the error. In our new imaginary BASIC commands, we are adding a new command set that starts with a '!'. Any command that starts with this character is ours and we should attempt to handle it. But with great power, comes great responsibility. Not only do we have to look for our commands, but we also need to handle errors gracefully as well - essentially setting the appropriate error ID, as above, if the command is not valid for some reason.

Alternate Approach:

This approach hooks into the error handling routine of the 64 to add new commands to BASIC. There are other ways, however. One way, found in the August 1983 edition of Compute!s Gazette, is to copy the BASIC ROM to RAM, and then modify the lookup table for relatively unused keywords, and change their entry points to your own routines.