🚀 go-pugleaf

> 	I drew a small 2x2 box on the screen at 100,100. Then I used:
> 	 SSHAPE A$,100,100,102,102 : rem should save all data from 100,100
> 				to 102,102 into A$.
> 	then:
> 	 SPRSAV A$,5 : rem  assigns the data in A$ to sprite 5
> 
> 	Now, sometimes this would ALMOST work, I would get the general shape 
> 	I was looking for, but I would also get a few bits of junk that is
> 	not supposed to be there. Also, it was NOT what I drew on the screen.
...
>
> (What I would really appreciate is a memory map of the sprite pointers
> 	to see where they have been relocated and of the sprite registers so
> 	I can use them the old way. If it is possible.)


When you copy a SSHAPE into a sprite, you must be sure the dimensions of the
area you saved is exactly that of a sprite (24x21).  If your first example had
been  SSHAPE A$,100,100,123,120  then your resulting sprite definition would
have been correct (assuming high-res mode-  SSHAPE A$,100,100,111,120 is
correct for a muticolor shapes.  Each dot in X needs 2 pixels in this case).

To create your own SSHAPE strings, you must understand how the shapes are
stored in the strings.  Because BASIC limits string lengths to 255 characters,
the size of the area you can save is limited (no problem for shapes destined
for sprites, obviously). The string size required can be calculated using the
following (unscaled) formula:

          Length = INT((ABS(x1-x2)+1)/M+.99) * (ABS(y1-y2)+1) + 4

where (x1,y1) and (x2,y2) are diagonally opposite corner coordinates and M=4
for multicolor mode or M=8 for high-res mode.  The shape is saved row by row.
The last four bytes contain the width-1 and height-1, in low/high byte format.
For sprite shapes, the Length will always be 67 and the last four bytes will
always be  23, 0, 20, 0  (regardless of graphic mode).

BASIC automatically sets the sprite pointers to the system's sprite definition
area, $E00-$FFF.  The pointers are found in the last 8 bytes of the video
matrix, $7F8-$7FF for text mode  or  $1FF8-$1FFF for graphic mode.  You can
alter these (eg., point more than one sprite to the same definition), and as
long as you do not clear the screen the modified pointers will be left alone.

One last note.  BASIC 7.0 controls the VIC itself, maintaining 'shadow'
registers in RAM which are copied to the VIC automatically during each raster-
generated IRQ  (the SID is similarly controlled).  You can disable this
(and consequently lose some BASIC sound and animation capabilities) by POKEing
a non-zero value to RAM location $12FD.  This would give you, and not BASIC,
control of most VIC registers.  Incidentally, the VIC 'shadow' registers are
located at $11D6;  these contain the 16 sprite X-Y position coordinates.
You can re-enable BASIC's IRQ handler by POKEing a zero to $12FD.

Addressing other VIC registers for purposes of moving the screen, for example,
is possible too, only a bit more involved and beyond the scope of your original
questions, I think.  Happy experimenting.
-- 
Fred Bowen			uucp:	{ihnp4|seismo|caip}!cbmvax!fred
				arpa:	cbmvax!fred@seismo.CSS.GOV
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380