Re: [cc65] C64 fast-loader suggestion?

From: <silverdr1wfmh.org.pl>
Date: 2011-12-12 13:50:00
On 2011-12-12, at 11:32, Oliver Schmidt wrote:

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

Precisely..

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

I guess it is because fopen()/fread() most probably uses "CHRIN" KERNAL calls while cbm_load uses "LOAD" KERNAL call. When doing I/O on a 64 LOAD was always preferred whenever possible due to being exactly much faster and not requiring "babysitting" ;-) Only when portions of the data had to be parsed or otherwise taken care of on the fly, CHRIN was used. OTOH while good speeders help speeding both LOAD and CHRIN operations, yet LOAD remains faster in any case.

-- 
SD!----------------------------------------------------------------------
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 13:51:32 2011

This archive was generated by hypermail 2.1.8 : 2011-12-12 13:51:37 CET