Jump to content
IGNORED

Atari 8-bit games in C ( CC65 ) ?


Blues76

Recommended Posts

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
Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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

Link to comment
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
Link to comment
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).

 

 

 

Link to comment
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?

Link to comment
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?

Link to comment
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
Link to comment
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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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