From: groepaz (groepaz_at_gmx.net)
Date: 2001-09-26 20:02:10
Hello Ullrich,
UvB> What I've seen it is quite C64 specific but as I said I didn't have a closer
UvB> look because I have so many open topics with the current development compiler
UvB> and I didn't want to start new ones.
well, yes it probably is pretty much c64 specific, since i develop for
a c64 ;=) however, i have written loads of portable code before and i
have atleast prepared most of this lib stuff to make it portable later
with ease. (all important stuff like kernal-entry points etc defined
in header/include files for example)
UvB> Well, what I said was not correct. Programs on the C64 have 50K memory
UvB> available, on the CBM510 it is 48K. This is somewhat less as with the CBM610
UvB> machines, mostly because I had to move the complete VIC data including the
UvB> character ROM into the execution bank to make sprites possible (which are
UvB> needed for the mouse support). But this does also mean that the character data
UvB> is also in RAM and modifyable.
ah ok ;=) i guess it would be kind of hard to get my hands on a p500
anyway ;=))
UvB> I will send you the changed source in private mail and add it as a new sample
UvB> program to the head branch. Most of the changes are for readbility, some more
UvB> to support other platforms than the C64, and a great part of the remaining
UvB> changes do not help with the current stable compiler version. See my next mail
UvB> for a discussion of the changes that were responsible for the first 50%
UvB> speedup.
got it..thanx.. your changes make this look like an entire
new/different program to me hehehe ;=P probably its those massive
comments (my comments are sparse...the code says it all ;D)
btw to make this look like in a real (bad ;=P) demo, add
*(VIC+0x16)^=4;
after each screen-buffer swap (will look horrible if less than 50 fps
though ;=P)
>> 12 fps is VERY acceptable now i think, considering how hard the job
>> for the compiler is in this case :=)
UvB> Here is what the current development compiler generates for the inner loop:
[snip]
UvB> I think this is rather good, and it is almost impossible to generate better
UvB> code with an all purpose compiler/optimizer.
looks almost optimal to me, right ;) (other optimizations that come to
mind would all involve self-modifying code which i think the compiler
wouldnt be able to handle nor generate, right?)
another question would be, how it'll look if you'd use 2 different
routines for each of the screenbuffers (one of the common
optimizations when it comes to handcoded demo-routines) .... maybe
it's also possible to write the C code in a different way so both the
screen and the sinus-buffers can use indexed adressing....
i'll check this out when the compiler has been released i guess :=)
it'll be WAY cool if it'd be possible to make this sucker run at full
speed (say 50fps) ;=)
UvB> You may add the module as the second module on the command line, or you may
UvB> use a special memory setup. When using banking you will probably need such a
UvB> setup anyway, because some of the code may be banked, while other code and all
UvB> of the data must always be available.
well the current implementation uses handwritten routines to copy data
from/to the floating-point "registers" (that is, zeropage locations
called "FAC" and "ARG") and just the basic-routines that actually
process that data need the basic-rom to be banked in.... this way
source+destination of the data can be anywhere in memory, even under
the banked rom.... just the stub that calls the rom-routines (and
which does the banking) needs a safe place that isnt affected by
banking to live in. (and its a small stub aswell, around 2 pages or
sth, working on getting this even smaller)
--
Best regards,
groepaz mailto:groepaz_at_gmx.net
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:42 CET