Jump to content
IGNORED

cc65 call to _graphics


Recommended Posts

Hi folks,

Sorry to be a bother but I've searched the internet looking for a good example on how to set the graphic mode for the Atari A8 using C and the atari.h header file with the cc65 compiler. I can't see to get it working. Anyone have a good code sample to get me started?

Link to comment
Share on other sites

Is your project building OK? If not, can you post a snippet of the problem source code and the errors. I'm not familiar with CC65 on the A8 but I have used it on the Atari 7800 for game development.

 

According to the header file it states that the parameter passed to _graphics matches the one in BASIC. Maybe that helps?

Link to comment
Share on other sites

Hi folks,

Sorry to be a bother but I've searched the internet looking for a good example on how to set the graphic mode for the Atari A8 using C and the atari.h header file with the cc65 compiler. I can't see to get it working. Anyone have a good code sample to get me started?

 

 

Hi

 

I did a quick search on Bing and came across this which should help

 

http://atariwiki.strotmann.de/xwiki/bin/export/Code/Graphics15?format=pdf&

Link to comment
Share on other sites

I whipped up a quick program, and it seems to work... Of course, writing ascii text directly to the screen isn't much good, but at least you can see something. I'm using cc65 version 2.12.0.

 

 

#include <atari.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

 

 

#define SAVMSC *(unsigned int *) 88 // screen address

 

void main(void) {

char *screen;

_graphics(2);

 

screen = (char *) SAVMSC;

strcpy(screen, "This is text");

 

while(1);

return;

}

  • Like 1
Link to comment
Share on other sites

That did the trick. My C is quite rusty but I wanted to do something more than just play games and 'have' an Atari. By the way what IDE do you use with CC65? I've Eclipse but I'm thinking major overkill.

 

I whipped up a quick program, and it seems to work... Of course, writing ascii text directly to the screen isn't much good, but at least you can see something. I'm using cc65 version 2.12.0.

 

 

#include <atari.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

 

 

#define SAVMSC *(unsigned int *) 88 // screen address

 

void main(void) {

char *screen;

_graphics(2);

 

screen = (char *) SAVMSC;

strcpy(screen, "This is text");

 

while(1);

return;

}

Link to comment
Share on other sites

The _graphics call is ok for doing simple stuff, but there's a few things it doesn't do ( such as reserve memory ). I have found it better to write my own graphics setup calls. You can find plenty of info about how to do so by searching for atari documents ( mapping the atari, atari graphics, etc. )

 

For 'IDE' I've used Visual Studio Express with good results, as well as Vslick. Eclipse is overkill for anything in my opinion, but if you can stand the complexity and slow execution it's probably fine to use.

 

That did the trick. My C is quite rusty but I wanted to do something more than just play games and 'have' an Atari. By the way what IDE do you use with CC65? I've Eclipse but I'm thinking major overkill.

 

I whipped up a quick program, and it seems to work... Of course, writing ascii text directly to the screen isn't much good, but at least you can see something. I'm using cc65 version 2.12.0.

 

 

#include <atari.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

 

 

#define SAVMSC *(unsigned int *) 88 // screen address

 

void main(void) {

char *screen;

_graphics(2);

 

screen = (char *) SAVMSC;

strcpy(screen, "This is text");

 

while(1);

return;

}

Link to comment
Share on other sites

The _graphics call is ok for doing simple stuff, but there's a few things it doesn't do ( such as reserve memory ). I have found it better to write my own graphics setup calls. You can find plenty of info about how to do so by searching for atari documents ( mapping the atari, atari graphics, etc. )

 

Take a look at the link.

You have to reserve the proper amount of memory for partcular graphics mode in linker file section __RESERVED_MEMORY__.

 

regards,

Jakub

  • Like 1
Link to comment
Share on other sites

Yes, thats what I was referring to.

 

The _graphics call is ok for doing simple stuff, but there's a few things it doesn't do ( such as reserve memory ). I have found it better to write my own graphics setup calls. You can find plenty of info about how to do so by searching for atari documents ( mapping the atari, atari graphics, etc. )

 

Take a look at the link.

You have to reserve the proper amount of memory for partcular graphics mode in linker file section __RESERVED_MEMORY__.

 

regards,

Jakub

Link to comment
Share on other sites

Thanks everyone for the support and help. It works wonderfully and I am able to printf to both areas in _graphics(2) mode. Oddly when doing a string copy into the the screen address of 88 the text that actually appears is partially garbled. However when printing the same text at the bottom of the screen it is correct.

 

I have modified atari.cfg with __RESERVED_MEMORY__: value = $1, weak = yes

I was at first thinking it was a memory addressing problem but not so sure at this point.

 

Code:

#include <atari.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define SAVMSC *(unsigned int *) 88 // screen address

void main(void) {

char *screen; 
_graphics(2);
screen = (char * ) SAVMSC;
strcpy(screen, "This is Atari\n");

printf("%s\n", screen);

sleep(10);
screen = (char * ) SAVMSC;
strcpy(screen, "This is a broken Atari");

printf("%s\n", screen);

while(1);
return;
} 

 

Clues?

post-24127-125184832104_thumb.jpg

Link to comment
Share on other sites

Thanks everyone for the support and help. It works wonderfully and I am able to printf to both areas in _graphics(2) mode. Oddly when doing a string copy into the the screen address of 88 the text that actually appears is partially garbled. However when printing the same text at the bottom of the screen it is correct.

 

Part of the problem is that screen data is not in the same format as ATASCII. So you cannot really put a string directly into screen memory without "converting" it from ATASCII to screen memory format. Printf does this for you automatically, but will only work with gr.0.

 

There are some problems with the code below:

char *screen; 
_graphics(2);
screen = (char * ) SAVMSC;

 

screen is defined as a character array, the address of which is taken from location 88. This is the screen memory area.

 

strcpy(screen, "This is Atari\n");

 

Doing a string copy into the memory area just throws some bytes into the screen memory. There is no conversion between ATASCII and screen memory format. It was intended as a quick and dirty way to show something on the screen, not as a proper method of doing things. Sorry for the confusion.

 

printf("%s\n", screen);

 

Wait a second... you are telling printf that the variable screen contains a string to print out. Which I guess it does actually, but really screen is the screen memory area. This is a bit confusing, but I guess it works. Maybe you realize that and intended it?

 

sleep(10);
screen = (char * ) SAVMSC;

 

No need to reassign this, it was done above.

 

strcpy(screen, "This is a broken Atari");
printf("%s\n", screen);

 

Like above, the strcpy is writing directly into screen RAM. The printf below is taking the screen ram as a string and writing it to stdout, like explained above.

 

Try this:

 

#include <atari.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define SAVMSC *(unsigned int *) 88 // screen address

void __fastcall__ str_to_internal(char *s);


void main(void) {
 char *screen;
 char txt[15];


  _graphics(2);                                // change to gr.2
  screen = (char * ) SAVMSC;                   // get the screen address

  strcpy(txt, "this is atari");                // set string to print
  str_to_internal(txt);                        // convert to screen format
  memcpy(screen, txt, 14);                     // copy into screen ram

  strcpy(txt, "THIS IS ATARI");
  str_to_internal(txt);
  memcpy(&screen[20], txt, 14);                // another line of it

  printf("This is Atari!\n");                  // prints to gr.0 section

  while(1);
  return;
}



/* str_to_internal
*
* Converts a string from atascii code to internal character set code.
* Usually we want to do this before writing it to a bitmap.
*/
void __fastcall__ str_to_internal(char *s)
{
 unsigned int i;
 unsigned int len;


 len = strlen(s);
 for(i = 0; i < len; i++) {
   if (s[i] < 32)
     s[i] += 64;
   else if (s[i] < 96)
     s[i] -= 32;

 }

 return;
}

 

PS. I don't use an IDE. I use a simple text editor called FED (by Shawn Hargreaves) and do everything else at the command line. I guess I should really join the 21st century though.

post-2472-125186051233_thumb.jpg

Edited by Shawn Jefferson
Link to comment
Share on other sites

...

 

Part of the problem is that screen data is not in the same format as ATASCII. So you cannot really put a string directly into screen memory without "converting" it from ATASCII to screen memory format. Printf does this for you automatically, but will only work with gr.0.

 

 

Wow! I completely assumed that ATASCII was a subset of ASCII when I was doing basic Atari I research. Furthermore I never thought to actually check to see if there was a difference between the two and now the fact that ATASCII and screen memory format are different adds a new layer to the challenge. I am deeply appreciative of your answers.

 

There are some problems with the code below:

char *screen; 
_graphics(2);
screen = (char * ) SAVMSC;

 

screen is defined as a character array, the address of which is taken from location 88. This is the screen memory area.

 

strcpy(screen, "This is Atari\n");

 

Doing a string copy into the memory area just throws some bytes into the screen memory. There is no conversion between ATASCII and screen memory format. It was intended as a quick and dirty way to show something on the screen, not as a proper method of doing things. Sorry for the confusion.

 

printf("%s\n", screen);

 

Wait a second... you are telling printf that the variable screen contains a string to print out. Which I guess it does actually, but really screen is the screen memory area. This is a bit confusing, but I guess it works. Maybe you realize that and intended it?

 

Indeed. I was trying to deduce if I was accessing a memory address incorrectly vs. some other problem with the printing to screen address 88. Thus I put the printf in there to print to the graphcs 0 portion of graphics 2. As you point out I was assuming that ATASCII and screen memory format were synonymous.

 

 

...

 

Like above, the strcpy is writing directly into screen RAM. The printf below is taking the screen ram as a string and writing it to stdout, like explained above.

 

...

 

PS. I don't use an IDE. I use a simple text editor called FED (by Shawn Hargreaves) and do everything else at the command line. I guess I should really join the 21st century though.

 

Thank you so much for your help! I 'grew' up on vi but was thinking I should join the 21st century as well. In the last 48 hours I've went through three different IDE's. I'm thinking about going back to vi with syntax highlighting.

Edited by rchennau
Link to comment
Share on other sites

Thank you so much for your help! I 'grew' up on vi but was thinking I should join the 21st century as well. In the last 48 hours I've went through three different IDE's. I'm thinking about going back to vi with syntax highlighting.

 

And what is wrong with vi? :lust:

 

Take a look at vim if your not already looking at/using it.

 

Once you get over the learning curve, why change?

 

There is a plugin for vim and visual studio, on the net somewhere. I used before I ditched IDEs.

Link to comment
Share on other sites

  • 1 year later...

Question: Why is the 't' in 'this is atari' missing?

Answer: The cursor is positioned at location 0,0 which is where the 't' is printing. The cursor overwrites th 't' and then is turned off at the end of the program execution thus making it appear no 't' was printed.

 

I changed the code by adding the line gotoxy(5) which moves the cursor five lines down. However a better solution is to figure out how to prevent the cursor from over writing any character on the screen.

 

...
...
void __fastcall__ gotox (unsigned char x);

int main (void) 
{
char *screen; 			// pointer to a char array of labled screen
char txt[15]; 			// create a character array txt with 15 entries

_graphics(2);			// call to Atari graphics mode 2
screen = (char * ) SAVMSC; 	// point screen to memory address of the atari display 
gotoy(5);
...
...

 

Shawn I noticed my version of this code running on atari800 v2.03 (linux) compiled with cc65 V2.13.2 that the first 't' in 'this is atari' is not printed. Screen cap below.

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