Re: [cc65] C64 fast-loader suggestion?

From: Oliver Schmidt <ol.sc1web.de>
Date: 2011-12-12 11:32:53
Hi,

>> ofcourse. i am not saying that you shouldnt use kernal loading - thats
>> ofcourse the preferred way to do things, especially when talking about
>> tools/applications. BUT i would always recommend to use cbm_load over
>> fopen/fread,

> The above is of course valid as long as we stick to CBM targets. And yes, the original question was about CBM. I guess it's me who tend to always think "portable" whenever cc65/C code on 6502/6510 is being spoken about. Maybe because for a 64 I feel as good (if not better :-) with pure assembler.. Thus - yes, as long as we speak of CBM only it's all correct.

The other scenario beside cross-65xx development is that cc65 allows
someone like me to do C64 development although I don't know cbm_load -
and basically don't want to learn about it. I'd call the C library
even from assembly language - and by the way still stay
cross-target...

When looking at the read() implementation for CBM I'm sort of having a
hard time to believe that it causes (too) much overhead. Is cbm_load()
really supposed to be noticably faster? I always thought the time is
spent on the serial transfer, not in the C library.

And when it comes to fastloading the open(), read() and friends
functions could even offer an opportunity in that a fastloader
wouldn't need to "emulate" closely the potentially very specific
behaviour of "some" low-level Kernal call but would "just" offer what
open/read/.etc need/want. Meaning that cbm_load() works the way it
always does and only read() is accelerated. Please understand that I
don't actually know if it makes sense what I say, I'm just talking
about potential design aspects.

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Dec 12 11:33:00 2011

This archive was generated by hypermail 2.1.8 : 2011-12-12 11:33:04 CET