Jump to content
Blues76

Atari 8-bit games in C ( CC65 ) ?

Recommended Posts

Hello,

I'm wondering what known games have been written in C for Atari 8-bit and if not known, at least home-brew.

Any source code?

Any resources to see how it works in C? (not the language but getting a basic game going -- sprites... )

 

 

Share this post


Link to post
Share on other sites

Curse of the Lost Miner. A simple platformer with source code available.

 

Source code is now available here: http://baktra.webowna.cz/software/packages/culomin/culomin_src.zip

 

This game uses solely means of cc65 when including game data (charsets, display lists, levels, and RMT music). Even though the quality of the game can be questionable, its source code can be educational at least.

Edited by baktra

Share this post


Link to post
Share on other sites

And when it comes to basic game going... It would be best to study the source code of both games.

A presentation - how to add game data to a CC65 program is attached.

cc65_gamedata.tar

Edited by baktra
  • Like 1

Share this post


Link to post
Share on other sites

Very interesting.

I read the power point and look at the code a bit.

It seems ( I didn't know) that I could compiled directly without the need of a emulator or real atari 8-bit hardware. , right?

 

I do have to look how are sprites included.

 

interesting.

Share this post


Link to post
Share on other sites

Observation of the sources provided so far suggests that using an external tool (even a home-brew one) to add game data to a CC65 program is a popular option.

Share this post


Link to post
Share on other sites

I'm been reading the code. This is very interesting. I hope to have a time to play with it.

Share this post


Link to post
Share on other sites

I was reading the tools for windows to develop for Atari 8-bit. In particular, I sow Eclipse for Macro-Assembler.

 

What tools do I need to develop using C?

 

For what the answers that were given (including this link: http://hdm.atari.pl/development.html),it is clear that I need at least

 

  • CC65
  • MADS
  • Atari Emulator
  • and figure out how to compile CC65 and MADS together (I sow a few links about this)

I think I can compile on a windows computer and then try it out in the emulator. Maybe the Eclipse plugin WUSDN may be helpful (but not sure if it will work with CC65 and MADS) and not clear how would I debug either.

 

Can you provide some more insight into the process, to be a bit more clear?

 

In a separate note, I think there was never a C++ compiler for Atari 8-bit, right?

 

thanks

 

EDIT: I also found this: http://atariage.com/forums/topic/255940-mads-in-visual-studio-code/

Edited by Blues76

Share this post


Link to post
Share on other sites

I believe that MADS is not absolutely necessary. CC65 comes with its own assembler - CA65.

On the other hand, MADS can help with creation of the final binary files (if LD65 is too difficult to master, or significant portions of your program are written in assembler)

 

  • WUDSN will work perfectly with MADS
  • WUDSN has no support for CC65.
  • I don't know if the ECLIPSE IDE can be forced to work with CC65.
  • Netbeans IDE can be tricked to work with CC65. Visual Studio too.

The workflow for cross-platform development is the following:

1. Edit your C and ASM code in your IDE

2. Compile and assemble your sources, create binary file. If your program is not standalone and requires a floppy disk with files on it, you can incorporate DIR2ATR to this step and create a bootable disk.

3. Run your binary file in emulator and debug. The Altirra emulator is well suited for debugging.

 

When your program works fine in the emulator, try it on the real machine. Emulation is only 99,99% of the real thing.

Edited by baktra

Share this post


Link to post
Share on other sites

Also look here:

 

https://atariwiki.org/wiki/Wiki.jsp?page=C#section-C-C

 

This page includes several C pgm. languages for the A8, as well as sources and some programs (in CC65: Greed, 3DMaze, Gr.15+).

 

Thank you.

 

There are few C compilers. I think CC65 is the most popular, right?

 

I was surprised to know that there was a C++ compiler there as well. It is probably a very old version but nevertheless.

it may not even have templates, I wonder and for sure not C++11, 14, 17 ready :) but it is very intriguing.

Share this post


Link to post
Share on other sites

I am wondering if there are sets of macros to support a kind of C-like structured programming in assembler like this one from IBM.

Are there similar sets of macros available for Atari native or cross-assemblers? Would that be useful?

Share this post


Link to post
Share on other sites

There are some structured programming macros for 6502 at http://wilsonminesco.com/StructureMacros/ which look promising, but I suspect your experience will vary by assembler.

 

For example, I tried to modify the SELECT ... CASE ... ENDCASE to work with MADS a couple of weekends ago, but was unable to get them to work. I think it was something to do with MADS being n-pass rather than 2-pass but I have not had time to investigate further.

 

Jeremy

Share this post


Link to post
Share on other sites

So there was a C++ then based on the link I found, right? anyone has info about C++ on the atari 8 bit?

Share this post


Link to post
Share on other sites

Forget about C++ on Atari - the only reasonable C compiler for Atari is CC65. The older native ones generate very poor code. With writing code in C++ it would be super easy to have the code bloated and it would require constant look at what is generated. Even with CC65 the way of programing should be as similar to ASM as possible. 6502 is not a processor to work with structs or pointers. Also using software stack is a bad idea, even for passing parameters to functions. Make everything as global as possible and check compiler options. In some other thread here you can find tips of how to write effective code using CC65.

  • Like 2

Share this post


Link to post
Share on other sites

"ECKN(+)" is about 75% written in cc65 and 25% ca65.

"dye" is about 95% cc65 and 5% ca65.

I tried to reduce the assembler part further, but some shortcomings make that hard (goal is/was a 100% full featured C game).

cc65 needs better constant expression support for initializations f.e. to abstain from asm-data initializations (extracting a high- or low- byte of a const address in non-const in cc65 (not in ca65!) and can only be performed at runtime -> bad).

 

 

 

Share this post


Link to post
Share on other sites

Forget about C++ on Atari - the only reasonable C compiler for Atari is CC65. The older native ones generate very poor code. With writing code in C++ it would be super easy to have the code bloated and it would require constant look at what is generated. Even with CC65 the way of programing should be as similar to ASM as possible. 6502 is not a processor to work with structs or pointers. Also using software stack is a bad idea, even for passing parameters to functions. Make everything as global as possible and check compiler options. In some other thread here you can find tips of how to write effective code using CC65.

 

I was searching but there are many threads on CC65. Any thread in particular you were referring on your comment?

Share this post


Link to post
Share on other sites

"ECKN(+)" is about 75% written in cc65 and 25% ca65.

"dye" is about 95% cc65 and 5% ca65.

I tried to reduce the assembler part further, but some shortcomings make that hard (goal is/was a 100% full featured C game).

cc65 needs better constant expression support for initializations f.e. to abstain from asm-data initializations (extracting a high- or low- byte of a const address in non-const in cc65 (not in ca65!) and can only be performed at runtime -> bad).

 

 

 

Could you provide an example?

Share this post


Link to post
Share on other sites

I thought I'd read it in David Wheeler's excellent article on 6502 compilers but I can't find the reference... but I always imagined it might be more efficient to handle a C parameter stack at a fixed address using four interleaved pages (to handle up to 32-bit args) with ABS,X instead of (ZP),Y. This places a hard limit on the number of parameters and places the stack at a fixed address during linkage but gets rid of the need to drop and bump the ZP pointer and access is a bit quicker.

  • Like 1

Share this post


Link to post
Share on other sites

 

See my example here:

https://github.com/cc65/cc65/issues/350

 

I see your point.

 

I do agree the compiler should do it but I guess they haven't gotten around to it.

 

I have to say that I have it easy with the C++ that we have today (even with C11)...

 

I hope they are able to make those changes given that CC65. While the main person stop in 2013, seems that other ones are still committing.

 

This is a problem with the amazing efforts by some but which is not supported monetary.

 

Thanks for the info.

Share this post


Link to post
Share on other sites

 

Thanks for the info.

 

cc65 for a "spare time" system is still very valuable. But seeing what current compilers are capable to "build" without any runtime penalty is really astounding:

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   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...