cc65 for Windows

[Songbird]

I got this to work, however the screen has some garbage at the bottom of the display. Is the "Hello World" program missing something or did I not build it properly?

 

Also, where can I get documentation on the TGI library functions? Thanks!

[+karri]

I got this to work, however the screen has some garbage at the bottom of the display. Is the "Hello World" program missing something or did I not build it properly?

 

Also, where can I get documentation on the TGI library functions? Thanks!

 

You may need to add a tgi_clear to set the screen black before writing the text.

 

The docs are in the doc folder of the compiler. I include them here as a zip file.

/*****************************************************************************/
/*                           TGI extras                                      */
/*****************************************************************************/
/* Color defines */
#define COLOR_BLACK             0x00
#define COLOR_RED               0x01
#define COLOR_PINK              0x02
#define COLOR_LIGHTGREY         0x03
#define COLOR_GREY              0x04
#define COLOR_DARKGREY          0x05
#define COLOR_BROWN             0x06
#define COLOR_PEACH             0x07
#define COLOR_YELLOW            0x08
#define COLOR_LIGHTGREEN        0x09
#define COLOR_GREEN             0x0A
#define COLOR_DARKBROWN         0x0B
#define COLOR_VIOLET            0x0C
#define COLOR_BLUE              0x0D
#define COLOR_LIGHTBLUE         0x0E
#define COLOR_WHITE             0x0F


#define tgi_sprite(spr) tgi_ioctl(0, spr)
#define tgi_flip() tgi_ioctl(1, (void*)0)
#define tgi_setbgcolor(bgcol) tgi_ioctl(2, (void*)(bgcol))
#define tgi_setframerate(rate) tgi_ioctl(3, (void*)(rate))
#define tgi_busy() tgi_ioctl(4, (void*)0)
#define tgi_updatedisplay() tgi_ioctl(4, (void*)1)
#define tgi_setcollisiondetection(active) tgi_ioctl(5, (void*)(active))

 

docs.zip

[LX.NET]

While not official documentation this might be of interest:

https://atarilynxdeveloper.wordpress.com/2012/04/19/programming-tutorial-part-5exploring-tgi/

[Songbird]

Thanks, Karri. Yep, the tgi_clear() did the trick -- that should get added to the Hello World program.

 

Regarding the docs, I don't see those HTML files in the tools/cc65/doc folder. All I see there are a bunch of SGML files (which my PC doesn't know how to interpret), and I only see a single lynx.sgml file there instead of the many HTML files. Thanks for providing the zip file!

[+karri]

Great!

 

The doc's are only built if you include the package "linux doctools". You can add that and build the docs by yourself too.

 

The best source is really LX.NET tutorial. It is clear and user friendly compared to the dull docs.

[Irgendwer]

The old compiler also created tighter code than the new one. Some of my old games did not fit in the rom with the newer compiler anymore.

 

You may like to try out the current version of cc65, as I improved the run-time code for the 65SC02. Your experience would be interesting.

[+karri]

 

You may like to try out the current version of cc65, as I improved the run-time code for the 65SC02. Your experience would be interesting.

 

I appreciate your suggestion. The text baselines have changed in the modern cc65 so I need to add a bit of remapping ifdefs in order to get it to work. Besides I have not followed the posting lists for years so I have no idea of what to expect.

 

Once I get Solitaire updated I could give it a try.

[Positron5]

This is a part conversion of Bastian Schick's (@42bs) fpolygon.inc/bll routine that I have made to be used with CC65 for Windows. This version draws triangles. I have changed the maths registers names to be the same as the hardware reference notes to make the program easier to understand . I have only converted the triangle drawing part of Bastian's code- which creates larger polygons with more vertices.

I am grateful for Bastian granting his permission to use his bll code. Please read the readme.1st file that comes included with the bll atari Lynx devkit of which Bastian is the author and all right reserved.

As it stands The resulting object file (game.o) can be run under mednafen emulator https://mednafen.github.io/ . copy the game.o file to the mednafen directory then in mednafen the usage is: mednafen game.o
The program waits for the button A to be pressed.

Cheers Positron

triangle.zip

[rmzalbar]

 

You may like to try out the current version of cc65, as I improved the run-time code for the 65SC02. Your experience would be interesting.

 

Would the current cc65 snapshot (2.17 xxxx) be recommended for cc65 Lynx development? With regards to thread recommendations to use a particular older version.

[rmzalbar]

I'm having an issue getting sprite chaining to work with cc65. The _suzy header appears to want a pointer reference (char *next) for next sprite. However, when I use a pointer to an SCB struct name, I get an incompatible pointer types error.

 

I can draw these two sprites individually so long as *next is set to 0, but trying to reference any SCB from any other for chaining is producing this compile error. So far as I understand pointers, I think I'm doing it correctly - but I'm not an expert in C.

 

Here are two SCB structs. backgrndsprite wants to chain to robotsprite, at line 34. The error is: game.c(34): Error: Incompatible pointer types at 'robotsprite.'

 

Using cc65 V 2.17.

 

Thank you,

SCB_REHVST_PAL robotsprite = 
{
  BPP_4 | TYPE_NORMAL,
  PACKED | REHVST,
  0x01,
  0,
  &robota,
  10, 20, 0x0100, 0x0100, 0x0000, 0x0000,
  { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }
};

SCB_REHV_PAL backgrndsprite = 
{
  BPP_4 | TYPE_NORMAL,
  PACKED | REHV,
  0x01,
  &robotsprite,
  &backgrnd,
  0, 0, 0x0200, 0x0200,
  { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }
};

[Turbo Laser Lynx]

If I remember correctly I think you should use the pointer name and not the sprite name, i.e. &robota would be correct instead of &robotsprite.

Edited April 2, 2018 by Turbo Laser Lynx

[+karri]

Well...

 

Obviously the definition is wrong in _suzy.h.

 

You should be able to cast the real sprite pointer to a char like

SCB_REHV_PAL backgrndsprite = 
{
    BPP_4 | TYPE_NORMAL,
    PACKED | REHV,
    0x01,
    (char *)&robotsprite,
    &backgrnd,
    0, 0,
    0x0200, 0x0200,
    { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }
};

This is a cludge. But if the sprites are of different types creating a generic next field is a bit tricky.

[rmzalbar]

Thi

 

Well...

 

Obviously the definition is wrong in _suzy.h.

 

You should be able to cast the real sprite pointer to a char like

[...]

(char *)&robotsprite,

This is a cludge. But if the sprites are of different types creating a generic next field is a bit tricky.

 

This worked! What do you mean by different types of sprites?

[42bs]

I guess he refers to sprite type: SCB_REHV_PAL. Which could be different. Actually, the next pointer should be a "void *", which makes it easier to insert any pointer.

[rmzalbar]

After a few agonizing months where 'life' 'happened' to me, I've gathered myself enough to pick this up again. Finally worked out how to make a struct of typedef'd SCB structs, so now I can track an array of bullets, which was my main obstacle to making them go and do things.

 

I suspect I shouldn't be abusing cc65's struct handling that way, and I should use ASM blocks to set up and reference them as others do, but I wanted to see it through until I understood what I was doing wrong first. The score is showing the bullet index, which I needed for troubleshooting. The second number is a player walk speed factor, adjustable from 1-100. Also, diagonal walk is speed-corrected.

 

Super fun so far. I'm not a C programmer, but I may be close to being one by the time I get a real game out of this

Edited July 7, 2018 by rmzalbar

[LordKraken]

Since I'm still using the old "new cc65" compiler, I can't say how much this applies to your compiler, but I'm pretty confident you can "abuse" c-struct as much as you want. The only thing you're risking is to lose a few bytes, esp. when using array of struct (this is particulary true with "new" cc65).

 

What I do for instance is instead of doing something like this:

myArray.hpos = xxx;

myArray.hpos = yyy;

myArray.hsize = zzz;

...

I get a pointer on the array liek that:

struct MyStruct* myStruct = &myArray;

and then:

myStruct->hpos = xxx;

myStruct->hpos = yyy;

myStruct->hsize = zzz;

 

 

This saved me hundred of bytes in my binary.

Edited July 7, 2018 by LordKraken

[rmzalbar]

Since I'm still using the old "new cc65" compiler, I can't say how much this applies to your compiler, but I'm pretty confident you can "abuse" c-struct as much as you want. The only thing you're risking is to lose a few bytes, esp. when using array of struct (this is particulary true with "new" cc65).

 

Too much of what I'm doing is trial and error. I'm not used to programming for memory efficiency. I get the concept of pointers OK, but not always why to use them, or what exactly is happening in some situations. The arrow operator you've used was unknown to me. I've just received The C Programming Language book, and this will be my bedtime reading for the next few days.

 

Anyway, shooting happens now:

Edited July 9, 2018 by rmzalbar

[+karri]

 

A good way to see how cc65 deals with the structures is to compile it with

cc65 -t lynx --add-source roadseg.c

It will create an assembler file with C-code inserted as comments.

 

/* ----------------- Road -------------------- */
unsigned char pixel[] = { 3, 0x84, 0, 0 };


static SCB_REHVST_PAL Spixel = {
    BPP_1 | TYPE_BACKGROUND,
    0x30, 0x20,
    0,
    pixel,
    50, 50,
    0x2800, 0x800,
    0x00, 0x100,
    {0x68}
};

will become

 

_pixel:
        .byte   $03
        .byte   $84
        .byte   $00
        .byte   $00
_Spixel:
        .byte   $00
        .byte   $30
        .byte   $20
        .word   $0000
        .addr   _pixel
        .word   $0032
        .word   $0032
        .word   $2800
        .word   $0800
        .word   $0000
        .word   $0100
        .byte   $68
        .res    7,$00

 

 

roadseg.zip

[rmzalbar]

Screenshot from 2018-07-09 13-50-57.png

 

A good way to see how cc65 deals with the structures is to compile it with

cc65 -t lynx --add-source roadseg.c

It will create an assembler file with C-code inserted as comments.

 

 

Nice! This will be useful immediately, because right now I am getting slowdown when there are 10 sprites on the screen, and I need to determine if it's code or hardware limitation.

 

All sprites are chained, and redrawn as soon as tgi_done.

 

- Playfield sprite (is also the blanking sprite)

- Player robot

- up to 10 bullets

 

Any bullets 8 or more causes slowdown when refresh is set to 60. Doesn't matter if page flip or not. Looking as ASM will probably help, and I can read timers or hblank to see how long my things are taking.

Edited July 9, 2018 by rmzalbar

[+karri]

The normal way to create real time games is to process time and display separately.

 

The Lynx is not fast enough to display all in-between frames,

[42bs]

 

Nice! This will be useful immediately, because right now I am getting slowdown when there are 10 sprites on the screen, and I need to determine if it's code or hardware limitation.

 

Likely a SW not a HW limit I made a small demo with bouncing "balls" (or a "gas simulation") with 20 particles + border and collision.

[rmzalbar]

That's good, because it gives me something to do. The arrays-within-arrays method of updating my SCB chain each blank isn't doing it any favors. 2800 lines of ASM code got generated just for what I've shown so far.

Edited July 10, 2018 by rmzalbar

[LordKraken]

Get a pointer on your struct, that should reduce your code by a fair amount

[42bs]

 

All sprites are chained, and redrawn as soon as tgi_done.

 

I don't think, it is a good idea to chain the sprites, even if it is possible. Inserting/removing would take to much time.

Rather maintain an array for the bullets and draw them separately.

[LordKraken]

42bs > Couldn't he keep the sprites chained and set a null sprite when the bullet is inactive (or set the zoom factor in the scb to zero)?

 

rmzalbar > Screen refresh might be 60hz but my experience is that if you're asking too much, the actual "frequency" will get reduced by 2, then 3, then 4 and so on. So if you're basing your animation on 60fps but you're asking too much you will soon discover (you did already!) that the lynx will reduce the framerate to 30 fps (60/2), then 20 fps (60/3) then 15 fps (60/4) etc. In your specific case it will explain why all of a sudden the bullet goes 2 times slower!

 

Try to create a timer and do your animation based on it. The speed will be the same, no matter what the frequency is.

 

I can help you with some code if you want.

Edited July 10, 2018 by LordKraken