The Southsider

I don't know how others did it, but here's what I did. I created 2 macros, JUMP_TABLE and BANKS_AND_VECTORS that go in every bank.

 

	MAC JUMP_TABLE; put this at the start of every bank
RORG $F000
InitSystem
cmp SelectBank1 ; inits system then goes to the menu
jmp InitSystemCode
VerticalBlankMenu
cmp SelectBank2
jmp VerticalBlankMenuCode
VerticalBlankGame
cmp SelectBank3
jmp VerticalBlankGameCode
KernelGame
cmp SelectBank4  ; draws score, top castles, dragons
jmp KernelGameCode
KernelGameBottom
cmp SelectBank1  ; draws bottom castles
jmp KernelGameBottomCode
OverscanMenu2		; Menu Entry Point if user hits SELECT 
cmp SelectBank2 ; or RESET during a game
jmp OverscanMenu2Code
OverscanGame
cmp SelectBank3
jmp OverscanGameCode
ENDM

MAC BANKS_AND_VECTORS; put this at the end of every bank
RORG $FFF6
SelectBank1 .byte $00 
SelectBank2 .byte $00 
SelectBank3 .byte $00 
SelectBank4 .byte $00
.word InitSystem; NMI
.word InitSystem; RESET
.word InitSystem; IRQ
ENDM

 

The macros are then used in the source like this:

 

; BANK 1 starts here
  ORG $C000
  JUMP_TABLE

;   code for Bank 1 goes here

  ORG $CFF6
  BANKS_AND_VECTORS
; BANK 1 ends here



; code for Bank 2
  ORG $D000
  JUMP_TABLE

; bank 2 starts here

  ORG $DFF6
  BANKS_AND_VECTORS
; BANK 2 ends here

; BANK 3 starts here
  ORG $E000
  JUMP_TABLE

;   code for Bank 3 goes here

  ORG $EFF6
  BANKS_AND_VECTORS
; BANK 3 ends here



; Bank 4 starts here
  ORG $F000
  JUMP_TABLE

; code for bank 4 goes here

  ORG $FFF6
  BANKS_AND_VECTORS
; bank 4 ends here

 

For an 8K game, remove the SelectBank3 and SelectBank4 lines from the BANKS_AND_VECTORS macro, then change all xFF6 to xFF8.

 

You're more than welcome to download the source for Medieval Mayhem, it's in my blog.

It looks like the explosions are playing a little... strange. They're going both forwards and backwards. But it's my fault.

 

I think it stems from the animated GIF I sent, which showed them running both forwards (exploding) and backwards (materializing). I did that because I was too lazy to break them into separate GIFs.

 

The explosions should just explode outward, starting from a different frame, depending on the size of whatever is blowing up.

 

Small ship:

Medium ship:

Big ship:

 

If you don't want the smaller explosions to end as large as the big ones, then you'd just need to stop them a frame or two sooner.

 

Besides that, it's coming along nicely. Blowing stuff up is fun.

 

As an aside... this kernel has the potential in it for a pretty decent racing game. Just flying along dodging ships is pretty cool, all by itself.

 

Question - will the engine flames fit into the kernel? I've been looking forward to seeing those.

Regarding 8K binaries:

 

My advice is to plan exactly what will go in each bank ahead of time because that will determine how you switch between them.

 

As for templates...it's pretty easy: after every ORG $wxyz statement put a RORG $Fwxyz statement and start your binary at $E000 instead of $F000. Or put your binary at $1000-$2FFF, however you want to do it. Then make sure to put start vectors in both 4K banks and remember that when you switch banks you immediately jump to the other bank but the PC stays the same.

 

Switching between the banks is the tricky part; I am unaware of any "standard" method. I've used different methods for Go Fish!, Reindeer Rescue, and Metroid. The most general was for Metroid but that is definitely overkill for an 8K binary (probably overkill for a 32K, for that matter ), the sloppiest was for Reindeer Rescue.

 

EDIT: By "tricky" I don't mean it is difficult or anything, it just takes some thought to figure out a method that will work for your needs.

True - when I planned mine out I decided to have a bank for each "major" thing, and the subroutines used by each section would be located in the same bank. THis allows me to JMP to the next section with the bank getting swapped then and not have to worry about "which bank to return too".

Thanks for the bankswitching pointers - I think I have a reasonable understanding of how to proceed now. At the moment I am planning to put the display kernel in one 4k block (basically most of the current code) and the rest of the code in the other.

 

Chris

Thanks for the bankswitching pointers - I think I have a reasonable understanding of how to proceed now. At the moment I am planning to put the display kernel in one 4k block (basically most of the current code) and the rest of the code in the other.

 

If you split the code right at the kernel boundary (which would probably be very logical), you could start the first bank (containing the kernel) with:

 org $0000
 rorg $1000
KERNELEXIT:
 nop $1FF9 ; Go to $1003 in normal bank (a simple RTS)
; KERNEL ENTRY STARTS HERE (got here from $1000 in other bank)

The second bank (containing everything else) would start with:

 org $1000
 rorg $F000
KERNEL:
 nop $FFF8 ; Go to $1003 in kernel bank
 rts   ; Got here from $1000 in other bank

 

If you don't use the BRK vector for anything, the cheapest way to force code to start in the last bank is to make the reset vector in all but the last bank point to $FFF9, put a zero in $xFF9 (all banks), and then point the BRK vector in the last bank at the real start of code (in any other bank, point it to $FFF9). For good measure, include zeros at $xFFA and $xFFB also, though it shouldn't matter.

 

Note that using any but the last hotspot for this approach is apt to be dangerous and unreliable, since carts may not behave consistently when given two consecutive hotspot addresses. If you use only the last hotspot, however, the cart will only see one hotspot access and thus there shouldn't be any problem.

When spawning enemies I think you still have to try to enforce some vertical separation. It looks like it's putting too many enemies right next to eachother when they could easily be offset by the height of a sprite yielding less flicker.