Re: [cc65] Disable KERNAL ROM ?

Hi Uz,

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

> But there are quite some disadvantages:
>
> 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.

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

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