Atari 2600 libraries for C compilers?

[jdrose]

Hello,

 

I was wondering if there are any libraries for the Atari 2600 that were developed for C compilers that produce native 6502 code such as DVC or Ace for example. Wondering if a C compiler could produce tighter code than the BASIC compiler?

[+Gemintronic]

There may be some support in cc65. Dunno.

bB already has a hand optimized assembly kernel for the game engine it produces. C would be more flexible but then your own engine would be relying on how well that particular C compiler assembles stuff.

[jdrose]

Thanks. I like CC65. It is a handy 6502 C cross compiler that includes an assembler as well. My gut feeling is dB would produce tighter code because it is optimized for the Atari 2600. However, I much prefer C to BASIC. May have to develop some libraries for CC65 and see the difference in program size. 4K is precious little to work with. Gotta conserve every byte.

[+Gemintronic]

I think the 7800 C scene is a little more mature. You may consider going 7800 and cc65 for a more comfortable fit

 

This guy has source for his Robot Finds Kitten port:

http://rfk7800.sourceforge.net/

[GroovyBee]

With 128 bytes of RAM on the 2600 you'd have a hard time to use it as a stack, compiler temporary storage, software parameter stack and your own program variables all at the same time. I suspect that for any non trivial program you'd spend most of your time looking at the assembly language produced by your "C" code to see what it was doing to the extent that you might as well have written it in assembler in the first place .

[Csonicgo]

With 128 bytes of RAM on the 2600 you'd have a hard time to use it as a stack, compiler temporary storage, software parameter stack and your own program variables all at the same time. I suspect that for any non trivial program you'd spend most of your time looking at the assembly language produced by your "C" code to see what it was doing to the extent that you might as well have written it in assembler in the first place .

 

Does not the Harmony allow for 8KBytes Accessible RAM? That may help in this case. I may not be well-read on the harmony setup but it's very tempting.

Edited January 14, 2013 by Csonicgo

[GroovyBee]

Does not the Harmony allow for 8KBytes Accessible RAM? That may help in this case. I may not be well-read on the harmony setup but it's very tempting.

 

There is no write signal available on the cart slot on a 2600. When RAM is read/written from/to on cart you use different addresses to access the same variable. By doing that the banks witching firmware knows the difference between a CPU read and write cycle and handles the data bus correctly.

 

On the CC65 compiler system you can create segments of memory. So you'd have a segment for read only RAM data (not the same as RODATA) and another segment for write only RAM data (not the same as BSS or DATA). In "C" you'd end up with code that looks like :-

 

wFoo=8;

....

t=rFoo;

 

Where wFoo is used to write a value and rFoo is used to read the same value back. Handling code like this creates more complex language statements. Simple "C" code like :-

 

++fred;

 

Would normally produce the following code sequence (only if fred has scope beyond the function) in assembler once compiled :-

 

inc fred

 

When you need to access two different memory regions to get the same effect the code becomes :-

 

wFred=rFred+1;

 

Which would compile to something like :-

 

clc
lda rFred
adc #1
sta wFred

 

Which adds a ton more cycles and ROM overhead as well.

 

You'd also have to modify all the standard library functions (which use the software parameter stack) to use the two separate memory space approach. Its certainly doable should anybody have the time or the inclination.

 

In my opinion batari Basic is much more suited to games development on the 2600 compared to "C" because its specifically adapted for it.

[roland p]

I once used macro's mostly for 16bit operations which could also be considered 'high level' as in high level language. I stopped using them because my code got bloated and I missed a lot of oppertunities to optimise my code.

[Matthew]

If there was a good C compiler/headers/ide for the 7800, I would start programming for it. I doubt cc65 produces tight enough code.

Edited January 25, 2013 by Matthew

[GroovyBee]

If there was a good C compiler/headers/ide for the 7800, I would start programming for it. I doubt cc65 produces tight enough code.

 

I've used CC65 "C" on the 7800 for several years now. Like most "embedded" style compilers you can adapt your coding style to get pretty good results. If a routine isn't performing well then rethink the algorithm or convert it to assembler (or both ) just like you would on any other platform. I also have my own games development library that is written in assembler for handling display lists, sprites, joystick, collisions, sound/music etc. which can be called from the logic/AI of the game written in "C".

[Matthew]

I've used CC65 "C" on the 7800 for several years now. Like most "embedded" style compilers you can adapt your coding style to get pretty good results. If a routine isn't performing well then rethink the algorithm or convert it to assembler (or both ) just like you would on any other platform. I also have my own games development library that is written in assembler for handling display lists, sprites, joystick, collisions, sound/music etc. which can be called from the logic/AI of the game written in "C".

 

 

I did something similar to this years ago for DOS. I wrote some assembly(8086) routines to handle the graphics and input, while programming the game logic in c.

 

If it were possible to produce games like this

 

 

/*Don't try to compile, you will break the matrix*/
#include <7800.h>
Byte *player={,,,,,,,,,,,,,,};
BYTE X=0;
BYTE Y=0;
void main void()
{
init7800();
Display->LoadSprite(0,player);
/*gameloop*/
while(1){
if(Joystick1->Right==1)X+=1;
if(Joystick1->Left==1)X-=1;
Display->ShowSprite(0,X,Y);
}
}

 

Then I would give it a go, otherwise, just not prepared to spend the time.

 

If a good commented library was publicly available, there would be far more homebrew games for the 7800. Especially if it added a layer of abstraction(i.e Don't need to know how the hardware works to create a game).

Edited January 25, 2013 by Matthew

[GroovyBee]

Then I would give it a go, otherwise, just not prepared to spend the time.

 

It kinda works like that.

 

If a good commented library was publicly available, there would be far more homebrew games for the 7800. Especially if it added a layer of abstraction(i.e Don't need to know how the hardware works to create a game).

 

You can't get away from not knowing something about the hardware unfortunately. The 7800 is a constrained system so techniques you might use on a multi-GHz PC with loads of RAM don't always scale down to 8 bitter capabilities. You need to know about MARIA's DLL, DLs, DLI's and how zones are broken down and composed otherwise you won't make interesting games. I do have plans to create a tool to help with that at some point. I have tools for graphics bitmap conversion for all MARIAs graphics modes (e.g. 160A, 160B, 320A, 320B, 320C and 320D) already done.

[+Gemintronic]

Actually, my brain is a constrained system - MARIA is quite flexible!

[danwinslow]

CC65 is great and usable on the 8 bit lineup, as mentioned you have to code carefully and skip a lot of the usual C library stuff. 2600 work is not feasible is my opinion.

[+SpiceWare]

I've got 4 projects in the pipeline for the 2600 that are mostly coded in C. The C is compiled as ARM code for the Harmony/Melody board. Homebrew topics exist for Space Rocks and Frantic, and source is available in their respective blog categories.

[Matthew]

Maybe that's the go. A light wait reusable multi-sprite kernel written in assembly, then the actual game is written in c for the on-board ARM.

 

Just have to wait for Harmony 2 for the 7800. (And a smart cookie to write the re-usable kernel + c libs).

Edited January 26, 2013 by Matthew

[GroovyBee]

Maybe that's the go. A light wait reusable multi-sprite kernel written in assembly, then the actual game is written in c for the on-board ARM.

 

You'll still have know about how MARIA operates .

[Csonicgo]

I've got 4 projects in the pipeline for the 2600 that are mostly coded in C. The C is compiled as ARM code for the Harmony/Melody board. Homebrew topics exist for Space Rocks and Frantic, and source is available in their respective blog categories.

 

amaaazziiinggg. This is awesome. I can do C for ARM, as that's what my hobby is. can't wait to get started.

[+Gemintronic]

amaaazziiinggg. This is awesome. I can do C for ARM, as that's what my hobby is. can't wait to get started.

 

Then why don't you ask SpiceWare for his build environment and libraries? Or, is just his source enough?

[bogax]

With 128 bytes of RAM on the 2600 you'd have a hard time to use it as a stack, compiler temporary storage, software parameter stack and your own program variables all at the same time. I suspect that for any non trivial program you'd spend most of your time looking at the assembly language produced by your "C" code to see what it was doing to the extent that you might as well have written it in assembler in the first place .

I think I disagree.

bB does all those things and would probably benefit from a data stack.

I think the problem is the overhead involved in implementing one on a

processor not built for it. And I think that's more a problem of speed

than of space.

Edited February 1, 2013 by bogax