Output from the new Kernel looks OK to me:

Due to the shift in timing, the new KernelEvent is more efficient than before. Before it looked like this:

KernelEvent:                  ; 3 27
        ; have to update PF2 before figuring out which Kernel Event, otherwise
        ; PF2 is updated to late in the Reposition Player 1 routines
        ldx DS_PF2L             ; 4 31
        stx PF2                 ; 3 34 - PF2L, before 38
        sty PF0                 ; 3 37 - PF0R, 28-49
        ASL                     ; 2 39
        BPL CheckRepo1          ; 2 41
        jmp Reposition0         ; 3 44

Now it looks like this:

KernelEvent:                    ; 3 21
        asl                     ; 2 23
        sbpl CheckRepo1         ; 2 25
        ; start of repositon player 0 routine

In the original KernelEvent we needed to do a time-critical update of PF2 without losing the contents of A. So we used LDX DS_PF2L, which takes 4 cycles. The new KernelEvent starts 6 cycles earlier, which lets the update of PF2 happen after we're done using A. This lets us use LDA #<DS_PF2L, which only takes 2 cycles. This increases the odds that the new reposition routines will take fewer scanlines.

The sbpl in the new code is macro that acts just like a bpl, but the macro will trigger an error at compile-time if the branch ends up going to a different page. This is to prevent problems later in development when added code could cause a shift in memory that results in the branch crossing a page. On the 6507 a branch taken will use 3 cycles, unless it cross a page at which point it will use 4 cycles. Timing is so critical in Frantic that an unexpected extra cycle would cause the display to become corrupt. If you'd like to use these macros in your own project just copy macro.h from the source file. Same page Branch macros exist for all the branch commands, as well as Different page Branch macros for when a branch needs to use an extra cycle of time when taken.

In a PM conversation with ScumSoft, he mentioned using incbin to automatically include the DPC+ driver. Doing so would turn a two step compile of:

dasm frantic.asm -f3 -v0 -sfrantic.sym -lfrantic.lst -of.bin
cat DPC+.arm f.bin > frantic.bin

to just one step:

dasm frantic.asm -f3 -v0 -sfrantic.sym -lfrantic.lst -ofrantic.bin

I stuck a note in the source about it, but forgot to follow up with him on how he did it. So I figured out how to do it myself. I changed this:

        SEG CODE
        ORG $0000
        
        ; include the custom ARM code.  This must be compiled before compiling
        ; the 6507 code by executing the MAKE command in the custom directory.
        INCBIN custom/bin/custom2.bin     

to this:

        SEG CODE
        ORG $0000
        
        ; include the Harmony/Melody driver so we don't have to merge it later
HM_DRIVER                INCBIN DPC+.arm

	; all following ORGs need to compensate for the driver size
HM_DRIVER_SIZE = * - HM_DRIVER

        ORG $0000 + HM_DRIVER_SIZE
        RORG $0000
        
        ; include the custom ARM code.  This must be compiled before compiling
        ; the 6507 code by executing the MAKE command in the custom directory.
        
        INCBIN custom/bin/custom2.bin   

and all following ORG statements were changed as well, so the ORG for bank 5:

ORG $5000        RORG $F000

became this:

        ORG $5000 + HM_DRIVER_SIZE
        RORG $F000

I use HM_DRIVER instead of DPC_DRIVER as I figured this logic could be used in the future for any Harmony/Melody driver, such as a bus-stuffing driver that I hope we can figure out for Timmy. I also set it up to calculate the size of the driver on its own in case the future drivers aren't 3K in size.

ROM

frantic_20140122.bin

Source

Frantic20140122.zip