Jump to content
Sign in to follow this  
TGB1718

Graphic modes in cc65

Recommended Posts

Am I missing something, I'm using cc65 to open screens in various graphics modes but finding it's not happening correctly.

 

The header file says:-           extern int  __fastcall__ _graphics (unsigned char mode); /* mode value same as in BASIC */

 

But in reality it looks like modes 0 through 6 work fine, anything else just doesn't seem to work.

 

I wrote a short program to cycle through all modes and put the value of one of the DL bytes in locations $600-$60F

It looks like only modes up to and including "B" (BASIC Mode 6) work, anything higher just doesn't.

Here's the DL values for each mode.

 

0600 02 06 07 08 09 0A 0B 0B
0608 0B 0B 0B 0B 0B 0B 0B

 

Share this post


Link to post
Share on other sites

For this particular subject, you can use a command line setting, but I highly recommend looking at the linker config file stuff.

CC65 is very config-file dependent. You won't get far unless you learn at least the basics of the linker config stuff. The payback for this is that CC65 is extremely flexible and powerful, providing full control over all aspects of memory placement and linking operations.

 

Edited by danwinslow
  • Like 1

Share this post


Link to post
Share on other sites

When doing graphics calls, either via tgi or via the atari OS, you need to ensure that your CC65 program doesn't grab all of the memory for itself by reserving the top part of memory for your graphics. The RESERVED_MEMORY variable in the atari linker configs can do this.

 

-Thom

 

Share this post


Link to post
Share on other sites
3 minutes ago, tschak909 said:

RESERVED_MEMORY variable in the atari linker configs can do this.

 

I have tried this but unfortunately it still doesn't work, also changed the start address as the link @Wrathchild gave suggested, again still no joy.

I've looked at the config files but can't see anything related to screen memory or anything else that might help :( 

 

cl65 -t atari -O -Wl "-D__RESERVED_MEMORY__=8196" --listing art.lst --static-locals   art.c -o art.xex

 

also tried the atarixl config, same result
 

Share this post


Link to post
Share on other sites
1 hour ago, TGB1718 said:

still no joy

Seems OK to me? You'll need to share your test code.

 

image.png.e65a6f6f20ea4d83b0e595fd54f372ff.png

#include <atari.h>
#include <fcntl.h>

#define MYDBG ((unsigned int *) 0x600)
#define SDLSTL ((unsigned int *) 0x230)

void main(void) {
  unsigned char i;
  int fd;
 
  for(i=0; i<16; ++i) {
    fd = _graphics(i);
	*(MYDBG+i) = *(SDLSTL);
	close(fd);
  }
 
  while(1);
  return;
}

 

Edited by Wrathchild

Share this post


Link to post
Share on other sites

I don't think it's working for you, if you look at the DL pointers, only the first 7 change addresses, after that they 

are all the same $B782, as the DL sits in front of the screen, the higher rezz modes should put the DL lower in memory

somewhere around $A27A

 

btw, your code is the same I am using :) I cut everything else out when it didn't work to try debug it.

 

Thanks for the help.

Share this post


Link to post
Share on other sites

I had the wrong picture up originally which corresponded to just calling _graphics but not recording the response and using it to close the IOBC channel

Edited by Wrathchild

Share this post


Link to post
Share on other sites
Just now, danwinslow said:

Rapidly looping through all of the screen modes was never a use case I tried...there may be some subtleness going on with that aspect.

Only did that to see what modes worked and what didn't, initially I was trying just ANTIC mode 9 and 11 and they didn't work, so tried 

$F and that failed too.

Share this post


Link to post
Share on other sites

I finally got it working, the only thing that seemed weird is the _RESERVED_MEMORY_ didn't look like it was working

even though I had reserved 8K, all I did was use Hex notation for the memory reservation 

 

cl65 -t atari -O -Wl -D__RESERVED_MEMORY__=0X2000 --listing art.lst --static-locals   art.c -o art.xex

 

and now it works !!!

 

all help appreciated, got me thinking :)

 

  • Like 1

Share this post


Link to post
Share on other sites

Changing the loop code to:

  for(i=0; i<16; ++i) {
    fd = _graphics(i);
    *(MYDBG+i) = *(SDLSTL);
    *(MYDBG+(16+i)) = fd;
    // close(fd);
  }

 

Shows that the _graphics call is returning an error (i.e. no free IOCB) after the 7th open so that probably explains your issue (compiling with the decimal arg on the command line works fine too)

 

image.png.7f71a572d24ec5d9bfea52bf1824e28f.png

 

[Edit] and the addresses stay the same as it hasn't changed mode 

Edited by Wrathchild

Share this post


Link to post
Share on other sites

Interestingly if I now call _graphics(9), it works ok, _graphics(9+16), works ok, _graphics(9+32) doesn't ???

it doesn't open a graphics  screen, it just stays in text screen, strange.

Even with the reserved memory which is plenty for this mode.

 

Share this post


Link to post
Share on other sites

Works fine for me ™

(btw there is no 9+16 as modes 9,10 & 11 don't have split screens)

 

image.thumb.png.a8a8f437d917331e895c32cf213c28b2.png

 

The graphics seen being the residual of the dlist for gr.0 from the request not to clear the screen

test.zip

Share this post


Link to post
Share on other sites
32 minutes ago, Wrathchild said:

Works fine for me ™

Can I ask you for your build script please, I think it's all down to that, maybe your using a switch or something I'm not.

Thanks

 

Tim

Share this post


Link to post
Share on other sites

same command as from post #5

cl65 -t atari -O -Wl "-D__RESERVED_MEMORY__=8196" --listing test.lst --static-locals test.c -o test.xex

 

Share this post


Link to post
Share on other sites
1 hour ago, Wrathchild said:

same command as from post #5

Think I'm going to bang my head against a wall :)

Just tried that old build script and it worked both normal open and +32 open.😲

 

Going for a long lie down, once again thanks for your input.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
13 hours ago, danwinslow said:

Probably missing the point, but...of course, since you commented out the close?

Yes, was looking to show why the issue in the OP may have occurred

Share this post


Link to post
Share on other sites

I am trying to figure out how to do something like a V = USR( routine , parameter 1 , parameter 2, ... ) in cc65. The documentation for cc65 is poor and lacks samples of how to use.

Share this post


Link to post
Share on other sites
11 minutes ago, CuloMajia said:

I am trying to figure out how to do something like a V = USR( routine , parameter 1 , parameter 2, ... ) in cc65.

Start a new thread for this and we can help but more context please, e.g. are you wanting to write routines that you can call from your basic program or replicate what you would do in Basic in C?

13 minutes ago, CuloMajia said:

The documentation for cc65 is poor and lacks samples of how to use.

Not really, could you say the same of GCC for example?

Share this post


Link to post
Share on other sites
30 minutes ago, CuloMajia said:

I am trying to figure out how to do something like a V = USR( routine , parameter 1 , parameter 2, ... ) in cc65. The documentation for cc65 is poor and lacks samples of how to use.

There is no USR, because you... ...just call the function.

 

-Thom

 

Share this post


Link to post
Share on other sites

I will try it. Does the parameters get pushed as 2 byte integer values on the stack like Basic does? I have old Turbo Basic, Atari Basic, Commodore Basic game program around for years that I like to port into something faster and put up on the internet. Some decent quality stuff if I can make stuff run faster. 

 

For graphics modes. I find it easier to just create a custom display list with the desired graphics mode. Have the option of placing the text window at the top or bottom also.

Share this post


Link to post
Share on other sites

Yeah, moving it to FB would be a much better experience for you I think. CC65 and C language port would be a lot more technically intensive.

To answer the stack question - the parameters for a function call, generally speaking, are stored on the C memory stack, which is not the same as the system call stack. Small calls like void foo( char a,x,y ) can be made to show up in the registers...using fastcall I think? I forget exactly, but its something like that.

Edited by danwinslow

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.
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...