bB 256k, 128k, 64k, 32k, 16k, Multikernel Frameworks

[+Gemintronic]

It doesn't restrict you from using extra characters, but you need to make changes uniformly for all banks.

 

i.e. When you edit the provided score_graphics.asm in one bank (and change the start of the graphics to allow for more characters) you need to modify the score_graphics.asm graphics start location similarly in all banks.

 

The underlying reasons you need to do this are 1)bank-switch routines normally need to be the same place in each bank, and 2)the bank-switch switch routine for these frameworks is in the score_graphics file, right after the graphics data.

 

I appreciate the inside info. I'm almost certain I've bugged you about this before. Only resorted to this after trying and failing more than a few times

 

I saw this topic: http://atariage.com/forums/topic/126058-defining-a-f-in-score-graphicsasm/

 

..and tried to replace this code:

ifconst ROM2k
ORG $F77C ; was ORG $F7AC
else
ifconst bankswitch
     if bankswitch == 8
     ORG $2F64-bscode_length ; was ORG $2F94-bscode_length
     RORG $FF64-bscode_length ; was RORG $FF94-bscode_length
     endif
     if bankswitch == 16
     ORG $4F64-bscode_length ; was ORG $4F94-bscode_length
     RORG $FF64-bscode_length ; was RORG $FF94-bscode_length
     endif
     if bankswitch == 32
     ORG $8F64-bscode_length ; was ORG $8F94-bscode_length
     RORG $FF64-bscode_length ; was RORG $FF94-bscode_length
     endif
else
     ORG $FF6C ; was ORG $FF9C
endif
endif

The last line with ORG statements appears different in the multi kernel framework. I'm wondering if this is the key section I have to change (besides adding the extra 6 character data). I'm also not sure what the changed values should be.

[RevEng]

Yes, it's the last ORG that needs to change, since the frameworks don't use native bB bankswitching.

 

For 6 new characters the bottom ORG needs to be FF3C.

 

To get that answer, I just used a calculator with a hex setting and punched in "ff6c−(6×8)"

[Bakunawa]

Would it be possible to use this with fewer than 8 banks? Judging from stella's disassembly of the 32kMultikernel.bas.bin, it seems like it could work, but if we only need 16k for the game then there'd be quite a lot of wasted space.

[RevEng]

7 hours ago, Bakunawa said:

Would it be possible to use this with fewer than 8 banks? Judging from stella's disassembly of the 32kMultikernel.bas.bin, it seems like it could work, but if we only need 16k for the game then there'd be quite a lot of wasted space.

Sure, I've attached a 16k version to the first post.

[Bakunawa]

Wow! Many thanks RevEng. I've seen many of your posts around here and you've been - and continue to be - a great help!

[RevEng]

Thanks for the kind words! You're most welcome

[r_chase]

I wonder if Al will pin this post because this might be important for some who really want to push the 2600 to its limit.

[Fernando Rodrigues Salvio]

Somebody know if Atari 2600+ run cartridges made with this multikernel?

[+Karl G]

13 hours ago, Fernando Rodrigues Salvio said:

Somebody know if Atari 2600+ run cartridges made with this multikernel?

The short answer is that it should work up to 64K, but the 128K and 256K versions will not, at least not currently.

 

The longer answer is that there's no technical reason that these sizes could be supported, but support for these bankswitching formats has not been added yet. The bankswitching formats that would need to be added to the 2600+ are:

 

DF (128K)

DFSC (128K + SuperChip RAM)

BF (256K)

BFSC (256K + SuperChip RAM)

 

My game Penult uses DFSC, so that will probably eventually be supported (since it's a released homebrew cart), but I have been asking about it for months with no sign of movement on it so far.

 

Edit: I should probably tag @RevEng to verify the accuracy of my answer since this is his framework.

[RevEng]

22 hours ago, Karl G said:

Edit: I should probably tag @RevEng to verify the accuracy of my answer since this is his framework.

Yep, it all looks right to me!