cc2600 - a new C compiler for Atari2600

[+bsteux]

Hi,

I'm new to the Atari 2600 community, after buying a SECAM Atari on eBay and falling in love with it. I've quickly designed a new C compiler for the Atari 2600 using the Rust programming language (another thing I fall in love with). Now that it looks complete (I've written a full game with it : HappyBird), I wanted to share this new tool to you. You'll find it at https://github.com/steux/cc2600. Contributors are welcome to test it and write tutorials and examples of use. Here are the headlines :

 

# cc2600

cc2600 implements a subset of C compiler for Atari 2600. The main goal of cc2600 is to enable making games for the Atari 2600
using C language, including writing kernels, not to provide full C support for the 6502
(have a look at cc65 if this is what you are looking for). Any code written for cc2600 can be compiled with gcc, but not
the other way round... The 6502 processor is famous for being an inefficient target for C compilers, due to its poor
stack support, its infamous indexing modes and its lack of registers. In addition to the limitations of the Atari 2600 (128
bytes of RAM, strong reliance on bankswitching, low speed in general), the use of pure C on this platform is limited.
cc2600 tries to cope with these limitations by not strictly implementing all C features but mapping C syntax to the specifics of 6502,
in particular indexing modes.

 

Note that this compiler is for writing "old school" code for ATARI 2600. It's not meant to be used for CDFJ (custom ARM
code on the Melody/Harmony cart) development, where the 6507 code is reduced to the minimum. On the contrary, it was
designed to write code the classical atari way, possibly with DPC or DPC+ accelerators or a superchip for more RAM.

cc2600 should not be a starting point for writing ATARI 2600. You'll first have to learn writing games
in assembler (I definitely recommend reading "Making Games For The Atari 2600", by Steven Hugg, see https://8bitworkshop.com/docs/books).
On the other hand, if you're an experienced ASM code writer, you may gain a lot of time using cc2600 for your
next game development, since cc2600 will enable you to leverage the use of structural code writing.

 

cc2600 is implemented in the Rust programming language, a touch of modernity for a 45 years old console... The C language grammar has been handwritten from scratch as a PEG grammar, so don't expect any ANSI or ISO C compliance.  

 

## Main features

- Produces DASM compatible code ([DASM](https://github.com/dasm-assembler/dasm) is required as a second stage compiler)
- Native Atari F4, F6 and F8, 3E (lots of RAM!), DPC and DPC+ bankswitching schemes support
- Superchip (128 bytes of additional RAM!) support
- Uses only 1 byte of RAM
- load/store/strobe intrinsics allow the writing of efficient kernels.
- X and Y registers are directly mapped to X and Y variables, just like if they ware declared as unsigned char global variables.
- All C constructs are implemented (for, if, while, goto, etc).
- Clean bootstrap/bankswitching code is automatically generated
- PlusROM support for Wifi communication with PlusCART

 

## Known limitations

- The only data types supported are char (8-bit), short (16-bit) and char pointers (16-bits), and one dimensional arrays of chars and pointers.
- Only global variables are supported, not local variables (no use of stack. It's so slow on 6502 and so dangerous due
    to the lack of RAM that it'd be a bad idea anyway)
- Functions can't have arguments and return values (no use of stack). Everything must go through global variables.
- Array subscripts are limited to constants, X and Y variables / registers.
- 16-bits arithmetic is severely constrained. Generated code may not work if too complex (carry propagation is not ensured).
- No 32-bits operations, no floating point.
- Works with one C file. No linking provided. Use `#include "other_file.c"` to cope with this.

 

Have a look. Could be funny. I'll answer any question on this thread.

Best regards,

    B. Steux

 

[+splendidnut]

Cool, sounds like you went down the same path I went down:

 

But you've gotten further than I have. 

 

 

 

[JetSetIlly]

Nice work. Any plans to output DWARF data?

[+bsteux]

10 minutes ago, JetSetIlly said:

Nice work. Any plans to output DWARF data?

No, I don't think so. I've inlined the C code as comment into the generated ASM code, and I'm debugging with Stella. I found it quite convenient. Stella's debugger is very powerful.

[+Gemintronic]

I think BASIC developers would be more agreeable to switching over to C.  But, I have yet to find another language or development suite with generic, "canned" kernels.  Those already familiar with assembly and C assume they'll be making the graphical kernel first.   Beginners need something already in place that they can tweak later as their savvy grows.

[+bsteux]

16 minutes ago, splendidnut said:

Cool, sounds like you went down the same path I went down:

 

But you've gotten further than I have. 

 

 

 

Sorry for not seeing this before. Probably VERY close to what I've implemented indeed. Have you had any success with it ?

[JetSetIlly]

Just now, bsteux said:

No, I don't think so. I've inlined the C code as comment into the generated ASM code, and I'm debugging with Stella. I found it quite convenient. Stella's debugger is very powerful.

I only ask because Gopher2600 works with DWARF data to help debug C programs compiled for the ARM (PlusCart, Harmony, etc.) at the source code level. It's very useful and would be reasonably easy to expand to a C like language targeting the 6507.

 

Are you planning to output 6507 binary directly, removing the need for DASM?

[+bsteux]

2 minutes ago, Gemintronic said:

I think BASIC developers would be more agreeable to switching over to C.  But, I have yet to find another language or development suite with generic, "canned" kernels.  While those already familiar with assembly and C assume they'll be making the graphical kernel first beginner go further with something already in place that they can tweak later.

My idea was to provide more example kernels in the future (like DPC+ multisprite, which should be simple to achieve). But definitely it will never be as fit to beginners as Batari can be... It's still C.

[+bsteux]

1 minute ago, JetSetIlly said:

I only ask because Gopher2600 works with DWARF data to help debug C programs compiled for the ARM (PlusCart, Harmony, etc.) at the source code level. It's very useful and would be reasonably easy to expand to a C like language targeting the 6507.

 

Are you planning to output 6507 binary directly, removing the need for DASM?

OK. I understand better. I'll add this in my TODO list then. Indeed, I could output 6507 binary directly, but as a lot of people use DASM and already have DASM code to be inlined or included (for instance the i2c / atarivox code, or the TIATracker music code), I preferred to design it as a DASM code generator, like Batari. But frankly, it's just a matter of modifying assemble.rs (for the assembler code management) and build.rs (the code that builds the final cartridge code), so I may do that in the future.

[zzip]

4 minutes ago, bsteux said:

My idea was to provide more example kernels in the future (like DPC+ multisprite, which should be simple to achieve). But definitely it will never be as fit to beginners as Batari can be... It's still C.

I haven't touched BASIC in ages, but am pretty fluent in C so this is an interesting project.    I definitely would need kernel examples though or I wouldn't know how to approach 2600 programming otherwise.

[+bsteux]

1 minute ago, zzip said:

I haven't touched BASIC in ages, but am pretty fluent in C so this is an interesting project.    I definitely would need kernel examples though or I wouldn't know how to approach 2600 programming otherwise.

I've already put a few examples in the examples folder (but very basic, displaying a joystick movable garfield sprite in DPC and DPC+), and provided a full game (Paul's HappyBird). I'll try to develop the examples in order to address less "professionnal" atari 2600 programmers. But I think "professional" ones should be at ease, especially looking at the HappyBird game source code.

[Mr SQL]

Nice Tiny C implementation! I think you should leave DASM in place so that programmers may modify the assembly.

 

[+splendidnut]

1 minute ago, bsteux said:

Probably VERY close to what I've implemented indeed. Have you had any success with it ?

For me, it's been a success.  It's been immensely helpful when working on game logic.  I've got a couple of my work-in-progress game projects using it:  Congo Bongo, BCA, Bruce Lee...

 

All in all in was a worthwhile thing for me to do.

 

1 hour ago, bsteux said:

- Only global variables are supported, not local variables (no use of stack. It's so slow on 6502 and so dangerous due
    to the lack of RAM that it'd be a bad idea anyway)
- Functions can't have arguments and return values (no use of stack). Everything must go through global variables.

If you're interested in supporting these things, take a look at Neolithic.  It supports:

   - local variables by building a call stack and creating static local stack frames for each call stack level.  (actually works out quite well)

   - function arguments by pushing on stack or passing via register.  (I'm still working on my implementation... it is still buggy... it works out best to immediately store function args in local vars)

 

 

I know how much hard work goes into something like this... Congrats on your accomplishment!

[+bsteux]

1 hour ago, splendidnut said:

For me, it's been a success.  It's been immensely helpful when working on game logic.  I've got a couple of my work-in-progress game projects using it:  Congo Bongo, BCA, Bruce Lee...

 

All in all in was a worthwhile thing for me to do.

 

If you're interested in supporting these things, take a look at Neolithic.  It supports:

   - local variables by building a call stack and creating static local stack frames for each call stack level.  (actually works out quite well)

   - function arguments by pushing on stack or passing via register.  (I'm still working on my implementation... it is still buggy... it works out best to immediately store function args in local vars)

 

 

I know how much hard work goes into something like this... Congrats on your accomplishment!

Bruce Lee really ? I have to see that. That was one of my favourite games. Indeed, I haven't had too much look into stack management, since stack size is so small on 2600 that clash with variables in zeropage is not easy to avoid. But the idea of stack frames is nice, and I definitely need a way to add function arguments, as least through shadowing registers... Designing cc2600 was hard work, but I did it during a flu week when I was stuck to bed. Intensive programming with fever. I love Rust and Pest, so programming it was very funny indeed.

[+splendidnut]

Any plans to provide binaries for the compiler?  It's a bit hard to try out a compiler without being able to download and run it easily.

[WhyLee commotari.club]

have you evaluated the kickc c compiler as well?

[+bsteux]

On 2/17/2023 at 1:12 AM, splendidnut said:

Any plans to provide binaries for the compiler?  It's a bit hard to try out a compiler without being able to download and run it easily.

Hi,

Here is the latest installer for windows (generated by Cargo Wix), which is also published on Github (releases).

Best regards

cc2600-0.1.7-x86_64.msi

[+bsteux]

On 2/28/2023 at 3:34 PM, WhyLee commotari.club said:

have you evaluated the kickc c compiler as well?

Yes. To me, it is very similar to cc65. It's a very complete and capable C compiler targeting "bigger" 6502 platforms like C64 or NES. But unlikely suited to writing 2600 kernels, and lacking support for Atari 2600 specific bankswitching schemes like 3E or DPC/DPC+. cc2600 is designed as a complement to DASM, not as a full C compiler like cc65 or kickc.