Bob's Blog

bB's bankswitching uses a similar concept, but yours is easier for asm work (with the indexed indirect stuff.) I see a couple ways to improve it (I think, I could be wrong...)

  brk
 .word Subroutine-1

...

 plp
 tsx
 inx
; dec $00,X - not needed due to above
 lda ($00, X)
 sta MiscPtr
 inc $00,X
 lda ($00,X)
 sta MiscPtr+1
 lsr
 lsr
 lsr
 lsr
 lsr
 tax
 nop $1FF4,X

...

ReturnFromBSSubroutine
 tsx
 lda 2,X     ;get high byte of return address
 lsr
 lsr
 lsr
 lsr
 lsr
 tax
 nop $1FF2,X

 

That said, I know that bB's BS method could use some improvement too! I have been meaning to check to see if indexed indirect used fewer cycles, but I've been too lazy to count them.

EDIT: Cut out my stupidity.

 

EDIT II: Ok, complete edit now. I now see what you are doing.

 

That is nice, would save 6 cycles by eliminating the DEC ZP, X instruction, plus save four more on the way back.

 

Just saw - I could cut out the initial INX also and do this...

  ;--BRK vector points here
  plp
  tsx
  lda ($01, X)
  sta MiscPtr
  inc $01, X
  lda ($01, X)
  sta MiscPtr+1
  lsr
  lsr
  lsr
 ;--etc.

The approach using indirect-Y addressing eliminates the bug which could hit if the BRK occurred just before a page boundary, but requires that the stacking address be known. IMHO, the BRK-based approaches are probably overkill unless code space or RAM are really tight (in which case you could generate a table listing all of the calls used by the program--most 2600-sized programs will have fewer than 128 subroutine calls within them). Use two tables--one for MSB/bank and the other for LSB. The BRK sequence would be, basically:

 

-1- Fetch the byte following the BRK instruction

 

-2- Pop all three pushed bytes off the stack and push that byte and that byte+1

 

-3- Jump to the "pseudo-RTS" routine which will pop the top byte from the stack, look it up in the lsb/msb tables, stash it someplace, and indirect-jump there.

 

This would require a little temp. stack space, but that could be easily overlayed with other kernel variables.

 

Otherwise, the approach I use in Strat-O-Gems is to define a macro called HEADERS which is .rorg'ed at the same address in every bank. It looks something like:

RESET:
 nop BANK1
 jmp V_RESET
KERNEL:
 nop BANK2
 jmp V_KERNEL
RTS1:
 nop BANK1
 rts
KERNEL_B3
 nop BANK2
 jsr V_KERNEL
 nop BANK3
 jmp KERNEL_B3_RET

Most routines will always be invoked from the same bank so they can end with a JMP to the appropriate RTS routine. There are sufficiently few cases where a routine is called from a 'funny' bank that I can handle those explicitly (as in the KERNEL_B3 example).

 

A call to another bank takes 6+3+3=12 cycles. A return to another bank takes 3+3+6 (also 12) cycles. An "unusual" call to another bank still takes 12 cycles (3+3+6) but the return takes 12+3+3=18 cycles (the first return goes into the KERNEL_B3 code, which then takes 6 more cycles to reach the proper destination).

 

Not quite as fast as FE-based bank-switching, but more versatile.