Jump to content
IGNORED

Dipping toes into cc65; porting Gem Drop!


Recommended Posts

Hey all, I'm finally dinking around with cc65 to cross-compile C programs for the Atari 8-bit. I did a ton of BASIC & TurboBASIC XL as a kid, and played with Action! a bunch in the 90s, but never got into 6502 assembly or C (directly on the Atari, or cross-compiled) until recently.

 

One of the first things I did was create some functions that acted like SOUND & DSOUND (for 16-bit precision pitches) from TurboBASIC XL. Then I got some very simple Display List and Vertical Blank Interrupts (DLI & VBI) going. And finally, I figured out how to muck with the ".cfg" file to give myself some room to load data from disk (fopen()...), or to have data built-in (e.g., "#include "myfont.h""). (You can see that work, including my 'extended headers' for the Atari 8-bits, over here.)

 

I'm finally at a point where I've taken the original Action! source code to my 1997 game "Gem Drop", ported it to C (again*), cross-compiled it with cc65, and ended up with an executable I can run... and it actually plays the game! Lots of stuff is still broken or missing, but it only took about 2-3 short rounds of hacking in the evening to get the game's ~15KB of .ACT source converted to valid C syntax!

 

At this point, aside from the intellectual exercise (aka syntax-rewriting grunt work), I'm not sure what else to do with it. I'm thinking maybe a "deluxe" version would be fun, since the game's 18th(!) birthday is coming up in September. Anyone want to make some music?

 

Once I have something worth posting (goal #1 is a fully working re-build that's as close to the Action! original as possible), I'll put it up on my website & drop a link in this thread.

 

Thanks!

 

-bill!

 

* I actually ported Gem Drop to C with, at first Xlib (X-Window) calls, then with libSDL (Simple DirectMedia Layer library) calls, and released it as "Gem Drop X". It runs everywhere (Linux, Windows, Mac, Dreamcast, etc.), and is even built-in to the Virgin America in-flight entertainment system! (YouTube vid). That is, quite literally, using code originally written in the Action! editor in my bedroom in college. Should go without saying, that was not part of my original plan. ;)

  • Like 8
Link to comment
Share on other sites

 

Cross development, usage of a ISO standard language, flexible memory layout, usage of a well documented and easy to enhance library.

 

I can understand the advantage of doing the coding on a modern machine with it's easier on the eyes screen and faster speeds. I'm not sure what flexible memory layout is, but I do think it sounds like it would be better than what Action! offers. As to the other two points though, Action! is fairly well documented and extensible via modular code, and also not being an ISO language doesn't seem to reduce it's functionality in any way.

 

Anyway, cc65 sounds interesting. Are there good Atari8 specific code libraries for it to handle things like IO, graphics, sound, etc. etc.?

Link to comment
Share on other sites

I'm not sure what flexible memory layout is, but I do think it sounds like it would be better than what Action! offers.

 

You have one central point (the memory config (the .cfg mentioned above)) where you determine the layout of memory usage. Libraries, C and assembler code should not use fixed memory locations as the placement is the task of the linker - controlled by the config.

So changing the assignments, shifting and shuffle locations is quite easy.

 

Anyway, cc65 sounds interesting. Are there good Atari8 specific code libraries for it to handle things like IO, graphics, sound, etc. etc.?

 

It depends. There are portable ways (standard libraries), where the code (should) run without change on any cc65 target (supporting the library) which may not offer all capabilities of the Atari and target specific ones.

Some examples:

The C-standard IO library maps to CIO on the Atari - quite well.

There is also a TGI library for graphics.

 

Of course non-portable library functions for the Atari are available too. See here:

https://github.com/cc65/cc65/blob/master/include/atari.h

 

Others wrote own graphics libs, like here:

http://atariage.com/forums/topic/154966-a8-graphics-library-cc65/

 

AFAIK there is no out-of-the box library for sound - seems that Bill changed that.

 

However, to have sound in my game ECKN(+) (also created with cc65), I linked the RMT player for the sound output to the program.

Direct access to the hardware is possible every time - so PMG utilization is a little bit like in Atari-Basic - no support by commands but fiddling with memory locations.

But of course the result is a lot faster.

 

Maybe other questions are covered by the FAQ:

http://www.cc65.org/faq.php

Link to comment
Share on other sites

If making software targeted just to the Atari8, is there an advantage of CC65 over Action! What would be the benefits?

 

Another advantage is there is a huge amount of source code available for C that you can mine.

The Atari TGI graphics support for CC65 is not very good.

 

Action is a great language, and lots of fun, but overall I personally is the best non-assembler development platform.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 months later...

BTW, I've got a cc65 alpha version of "Gem Drop Deluxe" available now. It's basically identical (if maybe a little slower sometimes) than the original Action! game, except it doesn't do any file I/O (so no high score, or highest-level-reached records), is a stand-alone XEX file (font data built-in), and you can press [F] to toggle the Super IRG flickery graphics effect. (The graphics it currently uses is generated, based on the two flickered fonts from the original game, so there's def. room for improvement)

 

http://www.newbreedsoftware.com/gemdrop_deluxe/

  • Like 3
Link to comment
Share on other sites

Bill: Would you like me to have a play around in ICE and see if I can improve the graphics a bit? :) My design skills have been improving.

I was thinking it'd be fun to try and convert the graphics for Gem Drop X that someone rendered for me, but I get the feeling it might not look so great, even with 13 colors. (See http://newbreedsoftware.com/gemdropx/screenshots/gemdropx4.giffor example)

Link to comment
Share on other sites

Bill: Do you have a sprite sheet for the Linux port? Ideally, it would need to be made 20 x 25 characters in size, have all of the block characters in it, and then resized to 320x200 resolution? With that I can plug it into g2f and do some mockups.

 

14 colors in Super IRG might do it decently, but I was also thinking about trying PCIN (12+10) or CIN (12+11) modes too. PCIN gets you 35 colors, while CIN allows 80, but the flicker gets more noticeable the more colors you go up.

 

With PCIN, you can still do checkerboarding (like in Super IRG) where the PF and BAK colors blend with each other, since there are no color palette changes. The other drawback in PCIN is, the mode is a little trickier to set up, in that it requires some funny business with the display list and the HSCROL register to correct for the Graphics 10 pixel shift, plus alternating the BAK register so that you get an extra 9th color group, without a flickering border.

Edited by Synthpopalooza
Link to comment
Share on other sites

OK, a rough sketch ... in PCIN mode. The resolution is a bit off but the colors are close.

 

post-23798-0-14772700-1444345484_thumb.png gemdrop.obx

 

There are improvements possible ... for one thing, the colors are undithered. Where you blend the PF colors and BAK, you can dither like in Super IRG to reduce the flicker. Also, these blocks don't fit exactly into 4x4 characters. A sprite sheet rendered at 320 pixels across will make the characters more accurate.

 

 

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

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...