Saving ROM space by removing bB features

[+Atarius Maximus]

This is something I've done for years but never really shared what I did to do it.  It's actually pretty easy.  If there are certain features of bB that you're not using in your game, you can save quite a bit of space by removing those features from bB.  If you don't use any of the playfield drawing commands or scrolling, you can really quickly save 354 bytes.

 

• If you compile a blank file with bB you'll get 2879 bytes free.  If you exclude everything below, you'll have 3233 bytes free.

• If you edit the default.inc file in the includes folder and comment out pf_scrolling.asm and pf_drawing.asm you'll save 354 bytes.

• if you remove only pf_drawing.asm, you'll save 162 bytes.

• If you edit the pf_drawing.asm file and simply comment out the following individual features, you'll save:
• 8 bytes  -  remove pfclear
• 17 bytes  -  remove setuppointers
• 13 bytes  -  remove pfread
• 6 bytes -  remove pfpixel
• 21 bytes  -  remove pfhline
• 25  bytes  - remove pfvline

• If you remove only pf_scrolling.asm, you'll save 192 bytes.

 

More can be saved by editing the kernel file itself, for example if you remove all the instances of shakescreen from std_kernel.asm you'll save 3 bytes.  There's plenty more space to be saved in the kernel file if there are other features you don't use.

 

 

[KevKelley]

I remember reading a while back about doing this but I always forget. 

[+Gemintronic]

Nah.  I'll just wait until you make another 2k racing game and cop off your kernel.  😛

 

P.S.  I'm only half joking.  That was the only way I was able to make a 2k game.  Thank you!

[+Atarius Maximus]

54 minutes ago, Gemintronic said:

Nah.  I'll just wait until you make another 2k racing game and cop off your kernel.  😛

 

P.S.  I'm only half joking.  That was the only way I was able to make a 2k game.  Thank you!

Ha!  Well, glad the old gate racer code helped, and you're welcome.   I removed a lot of stuff I didn't need for that recent game I posted "Cave Trap", and I could probably remove more.

[KevKelley]

Damn. Now looking at this post, Pinfinger is almost exactly 4k and it got me wondering just what I can fit if I freed up like 150 bytes. Lol

[glurk]

I'm not a bBASIC user, but I've looked at some ASM that it generates, and saw stuff like:

 

LDA #0

STA $81

LDA #0

STA $85

 

And even worse stuff than that.  So I imagine that if someone went in and hand-optimized the generated ASM, one could free up tons of space.

 

So, bB guys, don't take it as a criticism, but being a guy who looks at stuff in ASM and in the Stella debugger a lot, bB sure does generate a lot of sub-optimal code.....  FWIW.

 

 

[LatchKeyKid]

14 hours ago, Atarius Maximus said:

This is something I've done for years but never really shared what I did to do it.  It's actually pretty easy.  If there are certain features of bB that you're not using in your game, you can save quite a bit of space by removing those features from bB.  If you don't use any of the playfield drawing commands or scrolling, you can really quickly save 354 bytes.

 

• If you compile a blank file with bB you'll get 2879 bytes free.  If you exclude everything below, you'll have 3233 bytes free.

• If you edit the default.inc file in the includes folder and comment out pf_scrolling.asm and pf_drawing.asm you'll save 354 bytes.

• if you remove only pf_drawing.asm, you'll save 162 bytes.

• If you edit the pf_drawing.asm file and simply comment out the following individual features, you'll save:
• 8 bytes  -  remove pfclear
• 17 bytes  -  remove setuppointers
• 13 bytes  -  remove pfread
• 6 bytes -  remove pfpixel
• 21 bytes  -  remove pfhline
• 25  bytes  - remove pfvline

• If you remove only pf_scrolling.asm, you'll save 192 bytes.

 

More can be saved by editing the kernel file itself, for example if you remove all the instances of shakescreen from std_kernel.asm you'll save 3 bytes.  There's plenty more space to be saved in the kernel file if there are other features you don't use.

 

 

 

Interesting....   One of my first two homebrew attempts that I started up this summer was a small 4k program that quickly ran out of space.  I pretty much gave up because I had already cut alot of aspects that I wanted and still didn't have enough space to add in much in the way of sound at all.    I don't believe I'm using much in the way of those pf commands (iirc I only assign the playfield for each screen and that's it) so I could definitely free up some space if that's the case. 

 

What does the setuppointers function do?   Other than editing a few files for custom scorebars and fonts, I don't really have much experience with this aspect.   Could you post an already edited version here in the thread with those playfield functions removed?   Regardless, thanks in advance for the info!

 

Edited August 15 by LatchKeyKid

[KevKelley]

27 minutes ago, glurk said:

I'm not a bBASIC user, but I've looked at some ASM that it generates, and saw stuff like:

 

LDA #0

STA $81

LDA #0

STA $85

 

And even worse stuff than that.  So I imagine that if someone went in and hand-optimized the generated ASM, one could free up tons of space.

 

So, bB guys, don't take it as a criticism, but being a guy who looks at stuff in ASM and in the Stella debugger a lot, bB sure does generate a lot of sub-optimal code.....  FWIW.

 

 

This is an eventual goal of mine down the road - to slowly learn ASM to make better programs or do things differently. I love bB but I wanna learn to do more interesting things. 

[+Atarius Maximus]

1 hour ago, LatchKeyKid said:

 

Interesting....   One of my first two homebrew attempts that I started up this summer was a small 4k program that quickly ran out of space.  I pretty much gave up because I had already cut alot of aspects that I wanted and still didn't have enough space to add in much in the way of sound at all.    I don't believe I'm using much in the way of those pf commands (iirc I only assign the playfield for each screen and that's it) so I could definitely free up some space if that's the case. 

 

What does the setuppointers function do?   Other than editing a few files for custom scorebars and fonts, I don't really have much experience with this aspect.   Could you post an already edited version here in the thread with those playfield functions removed?   Regardless, thanks in advance for the info!

 

The setuppointers function actually shouldn't be removed alone as it's called by other functions in that file.  I'm not sure of it's exact purpose.  

 

I'll go ahead and post a Windows 64-bit version of bB 1.7 that has basically almost everything removed that I could quickly and easily remove.  In total it saves 367 bytes.   This is not a one-size-fits-all build of course, using this as-is will cause problems if you're using any of the bB functions mentioned below.  Used as-is, this modification of batari Basic will give you 3,246 bytes of free space in a blank 4k build, increased from 2,879 bytes.
 

This bB folder includes the following changes:

• In the includes subdirectory, the default.inc file was changed. The files pf_drawing.asm, pf_scrolling.asm and std_routines.asm were commented out so they will not be used at compile time.
• Also in the includes subdirectory, std_kernel.asm was modified with the changes listed below.  
  • Removed were references to shakescreen, pfres, playercolors, PFColorandheight, PFheights, pfcolors, player1colors, readpaddle, references to the minikernel, and shakescreen.
  • Note that I removed all of those things in std_kernel.asm in my testing and left them removed, however with a quick test compiling a blank file it looks like only removing shakescreen actually saves space (3 bytes).
• The pf_drawing.asm file was modified only to add additional information about what to comment out for each function and how much space it would save if you did.  It can be re-added in default.inc and modified to only remove the functions you aren't using.

Note that even with all those changes the space savings are only 3 bytes when compiling a blank file, which is saved by removing shakescreen alone.  I removed all of that other stuff during my testing.

default.inc file:

The 3 lines below were commented out (just add a semicolon at the beginning of the line):

;pf_drawing.asm     ; Contains "pfclear", "pfread", "pfpixel", "pfhline" and "pfvline" functions, saves 162 bytes
;pf_scrolling.asm    ; Contains "pfscroll" functions, saves 192 bytes
;std_routines.asm   ; Contains "rand" and "rand16" functions, saves 10 bytes

 

std_kernel.asm file:
See the CHANGES.txt file in the attached zip for details on exactly what was commented out.  You can also run a file compare with your favorite tool (I use WinMerge) to view the changes in the kernel file as compared to the default file.

 

bB_1.7_Winx64_AtariusMaximusMod.zip

[+Atarius Maximus]

1 hour ago, glurk said:

I'm not a bBASIC user, but I've looked at some ASM that it generates, and saw stuff like:

 

LDA #0

STA $81

LDA #0

STA $85

 

And even worse stuff than that.  So I imagine that if someone went in and hand-optimized the generated ASM, one could free up tons of space.

 

So, bB guys, don't take it as a criticism, but being a guy who looks at stuff in ASM and in the Stella debugger a lot, bB sure does generate a lot of sub-optimal code.....  FWIW.

 

Absolutely true, it doesn't produce optimized code.  If you have any quick and easy suggestions for basic things that could be changed to save space I'm sure everyone would appreciate the tips.

[+Karl G]

9 hours ago, glurk said:

I'm not a bBASIC user, but I've looked at some ASM that it generates, and saw stuff like:

 

LDA #0

STA $81

LDA #0

STA $85

 

And even worse stuff than that.  So I imagine that if someone went in and hand-optimized the generated ASM, one could free up tons of space.

 

So, bB guys, don't take it as a criticism, but being a guy who looks at stuff in ASM and in the Stella debugger a lot, bB sure does generate a lot of sub-optimal code.....  FWIW.

 

 

In this specific case, the way you write the bB code makes a difference. If you put multiple variable assignments with the same assigned value on one line (separated by colons), it will optimize to skip the unnecessary extra "LDA" statements.

 

Are there any other instances where you have seen the bB compiler produce non-optional assembly?

[glurk]

@Karl G  Hey!  TBH I havent looked too deeply, as I'm not a bB user.  But I'm weird and OCD about optimizing code, and more of a coder than a gamer.  So when any new game is released, I tend to poke around in the Stella debugger and check things out.

 

And numerous times (I never took notes) I've looked at bB-made games and the code made me go "eeeeww!!"  LOL.  It just seemed to me that a bit of hand optimization would go a long way, or maybe even adding an optimization pass to the compiler itself.

 

But that would require the game's coder to know ASM, or would maybe(?) not be possible for the language maintainers to add that feature...

 

So it was really just an off hand observation from an ASM guy....

[LatchKeyKid]

20 hours ago, Atarius Maximus said:

• Also in the includes subdirectory, std_kernel.asm was modified with the changes listed below.  
  • Removed were references to shakescreen, pfres, playercolors, PFColorandheight, PFheights, pfcolors, player1colors, readpaddle, references to the minikernel, and shakescreen.

default.inc file:

The 3 lines below were commented out (just add a semicolon at the beginning of the line):

;pf_drawing.asm     ; Contains "pfclear", "pfread", "pfpixel", "pfhline" and "pfvline" functions, saves 162 bytes
;pf_scrolling.asm    ; Contains "pfscroll" functions, saves 192 bytes
;std_routines.asm   ; Contains "rand" and "rand16" functions, saves 10 bytes

 

 

Thanks!   Just to be clear... this is for the standard bB kernel, correct?    I might put back the rand and rand16 functions if I'm using them (just remove the semicolon to turn the comment back into a command, correct?) since it only saves 10 bytes if I'm using them instead of trying to find a work around.   The savings for the pf functions are much more chunky for programs that don't use them.

 

Out of curiosity, why did you remove the references to pfres, playercolors, pfcolorandheight, pfheights, etc?    If this is for a standard kernel, does that mean those kernel options no longer work?  Thanks again in advance.

[+Atarius Maximus]

1 hour ago, LatchKeyKid said:

 

Thanks!   Just to be clear... this is for the standard bB kernel, correct?    I might put back the rand and rand16 functions if I'm using them (just remove the semicolon to turn the comment back into a command, correct?) since it only saves 10 bytes if I'm using them instead of trying to find a work around.   The savings for the pf functions are much more chunky for programs that don't use them.

 

Out of curiosity, why did you remove the references to pfres, playercolors, pfcolorandheight, pfheights, etc?    If this is for a standard kernel, does that mean those kernel options no longer work?  Thanks again in advance.

Yes, this is for the standard kernel.  I suppose there would be some possible space savings with the multisprite kernel as well but I haven't looked at that.

 

After spending quite a bit of time commenting out and testing the removal of functions in std_kernel.asm, the only thing that saved space was removing shakescreen.  There's not much point in using my modified std_kernel.asm file really, I'd just use the one that comes with bB and comment out the instances of shakescreen yourself if you'd like to save an extra 3 bytes.  Granted I was only testing/compiling with a blank text file, but I don't think that would matter.  I removed pfres, playercolors, pfcolorandheight, pfheights, etc just as part of my testing to see how much it would save and if it would still properly compile.  Yes, it would mean that those functions would no longer work.

[+Atarius Maximus]

15 hours ago, glurk said:

@Karl G  Hey!  TBH I havent looked too deeply, as I'm not a bB user.  But I'm weird and OCD about optimizing code, and more of a coder than a gamer.  So when any new game is released, I tend to poke around in the Stella debugger and check things out.

 

And numerous times (I never took notes) I've looked at bB-made games and the code made me go "eeeeww!!"  LOL.  It just seemed to me that a bit of hand optimization would go a long way, or maybe even adding an optimization pass to the compiler itself.

 

But that would require the game's coder to know ASM, or would maybe(?) not be possible for the language maintainers to add that feature...

 

So it was really just an off hand observation from an ASM guy....

I suppose optimizing the resulting asm file after bB compiles it wouldn't actually be all that useful to bB programmers, as once it was optimized and cleaned up any further changes to take advantage of any freed up space would then need to be added in pure ASM.  Recompiling in bB again would negate the savings.  It's of course still possible to take advantage of doing that, but at that point you might as well just write the game in asm.  Either way I appreciate your insight.