From: groepaz (groepaz_at_gmx.net)
Date: 2001-09-26 15:47:08
Hello Ullrich,
UvB> Sorry for the late answer. I didn't find the time to have a closer look at all
UvB> the sources, but...
hehe ;=P i was actually already wondering why it became that quiet on
the list since i posted my stuff ;=) before everyone seems to be in
urgent need for that file-stuff hehe ,=) (maybe my code is just to bad
to serve them well? mmh....but damn i'd like to know THAT aswell ;=P)
UvB> I've recently added support for the Commodore 510 (aka P500) to the compiler
UvB> package. It is on par with CBM610 support, plus mouse and joystick routines.
UvB> When doing tests, I noticed that is is quite easy to port programs from the
UvB> C64 (or C128) to the P500, because it does also have a VIC and a SID and even
UvB> somewhat more free memory than the C64. As a result, the mousedemo and nachtm
UvB> samples do also run on the P500.
mmmh.... may it be even possible to port bigger c64 programs then?
what about the kernal/basic rom in the p500 (never heard of a C510
;=)) .... maybe an interisting target for a WiLD! Demo ;=P
UvB> When searching for more sample programs, I found the plasma.c code in your
UvB> package. It was rather slow with the official compiler release (2 frames per
UvB> second), and contained too much C64 specific code for my taste. So I did some
UvB> code cleanup (which improved the speed by almost 50%) and added a few macros
UvB> to make it compile for both, the C64 and CBM510.
would you sent that main.c to me in private mail? i'd love to checkout
what you actually changed in the code to make it faster :=)
UvB> The nice thing when writing your own compiler is that you can add
UvB> optimizations that will make your benchmark programs look good:-) (all chip
UvB> makers do this to get higher SPEC ratings). Adding such optimizations improved
UvB> the fps of the plasma.c sample by about 400% - it does now run with ~12 frames
UvB> per second (pure C!), and looks really great.
hehe NICE improvement really.... i actually was a bit disappointed
when i have seen it run at 2fps only since its VERY easy to get this
routine running in one frame (less than 60% of a frame actually) if
you code it in asm (that wouldnt even be the most optimized and
unrolled as hell version then)...
12 fps is VERY acceptable now i think, considering how hard the job
for the compiler is in this case :=) so would there be chance that one
will be able to write c-code that will compile the innerloop into
something like
...
lda xbuff,x
clc ; drop this in handcoded routine....noone
; on earth will notice the error ;=P
adc ybuff,y
ldy #$00
sta (screen),y
...
instead of accessing those 2 little buffers via indirect adressing
aswell ? (my first thought was, add some optimization to the compiler
so arrays <256 elements can be accessed via x/y indexed adressing)
btw, just for curiousity.... the same plasma compiled for WIN32 (using
mingw32 - YEAH i managed to set it up properly ;D) runs kind of DEAD
SLOW ,=P ~20fps in a 80x50 resolution (on p450) ... i am no more
wondering now why windoze apps are slowish hehehehe .=)
UvB> Because sample code is a great way to show people what is possible with the
UvB> compiler, and to get them started using the tool chain, I would like to ask if
UvB> you would allow me to distribute this code as part of the cc65 samples?
pretty much definetly YES ;=P if anything, i am writing those little
samples to show ppl what can be done and how ;=)
UvB> And, if anyone else is willing to contribute code that is written in C and
UvB> suitable as a sample program, please contact me. Things like graphics and
UvB> sound are great, because they are appealing for many end users.
i am probably going to knock up some more of those little things i
guess.... those kinda routines (plasma, radial mapping,
mandelbrot-zoomer, zoom-rotator etc) belong to my personal "test
suite" which i use to check how well certain techniques work on a new
platform.... and yeah, they make a pretty good benchmark aswell :o)
UvB> I will definitely try to get a new release out of the door, but unfortunately
UvB> there are several areas where more work is needed because essential features
UvB> are missing (there are programs that won't compile). I don't know, if I will
UvB> be able to have a closer look at your libraries until then.
well...no hurry.... those libraries are by far _NOT_ in a shape one
could add them to whatever serious 'official' release.... they do
somewhat work for the purpose i have used them for, but thats all....
take them as a sneak-peek into what i am playing around with, i just
thought i could share them even at this point since they could be
useful for some people.
however.... we have also talked about this before, i have almost
finished a library that can deal with floating-point numbers ;=) for
now its just a stub that wraps some functions from the basic-rom into
c-functions, but it implements all arithmetic/logical/mathematical
functions that you could think of (no derivated functions ofcoz),
including the cbm-basic specialty which is calculating n-grade
polynoms (very useful for calculating/approximating whatever
trig./math functions that could come across your way).
anyway, it works fine so far, just one question: how can i make SURE
that this library-module will be linked in say straight after the
startup-code (so it will never appear in the memory which is banked
under the basic-rom) ? theres not a high chance that this is going to
be a problem anyway i guess (not in my test programs however hehee)
but i'd ofcoz want to make it 100% right.
maybe there's a snapshot#2 soonish then ,=P (and after that... i need
hires-gfx lib so i'll implement it aswell hehe ,=))
--
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