Eye on Coleco, But Many Questions

[Tony Cruise]

The main things you will need to consider when switching from 2600 to Coleco are some fundamental differences which mean you need to use different techniques and approaches.

- CPU Speed - Much faster CPU - the Z80 is clocked at 3.67MHz

- Split Ram - Two sets of Ram & limited pipe between them - You can't write/access Video Ram directly you need to work through a port & it is only possible to transfer so much each vertical blank. Also due to the Coleco's limited 1k of Ram, you can't do large block writes (unless from a fixed Rom area) as you just don't have the space - this is why a lot of MSX games are faster than Coleco conversions - The SGM fixes this issue.

- Horizontal blank - Sorry no horizontal blank - one of your main tools on the 2600, plus Coleco in difference from MSX does not have any Z80 interrupt support, the only one you get is the Horizontal Blank for the VDP, so all timings have to come from that - annoying, but it can be worked around.

- Colour Palette - Only a fixed palette of 16 colours - but at a much higher resolution than the 2600 - you can use colour mixing techniques to achieve more colours - see my site and Cavern Fighter as an example.

- Screen detail/tiles - The screen is divided into three pattern tables of 256 8x8 blocks. Each 8x1 line can be two colours i.e. foreground & background colour can be set, or if transparent the background colour shown.

- Multi-coloured sprites - You can easily achieve multi-coloured sprites by overlaying them (no gaps required). Sprites are shown in a strict priority order, by planning your layering & game structure a lot of the 4 sprites per line issues can be avoided. But if not you have to implement sprite sorting (as others have mentioned). which does introduce flickering.

- Scrolling - easy in 8 pixels chunks by moving the pattern table pointers, but nice if you can go to the next step of pre-storing enough patterns to smooth scroll 2-pixel doesn't do to bad in this respect. Smooth scrolling illusion can be created in some circumstances using sprites, being mindful of the 4 per line limit of course.

- Collision detection - Hardware is sprite to sprite only, it is only a single register bit from the VDP & only tells you that one sprite is touching another, not which one. So you need to implement hit boxes, but remember you have a much faster processor. Most keep the whole sprite table in Ram & copy it once per vertical blank.

 

Any questions, feel free to ask

[Cybearg]

Interesting stuff! A few questions, then:

 

1. With the limited video pipe, does that mean that levels have to be loaded slowly, like some of those old computer games where the level slowly gets drawn in before your eyes?

 

2. I assume you'd get more colors by using a mottled pattern of two colors. How visible (and intrusive) will those mottled patterns be on a real Coleco?

 

3. Which is the transparent background color?

 

4. Is there any tutorial, guide, or framework that can be used for scrolling, either horizontal or vertical (or both)? And if super-nice scrolling isn't possible and it has to be done on 8-pixel tiles, that's okay except that I wonder--how does that work logically with the player sprite? That is, if your sprite was moving to the right and then stopped at a certain point to "push" the screen, the sprite would be running still against an invisible barrier for 7 out of 8 pixels before a new tile would snap in, right?

 

5. Apparently the lack of per-pixel hit collision on sprites isn't an issue, then? I know that the leniency of per-pixel collision can be important in a lot of 2600 games.

 

6. Compared to the 2600, how "big" is everything, really? From what I've seen on the 2600 versus the ICVGM tools, it seems like Coleco pixels are smaller and more detailed than 2600 pixels, and I don't just mean the huge batariBasic playfield pixels, but the actual pixels on-screen. Is this the case or just me misunderstanding?

 

7. Which tools in particular would be useful from the MSX to the Coleco?

[Kiwi]

Interesting stuff! A few questions, then:

 

1. With the limited video pipe, does that mean that levels have to be loaded slowly, like some of those old computer games where the level slowly gets drawn in before your eyes?

 

With NMI disabled, it can write to pattern table, color table, sprite table and name table. These are 12-16KB of writes. It could take a few frames to complete this task. With NMI enabled, you can do small writes to VRAM if you're updating small portion of the screen using put_frame function and updating the score. There's a chance of VRAM curruption if NMI is enabled. I assume if you're scrolling, you have to disable NMI since it has to write 784 bytes to name table and 128 bytes to sprite table if you're updating the sprites. It may take a few frames for it to complete it task.

 

2. I assume you'd get more colors by using a mottled pattern of two colors. How visible (and intrusive) will those mottled patterns be on a real Coleco?

 

http://atariage.com/forums/topic/209122-colecovision-mock-up-pictures-slideshow/?do=findComment&comment=2700209

This will give you an idea what's possible graphics this system can do.

 

3. Which is the transparent background color?

 

Color number 0. The people in other post mentioned the border. The color number 0 will be the color of the border. The border is the black portion that surrounds the game screen. You can change the color of the border in C, paper(13); The color invisible will be color 13.

 

4. Is there any tutorial, guide, or framework that can be used for scrolling, either horizontal or vertical (or both)? And if super-nice scrolling isn't possible and it has to be done on 8-pixel tiles, that's okay except that I wonder--how does that work logically with the player sprite? That is, if your sprite was moving to the right and then stopped at a certain point to "push" the screen, the sprite would be running still against an invisible barrier for 7 out of 8 pixels before a new tile would snap in, right?

 

Unfortuately, there isn't a guide. I have a theory to use a grid of put_frames and use that as tiles to do 8 way scrolling, but there's multiple way to scroll in programming. At the moment there is no framework for scrolling.

 

5. Apparently the lack of per-pixel hit collision on sprites isn't an issue, then? I know that the leniency of per-pixel collision can be important in a lot of 2600 games.

 

Yup.

 

6. Compared to the 2600, how "big" is everything, really? From what I've seen on the 2600 versus the ICVGM tools, it seems like Coleco pixels are smaller and more detailed than 2600 pixels, and I don't just mean the huge batariBasic playfield pixels, but the actual pixels on-screen. Is this the case or just me misunderstanding?

 

Its the actual pixels on screen. There's 256 pixel horizonally while Atari 2600 playfield is 40 pixel across. The color clock(pixel) for sprites(48 pixel with 3 clones enable), missile(1 pixel or 3 if clone is enabled), and ball(1) is 160(?) pixel across.

 

----

 

I would suggest start small if you're planning to work in C. I'm very fond of Notepad++. You can use CCI2 to compile your project. It took me hours for me just to load my pattern when I first started. For assembly, I would get the MSX book others suggested. I do have tniasm to assemble projects. I'm still figuring out assembly. I understood Atari 2600 asm. z80, I'm still learning the directives and learning z80's multiple registers.

[PkK]

If you want to program in C, I would suggest to have a look at teh tutorial here:

http://www.colecovision.eu/ColecoVision/development/tutorial0.shtml

and also at the demos that come with libcv/libcvu at

http://www.colecovision.eu/ColecoVision/development/libcv.shtml

 

Philipp

[Cybearg]

If you want to program in C, I would suggest to have a look at teh tutorial here:

http://www.colecovis...tutorial0.shtml

and also at the demos that come with libcv/libcvu at

http://www.colecovis...ent/libcv.shtml

 

Philipp

 

Big help, thanks!

 

Sorry for the non-responses lately. I'd like to finish stuff with the 2600 before moving on to Coleco. Still, awesome seeing all this! Thanks, everyone!

 

A question, though--Since Colecovision can't do the same kind of dirty tricks the 2600 can do and its hardware specs are pretty much the as-is limit, how are things like Donkey Kong on Colecovision possible, where Mario seems to have three different colors in his body and Donkey Kong seems to have two or three, yet they can stand side by side without any apparent issues, even though that should be a total of 6 sprites. What gives?

[PkK]

Big help, thanks!

 

Sorry for the non-responses lately. I'd like to finish stuff with the 2600 before moving on to Coleco. Still, awesome seeing all this! Thanks, everyone!

 

A question, though--Since Colecovision can't do the same kind of dirty tricks the 2600 can do and its hardware specs are pretty much the as-is limit, how are things like Donkey Kong on Colecovision possible, where Mario seems to have three different colors in his body and Donkey Kong seems to have two or three, yet they can stand side by side without any apparent issues, even though that should be a total of 6 sprites. What gives?

 

Well, there's basically two ways to get more colors in an object:

 

* Use background tiles in addition or instead of sprites.

* Use different sprites for the top an lower parts - the 4 sprite limit is per line.

Edited June 14, 2013 by PkK

[Pixelboy]

Well, there's basically two ways to get more colors in an object:

 

* Use background tiles in addition or instead of sprites.

* Use different sprites for the top an lower parts - the 4 sprite limit is per line.

 

Right on. With a little imagination, you can minimize the impact of the 4-sprite-per-scanline limit. Sometimes an object that looks like a sprite is actually made up of background tiles.

[Cybearg]

But you can see the difference because background tiles can only move in 8-pixel increments, right? Or can they move one pixel at a time?

[Pixelboy]

But you can see the difference because background tiles can only move in 8-pixel increments, right? Or can they move one pixel at a time?

 

It's true that you're stuck with 8x8 background tiles that cannot technically move or scroll, but you can design frames of animation that are distributed over several adjacent tiles. Consider the example of the Moon Patrol prototype for ColecoVision:

 

http://www.youtube.com/watch?v=j9vzGjMALM4

 

The background scrolls in increments of 1 pixel for the blue mountains and 2 pixels for the green hills, and to do this, the scrolling engine uses a ton of tiles in VRAM to store each of the scroll offsets. That kind of programming requires a lot of planning and code optimizations, so I can't imagine this being easy to do in C language (Z80 assembly language is a better option to exercice tight control over the console).

 

It really depends on the kind of game you're doing, and you can come up with a clever type of tile-based object animation that works just for your particular game.

[Cybearg]

So is that what's being done for Mario?

 

Also, how is the actual Moon buggy being done there? it has a number of colors and looks good against many different backgrounds. Is it made up of tiles as well, or is it three layered sprites? Because I could have sworn I saw more than a single other sprite in-line with it and it still looked fine. Not to mention the sprites that make up the gun shots.

Edited June 14, 2013 by Cybearg

[Pixelboy]

So is that what's being done for Mario?

 

What Mario game are you referring to, exactly? Donkey Kong?

 

 

Also, how is the actual Moon buggy being done there? it has a number of colors and looks good against many different backgrounds. Is it made up of tiles as well, or is it three layered sprites? Because I could have sworn I saw more than a single other sprite in-line with it and it still looked fine. Not to mention the sprites that make up the gun shots.

 

I believe the buggy is mostly done with tiles, except for the black wheels and weapon shots. It really looks like super-imposed sprites, doesn't it? Very clever programming, and an excellent example of what can be done when a programmer refuses to compromise on visual rendering.

[Cybearg]

Yeah, in Donkey Kong.

 

What about those dips in the ground that you need to jump over? It's yellow with black and then a different color for the "empty" area. How was that done, or is it a clever trick and it's really just yellow/black and the empty color/black with the square transition being seamless?

[Pixelboy]

Yeah, in Donkey Kong.

 

Given that, in the early days of CV development, programmers didn't have a wide experience of the hardware, I'd say Mario is simply made of super-imposed sprites.

 

What about those dips in the ground that you need to jump over? It's yellow with black and then a different color for the "empty" area. How was that done, or is it a clever trick and it's really just yellow/black and the empty color/black with the square transition being seamless?

 

I would say the black outlines are sprites. I say this because if you look carefully at the video, there are one or two black pixels that occasionally flicker at the top of the outlines of the larger craters.