Most of my favorite 2600 games were 4KB - Adventure, Pitfall!, Space Invaders, Frostbite, and Frogger to name a few.  So in my mind a 4KB game is a "standard" 2600 game and that's what I wanted to make and I did.  I thought my final 4KB game was pretty good - I was able to get 64 screens into the game!  I read up on bank switching in my Steven Hugg 2600 programming book.  I had to try it out.  I was always curious how bank switching worked.  I'm glad I did because I could do WAY more with the extra ROM!

At 4KB I was completely desperate for any spare bytes.  More bytes equals more game.  When I switched to 32KB ROM I had more ROM than I knew what do with (at first).  Initially I had this idea to have a few frames of my animated face as an Easter egg... and it would use up half the ROM.  My new profile photo is a mockup of my face in playfield graphics style from that time.  I'm glad I didn't implement that dumb idea; however, that dumb idea might inspire a future game - no promises.  Bank switching allowed my favorite aspects of this game to be possible - the title screen, the AI, big explosions, tons of screens, select screen, and many more subtle refinements to the game.  While my game is no longer "standard" it is still something that could have theoretically been made back in the day.  Fatal Run on the 2600 was a 32KB game that came out in 1990 while the 2600 was still officially supported.

I know there are many different types of bank switching.  I didn't want to get fancy with this so I stuck with "standard" F4 bank switching.

Now lets get into some drawbacks of bank switching.  It's a tad slow - I calculated 27 cycles per bank switch.  My bank0 was full so early on I moved code from my VBlank and Overscan into Bank1 and then I jump into Bank1 to run those code chunks and then jump back to Bank0 as needed.  I have bank switches to and from the title screen, to and from the banks of screens, to and from the select screen, and to and from the AI code.  That's a lot of jumping around even though I tried to keep it a minimum.  I thought it was kind of weird how I did a bank switch during the drawing of the select screen as I mentioned earlier.  This allowed me to draw the ship sprite on the select screen without duplicating code to do so.

One thing that really annoyed me with banks is that any label defined in one bank is visible from any other bank.  This would cause me a lot of frustration when I would mistakenly called a function in another bank... the address of that function was not correct in the bank I was in so I would jump to some "random" location in the current bank.  To reduce my confusion I would tack "_BANK0" labels on any subroutine or table in Bank0... and of course I did this for all the other banks as well.  I wanted it to be crystal clear to me when I scrolled into another bank so I would have comments like this in my code:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;*BANK2;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;                                                     ;;;;;;

;;;;;;  ###   ##  #   # #  #     ##                        ;;;;;;

;;;;;;  #  # #  # ##  # # #     #  #                       ;;;;;;

;;;;;;  ###  #### # # # ##        #                        ;;;;;;

;;;;;;  #  # #  # #  ## # #      #                         ;;;;;;

;;;;;;  ###  #  # #   # #  #    ####                       ;;;;;;

;;;;;;                                                     ;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

My next annoyance is related.  When debugging code in Stella all labels from all banks were applied and would often clobber each other.  This made debugging very frustrating because the labels were all messed up and I had no idea what code I was looking at!  This was such a big problem for me I was tempted to quite this project a few times.  In my opinion all these assemblers and debuggers should disregard labels defined in other banks.