Commander X16

One thing that I think might be better for an API (esp on 6502) would be to pass a pointer to a structure instead of a bunch of individual values.

46 minutes ago, Scott Robison said:

One thing that I think might be better for an API (esp on 6502) would be to pass a pointer to a structure instead of a bunch of individual values.

I totally grok that, good catch, thank you.



 

Now I'm looking at Matt's tutorial to see how he addresses VERA RAM.

I. IMAGE DATA LOAD

At least I can bypass his load code, since (I think) I can load straight to VERA, e.g.:

   cbm_k_setnam("xebec-32x32.bin");
   cbm_k_setlfs(0,8,0);
   cbm_k_load(TO_VERA, 0x4000);

 

II.  SPRITE CONFIG

OK.  Ok.  

GIVEN a target memory address "address" for VERA, and data "the_byte" to move in there:



uint8_t low = address & 0xff;     

uint8_t high = (address >> 8 ) & 0xff;



POKE( 0x9f20, low );

POKE( 0x9f21, high );

POKE( 0x9f22, 1 );

POKE( 0x9f23, the_byte );

 

So the cumbersomeness of addressing VERA makes me want to split up the API differently:

spr_define(s,*cfg) -- sets mode and address, height, width, palette offset (bytes 0, 1, 6, and 7).

spr_pos(s,*pos) -- sets x, y position (bytes 2, 3, 4, 5).

spr_vflip(s), spr_hflip(s) -- flips along x or y axis (byte 6)

 

1 hour ago, rje said:

Now, I'm looking at Matt's tutorial to see how he addresses VERA RAM.



II.  SPRITE CONFIG



OK.  OK.  



GIVEN a target memory address "address" for VERA, and data "the_byte" to move in there:



uint8_t low = address & 0xff;     

uint8_t high = (address >> 8 ) & 0xff;



POKE( 0x9f20, low );

POKE( 0x9f21, high );

POKE( 0x9f22, 1 );

POKE( 0x9f23, the_byte );

#include <cx16.h>

...

VERA.control = 0;

VERA.address = address;

VERA.address_hi = 1;

VERA.data0 = the_byte;

It compiles to the same Assembly code.  But, it looks more C-like, less BASIC-like.

cc65 also has vpeek() and vpoke() functions.  They directly touch VRAM and internal registers.

3 minutes ago, Greg King said:

#include <cx16.h>

...

VERA.control = 0;

VERA.address = address;

VERA.address_hi = 1;

VERA.data0 = the_byte;



It compiles to the same Assembly code.  But, it looks more C-like, less BASIC-like.



cc65 also has vpeek() and vpoke() functions.  They directly touch VRAM and internal registers.

 

First: beautiful, thank you.  I assume there's a way to set the auto-increment?

 

Second: why aren't these functions in the DOCUMENTATION?  Am I looking in the wrong place?? https://cc65.github.io/doc/funcref.html

 

4 minutes ago, Greg King said:

cc65 also has vpeek() and vpoke() functions.  They directly touch VRAM and internal registers.

 

Oh heck, cx16.h has ALL KINDS OF GOOD STUFF.

That's what I get for not reading the header file....  Silly me for relying on documentation.

 

14 minutes ago, rje said:

First: beautiful, thank you.  I assume there's a way to set the auto-increment?



Second: why aren't these functions in the DOCUMENTATION?  Am I looking in the wrong place?? https://cc65.github.io/doc/funcref.html

Currently, the increment/decrement must be or'ed into the address expression that's given to vpeek() and vpoke().

No one has taken the time to document a lot of the functions that are available in cc65's libraries.  (Usually, someone finds a function in a header, learns that it's very useful to him, notices that it's not in the doc, then submits a patch to "funcref.sgml".)

28 minutes ago, rje said:

Oh heck, cx16.h has ALL KINDS OF GOOD STUFF.

Yep.  But, it isn't complete.  For example, there are no constants for configuring sprites.  "cx16.inc" (for Assembly programming) has much more of that stuff in it.

cc65’s documentation is not very helpful to me, at least not the function references.

I wish they had example usage for functions, or at least a little discussion of the parameters.