From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-09-26 17:17:27
Hi!
On Wed, Sep 26, 2001 at 03:47:08PM +0200, groepaz wrote:
> 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)
What I've seen it is quite C64 specific but as I said I didn't have a closer
look because I have so many open topics with the current development compiler
and I didn't want to start new ones.
> 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
Well, what I said was not correct. Programs on the C64 have 50K memory
available, on the CBM510 it is 48K. This is somewhat less as with the CBM610
machines, mostly because I had to move the complete VIC data including the
character ROM into the execution bank to make sprites possible (which are
needed for the mouse support). But this does also mean that the character data
is also in RAM and modifyable.
> 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 :=)
I will send you the changed source in private mail and add it as a new sample
program to the head branch. Most of the changes are for readbility, some more
to support other platforms than the C64, and a great part of the remaining
changes do not help with the current stable compiler version. See my next mail
for a discussion of the changes that were responsible for the first 50%
speedup.
> 12 fps is VERY acceptable now i think, considering how hard the job
> for the compiler is in this case :=)
Here is what the current development compiler generates for the inner loop:
;
; for (i = 0; i < 40; ++i, ++scrn) {
;
.dbg line, "test.c", 115
lda #$00
sta L0109+0
L0155: lda L0109+0
cmp #$28
bcs L014F
;
; *scrn = (xbuf[i] + ybuf[ii]);
;
.dbg line, "test.c", 116
lda _scrn+0
ldx _scrn+0+1
sta ptr1
stx ptr1+1
ldx L0109+0
lda L0106+0,x
sta sreg
ldx L010A+0
lda L0108+0,x
clc
adc sreg
ldy #$00
sta (ptr1),y
;
; for (i = 0; i < 40; ++i, ++scrn) {
;
.dbg line, "test.c", 115
inc L0109+0
inc _scrn+0
bne L0155
inc _scrn+0+1
jmp L0155
I think this is rather good, and it is almost impossible to generate better
code with an all purpose compiler/optimizer.
> pretty much definetly YES ;=P if anything, i am writing those little
> samples to show ppl what can be done and how ;=)
Thanks!
> 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) ?
You may add the module as the second module on the command line, or you may
use a special memory setup. When using banking you will probably need such a
setup anyway, because some of the code may be banked, while other code and all
of the data must always be available.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
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