Neolithic Compiler - WIP - alpha/beta release with source

[+splendidnut]

Neolithic Compiler - Simple C Cross-compiler for the 6502

 

This C-like compiler is mainly focused on generating optimized 8-bit code for the 6502 to use for developing projects for the Atari 2600.

 

Neolithic v0.3.1 Binaries (Windows/MacOS) available on Github:

https://github.com/splendidnut/Neolithic/releases/tag/v0.3.1

 

In-development release can be compiled from source code (Available on Githib):

https://github.com/splendidnut/Neolithic

 

Due to lack of documentation, here's example code (Congo Bongo POC source code for Jan 16, 2022):

congo_c_20220116.zip

 

Compile with:

    neolithic congo -icongo_ntsc_config.c       <-- for NTSC version

    neolithic congo -icongo_pal60_config.c     <-- for PAL60 version

    neolithic congo -icongo_pal50_config.c     <-- for PAL50 version

 

Please feel free to ask any questions!

[+splendidnut]

BACKGROUND
This has been one of my main projects I've been working on over the past 2 1/2 years.  It started life as being a different compiler (mix of C and Javascript) for PC, but before much work was done, switched to just C and targetting the 6502.  This move was inspired by my experiments with CC65.

 

While working with CC65 and testing out how well it could be used with the Atari 2600, I ran into some issues.  There didn't seem to be an easy way to declare zeropage variables (a must for the 2600), and what I actually found seemed a bit convoluted.  Also, while developing a display kernel in C (I know, crazy idea), I found the optimizer to be a bit sub-optimal.  I did hack away a bit at CC65's optimizer source code, which by-the-way is really cool... But being as I already was in the mindset of developing a compiler, I decided to develop my own.

 

The goal of this compiler is to try and make decent C cross-compiler for the Atari 2600 / 6502 that:

•   - focuses on the strengths of the 6502 (zeropage)
•   - works around the weaknesses (small stack)
•   - modify / improve the language

Current "big goals" that have been accomplished:

• an all-in-one compiler - from Source Code to binary file with one executable
• providing user useful information about compiled program:
  • variable memory allocations
  • call tree depth
  • ROM layout
• providing annotated assembly listing

AREAS WHICH NEED IMPROVEMENT:

• 16-bit support - there is enough there to support assigning pointers and adding 8-bit values, but that is about it.
• multi-bank support - there's some preliminary data structures and maybe some code, but no actual support yet.
• conditional support - currently work okay, but only for relatively simple expressions

ON THE SOURCE
I've tried to do my best to make the code itself easily understandable.  I'm more than willing to answer any questions regarding any of the code.  I know there's a lack of comments, but that's mostly because I wrote it and have most of that information in my head.  So, I need to know what needs to be commented.  There are areas of the source code that I think could be rewritten better, but overall I'm happy with the code.

I've released the source in hopes that I will find people who are interested in working on it.  I'm really happy I've made it this far on just self-motivation.  But, I've stalled out quite a bit this year, so I'm hoping there are others who are interested in working on it.

With that said, Enjoy!

 

--Philip

[Fort Apocalypse]

@splendidnut This is awesome! I'm looking forward to getting this to work! I tested the Mac version in the distribution and ran into problems in the output running ./neolithic-mac congo (...Unable to process program due to error...), so would you like to start up another thread just for bugs, and I'll paste the output there, or should I just post it here since it's an alpha release?

 

 

Edited July 23, 2022 by Fort Apocalypse

[+splendidnut]

Sorry, totally forgot to include the compile instructions for Congo Bongo since it uses separate include files depending on whether you want NTSC, PAL60, or PAL50 binary.

 

Compile with (Windows Command Prompt):

    neolithic congo -icongo_ntsc_config.c       <-- for NTSC version

    neolithic congo -icongo_pal60_config.c     <-- for PAL60 version

    neolithic congo -icongo_pal50_config.c     <-- for PAL50 version

 

Compile with (MacOS Terminal):

    ./neolithic-mac congo -icongo_ntsc_config.c       <-- for NTSC version

    ./neolithic-mac congo -icongo_pal60_config.c     <-- for PAL60 version

    ./neolithic-mac congo -icongo_pal50_config.c     <-- for PAL50 version

[Fort Apocalypse]

On 7/23/2022 at 3:45 PM, splendidnut said:

Sorry, totally forgot to include the compile instructions for Congo Bongo since it uses separate include files depending on whether you want NTSC, PAL60, or PAL50 binary.

 

Compile with (Windows Command Prompt):

    neolithic congo -icongo_ntsc_config.c       <-- for NTSC version

    neolithic congo -icongo_pal60_config.c     <-- for PAL60 version

    neolithic congo -icongo_pal50_config.c     <-- for PAL50 version

 

Compile with (MacOS Terminal):

    ./neolithic-mac congo -icongo_ntsc_config.c       <-- for NTSC version

    ./neolithic-mac congo -icongo_pal60_config.c     <-- for PAL60 version

    ./neolithic-mac congo -icongo_pal50_config.c     <-- for PAL50 version

Thanks! That worked!

 

[Fort Apocalypse]

@splendidnut I looked at the documentation and at the congo.c example and have some comments and a question:

• The asm defining functionality is nice!
• Love the C code that makes things look easy, like:

	if (canMove || (playerState == SPR_STATE_CLIMBING)) {
		if (joyInput & JOY_RIGHT) {
			newPlayerX++
			explorer.state &= SPR_FACE_RIGHT
		} else if (joyInput & JOY_LEFT) {
			if (newPlayerX > 0) newPlayerX--
			explorer.state |= SPR_FACE_LEFT
		}
		
		if (joyInput & JOY_UP) {
			if (newPlayerY > 0) newPlayerY--
			explorer.state |= SPR_FACE_LEFT
		} else if (joyInput & JOY_DOWN) {
			newPlayerY++
			explorer.state &= SPR_FACE_RIGHT
		}
	}	

• One of the reasons I like bB is that the ratio of art (playfield and sprite definitions) to code can be so high with low overall complexity for a fun game. Looking at congo.c- maybe about 1/4-1/3 of the lines I see in my editor are for art; that's impressive!
• Is there a tool that could be used to help visualize and create the playfield and player sprites? (My eyes glaze over arrays of hex, and comments don't help unless I can edit them and re-run something to update the hex.)
• It would be helpful to have information on the basics of Neolithic specifically for 2600 game developers, like: defining colors, sprite definitions, collisions, etc., like a starting point for what could become similar to RT's batari Basic Commands? I'm grateful for the Neolithic Language Guide you wrote and it's a good primer for the language. But, I could use a tutorial to get started writing games.

Thanks!

[+splendidnut]

1 hour ago, Fort Apocalypse said:

One of the reasons I like bB is that the ratio of art (playfield and sprite definitions) to code can be so high with low overall complexity for a fun game. Looking at congo.c- maybe about 1/4-1/3 of the lines I see in my editor are for art; that's impressive!

That's an interesting metric to look at.  I'm not sure how well that would hold up across the board, but in this case, it does seem to correlate to the final binary output: 1kb of the 4k ROM is graphics data.

 

2 hours ago, Fort Apocalypse said:

Is there a tool that could be used to help visualize and create the playfield and player sprites? (My eyes glaze over arrays of hex, and comments don't help unless I can edit them and re-run something to update the hex.)

Sorry, I don't have any cool tools written... The playfield for Congo Bongo was actually generated using a PNG file of an arcade screenshot that was resized to a 40x192 (or 40x176?  I don't quite remember the exact size) image.  It was run thru a simple C program that read the image, translated it into interleaved lines, and wrote the final output in DASM .byte statements for the original POC from last year.  I did a couple of 'find/replace' steps to convert those lines into a C-compatible format.

 

I do have a GUI tool in the works to do those sort of image to text conversions (mainly for 7800 graphics, but easy to support both).  I just haven't worked on that too much lately because I haven't had a need for it. 

 

With Neolithic I could potentially add something that allowed ASCII art... Also, I probably should add something like #incbin to allow binary data files to be directly added into arrays, or code, or something... I'm not sure how that should work.

 

2 hours ago, Fort Apocalypse said:

It would be helpful to have information on the basics of Neolithic specifically for 2600 game developers, like: defining colors, sprite definitions, collisions, etc., like a starting point for what could become similar to RT's batari Basic Commands? I'm grateful for the Neolithic Language Guide you wrote and it's a good primer for the language. But, I could use a tutorial to get started writing games.

Glad you found the little Neolithic Language Guide helpful.  I do need to sit down and write up some tutorials to go along with this.  Thanks for the suggestions, if you have any more, let me know.

 

-----

 

I've kinda been working on getting some simple example programs written and included... but they keep getting overly complicated... one of them is pushing me to flesh out the 16-bit math support.   ... which I've started working on.

 

Probably the biggest hurdle right now is that there aren't any libraries provided with the compiler.  The only 'library' I've written is 'atari2600.c' (provided with the Congo Bongo source

code) that provides basic frame management functions and the horizontal positioning routine... the key pieces.

 

This is probably the easiest place where the community can help out... either with library function suggestions and/or development of those libraries.  And some display kernels.

 

So if anyone can help out with this, it would be much appreciated.

 

[orange808]

It's a really cool coding experiment and as accomplishment as it is. It's been fun to play with.

 

With that said, do you have any specific ultimate mission statement and/or development use case in mind for the project?

 

It's (also) fine if this is for fun--and there doesn't have to be any ultimate goal, targets, or pressure. I'm just curious where you see it among the other available options to make games, given the capabilities of the AtariAge chips most people are using (if that even matters).

Edited July 26, 2022 by orange808

[+splendidnut]

It's ultimately a fun project for me.  I've always wanted to develop a compiler; something I could use for development and also do some language experiments with.  It's been quite fulfilling to get this far.

 

I see this as mainly just providing another development option.  I'm not too concerned about this gaining traction, but I do hope people will find this useful.  I think there's a lot of potential here yet to be uncovered.

 

I'm happy to hear your having fun with it.