Re: [cc65] Disable KERNAL ROM ?

On 2013-02-13, at 23:49, Oliver Schmidt wrote:

>> I have similar feelings as Spiro. If the c64 platform is changed, it doesn't
>> make sense to bank out just the kernal. Banking out I/O also is not much
>> worse, but has the advantage of giving linear memory.
> 
> I see. My reading on C64 memory layout options didn't reveal that
> option. Otherwise I'd probably proposed it in the first place.

On a 64 banking out the I/O is usually done as "last resort" when running out of mem, therefore it didn't strike me that you were not proposing it as first thing to do. But for a compiled programs it may well be the case.

>> Almost no code written by cc65 beginners will work. What I have seen from
>> posts here and in the web, people start using short programs which increment
>> $D020 or call BSOUT via inline assembler, either because they come from BASIC
>> or from assembler. And none of this stuff will work any more.
> 
> If these programs are what you measure cc65 against then this is of
> course a showstopper.
> 
>> In addition, programs will get larger and slower.
> 
> Many features of the runtime / C library make programs larger. I.e.
> being able to access both the screen and the disk with write() is an
> overhead as many programs use it only for one or the other task. So
> I'd say that the fact that programs get larger is by itself no
> argument. It's always the question of the overhead related to the
> benefit. Otherwise there would be no need for cc65 and everybody would
> code everything in assembler as it gives smaller programs.
> 
> Regarding speed I'd like to learn about _meaningful_ scenarios which
> would suffer in a noticable way. Maybe I'm naive but nevertheless...
> 
>> While I agree that having the option of a banked out kernal is an advantage
>> for some programs, it has no advantages for most programs and disantages for
>> many.
> 
> Again one needs to additionally assess how much "the many" programs
> suffer and how much "the few" programs benefit to turn this raw fact
> into a meaningful argument.

I'd rather say that it is more important who the actual target is. For small programs, the final size of a compiled binary is usually plainly repulsive when compared to few lines of assembler that would achieve the same thing. So - when the target audience are the "beginners" then it would hurt more than give benefits. When we talk about serious usage though - every bit of RAM you can squeeze out may be a godsend, when RAM starts to be precious.

>> Maybe the best approach would be a separate library as with the C16/Plus4:
>> They're in fact the same platform, but the C16 has the kernal in place, while
>> the Plus4 banks it out. But this would of course mean a separate platform
>> library to maintain.
> 
> Mayby that's at least partly a question of how this is set up. The
> various CBM targets have a lot of code actually duplicated. This
> causes of course quite some (unnecessary) effort. The approach taken
> for apple2 / apple2enh causes in contrast rather moderate effort...
> 
> Anyway I don't believe that there's a momentum to change the exsisting
> c64 target so the question is if linear RAM up to $FFF9 is worth the
> effort to create an maintain an additional target.

Depends on how it is done. I personally would like to see the possibility of using all the RAM that can be used. But I also have to agree that it would be good to find a compromise that would not repulse someone who writes the hello.c to see how the compiler works (before getting on to something more serious) and after seeing 22KiB of binary as a result of one printf() just simply gives up. [*]

If it can be done in a way that would allow to minimise the effort (maybe even optimise other cbm targets on the way?), then it would be clearly a good thing to me. ... my $0.03.

* - exaggerated on purpose ;-)

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