Can't get F8 Bankswitching Working

[Heroes & Shadows]

Hello,

 

Trying to get F8 Bankswitching working after my cloud instance crashed. At the moment all I get is a black screen. If I remember correctly Bb with the 8k ROM option stores the code in Bank 0, and graphics and data in Bank 1 according to something i read. I am trying to accomplish the same effect. If anyone can help me it would be greatly appreciated.

 

Source: https://www.dropbox.com/s/3cnn483zog0bkra/Source_11-19-18.zip?dl=1

 

Regards,

 

Heroes & Shadows

Edited November 20, 2018 by Heroes & Shadows

[Nukey Shay]

I know nothing of bB. One problem I can spot immediately is that "Nope" does not lead into "Reset":

 

If the console powers up in the second bank, the vector points it to $F000...where a bankswitch instruction exists to flip to the first bank. The instruction is 3 bytes long, so now you are at $F003 in the first bank. This is the ".divideby15" subroutine. The subsequent RTS will bounce you to parts unknown (since Ram had never been initialized at this point).

 

So you should use something like this at the top of the first bank:

 

 

   org $E000 ; start first bank exactly at (2nd bank minus $1000)
   rorg $F000 ; Tell the assembler that the bank's address is actually $F000
;i.e. because only odd-numbered blocks are ROM to the 2600.
 
   NOP
   NOP
   NOP ;waste those 3 bytes taken by the bankswitch in the other bank
   JMP Reset ; go and do your prep.

[Nukey Shay]

BTW there's another trick you can use:

 

Since any access to $FFF8 causes a flip to the first bank in this scheme, you can ORG a JMP Reset instruction at $FFF6 in the second bank.

 

 

  ORG $FFF6
Nope:
   JMP Reset

 

JMP is a 3-byte instruction, so the hotspot is automatically triggered as it reads the destination address

[Heroes & Shadows]

I managed to get it running, sort of. It seems to work, but none of the player or playfield graphics are working. All i get is a box instead of a face for the player and the playfield simply does not load at all. I have added a link to the source code for reference.

 

Source

[Nukey Shay]

For the F8 scheme, the display routine (or at least the portion that reads the gfx data) must reside in the same bank as the data it's trying to read. You can see the problem quite clearly in Stella's debugger. Be aware that as far as the hardware "knows", only 4k of Rom exists...it's the most that the 2600 can see at any time.

 

I'd suggest placing the whole display kernel in the second bank (for simplicity), and leave the first bank just for startup and overscan/support routines. It's probably the easiest approach until you become accustomed to how banking works.

[Heroes & Shadows]

So what's the benefits of having 2 banks if most of your code and/or data has to reside in a single bank anyways?

[+Karl G]

The code and data for the display kernel should ideally be in the same bank due to timing constraints, but game logic and supporting data in vblank and overscan can be spread out however makes sense to you.

[Nukey Shay]

I wrote "for simplicity". Once you get used to banking, you can shoot the game kernel through multiple bankswitches (to take advantage of every spare byte in the Rom). At this point, it's just easier to manage. Timing, as well...since each bankswitch instruction will cost you at least 4 cycles of display time. That is all avoided if the data is present along with all the rest.

 

Then, you can experiment with more-complex schemes (banking just portions of the 4k instead of an entire flop).

Edited January 21, 2019 by Nukey Shay

[Heroes & Shadows]

I'd suggest placing the whole display kernel in the second bank (for simplicity), and leave the first bank just for startup and overscan/support routines. It's probably the easiest approach until you become accustomed to how banking works.

Unless i'm misunderstanding you, it tried what you said and now the Atari 2600 is bleeping at me.

 

Source

[Nukey Shay]

Not quite. Remember the problem with startup you originally had, the bankswitch instructions need to line up in memory. They just swap the bank, so the next program instructions absolutely have to be next in Rom memory.

 

In addition...you can reference labels from either bank, but you can't actually jump to them unless they are in the same bank the program is currently in.

 

Fixed version below: I put the bankswitches up top so they line up, and pasted just the wait loop and visual display kernel in the second bank.

Untested since I'm not at my PC at the moment, but you should be getting the idea.

source.asm