Re: [cc65] Optimizations needed!

 
 
I once started working on a program called MemBank128 which gives access to 
 Bank 1 to C128 code.  Perhaps if I complete it, I could convert the game 
to  the C128.  Thank you for your suggestion.
 
In a message dated 11/27/2010 3:32:24 A.M. Eastern Standard Time,  
64subnet@gmail.com writes:

What  does your memory map look like?  If you haven't already played
with  your config file, you might try some of these...

1.  Find a way to  use the    RAM under Kernal ROM
2.  Use RAM under the I/O  area.
3.  Make any init code only needed at startup disposable.   Note
that the standard startup and init are to blame for 200+  bytes of
code that could be discarded, but the default  configurations
leave it all in memory.  You'll need to  play with what you can
throw out and how to make it  happen.  (I haven't experimented
with this  yet.)
4.  Make use of the cassette buffer for something.  It's  only 192
bytes, but a byte is a byte.

1 and 2 give you  another 12K, which is more than you'll gain from
any of the other things  suggested (I think), and with less effort
and less performance  issues.  Just as with overlays, you'll have to
experiment with what  code can go there most easily.  Any code that
is rather isolated from  I/O and Kernal calls will avoid the need for
a lot of stubs to bank RAM in  & out around function calls.  Core
parsing logic might be a good  candidate.  Also beware of interrupts
that assume I/O and Kernal are  banked in; you may need to SEI/CLI
around the hidden code.

> 9.  Never use printf. The library code to handle it is huge.  Write
>   your own functions

Perhaps this is slightly  exaggerated.  Some details might help put it
into perspective.  I  just compiled a number of test programs for
the C64...
a)  A  bare-bones "Hello World" program is smaller than 400 bytes.
b)   Add a single /trivial/ printf( ""); and you incur a hit of
just over 2K increase in code size.
c)  That's it.  No  matter how much you use the printf features,
you've already  paid for the library code.  Any additional size
increase  will be from the actual calls you add.

2K is not insignificant, but  considering what you get, it seems like
a bargain to me.  It might be  a good candidate to go under I/O,
since all you would need to have  accessible at all times would be
the outer printf function, modified to  bank in RAM before calling
the internal (non-variadic) function.

//  Agent  Friday
----------------------------------------------------------------------
To  unsubscribe from the list send mail to majordomo@musoftware.de with
the  string "unsubscribe cc65" in the body(!) of the  mail.





-------------------
Joseph Rose, a.k.a. Harry Potter
Working  magic in the computer community...or at least striving to!  :(
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.