Re: [cc65] Disable KERNAL ROM ?

Hello,

Note that the cc65 RTL already banks out the BASIC ROM at $A000-$BFFF,
this, the win is not as high as it might seem at first glance.

* On Wed, Feb 13, 2013 at 03:00:35PM +0100 Oliver Schmidt wrote:
 
> I'm thinking of routines like this
> 
> BSOUT:
>   pha
>   lda #??
        ^^^^ $36
>   sta $01
>   pla
>   jsr $FFD2
>   pha
>   lda #??
        ^^^^ $35, or even $34 if $D000-$DFFF should be banked out, too.
>   sta $01
>   pla
>   rts

This is a perfect example where this is NOT a good idea. ;)

IMHO, the overhead for outputting just one byte is too high. If a
function putstring() (or however it is called in cc65) would use such a
thunk, ok. But, in contrast, calling the BSOUT from above in a loop
would add too much overhead.

But: If a putstring() function would be written (or changed, if such a
thing exists), what if it wants to output strings under the ROM? Thus,
special care would have to be done (or it would not be feasable to use
putstring(), and BSOUT as above would be the solution)

Having said this, I think this is the biggest disadvantage of your
approach. I would assume that most projects would not have problems with
the available RAM of the cc65 compiler. There is $0400-$CFFF = 51 KB
freely available.

You approach would add 8 KB extra (or even 12 KB, if special care would
be taken for $D000-$DFFF). For projects which need this extra memory,
that would be very good. But what about projects that do not need this?
They would have to carry the burden of the extra memory and time
consumption of this approach - or you would be effectively having two
different RTL versions for the C64.

For the IO banked out, every access to the I/O area would also need
chunks.

Is this all worth it? How many projects are there that would benefit
from this extra memory?

Note also that I believe that projects can use this extra memory if they
do this handling themselves. This involves carefully planing the
placement of functions, strings for output (see above), and so on.

Thus, an additional library which allows easy implementation of such a
program might be more feasible than putting this all into the generic
RTL.

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.