Re: [cc65] C64 fast-loader suggestion?

On Wed, Dec 14, 2011 at 03:12:20PM +0100, silverdr@wfmh.org.pl wrote:
> 
> On 2011-12-14, at 14:13, Gábor Lénárt wrote:
> 
> > 2. fastloaders usually accelerates LOAD not CHRIN (however I can be wrong
> >   here: as 'file' $ is not a real one, but created by the drive as a
> >   "virtual" file containing the directory as a BASIC-like program, maybe
> >   fastloaders can't accelerate the loading of $: am I wrong here?)
> 
> It depends. Good, especially hardware supported speeders DO accelerate
> LOAD, CHRIN reads and "$" directory reading.  Still - as I wrote earlier -
> in any case LOAD is always faster.  So, yes this can be sped up but
> generally it is not so important.  The amount of data when reading a
> directory is small and when output directly to the screen, it may even be
> a sort of advantage when the speed of the output gives you more time to
> read it ;-)

Btw, one more question. I'm using KERNAL's LOAD to load files now into a
dedicated buffer.  First, I need the disk's directory to I load file $
there, I can parse it then.  It's nice and works now.  However while I
watched the hexdump of a directory (to code my routine) I discovered that
there is a +2 offset difference.  I guess it's because KERNAL does not put
the first two bytes into the buffer, which would be the load address.  I use
secondary address 0 when calling LOAD, so I can specify where I want to load
the program, instead of using the address stored in the file itself.  The
missing two bytes does not mean any problem with directory, since I don't
need that information.  However now I see a problem: I also want to use LOAD
to load the selected file then (from directory list, by user).  And that is
not a program for real but data file so I _need_ the first two bytes too! 
However according to my experience LOAD won't store that at all.  So,
"loading" a data file (which does not have real loading address stored) is a
situation when I can't use LOAD at all, and my only choice is to do it
myself calling BASIN/CHRIN myself for every bytes?  :( It does not sound
good, as some fastloaders only accelerates LOAD, if I am correct .......

Also, I am not sure it would work with SEQ file, and not PRG.
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.