Programming Languages

[Allas]

Well I modified the program and compiled with -Osir but visual speed not change.

 

This is the ML program version

        *=$0600

        pla

        ldy #$00

bucle   tya

        sta ($58),y

        iny

        bne bucle

        rts

 

 

This is the CC65 version

#define poke(addr,val)  (*(unsigned char*) (addr) = (val))

#define pokew(addr,val) (*(unsigned*) (addr) = (val))

#define peek(addr)      (*(unsigned char*) (addr))

#define peekw(addr)     (*(unsigned*) (addr))

int main (void)

{

   int n = 0;

   int x = peekw(0x58);

 

   for(n=0;n<702;++n)   // Print chars in screen

   {

     pokew(x+n,n % 256);

   }

 

   while(peekw(0xD01F)!=6) {  // Wait key START

   }

 

   n=0;               // Clear chars in screen

   while(++n<702)

   {

     pokew(x+n,0);

   }

 

   while(peekw(0xD01F)!=6) {   // Wait key START

   }

 

}

 

 

I use to compile cl65 -t atari -Osir prueba.c -o prueba.xex

There are much difference between ML and CC65 speed. So ML has the advantage that only use one byte counter offset to print chars. After all, I study the ML resulting from CC65 compiler.

 

prueba.zip

prueba2.zip

 

P.D. I feel very fine to program in C and it's incredible for me to see after years that CC65 had grown. I'm sure complex logic projects will be developed in right way. Last example, show differences about using WHILE and FOR loops. In any way, commands loops stole much procesing time. But I read more about.

Edited October 19, 2005 by Allas

[Shawn Jefferson]

This is the ML program version

 

That's quite a difference, which illustrates how hand-tuned assembly can be faster. Also, your C program is using double-byte math. It could be written to not use int data types. Still, you will never get the compactness and speed of hand made assembly.

 

I'm sure complex logic projects will be developed in right way.

 

That's really the power of high-level languages. You can build your project quickly and then optimize where its needed (if at all.)

[Wrathchild]

Try this for slightly better generated code, the use of statics

removes the overhead of using the CC65's stack to hold the

variables and hence call functions to maintain them.

 

#define poke(addr,val)  (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr)      (*(unsigned char*) (addr))
#define peekw(addr)     (*(unsigned*) (addr))

int main (void)
{
  static unsigned char n = 0;
  static unsigned char *x;

  x = (unsigned char *)peekw(0x58);

  n=0;
  do
  {
    x[n] = n;
  } while (n != 0);

  while(peek(0xD01F)!=6) {  // Wait START
  }

  n=0;
  do
  {
    *(x+n) = 0;
  } while (n != 0);

  while(peek(0xD01F)!=6) {   // Wait START
  }

}

 

Note too the difference in the loops in the of accessing memory.

This mirrors what your asm application was doing - your 'C'

file was using a larger range of addresses you wanted to fill/clear

and so the comparison wasn't really a fair one.

 

Regards,

Mark

Edited October 20, 2005 by Wrathchild

[devwebcl]

if you need speed you should use assembler, and for faster development can use high level language as cc65. anyway there are several optimization for C code as loop unroll.

trying to avoid division, modulos, etc (you can find in internet more information about it, I remember a pdf paper for Arm CPU optimization but it can be used for any C compiler).

 

for examples change loop (for(;<N;)) for the same N explicit commands of course only if you know how many iteration are going to be. in your example is very clear so this is it. (modulo division also I took it out)

 

the performance is much better but still it's as good as assembler code.

attached there are several examples of it.

 

cheers,

 

--devwebcl

 

 

#define poke(addr,val)  (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr)      (*(unsigned char*) (addr))
#define peekw(addr)     (*(unsigned*) (addr))

int main (void)
{
  int n = 0;
  int x = peekw(0x58);

  // Print chars in screen
 pokew(x+0,0);
 pokew(x+1,1);
 pokew(x+2,2);
 pokew(x+3,3);
 pokew(x+4,4);
 pokew(x+5,5);
 pokew(x+6,6);
 pokew(x+7,7);
 pokew(x+8,8);
 pokew(x+9,9);
 pokew(x+10,10);
 pokew(x+11,11);
 pokew(x+12,12);
 pokew(x+13,13);
 pokew(x+14,14);
 pokew(x+15,15);
 pokew(x+16,16);
 pokew(x+17,17);
 pokew(x+18,18);
 ...
 ...
 ...
 pokew(x+666,154);
 pokew(x+667,155);
 pokew(x+668,156);
 pokew(x+669,157);
 pokew(x+670,158);
 pokew(x+671,159);
 pokew(x+672,160);
 pokew(x+673,161);
 pokew(x+674,162);
 pokew(x+675,163);
 pokew(x+676,164);
 pokew(x+677,165);
 pokew(x+678,166);
 pokew(x+679,167);
 pokew(x+680,168);
 pokew(x+681,169);
 pokew(x+682,170);
 pokew(x+683,171);
 pokew(x+684,172);
 pokew(x+685,173);
 pokew(x+686,174);
 pokew(x+687,175);
 pokew(x+688,176);
 pokew(x+689,177);
 pokew(x+690,178);
 pokew(x+691,179);
 pokew(x+692,180);
 pokew(x+693,181);
 pokew(x+694,182);
 pokew(x+695,183);
 pokew(x+696,184);
 pokew(x+697,185);
 pokew(x+698,186);
 pokew(x+699,187);
 pokew(x+700,188);
 pokew(x+701,189);


  while(peekw(0xD01F)!=6) {  // Wait START
  }


}

pruebas.zip

Edited October 21, 2005 by devwebcl

[danwinslow]

Uh, well, no offense devwebcl but thats sort of unrealistic. Yes, its fast, but you might as well use assembler. Maybe thats your point

 

I find that its very good to write things up in C, and then use CC65's inline ASM function to hand optimize where necessary. Using single byte code *really* helps as well. And, remember you can do all the same look up math table tricks in C that you can in assembler, not to mention pointer arithmetic. Really, C is just a kind of very fancy macro assembler.

Edited October 20, 2005 by danwinslow

[Shawn Jefferson]

And, remember you can do all the same look up math table tricks in C that you can in assembler, not to mention pointer arithmetic. Really, C is just a kind of very fancy macro assembler.

951626[/snapback]

 

If you look in the graphics library I started, I used some lookup tables for just that reason. I'm sure more can be done there...

[devwebcl]

Uh, well, no offense devwebcl but thats sort of unrealistic. Yes, its fast, but you might as well use assembler. Maybe thats your point

 

no, no offense at all, this is a forum and it's here to write down our ideas

and yes, asm always is going to be the fastest language, but what I'm trying to show is that there are several optimization tricks for C language and the most famous is loop unrolling buecause in this way you avoid asm instructions in the final macro code when it's linking and compiling the C compiler

 

like we mentioned: also trying to avoid expensive functions like division, trigonometric, etc, there is better to use tables, use the basic word for variables (int usually is in C).

the for(; making it, the comparision always against zero. avoid recursion.

 

here there is a good article:

http://www.codeproject.com/cpp/C___Code_Optimization.asp

 

--devwebcl

[Shawn Jefferson]

here there is a good article:

http://www.codeproject.com/cpp/C___Code_Optimization.asp

 

That is a good article, but also read the cc65 documentation since a lot of optimizing C code is compiler/processor dependent.

 

http://www.cc65.org/doc/coding.html

 

For instance, unsigned int isn't the best data type to use on the 6502. unsigned char is what you would use. Also there is a mailing list for cc65 (check the www.cc65.org website) where several asm and C wizards can answer our questions. I know because I've asked all sorts of stupid questions of them.

[Allas]

Im in the middle of a simple game that use bitmappings, direct draw in screen and sprites. I read most of the ATARIGFX library. As Shawn said, sprites still dont work.

 

Another simple problem I found : inverse video text cant be printed in screen, only I get garbage in his place.

 

Do you get any progress in ATARIGFX? I feel I use every command , and im very happy with more functions added.

[Shawn Jefferson]

Im in the middle of a simple game that use bitmappings, direct draw in screen and sprites. I read most of the ATARIGFX library. As Shawn said, sprites still dont work.

 

Another simple problem I found : inverse video text cant be printed in screen, only I get garbage in his place.

 

Do you get any progress in ATARIGFX? I feel I use every command , and im very happy with more functions added. 

974642[/snapback]

 

Sorry, I don't have time to do any development on it, that's why I released the source that I do have. There most likely are bugs in the ascii to screen routines that I wrote, and probably a better way to do it anyway.

[+MrFish]

Well I finished to scan the Quickcode manual. If anyone put the ATR image of Quickcode will be a great help.

944657[/snapback]

 

Thanks for the manual Allas. Has anyone come up with an ATR for this yet?

[+MrFish]

From what I have read (and now learning by typing in the manual), ACTION! is supposed to be pretty easy to learn and can be compiled.  Run-Time files have to be included with the distribution which limits it to being a disk I believe.  If you want to do a straight Binary file (for cartridge), one of the assembler's would probably would do you best, but harder to learn than say BASIC or ACTION!  If you do a google, you can find many reviews of them.  Also, the Wikipedia (http://www.wikipedia.org) has information on the different programmig languages for the Atari 8-Bit.

 

As for the action manual, should be done in a couple weeks.

 

Corey

943296[/snapback]

 

How's it coming on the Action manual? Looking forward to this. BTW, thanks for the Basic XL manual. Great job.

[Allas]

Well I finished to scan the Quickcode manual. If anyone put the ATR image of Quickcode will be a great help.

944657[/snapback]

 

Thanks for the manual Allas. Has anyone come up with an ATR for this yet?

979720[/snapback]

 

 

I cant believe any atarian in the earth have the Quikcode manual, specially the assembler coders. Quickcode its the best library for Assembler. But, I know someone who should have it. Just, the owner manual

 

That was 20 years ago...

Edited December 10, 2005 by Allas