Re: [cc65] Disable KERNAL ROM ?

Hi

>> BSOUT:
>> [...]

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

Maybe. I didn't think much about it when I choose it. The programs I
know/write/have in mind call it primarily inside write(). And there it
would of course make sense to have an exception to the rule and
actually modify the C library: Bank once, loop through the BSOUTs,
bank back once. Same goes for read().

> 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.

ACK - see above.

> 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)

Exactly this can't happen as under the ROM is only CODE, no DATA,
RODATA, BSS, heap, stack, ... :-)

> 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.

You see, I have sort of the opposite perspective: Each and every
project I did so far with/for cc65 hit sooner or later the "memory
barrier". The only exception so far was NanoVM, which was just way too
slow to grew.

> There is $0400-$CFFF = 51 KB
> freely available.

Thanks for pointing out ;-))

> 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 -

Regarding the memory: You could as well argue that for a small program
it is only a marginal issue to be a little bigger while for large
programs it is a showstopper to not fit into memory.

Regarding the CPU: I really wonder if any "clean" cc65 program would
slow down enough to be noticable. Significant screen output is usually
done via CONIO (and is thus wthout KERNAL interaction) while POSIX
disk i/o would benefit from the spacial handling in read() / write() -
see above.

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

cc65 is certainly supposed to be generic and not focused on specific
projects - but as you explicitly ask for:

With that memory I could build a Contiki 2.x in the Contiki 1.x style:
A desktop core that loads individual programs (instead of / in
addition to the standalone programs you currently have).

> 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.

This might work for projects written from scratch for the C64. But
from my perspective the cool thing about cc65 is that it enables you
to bring projects to the 6502 which were not necessarily intended for
it originally.

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