Jump to content
  • entries
    6
  • comments
    34
  • views
    7,547

Maybe yet another C Compiler for 6502 programming...

splendidnut

208 views

Mocha/BCA Announcement

 

Usually, the biggest hassle with getting things done for me has always been a lack of enough big chunks of free time to do stuff.  Due to the current pandemic, that is no longer the case.  Since I'm pretty much home-bound waiting for the weather get warmer, I have a lot more free time to work on personal projects.

I've been wanting to announce and talk about my current projects for a while.

 

I'm in the process of developing a C-like compiler focused on generating optimized 8-bit code for the 6502 to use for developing projects for the Atari 2600.  There have been a few people that have announced projects like this a few years ago, all of which seem to have stalled out.  That's why I'm a bit hesitant to annouce this.  I wanted to wait until I was further along, so that I could actually feel confident enough to release a beta-version of the compiler.

 

Currently the compiler does work to a point... As long as the code remains relatively simple, the compiler produces decent assmebler code which can then be fed thru DASM to get a working program.  Anything the compiler can't handle, it either yells loudly about (usually syntax errors that can't make it thru the parser), or let's you know there was an error and still produces an assembly file containing all the code it could compile.

 

In parallel with the compiler, I'm working on a game that I started long before ChaoticGrill.  I've been able to get a somewhat simpler version of the original display kernel programmed and running in C code.  Which shows that, Yes, you can write a display kernel in C for the 6502.  The only thing in the demo that has strickly been written in 6502 code, is the Sprite Positioning routine.

 

Working on the two in parallel, while a bit slower... seems to keep the motiviation going as I flip back and forth between the two.  While working on the game/demo when I hit a need for something to be implemented in the compiler, I can switch over and implement it.  And when I get tired of working on the compiler, I can always switch back.

 

----

This all came about because I was playing around with a lot of different things the past several months...


  *  Progress on Chaotic Grill has been slow because I'm now at the point where I need to fill in the framework surrounding the game:  the titlescreen, menu system, extra features... like SaveKey support.  On top of debating whether I want to add anything to the gameplay.
 
  *  I've been thinking about writing a compiler for a while now.  It's something I've always wanted to do, but just haven't had the time or motivation.  I've spent some of my free time playing around with some old Turbo Pascal projects, experimenting with old C/C++ compilers, and digging more in depth into Javascript.  And that has all led me back around to thinking of developing my own compiler... which led to the root of this project.
 
  *  I did some experimenting with CC65 and trying to get something compiled and running for the Atari 2600.  I was able to get a very simple display kernel working... but only after I started hacking away at the CC65 code base, adding my own code optimizers into CC65's vast optimizer code base.  There was some success... but it was a bit of a painful process.  Ultimately I came to the conclusion that, while you could do a project in it (other's have... Robo Ninja Climb / https://atariage.com/forums/topic/280856-robo-ninja-climb-atari-2600/ ), you kind of had to jump thru hoops to do it.
 
  *  I attempted to experiment with the C02 Compiler (https://atariage.com/forums/topic/267074-c02-compiler/), but it appears there's a very constraining identifier length limit (6 chars!!!!)... which the codebase itself adheres to also.  After trying my previous efforts hacking away at CC65, I was not about to do that again.... There were also some other reasons, but I don't remember what they were.  This was the final push into developing my own compiler.
 
----

For the most part, the compiler I've written trys to following somewhat closely with the C89 (Ansi) spec.  My main reference has been "The C Programming Language: Second Edition" by Brian W. Kernighan and Dennis M. Ritchie.

 

I'm probably not going to implement Preprocessor stuff...  I currently have one, it only processes the #include stuff (in a very hacky/not quite implemented fully way), but I'm debating just pushing that into the parser itself.  I will not be one to enable "macro abusers" :) Constants are currently implemented and working, and I'll be adding either a manual or automatic function inliner.  Both of which are usually what macros are used for.

 

I've greatly simplified the variable declaration stuff.  Only handling 8/16 bit values, pointers and arrays.  The most complicated thing you can create is an array of pointers:  char *gfxPtrs[5];  So far, I've found this to be sufficient.

 

I've yet to implement one of the features I'd really like to see:  Inline assembly.  It hasn't been done yet, mainly because I'll need to write a parse/code generator for that.  i.e.  Lazy...  I've got my position sprite routine... what more do I need?  :) Uhh... a score kernel...

 

So far, the compiler mainly deals in byte-based operations... there are a few things that can work with integers (mainly for the current pointer support), but for the most part, the 16-bit support is missing.  For comparisons, signed/unsigned-ness has generally been ignored, mainly because I haven't used it that much.


-----


Overall, despite that half-implementation of most things... I've been slowly adding features to make the compiler ready for general consumption.  Or at least tolerable.  Since I currently don't know when I can throw anything out there, I decided to make this a blog post instead of a general announcement. 


Oh... and here's two binaries.  One of the original game project in ASM (pre-ChaoticGrill), and one of the C reimplementation using the aforementioned compiler.  And might as well throw some C source code out there too.

 

Feel free to ask questions or comment.

 

--Philip

 

 

bca-asmEng.bin bca-mocha.bin bca.c

 

  • Like 1


11 Comments


Recommended Comments

Sounds like quite the challenge, although I have to wonder what you are planning on using it for.  It's not like you're going to implement the standard C libraries on the 2600.

 

For me, I'd start with what problem I'm trying to solve and then build up something from there.

Share this comment


Link to comment

There's really no need for the standard C library as I plan to use this mainly to write games for the Atari 2600.  While my experience with working on Chaotic Grill (my Atari 2600 port/remake of BurgerTime) in 6502 assembly has been a nice experience, I'd like to try and speed up that process by writing in a higher level language.  After seeing how quickly @johnnywc and cohorts brought Galaga to fruition (which was partially attributed to the use of C on the ARM/Melody platform), I figure that my biggest issue with ChaoticGrill had been the lack of flexibility that assembly language provides... There were a few times in which I needed to rewrite large portions of the code to move forward.

 

You may ask: So why not BatariBasic (Bb)?  Well, while Bb provides a nice way for coders and non-coders alike to develop games for the Atari 2600... It relies on canned kernels... and it seems to be a little bit of a pain to include/use your own assembly display kernels.  Granted this is all from what I gathered from reading thru posts, especially @Karl G's posts in which he does a great service to the Bb community by using his skills to help others in this aspect.

 

Overall, developing this compiler has been surprisingly rewarding.  It's been a great learning experience and a good way to help me improve my C coding skills... which have partially rusted since I spend most of my time (at work) in Java/Javascript land. 

 

I am hoping that the compiler will also serve the purpose of providing a base compiler for any other compiler related projects I'd want to do in the future.  I've been pondering something like a C / Javascript hybrid compiler... which is partially how this compiler project started... hence the name/codename Mocha.

 

TLDR;

Yes, challenging and rewarding.  Plan to use for game making.  No need for standard C library.  Trying to solve the problem of slow development time.  It's already produced good results (see attachments)  :)

Share this comment


Link to comment
On 4/24/2020 at 3:27 PM, splendidnut said:

After seeing how quickly @johnnywc and cohorts brought Galaga to fruition (which was partially attributed to the use of C on the ARM/Melody platform) 

Hi Philip!

 

Wow - this seems really cool!  I agree; one of the things that attracted to me to the ARM development was being able to use C for the game logic.  Not only does it speed up development, but it makes it so the game development is more fun than frustrating (to me).  As far as Galaga is concerned, certainly writing the logic in C helped a lot, but the main reason we were able to get a playable game done so quickly was because I had done a port of Galaga for the PC back in 1997 (in C, nonetheless) so I was able to use a good portion of the game logic, patterns, etc. to get things working quickly.  Add to the fact that I have a pretty good SDK that handles all of the monotonous boring stuff like UI, high score tables, etc. and a playable prototype can be done fairly quickly. :)  For other games, like Zoo Keeper, the development has been slower (I started it in October of 2018) but writing logic in C has been extremely helpful.

 

Good luck and I will be interested to see how this goes! :thumbsup:  

  • Like 1

Share this comment


Link to comment

Yes I have.  The KickC developer and I appear to have similar ideas (like how inline assembly blocks should work).  The big difference is KickC requires Java (it's written in Java) and mine (written in C) does not.

 

And semicolons are optional in mine :)

Share this comment


Link to comment
On 4/24/2020 at 3:27 PM, splendidnut said:

You may ask: So why not BatariBasic (Bb)?  Well, while Bb provides a nice way for coders and non-coders alike to develop games for the Atari 2600... It relies on canned kernels... and it seems to be a little bit of a pain to include/use your own assembly display kernels.  Granted this is all from what I gathered from reading thru posts, especially @Karl G's posts in which he does a great service to the Bb community by using his skills to help others in this aspect.

It's not a pain to add kernels to bB. The language is very modular, but you need to know how to write a kernel, and you need to know how to write assembly code, since any higher level language will obscure cycle timing and page crossing penalties.

 

Since many people are drawn to bB because they want to program 2600 games without learning assembly or machine internals, they're not wanting to learn all that to write games in bB. Instead they rely on the kindness of others.

Share this comment


Link to comment

Fair enough @RevEng.  In my bit of research, adding kernels to BatariBasic was not obvious to me... that is a pain :)  So I looked around a bit, and came upon your title screen examples and it seems "easy" enough.  Maybe it's just me, but it doesn't seem "Basic" enough.  (quotes are for laughs)  To be fair, I'm not going to magically solve that problem here either.  Display kernels, for the most part, will always have to be written in assembly.  Until someone proves that wrong... (Note that I'm not including my own sloppy example above).

 

My goal is to reach the middle ground between Batari Basic and Assmebly.  By it's very nature, a C-like (or any Algol derivative) language falls nicely in that area. 

 

Over the weekend I've added code to my compiler to handle inline assembly (in a better way than CC65... similar to KickC), which I personally think makes it easier/more flexible to add/include display kernels than in BBasic.

Share this comment


Link to comment

Looking forward to your release, and SpiceC also - similar but different niches there too.   The 2600 is getting an embarrassment of developer riches. 👍

Share this comment


Link to comment
On 4/26/2020 at 6:01 PM, splendidnut said:

Yes I have.  The KickC developer and I appear to have similar ideas (like how inline assembly blocks should work).  The big difference is KickC requires Java (it's written in Java) and mine (written in C) does not.

 

And semicolons are optional in mine :)

No semicolons? are you using LALR(1) parser? ;) Looking forward to it! 

Share this comment


Link to comment

Yup, currently semicolons are optional.  I set it that way when I was debugging some parser issue and then just never removed the conditional check for them.  Seems to work good for now.  Although there are probably a few potential issues that will have to be dealt with from not enforcing them.  I'm still in the early stages of adding error reporting in the parser and am leaning towards a "one and done" since any syntax error can throw parsing completely off.  While enforcing semicolons would allow multiple syntax errors to be reported... I grew up with Turbo Pascal so I am very used to the "one and done" error reporting :)  I'm not sure how helpful it would be to have multiple syntax errors thrown.  My experience with various C/C++ compilers was that it wasn't really helpful since anything beyond the first error could be a false positive due to the first error.

 

Currently I'm using a hand-written recursive descent parser with no look-ahead.  I've thought about adding look-ahead, but I haven't run into the need for it yet... and that might just be because I'm only doing a subset of C.  Or that might more due to that being a "grammer to parser" parser generator issue... I'm really not sure.

Share this comment


Link to comment

Just realized that since I'm not going to allow assignments in expressions (in other words, I'm only allowing assignment statements), that probably helps alleviate some of the use cases that would otherwise require semicolons.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...