[coleco] Sprites Sample ( assembly codes listing )

[+evg2000]

cool, thanks

 

here is a screen shot of the game I was working on at one time:

Edited February 8, 2012 by evg2000

[retroillucid]

cool, thanks

 

here is a screen shot of the game I was working on at one time:

 

Looks pretty nice Charles!

[+evg2000]

unfortunately after posting pic, I realized that I think that's from the pc version I did in turbo c back in the early 90's. have to look again to see if I still have my cv files.

 

(null)

[+SpiceWare]

I made some headway on the mode file last night, even figured out a few glitches I couldn't figure out when I set up the Atari one back in 2006 so I'll need to update it as well.

 

Is there a standard include file^* anywhere that contains the Coleco BIOS routine names, register names, etc? I'm setting it up to highlight those as well, but at the moment I've only got 2 BIOS routines in my self-made file.

 

I set it up so 8 bit registers get one color, 16 bit get another. Hmm, I don't recall seeing a Z register. I see there's also JR NZ further down in the listing... probably a conditional jump based on zero or not-zero result of the bit and cp commands - so much to learn

 

 

^* For the Atari VCS/2600 coding I use VCS.H which defines all the registers (there's no BIOS).

[+SpiceWare]

Any chance of getting a copy of zasm for mac and your jedit mode file?

 

Posted in my blog.

[+evg2000]

cool, now I just have to find time to download and try it;)

[tomjscott]

Here, I'm posting a sample code concerning Sprites. If you have not see my previous posts (messages/videos) please do so in order to understand a few things.

 

For those who already see my messages, you know that this code is made based on TNIASM, a cross-compiler you can find in the Internet, used for example in the GameBoy homebrew scene for years.

 

I'm not gonna talk about the video settings, but about sprites.

 

The following listing doesn't move or change color a bunch of sprites... let's keep it simple and just display sprites on screen. In the video, I'm showing the evolution of this listing starting from 1 sprite to 3,5 and then 7 sprites. With 5 sprites, because the video chip doesn't show more than 4 sprites in a row, I've added a sprites flickering effect based the principle of a circular buffer with the sprites priority table. Other technics like simply swap to the highest priority the non showing sprite might be fast but raise the question why if another sprite (that we are not aware of) does also need to get a higher priority at the same time? That's why I'm using the solution shown here.

 

The table of sprite priorities is initialized with the numbers 0 to nbr_sprites-1, so if there is 5 sprites to show then the table of priorities is [0,1,2,3,4]. When the flickering effect is needed, the first sprite to be the 5th sprite in a row is retreived from the video register and used as a starting point for the circular buffer. For example, if always the 5th sprite condition occurs for a 5 priorities table, you get the following tables of priorities during time : [0,1,2,3,4] -> [4,0,1,2,3] -> [3,4,0,1,2] -> [2,3,4,0,1] -> [1,2,3,4,0] and so on. This makes all the 5 sprites flickering on screen. With the "swap only the 5th sprite to the highest priority" solution, only 2 sprites are flickering on screen, which seems to be a pretty good solution, but deny the possibility if there is a 6th sprite or even a 7th sprite. The flickering effect with 7 sprites, in this sample program, acts as follow : [0,1,2,3,4,5,6] -> [4,5,6,0,1,2,3] -> [1,2,3,4,5,6,0] -> [5,6,0,1,2,3,4] -> [2,3,4,5,6,0,1] -> [6,0,1,2,3,4,5] -> [3,4,5,6,0,1,2] and so on. Well, it should be this sequence, I can't be sure if the emulator you are using will gives you this sequence of sprites order and so this sprites flickering effect.

 

As usual, if you appreciate this program, if you find it useful, please consider voting and/or leave a message.

 

 

Am I missing something here? Why would you "want" to have a flickering effect? Also, I notice on vcoleco emulator that the flickering effect doesn't occur and so it looks the same with or without the reordering code.

 

I also tried this on Virtual Adam with sprite limitations turned on and I see the same flickering result with or without the reordering code.

Edited March 22, 2013 by tomjscott

[tomjscott]

Disregard my last post. I didn't update my ROM image when I ran the version without the reordering. I see that the sprites are actually chopped off and you can't see them when the reordering code is not there. So, the flickering effect is a compromise solution.

[Pixelboy]

Disregard my last post. I didn't update my ROM image when I ran the version without the reordering. I see that the sprites are actually chopped off and you can't see them when the reordering code is not there. So, the flickering effect is a compromise solution.

 

Of course, since you can't have more than 4 sprites on any scanline on the screen. That's a limitation of the VDP (and a very annoying one at that).

[tomjscott]

Of course, since you can't have more than 4 sprites on any scanline on the screen. That's a limitation of the VDP (and a very annoying one at that).

 

I never realized how it manifested itself though. I had always thought that the flickering effect was a natural consequence of having too many sprites on the same line. I didn't know that it would really look chopped off and that special code was implemented to get the flicker.

[tomjscott]

I'm seeing some strange differences between running on Virtual Adam and running on vcoleco. At this point, I don't know if my code is bad or if one emulator isn't working as expected. I find either hard to accept considering the code works on one emulator and the other emulator seems to work fine on game roms. Anyway, I've added some simple code to the 7 sprite demo as follows:

 

; Display Sprite(s)
    ld a,NBR_SPRITES
    call WR_SPR_NM_TBL
    ld a,$d0
    out ($be),a
    ; Increment first sprite's Y position to see what happens
    ld hl, SprAttrib
    inc (hl)
    ; Get Video Status
    call READ_REGISTER
    bit 6,a
    jr z,DoNothing

 

I just added the Y increment code so that the sprite will continuously move down the screen then wrap around and do it again forever. This works fine on vcoleco, but has no effect whatsoever on Virtual Adam. I added a command to copy the new ROM file into the Virtual Adam roms folder whenever I do a make so I know the rom is updated there now when I run it. I tried changing color and x position too, but nothing on Virtual Adam and yet works fine on vcoleco.

 

Anyone have any advice for a new Z80/Coleco programmer?

[Pixelboy]

Careful what you use as Y value on any sprite. A value of 208 (IIRC) means "end of sprite attribute table".

 

You should use blueMSX to test your code. It's one of the better CV emulators out there.

[tomjscott]

Careful what you use as Y value on any sprite. A value of 208 (IIRC) means "end of sprite attribute table".

 

You should use blueMSX to test your code. It's one of the better CV emulators out there.

 

I never heard of that emulator. I'll give it a try if I can find it. Yeah, I forgot about that 208 thing. I saw that in one of the docs. I'll test this code by incrementing the X location instead for now.

[tomjscott]

The code doesn't work in blueMSX either. I must be doing something wrong. This time I tried incrementing the X position. I also tried the color, but neither works. Weird. I wonder why vcoleco does what i would expect.

[Pixelboy]

Did you set up blueMSX to run Coleco ROMs? It's set to MSX by default...

 

EDIT: Run a commercial CV game ROM under blueMSX to make sure it's in ColecoVision mode, before you run your own test ROM.

[tomjscott]

Did you set up blueMSX to run Coleco ROMs? It's set to MSX by default...

 

EDIT: Run a commercial CV game ROM under blueMSX to make sure it's in ColecoVision mode, before you run your own test ROM.

 

Yes, I did that and it was running the ROM fine, but it just doesn't move the sprite as I expected. However, I did run Galaga on blueMSX and seeing the game slowdown significantly whenever I use the arrow keys to move the ship around. The game is unplayable due to this slowdown. I find it hard to believe it's my machine since I'm running an Intel Core 2 Duo 3Ghz machine with 3.5GB of RAM and a decent ATI Video Card.

 

One other thing I notice in these sample programs is that the sprites are really slow. The bouncing sprite demo posted here has the sprites barely moving on the screen at all and there isn't even any delay code in there. If I were to do something like that in 6502 Assembler on the C64, the sprites would be going so fast that they'd be warping all over the place and you'd barely be able to see them. What is causing the Colecovision to go so slow?

[carlsson]

Isn't the example code hooked to the NMI, whenever how often a such occurs on the Colecovision?

[tomjscott]

Yeah, I was suspecting it might have something to do with the NMI and it occurring only at a certain refresh rate. But I thought the nmi was mandatory for things to work right. So how does one have sprites zipping around at high speed?

 

Anyway, this is just getting crazy now. I changed my code to include Daniel's moving, bouncing code and that doesn't do anything on blueMSX either. But it works fine on vcoleco. I'm wondering now if there is something wrong with the way I'm compiling this in tasm that's causing the issue. The code runs and I see the sprites and the whole flickering thing, but no movement or bouncing. This is very odd.

[+5-11under]

Careful what you use as Y value on any sprite. A value of 208 (IIRC) means "end of sprite attribute table".

 

You should use blueMSX to test your code. It's one of the better CV emulators out there.

207?

[tomjscott]

207?

 

From the Programming Colecovision Games document by Daniel Bienvenu:

 

 

"The Y location of a sprite can be any values between 0 and 255 except 208. The special value 208 tells the video chip to stop checking for sprites to display on screen. If you want to don’t show sprite#1 but you want to show sprite#2, use a value like 207 for the Y location of sprite#1."

 

As I re-read that text, it makes absolutely no sense whatsoever. You can't use 208 because it stops checking for sprites, which would mean to me that anything after sprite #1 would be ignored. But in his example, he says if you "want to don't" show sprite #1 (bad English; meaning here?) but you want to show sprite #2, use a value of 207 for sprite #1. Huh? Does he mean really that it's not the value 208 but the 208th position value? As in 0-207, which makes 207 the 208th value? This is just one example of the poor documentation for this system. Once I figure this all out, I plan to provide some good, clean documentation that new programmers can understand and use right out of the gate.

Edited March 23, 2013 by tomjscott

[+5-11under]

From the Programming Colecovision Games document by Daniel Bienvenu:

 

 

"The Y location of a sprite can be any values between 0 and 255 except 208. The special value 208 tells the video chip to stop checking for sprites to display on screen. If you want to don’t show sprite#1 but you want to show sprite#2, use a value like 207 for the Y location of sprite#1."

 

As I re-read that text, it makes absolutely no sense whatsoever. You can't use 208 because it stops checking for sprites, which would mean to me that anything after sprite #1 would be ignored. But in his example, he says if you "want to don't" show sprite #1 (bad English; meaning here?) but you want to show sprite #2, use a value of 207 for sprite #1. Huh? Does he mean really that it's not the value 208 but the 208th position value? As in 0-207, which makes 207 the 208th value? This is just one example of the poor documentation for this system. Once I figure this all out, I plan to provide some good, clean documentation that new programmers can understand and use right out of the gate.

Maybe that's where I got the 207 from. It sounds like if you have a sprite at 208, it won't process the rest of the sprites after that... so if it's 207 or less, then it will show the next sprite(s).

[tomjscott]

Maybe that's where I got the 207 from. It sounds like if you have a sprite at 208, it won't process the rest of the sprites after that... so if it's 207 or less, then it will show the next sprite(s).

 

Here is the info from the TMS9918 Datasheet:

 

 

Sprite processing is terminated if the VDP finds a value of 208 (DO 16) in the vertical position field of any entry in the Sprite

Attribute Table.

[Pixelboy]

208 is the "sprite processing stopper" value. The idea is that you can have up to 32 sprites on the screen, but if you want to display less than 32, you put the value 208 after the last defined sprite in the sprite attribute table. Anything after that value is ignored by the VDP.

[+atari2600land]

I tried for a few hours to try to make the sample code slow down because it was moving too fast but I failed miserably. Is there a way to slow the fish (in my code) down?

 

flawedcodgod.asm