Bank Switching problems

[Coolcrab]

I am trying to understand how bank switching works. I found RT's tutorial and example but I can't seem to be able to apply it to my own game.

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bankswitching

 

As far as I understand: the first bank should become larger if you set it to 8k, but for me it becomes smaller. I have 8b left in 4k mode and -200 in 8k mode.

This is when I put bank 2 right before the score minikernel at the very bottom. If I put bank 2 before the main loop then it doesn't fit in bank2 and if I split the main loop between the two banks then I get errors or garbled graphics.

 

People don't seem to have such troubles with this so maybe its the minikernels? If anyone has any idea of how this works then it would be great if they could take a look. At the moment I mainly want more space for the AI but I might want to add a title screen kernel later.

MonkeyKing0.16.bas.bin

MonkeyKing0.16.bas

score_graphics.asm

playerscores.asm

[+Karl G]

I'm not seeing the same results as you when I compile:

 

MacBook-Pro:Downloads kdgarris$ 2600bas MonkeyKing0.16.bas 
Found dasm version: DASM 2.20.11 unofficial 20140202a
Starting build of MonkeyKing0.16.bas
batari Basic v1.01dreveng40 (C)2005-2017
2600 Basic compilation complete.
User-defined score_graphics.asm found in current directory
      3387 bytes of ROM space left in bank 1
      87 bytes of ROM space left in bank 2


Complete.
Build complete.

[Coolcrab]

I get this, but that might be a mac vs win thing. If you run the game does it work for you?

 

Compilation completed at 8/30/2018 9:32:48 PM

view output file:///C:/Users/Alex/Downloads/bin

Post compilation files deleted

[8/30/2018 10:17:55 PM] saving C:\Users\Alex\Downloads\MonkeyKing0.16.bas succeeded.

Compile started at 8/30/2018 10:17:55 PM

Compiling C:\Users\Alex\Downloads\MonkeyKing0.16.bas

2600 Basic compilation completed.

3387 bytes of ROM space left in bank 1

87 bytes of ROM space left in bank 2

Compilation completed at 8/30/2018 10:17:56 PM

view output file:///C:/Users/Alex/Downloads/bin

Post compilation files deleted

 

[+Karl G]

Okay, after changing your source slightly, I am seeing the same results as you - moving to 8K reduces the space in bank 1, and I have no idea why that should happen. It should free up space in bank 1 just because the display kernel should be relocated to bank 2, but that's not what I'm seeing, either. I'm not sure what is going on, here.

 

Here's the version with bank 2 at the end, and just the minikernel definition in bank 2, which "should" work (but doesn't).

 

Does anyone else have any ideas?

 

 

[+Karl G]

(duplicate post)

[+Random Terrain]

When I downloaded and compiled, I see this:

---

      3387 bytes of ROM space left in bank 1
      87 bytes of ROM space left in bank 2

---

I am using bB.1.1d.reveng41 and VbB 568.

[RevEng]

As far as I understand: the first bank should become larger if you set it to 8k, but for me it becomes smaller. I have 8b left in 4k mode and -200 in 8k mode.

A bankswitched binary has code at the end of each bank to deal with bankswitching. A 4k ROM doesn't have this code.

 

[edit - nevermind. I see you've split the kernel and code. I'll have a deeper look.]

 

[edit 2 - looked deeper. see comments below]

 

The .bas as provided does split off some code to bank 1 and bank 2. So really the question is, why does a 4k binary use 4080 bytes, and the same code in a 8k format use 4710 bytes?

 

64 bytes of that is the bankswitch code. (32 per bank) Another 12 bytes is lost to the hotspot.

 

Each of the pf* commands is doing a bankswitch "gosub", which takes 25 bytes of rom instead of 3 bytes for the non-banked version. (You'll be adding similar overhead when you start using banked gosubs)

 

There are are fair number of pf* commands, so I think that probably accounts for most of it.

[Coolcrab]

When I downloaded and compiled, I see this:

---

      3387 bytes of ROM space left in bank 1
      87 bytes of ROM space left in bank 2

---

I am using bB.1.1d.reveng41 and VbB 568.

But does it work for you?

 

A bankswitched binary has code at the end of each bank to deal with bankswitching. A 4k ROM doesn't have this code.

 

[edit - nevermind. I see you've split the kernel and code. I'll have a deeper look.]

 

[edit 2 - looked deeper. see comments below]

 

The .bas as provided does split off some code to bank 1 and bank 2. So really the question is, why does a 4k binary use 4080 bytes, and the same code in a 8k format use 4710 bytes?

 

64 bytes of that is the bankswitch code. (32 per bank) Another 12 bytes is lost to the hotspot.

 

Each of the pf* commands is doing a bankswitch "gosub", which takes 25 bytes of rom instead of 3 bytes for the non-banked version. (You'll be adding similar overhead when you start using banked gosubs)

 

There are are fair number of pf* commands, so I think that probably accounts for most of it.

Aha so that costs more because it goes to the drawing in a different bank? In a way it shouldn't matter much as long as the game compiles, as I could hide more stuff in Bank 2. But do you have any clue why it doesn't run after compilatukn? Should I not break up the main loop? If so does that mean that this game can't be larger than 4k?

[+Random Terrain]

It doesn't look like you updated your code to work with more than one bank, so there is a good chance that it won't work properly. Take a look at these spots on the bB page:

 

goto

 

gosub

 

return

[+Lewis2907]

Return thisbank

 

Return other bank

 

Return

 

Saves varying cycles. I think RT site has what it saves on bytes. Also as recommend by others restructuring or thinking of another way can reduce the size of your program. Hope this helps. So far the game looks good, thanks.