Maybe yet another C Compiler for 6502 programming...
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
- 2
11 Comments
Recommended Comments