PAGECHECK

Issues a warning if current line (i.e. current instruction) is on a different page than the instruction on or following the specified label.

This macro compares the high bytes of the current instruction and that on or following the label. If they don't match, then a build warning is issued (but no other action is taken).

CRITPAGECHECK

Performs the same check as PAGECHECK, but issues a build error and blocks compilation if the check fails.

It uses the CC65 macro ASSERT, see the CC65 docs for more info.

Example:

WaitScanline (Bank F in the original game) uses this macro to guard againstloops crossing a page boundary, which invariably results in catastrophic memory corruption.

The underlined lines in the snippet below indicate the instructions being checked against the current instruction (following each CRITPAGECHECK macro).

The bolded lines (after #Loop and @Reload) are the instructions against which the current instruction's page address is checked.

WaitScanline:
    LDY #16          ; +2 cycles

  @Loop:
    DEY            ;   +2

    BNE @Loop      ;   +3  (5 cycle loop * 16 iterations = 80-1 = 79 cycles for loop)

CRITPAGECHECK @Loop      ; ensure above loop does not cross page boundary

    LDA tmp+2        ; +3
    DEC tmp+2        ; +5
    BNE @NoReload    ; +3 (if no reload -- 2/3)
                     ;   or +2 (if reload -- 1/3)

CRITPAGECHECK @NoReload  ; ensure jump to NoReload does not require jump across page boundary

@Reload:
    LDA #3           ; +2   Both Reload and NoReload use the same
    STA tmp+2        ; +3    amount of cycles.. but Reload reloads tmp+2
    RTS              ; +6    with 3 so that it counts down again

@NoReload:
    LDA #0           ; +2

OP

OP opcode, count

JUMPTO

JUMPTO address

.WORD address

See INBANK below for more detail.

INBANK

INBANK bank_number

.BYTE bank_number

While this isn't part of the original game, that routine is an experimental extension that FFHEX supports. The purpose of LongCall is to allow cross-bank routine calls without needing a lot of boilerplate/setup code at each call site. The pattern looks like this, assuming that this is called from (say) Bank C:

JSR LongCall
JUMPTO SomePriceRelatedRoutineInBankD    ; sets carry if some condition met
INBANK D
... code after the long call, e.g.
BCS @DoThisIfCarryIsSet
...

The JUMPTO and INBANK macros only serve as visual, searchable cues for the LongCall params. Without them, the code would look like this:

JSR LongCall
.WORD SomePriceRelatedRoutineInBankD    ; sets carry if some condition met
.BYTE D
... code after the long call, e.g.
BCS @DoThisIfCarryIsSet
...

LongCall is incredibly useful once you understand the principle and the caveats; read more about it in these posts on the RHDN forums:

The issue with Bank Swapping outside the fixed bank
Description of the LongCall routine