Re: [cc65] Putting some cc65 puzzle pieces together

Interesting.  That's a good use of emd over my memory enhancements.  Of course, Hidden64 and MemBank128 allow you to load a memory image directly into the extra memory and access such memory directly.  Em provides more available memory, though.  
 
BTW, when you're done, I'd like to see your demo.
 
BTW again, do you think one can combine Hidden64/MemBank128 with an EMD?  Try it out and let me know.  :)
-----------------
Joseph Rose, a.k.a. Harry Potter
Working magic for the computer community


________________________________
From: Oliver Schmidt <ol.sc@web.de>
To: Lists <cc65@musoftware.de> 
Sent: Wednesday, August 8, 2012 6:20 PM
Subject: [cc65] Putting some cc65 puzzle pieces together

Hi,

Piece one:

In my opinion the cc65 loadable drivers are somewhat over-engineered
for most scenarios because most of the time there's only one driver
possible anyway for one reason or another. However the extended memory
drivers are an exception. Especially on the C64 they are similar and
numerous enough to make the benefits of loadable modules tangible.
Unfortunately cc65 extended memory drivers seem not that popular - at
least I don't know of any program using them. So I thought it was time
to create one.

Piece two:

Usually the potential flexibility of loadable modules ends at the
latest in programs having their names hard-coded in the source code.
The only exception I know of is Contiki where I introduced a config
file containing (among other things) the name of the Ethernet driver
to load. However a program can as well "just" look what driver(s) are
present and try those. The recent implementation of opendir() and
friends on the CBM targets allows to do so in a cross-target fashion
on several targets. At least in general extended memory drivers are
able to detect if the type of memory extension they are applicable for
is actually present. Thus a program can try several drivers it finds
one after the other until one loads successfully.

Piece three:

In order to really leverage the flexibility of loadable extended
memory drivers a program shouldn't rely on a certain amount of
extended memory - or extended memory being present at all. The ideal
scenario is therefore one where the extended memory serves as some
sort of optional cache. Given the typical CBM disk access performance
a disk cache is the obvious candidate. So we're looking for a scenario
that requires loading the same files from disk several times...
Overlays!

Putting the pieces together:

The new sample program 'samples/multidemo.c' looks for extended memory
drivers. If it finds one that loads successfully it uses it to load
its overlays from disk into extended memory as long as there's enough
memory left. Then it actually uses its overlays: The ones loaded into
extended memory are loaded from there. The rest is loaded straight
from disk.

The source code looks pretty much what one would expect with possibly
one exception:

====================

        while (size) {
            void *buf;

            /* In general one could as well use em_copyto() to copy a fully
            * loaded overlay into extended memory in one step. However the
            * "streaming" of an overlay from disk to extended memory shown
            * here has two advantages:
            * - It can be done from another overlay (like done here).
            * - It avoids unnecessary double buffering with emdrivers that
            *  provide a hardware memory window.
            */
            buf = em_use (page++);
            size -= read (file, buf, EM_PAGE_SIZE);
            em_commit ();
        }

====================

I personally like the way multiple (hence the name 'multidemo') cc65
features work together here nicely. And as a side effect everybody
looking for a (relatively) easy way to have cc65 programs make use of
memory extensions has a starting point :-)

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