Jump to content

Photo

Can't get F8 Bankswitching Working


9 replies to this topic

#1 Heroes & Shadows OFFLINE  

Heroes & Shadows

    Star Raider

  • 53 posts

Posted Mon Nov 19, 2018 9:06 PM

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....-19-18.zip?dl=1

 

Regards,

 

Heroes & Shadows


Edited by Heroes & Shadows, Mon Nov 19, 2018 9:07 PM.


#2 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,857 posts
  • Location:The land of Gorch

Posted Tue Nov 20, 2018 6:08 AM

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.


#3 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,857 posts
  • Location:The land of Gorch

Posted Tue Nov 20, 2018 6:21 AM

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 ;)



#4 Heroes & Shadows OFFLINE  

Heroes & Shadows

    Star Raider

  • Topic Starter
  • 53 posts

Posted Sun Jan 20, 2019 6:04 PM

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



#5 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,857 posts
  • Location:The land of Gorch

Posted Sun Jan 20, 2019 7:02 PM

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.



#6 Heroes & Shadows OFFLINE  

Heroes & Shadows

    Star Raider

  • Topic Starter
  • 53 posts

Posted Sun Jan 20, 2019 7:24 PM

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?



#7 Karl G OFFLINE  

Karl G

    Dragonstomper

  • 742 posts

Posted Sun Jan 20, 2019 7:36 PM

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.



#8 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,857 posts
  • Location:The land of Gorch

Posted Sun Jan 20, 2019 8:29 PM

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 by Nukey Shay, Sun Jan 20, 2019 8:33 PM.


#9 Heroes & Shadows OFFLINE  

Heroes & Shadows

    Star Raider

  • Topic Starter
  • 53 posts

Posted Sun Jan 20, 2019 10:58 PM

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. :P

 

Source



#10 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,857 posts
  • Location:The land of Gorch

Posted Mon Jan 21, 2019 1:40 AM

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.

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users