Sprites in ML

[Mike]

I'll take a look at the program this evening. Thanks for uploading.

Michael

[hawk]

Has anyone had a chance to dissassemble the Sprite-Imation code yet?

I made a start on it, but I'm not particularly good at it, so it takes me a while.

Hawk

[Victragic]

I attempted, but I'll have to admit that this is a little beyond my ability at this point, so I'll have to leave it for someone else..

A man's got to know his limitations..

-G

[hawk]

Well I'm still working on it. I'm actually learning quite a bit about machine code wedges in BASIC, although my interest in the sprites is for use from assembley or C.

So far I've dissassembled the wedge, and now I'm getting into the nitty gritty of the sprites.

Hawk

[carlsson]

Of course the raw disassembly is an automated process, but what you're trying to do is to understand the code. To move it up one level from disassembled machine code to logic, commented assembly code that one can follow.

[hawk]

You're absolutely correct Carlsson, appropriately commented assembly code is the goal. I should have clarified that.

I've posted what I've done so far here;

http://www.users.on.net/~hawkeys/mike/r ... mation.asm

Hawk

[carlsson]

Keep up the good work. My head hurts just looking at it. May I suggest that while you're onto it, add home-made logic labels for each section of the code there is a jump or branch to? Likewise if the routine has data blocks, once you identify what the data is for, label it so the code in the end will look more like this:

Code: Select all

plot:
  LDA data,X
  JSR do_plot
  BNE no_coll
  JSR do_collission
no_coll:
  ...

You would lose the byte-by-byte address references, but on the other hand have a routine that can be improved upon and assembled to a different origin.

[hawk]

Yeh Carlsson, I will add the labels and the byte references, but it's easier for me to leave the addresses and opcodes in for the moment. It also takes a few difference references sometimes to work out the function of a piece of code. The original article is helping a fair bit with some of the data addresses.

Ultimately, my aim is to have assembly code that I can then incorporate into other programs. I've been using the AS65 assembler, which has a slightly difference syntax to what most people use, so I may have to choose a more commonly used assembler to be of use to most people.

Hawk

[Victragic]

One thing about Sprite-Imation is that it writes directly to the screen and to character memory, which causes flicker and doesn't allow for background object movement (other than other sprites).

Given it is written for an unexpanded machine this is understandable, but I have discovered the best way to avoid flicker from graphics and clashes with background is to buffer the entire screen to a memory location outside the sacred 4k and then write the entire screen whenever changes in screen data occur. Similarly, performing character data manipulation for the sprites in separate memory and then writing over the existing character data will eliminate the 'flicker' altogether. It really doesn't slow down the machine noticeably (most things I have tried coding move too fast anyway).

Useful if you have 1k or so to spare of memory.

-Glen

[MrSterlingBS]

Hi at all,

is there some progress on the topic?
I am very interested in this sub routine.

BR
Sven

Have fun!

[MrSterlingBS]

Code: Select all

; Important Sprite-Imation Registers
;                                               SPRITE NUMBER
; FUNCTION                                      0         1       2       3
; -----------------------------------------------------------------------------
; Location of sprite data                       $02D0     $02D1   $02D2   $02D3
;             
; Position of sprite on screen (X)              $02DA     $02DC   $02DE   $02E0
; 
; Position of sprite on screen (Y)              $02DB     $02DD   $02DF   $02E1
;
; Enable sprite (on if <> 0)                    $02E4     $02E5   $02E6   $02E7
; 
; Sprite multicolor mode (on if <>0)            $02EA     $02EA   $02EA   $02EA
;
; Sprite foreground color (0-7)                 $02EE     $02EF   $02F0   $02F1
;
; Sprite auxiliary color (0-255)                $900E     $900E   $900E   $900E
;
; Sprite-sprite collision (0=none)              $02F4     $02F5   $02F6   $02F7
;
; Sprite-backround collision (0=none)           $02FA     $02FB   $02FC   $02FD
;
; Number of sprites (1-4)                       $02D5     $02D5   $02D5   $02D5
;
; Alternate joystick register (X: 0-2)          $02D6     $02D6   $02D6   $02D6
;
; Alternate joystick register (Y: 0-2)          $02D7     $02D7   $02D7   $02D7
;
; Alternate joystick register (fire button)     $02D8     $02D8   $02D8   $02D8


; Large-Scale Memory Map of Sprite-Imation
;                                                       START           END
; FUNCTION                                              ADDRESS         ADDRESS
; -----------------------------------------------------------------------------
; Sprite-Imation registers and data                     $02D0           $02FD
;             
; Vector addresses and system variables for sprites     $02FE           $03FC
; 
; 3K Expansion RAM memory                               $0400           $0FFF
;
; User Basic memory in RAM                              $1000           $1679
;
; Sprite-Imation interpreter and subroutines            $167A           $17FF
; 
; Sprite-Imation character matrix in RAM                $1800           $19FF
; 
; Sprite-Imation work area and main programm            $1A00           $1DFF

[Mike]

is there some progress on the topic?

You should check out the thread "Software sprites?", where Robert Hurst ultimately developed a versatile Sprite engine (SSS), which he used in several of his own games, and which also got quite some 3rd party use.

Sprite-Imation, as interesting as it seemed at the time the thread here was conceived, ultimately suffered the fate of a binary executable with no further documentation than what was given with the magazine article, having mostly only one example/demonstration program, without source, no easy way to adapt it for bigger RAM setups and also being too ambitious in its ideas: unlike the sprites on the C64 which have their own colours and are definitely independent off their background, this simply cannot be achieved with the VIC-I video chip. The simple act of scrolling the screen destroys any illusion it could be done that easily on the VIC-20.

[AndyH]

I can also offer the routines I have included with Turbo Rascal. It's an IDE, compiler, assembler and more for many computer formats including the Vic 20.

For the Vic 20 specifically, there is VBM (Vic Bitmap Mode) that is very developer friendly - this creates a full screen bitmap and a number of sprite, text, tile and other routines useful for making games. This requires 8K or greater expansion. I also have LBM (local Bitmap Mode) which is a little closer to what is disucssed in this thread, but that is not yet very developer friendly. Finally, I also have PBM (PETSCII Bitmap Mode) that uses PET block characters to create a bitmap with sprite and tile routines for drawing to it (works a bit like ZX81 graphics).

All the above is embedded in Turbo Rascal, meaning they are easy to use in this context, but as ASM is produced you could rip them out to use in your own assembler environment I guess, although I'd hope you find using Turbo Rascal a fun and interesting way to develop for the Vic 20 If you do rip anything a firendly acknowledgement wouldn't go amiss

[AndyH]

BTW, has anyone got the DSK / PRG for the Sprite-Imation ... be interested to have a look at it (the links in this thread are no longer working).

[AndyH]

I've written my LBM library in TRSE from the ground up to be much simpler to use.

Just one command to call every loop at a suitable raster position that clears any previously draw sprite bitmaps, and then a simple command for each sprite bitmap you wish to draw.

Will require fewer characters to render a sprite and speed boost if you constrain one of the axis to be aligned to the character grid (eg multiples of 8 ) and of course supports moving freely on both x and y axis. As the previous version, can use on an unexpanded Vic 20 with advantage that the code is much smaller in size.

I'm quite please at how easy it is now, compared to my previous version. It should now be available in the nightly downloads with two examples demonstrating it's use.

While I didn't get to see sprite-imatation, it did spark some thoughts and new ideas. Now I need to make a game with it.