Jump to content
Cybearg

Eye on Coleco, But Many Questions

Recommended Posts

I've been working on games for the 2600 on and off for about four months now, though I've only released about four. It was thrilling to work within the limitations of the 2600, at least at first, but now I'm starting to find the limitations a bit frustrating (at least when working with batariBasic, as I have been doing).

 

I have a number of game ideas that I would have liked to try for the 2600, but I'm hoping that the Coleco will be a somewhat more flexible system to build on, since (from what I understand) it has more sprites and the characters feature seems very nice. I have a few questions before I get too far into it, though:

 

1. I know that there can be up to 32 sprites on-screen at once, with a limit of 4 per scanline. Now when we say "limit," does it mean that, if there are more, the sprites will start to flicker a bit but everything will work fine and it won't be a real big deal until there are 8+ sprites sharing a scanline, or is it an absolute "cannot have more than 4" limit? What happens if this limit is exceeded?

 

2. The 2600 has a fairly nice 128-color palette (NTSC). I know that Coleco only has 16 colors. Now is this a shared 16-color palette, or are games just limited to 16 colors from a larger palette? What colors are available for the Coleco? Hopefully it's not like the awful CGA color palette.

 

3. How many characters can a single ROM hold? This is especially important if they can (as I hope) be used like tiles in NES games. Do characters have collision detection or does it have to be faked by having a playfield behind the characters?

 

4. In 2600 games, sprites can be of (essentially) unlimited height and have a different color for every horizontal line of pixels (with the right batariBasic kernel/settings, anyway). Now, I know that Coleco sprites are limited to 8x8 or 8x16 only and don't have the same flexibility in that regard that 2600 ones do, but what about the colors? Do Colecovision sprites have to be a solid color, or are there ways to have different colors per line (especially with the C-based Colecovision programming environment, which I hope to use)?

 

5. How does collision work with the Colecovision? With the 2600, there is hardware collision that goes based on what is on-screen, so if you see a sprite overlapping a playfield, a sprite overlapping another sprite, etc., it can return that there is a collision.for whichever combination you specify. The down-side is that there needs to be a collision happening for it to work--you can't anticipate potential collisions and avoid them, such as to make sure that, in a platformer, the sprite stays standing on top of a platform, doesn't enter the platform from below, and can't slide into the platform from the side (though the latter is difficult because you don't know what angle the collision is from). What options are there for collision detection with the Coleco and how difficult is it to, for instance, ensure that the player sprite collides with but cannot enter a square in the center of the screen, regardless of what angle it is struck from?

 

6. The Colecovision is limited to 32k ROMS at most, correct? Does this size limitation tend to be very restrictive for most games? What is each bank's size? Are they each 4k like the 2600?

 

7. If one did have a Coleco ROM made, how would one go about getting it made into a cartridge? Is there someone who can be approached about that, like with Al and 2600 carts?

 

8. What are the odds of a Coleco player having a non-Coleco controller? From what I've heard, the Coleco controller is pretty awful and I'd much rather program for the use of a SMS gamepad or something, but can one expect most to have additional controllers, or is it pretty rare?

 

9. Is there any equivalent of a Harmony cartridge for a Colecovision, allowing one to easily test ROMs on a real system? If not, how accurate are Colecovision emulators to show if something wouldn't work on actual hardware?

 

... That's it for now, but there may well be more questions, I'd greatly appreciate any Coleco Gurus being willing to answer them. Thanks for your time!

Share this post


Link to post
Share on other sites

There is an Atarimax SD cart where you can put your game on that cart and play it on real hardware. You just have to be able to load your game on an SD card which everone now adays seems to be able to do.

I am sure if you do google search on Atarimax SD colecovision that it will show up.

 

There are people out there that will create the guts of the cart and there are people that create new cart casings.

 

A coleco player having other controllers are out there but most people use their colecovision controllers and you can't just plug any controller into the system and have it work because it won't. You would have to convert a gamepad in order to make it work. I think some people have done that but those are considered rare.

 

As for 32KRoms for carts, people have made carts bigger if you need it. There is also a newly released SGM expansion module for colecovision which gives you more RAM and better sound chip. If you look in Opcode forum you can see the info for that.

 

After 4 sprits on a line a flicker starts to happen and you have to manage it programmatically or you will drive your players nuts with all the flickering.

 

I know this is just general info and not exact but I thought I would get you some info in case it takes a while for others to respond.

Share this post


Link to post
Share on other sites

1. I know that there can be up to 32 sprites on-screen at once, with a limit of 4 per scanline. Now when we say "limit," does it mean that, if there are more, the sprites will start to flicker a bit but everything will work fine and it won't be a real big deal until there are 8+ sprites sharing a scanline, or is it an absolute "cannot have more than 4" limit? What happens if this limit is exceeded?

 

On a given TV scanline, only the first four sprites will be displayed. The fifth sprite will not show up at all on the screen. The flicker is done at the game software level, as a workaround to the 4-sprite limit. This implies that even if someone makes a CV clone that can display all 32 sprites on the same scan line, legacy games will make sprites flicker anyway, because the software doesn't know it's running on "better" hardware.

 

 

2. The 2600 has a fairly nice 128-color palette (NTSC). I know that Coleco only has 16 colors. Now is this a shared 16-color palette, or are games just limited to 16 colors from a larger palette? What colors are available for the Coleco? Hopefully it's not like the awful CGA color palette.

 

You've got 16 colors only, and they are non-editable. There's no concept of "larger palette to choose from" on the CV. You've got three shades of red, green and blue (light, medium and dark), plus magenta, gray, light yellow, dark yellow and (of course) white and black.

 

 

3. How many characters can a single ROM hold? This is especially important if they can (as I hope) be used like tiles in NES games. Do characters have collision detection or does it have to be faked by having a playfield behind the characters?

 

I'm not sure I understand your question. Perhaps someone else will better understand what you mean and provide a suitable answer. All I can tell you is that the CV offers two main graphic modes (and some auxiliary modes which are almost never used) and 8x8 tiles are... well... 8x8 tiles. :)

 

 

4. In 2600 games, sprites can be of (essentially) unlimited height and have a different color for every horizontal line of pixels (with the right batariBasic kernel/settings, anyway). Now, I know that Coleco sprites are limited to 8x8 or 8x16 only and don't have the same flexibility in that regard that 2600 ones do, but what about the colors? Do Colecovision sprites have to be a solid color, or are there ways to have different colors per line (especially with the C-based Colecovision programming environment, which I hope to use)?

 

Actually, there are three sprite modes: All sprites are 8x8, all sprites are 16x16 (this is what most CV homebrew programmers use) and all sprites are 16x16 but magnified to appear as 32x32. Sprites on the CV are one color only. All bits set to 1 in your sprite pattern will take the desired color, bits set to 0 will remain transparent. If you want to have a sprite with two colors, you need to superpose 2 sprites. And of course, there's always the 4-sprite-per-scanline limit to worry about.

 

 

5. How does collision work with the Colecovision? With the 2600, there is hardware collision that goes based on what is on-screen, so if you see a sprite overlapping a playfield, a sprite overlapping another sprite, etc., it can return that there is a collision.for whichever combination you specify. The down-side is that there needs to be a collision happening for it to work--you can't anticipate potential collisions and avoid them, such as to make sure that, in a platformer, the sprite stays standing on top of a platform, doesn't enter the platform from below, and can't slide into the platform from the side (though the latter is difficult because you don't know what angle the collision is from). What options are there for collision detection with the Coleco and how difficult is it to, for instance, ensure that the player sprite collides with but cannot enter a square in the center of the screen, regardless of what angle it is struck from?

 

If there's any collision detection available in the CV hardware, it's probably defined as a BIOS routine, but I'm no expert on that particular subject. No one uses BIOS routines except for basic stuff and sound output, so you're usually left with programming collision detection yourself in your own game code.

 

 

6. The Colecovision is limited to 32k ROMS at most, correct? Does this size limitation tend to be very restrictive for most games? What is each bank's size? Are they each 4k like the 2600?

 

The basic ROM limit is 32K. Some homebrew PCB solutions have been created to break this limit, such as Opcode's MegaCart which allows for 128K, 256K, etc. all the way up to 1024K of ROM. In the case of the MegaCart, bankswitching is relatively simple: The first 16K (bank zero) is fixed, and the other 16K bank is switchable.

 

7. If one did have a Coleco ROM made, how would one go about getting it made into a cartridge? Is there someone who can be approached about that, like with Al and 2600 carts?

 

I can think of 5-11under and PkK, both of which are members on AtariAge, and they offer different solutions for 32K PCBs. There's also Opcode Games who can provide you with MegaCart PCBs. In terms of full-scale publishing with box and manual, there's CollectorVision who can help you out.

 

 

8. What are the odds of a Coleco player having a non-Coleco controller? From what I've heard, the Coleco controller is pretty awful and I'd much rather program for the use of a SMS gamepad or something, but can one expect most to have additional controllers, or is it pretty rare?

 

You should program your game for the stock CV controller, unless you want to use the steering wheel, Roller Controller or Super Action Controllers. Most third-party controller solutions aren't terribly recommendable on the CV, and most people have stock CV controllers anyway.

 

 

9. Is there any equivalent of a Harmony cartridge for a Colecovision, allowing one to easily test ROMs on a real system? If not, how accurate are Colecovision emulators to show if something wouldn't work on actual hardware?

 

You have two options: The AtariMax 128-in-1 USB cartridge, and the AtariMax SD cartridge. See atarimax.com for more details.

  • Like 1

Share this post


Link to post
Share on other sites

I would like to add that 8x8 character tiles work the same way on the CV as they do on the NES, but the CV doesn't offer hardware scrolling features. How to structure the pattern and color data in VRAM is also different between the CV and NES, but the end appearance on the TV screen is similar.

Share this post


Link to post
Share on other sites

3. How many characters can a single ROM hold? This is especially important if they can (as I hope) be used like tiles in NES games. Do characters have collision detection or does it have to be faked by having a playfield behind the characters?

About sprites, the VDP can display 32 sprites from a table of 64 sprites (16x16) or 256 (8x8), but it is not limited to that as you can redefine the sprites on the fly.

 

About characters (the background graphics), in the most advanced mode you have 3 zones each with 256 different character blocks (8x8 bitmap with independent two colors per line.) There is an indirection here as there is a screen table that refers to pattern memory, so you can update only screen table (bitmaps previously defined) or only bitmaps (more slower because more data). Also not limited as you can redefine characters on the fly.

Share this post


Link to post
Share on other sites

There is an indirection here as there is a screen table that refers to pattern memory, so you can update only screen table (bitmaps previously defined) or only bitmaps (more slower because more data). Also not limited as you can redefine characters on the fly.

 

Just in case his explanation is not totally clear, there's a screen table in VRAM of 32x24 characters (often called the "name table" in tech docs) and this table references pattern tables and color tables defined elsewhere in VRAM. This explains why the CV has 16K of VRAM. :)

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for all the answers!

 

To clarify, when I asked about the multiple colors per sprite, I'm referring to the effect achieved with the 2600 such as with Princess Rescue here:

 

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

 

The 2600 can only do a single-color sprite as well, but by changing the color value being read for the sprite as the scanlines are being drawn, different colors per each horizontal pixel row can be used.

 

I suppose this probably isn't possible with Coleco since Coleco uses video ram instead of "racing the beam" video data on the fly. Even if it was possible, I suppose it's kind of moot with only 16 colors.

 

The 16 color limitation sounds especially painful after being used to 128 colors on the 2600. I take it that this limitation isn't too big of a deal in practice (I'm kind of looking for some reassurance here)?

 

As for my questions about collision detection, if there is no way to detect automatically if a sprite is or isn't colliding with another sprite or with the playfield, what is the recommended method for collision detection? Does one need to keep an array for all tile locations that should serve as positive collision detection? Presumably, there is no per-pixel hit detection then and instead one needs to program in a hit box (basically, comparing values to see whether two sprites share coordinates within the same range)?

 

Since it's advised that I program for the Coleco controller, can anyone attest to the quality of the controller? From the AVGN/other things I've seen for it, it's not as bad as the 5200 controller, but it's about on par with the Intellivision controller and being overcomplicated and clumsy to use. Is this the case?

 

It was mentioned that there is no hardware scrolling for the tiles, but presumably it can be performed with software and still look pretty good?

 

Since tiles allow for a lot more detail than the solid-color playfield, is there any real reason to use the playfield? Also, are the playfield/background indeed limited to a single color or, as with the question regarding multicolored sprites above, is there any way to have different colors on different lines?

 

Thanks again for all the responses!

Share this post


Link to post
Share on other sites

5. How does collision work with the Colecovision? With the 2600, there is hardware collision that goes based on what is on-screen, so if you see a sprite overlapping a playfield, a sprite overlapping another sprite, etc., it can return that there is a collision.for whichever combination you specify. The down-side is that there needs to be a collision happening for it to work--you can't anticipate potential collisions and avoid them, such as to make sure that, in a platformer, the sprite stays standing on top of a platform, doesn't enter the platform from below, and can't slide into the platform from the side (though the latter is difficult because you don't know what angle the collision is from). What options are there for collision detection with the Coleco and how difficult is it to, for instance, ensure that the player sprite collides with but cannot enter a square in the center of the screen, regardless of what angle it is struck from?

 

The ColecoVision has pixel-accurate colission detection hardware for collisions between sprites. However, this functionaily is not commonly used by games. And unfortunately, it seems to be one of the first things to fail when the voltage supply at the graphics chip is too low (low voltage is a common problem on ColecoVisions due to voltage switch dirt buildup and power supply degradation). So if you use it be prepared for players complaining that your game doesn't work even though other games are working on their systems.

 

Early beta versions of SCJ3 did use it, then I changed it to detect if the colission detection is working at startup, but in the end I just went with always using the software fallback, that I needed anyway for when the hardware didn't work.

 

6. The Colecovision is limited to 32k ROMS at most, correct? Does this size limitation tend to be very restrictive for most games? What is each bank's size? Are they each 4k like the 2600?

 

You can access the whole 32K directly. Bank selection is only required is you're using some custom hardware to go over the 32K limit.

 

8. What are the odds of a Coleco player having a non-Coleco controller? From what I've heard, the Coleco controller is pretty awful and I'd much rather program for the use of a SMS gamepad or something, but can one expect most to have additional controllers, or is it pretty rare?

 

Low for non-Coleco controllers, but many player will have the super action controllers from Coleco.

 

Philipp

Share this post


Link to post
Share on other sites

7. If one did have a Coleco ROM made, how would one go about getting it made into a cartridge? Is there someone who can be approached about that, like with Al and 2600 carts?

 

One option would be these homebrew kits:

http://www.colecovis...ebrew kit.shtml

 

Philipp

Share this post


Link to post
Share on other sites

I never have thought the colecovision controller was clumsy but you are right everyone else seems to complain about them.

 

However a guy in this forum called Yurkie does a mod where he puts a ball top controller on instead of the disc and straightens the coards so they are longer and don't pull at you.

With those mods I think pretty much everyone has been in agreement that it makes the controllers a 100 times better and people actually like to use them then.

Share this post


Link to post
Share on other sites

I suppose this probably isn't possible with Coleco since Coleco uses video ram instead of "racing the beam" video data on the fly. Even if it was possible, I suppose it's kind of moot with only 16 colors.

No, it's not possible.

The 16 color limitation sounds especially painful after being used to 128 colors on the 2600. I take it that this limitation isn't too big of a deal in practice (I'm kind of looking for some reassurance here)?

I think you'll find the palette pretty reasonable. (there is three blue tones, three green tones, two yellows, three red (one looks like maroon), purple, gray and white) (wow!, I've used nested parenthesis :D)

As for my questions about collision detection, if there is no way to detect automatically if a sprite is or isn't colliding with another sprite or with the playfield, what is the recommended method for collision detection? Does one need to keep an array for all tile locations that should serve as positive collision detection? Presumably, there is no per-pixel hit detection then and instead one needs to program in a hit box (basically, comparing values to see whether two sprites share coordinates within the same range)?

There is a bit for collision detection, any sprite versus other, but it's not to be trusted! Hit boxs are a lot better.

Since it's advised that I program for the Coleco controller, can anyone attest to the quality of the controller? From the AVGN/other things I've seen for it, it's not as bad as the 5200 controller, but it's about on par with the Intellivision controller and being overcomplicated and clumsy to use. Is this the case?

The standard Coleco controllers are very hard, you can always choose another controller. In fact you can use Atari controllers if you use only a button and don't use keypad.

 

But believe me, you get accostumed to them or you change them. I've used the standard Coleco controllers for testing my own games and playing a lot of other games, easily I can talk about several hundred hours playing, and I can say you that now I have stronger hands :)

It was mentioned that there is no hardware scrolling for the tiles, but presumably it can be performed with software and still look pretty good?

Indeed.

Since tiles allow for a lot more detail than the solid-color playfield, is there any real reason to use the playfield? Also, are the playfield/background indeed limited to a single color or, as with the question regarding multicolored sprites above, is there any way to have different colors on different lines?

Oh yes!, what you call the playfield is simply the border color showing below (in fact your tiles can use the zero transparent color), and it's very useful for bombs exploding and thunders as you can change color writing to a single register.

Thanks again for all the responses!

You're welcome.

Edited by nanochess

Share this post


Link to post
Share on other sites

1. I know that there can be up to 32 sprites on-screen at once, with a limit of 4 per scanline. Now when we say "limit," does it mean that, if there are more, the sprites will start to flicker a bit but everything will work fine and it won't be a real big deal until there are 8+ sprites sharing a scanline, or is it an absolute "cannot have more than 4" limit? What happens if this limit is exceeded?

 

The sprite that load last will be dropped on the scanline. Flickering is done by reordering the sprites every frame by software.

 

2. The 2600 has a fairly nice 128-color palette (NTSC). I know that Coleco only has 16 colors. Now is this a shared 16-color palette, or are games just limited to 16 colors from a larger palette? What colors are available for the Coleco? Hopefully it's not like the awful CGA color palette.

 

Only 16 fixed colors.

 

3. How many characters can a single ROM hold? This is especially important if they can (as I hope) be used like tiles in NES games. Do characters have collision detection or does it have to be faked by having a playfield behind the characters?

 

With rle compression, I can cram as many pattern, color, and name table into 32KB rom. It really depends on the project itself and the game size you're going for.

 

4. In 2600 games, sprites can be of (essentially) unlimited height and have a different color for every horizontal line of pixels (with the right batariBasic kernel/settings, anyway). Now, I know that Coleco sprites are limited to 8x8 or 8x16 only and don't have the same flexibility in that regard that 2600 ones do, but what about the colors? Do Colecovision sprites have to be a solid color, or are there ways to have different colors per line (especially with the C-based Colecovision programming environment, which I hope to use)?

 

Colecovision can only do 8x8, 16x16, sprite simple, sprite double. Even at 8x8, you're still limited to 4 sprites in a row. 16x16 size is used the most. Each sprite can only have one color.

 

5. How does collision work with the Colecovision? With the 2600, there is hardware collision that goes based on what is on-screen, so if you see a sprite overlapping a playfield, a sprite overlapping another sprite, etc., it can return that there is a collision.for whichever combination you specify. The down-side is that there needs to be a collision happening for it to work--you can't anticipate potential collisions and avoid them, such as to make sure that, in a platformer, the sprite stays standing on top of a platform, doesn't enter the platform from below, and can't slide into the platform from the side (though the latter is difficult because you don't know what angle the collision is from). What options are there for collision detection with the Coleco and how difficult is it to, for instance, ensure that the player sprite collides with but cannot enter a square in the center of the screen, regardless of what angle it is struck from?

 

For collusions, sprite on sprite, I use hit boxes. If I need to the sprite to interact with the background tiles. I get the location of the sprite, then divide it x and y by 8. I use that value to get the name table ID. Then do a comparsion to determine whether the name table ID is what the sprite is looking for. If there a match, then an action will occur.

 

6. The Colecovision is limited to 32k ROMS at most, correct? Does this size limitation tend to be very restrictive for most games? What is each bank's size? Are they each 4k like the 2600?

 

Colecovision can only read 32KB at a time, like Atari 2600 can only read 4KB at a time. The games has to be bankswitch to read more ROM space.

 

9. Is there any equivalent of a Harmony cartridge for a Colecovision, allowing one to easily test ROMs on a real system? If not, how accurate are Colecovision emulators to show if something wouldn't work on actual hardware?

 

Ultimate SD cartridge, this thing is awesome! It also have bankswitching testing.

 

 

16 colors isn't really painful. It is limiting The higher definition will make the tiles and sprite more defined. Pixel artist usually good at taking advantage of the 16 colors.

 

I can't really compare the 5200 to the Colecovision because I never used a 5200 before. The 7800 when I was a kid, however, my dad had a hard time to find a replacement controller once the right button stopped working.

Share this post


Link to post
Share on other sites

Thanks for all the info again, folks!

 

It's encouraging to hear that the 16 color limitation isn't too bad. 16x16 pixels will seem like an insane amount of available detail, since I'm used to 8x8 or 8x16. Pretty awesome!

 

By the way, those are square pixels, correct?

 

Also, generally how sensitive is the 4-sprites-per-scanline limitation of the Coleco? That is, if the sprites were stacked on top of each other, pixel to pixel, would it be all good, or does there need to be a big of a gap between them? In the 2600, in kernels that support more than just 2 sprites, they can't sit one on top of the other and there needs to be a gap of a few pixels, or so it seems in my experience.

 

Also, is there a graphic tool to make creating playfields/setting tiles easier, rather than planning and plotting out 1s and 0s in a long string? Visual batari Basic has a very nice playfield creation tool (and a sprite creation tool as well) which help immensely to keep the process visual and intuitive, then it just exports the data arrays that make up the actual sprite/playfield data. Anything like that for the Coleco programmer? Any other useful tools?

Edited by Cybearg

Share this post


Link to post
Share on other sites

You can grab the character editor ICVGM from his blog. http://newcoleco.dev-fr.org/p4179/2009-12-02-editeur-graphic-i-c-v-g-m.html

This is my most favorite tool and I love it to death.

 

http://newcoleco.dev-fr.org/p4136/2009-03-22-outil-graphique-cv-graphics-toolkit.html This one has the CVpaint, which you can import picture from the clipboard(Copy a picture from any source). Then another tool CV Sprites 2, will allow you to use backdrop you saved using cvpaint. You can make sprites, place them on to the scene. It will give you the x and y coordinate information on the bottom of the screen. Also, all the program above can compress tables to RLE format.

 

http://newcoleco.dev-fr.org/p4118/2009-02-02-coleco-dev-sdcc.html has the sample codes.

 

The programming book http://www.gooddealgames.com/articles/Colecovision_Programming2.html

 

Here are some videos to install sdcc and get stuff compile.

 

 

The sound function isn't working at all, but I hope I will find a solution to that soon. Aside from sound, CCI3 been excellent. I hope this get you started. Enjoy!

Share this post


Link to post
Share on other sites

Thanks for those links, Kiwi! After fidlding around, I've already got something not-that-bad out of it thanks to that awesome program. Cheers!

 

Can folks recommend some good Coleco game videos to check out to get an idea of the capabilities of the system and what the visuals are like? Also, if you have a time to check out the .dat file I posted, any suggestions for how something like the screen I've got there could be improved by being packed with more detail? I was going for a sorta Castlevania-ish thing.

testset2.zip

Share this post


Link to post
Share on other sites

Okay, now I've just been having too much fun with this tool. I'm loving the control it offers compared to the limited 2600 background options!

 

Going back to my question on collision detection, since the whole background will pretty much be tiles (why wouldn't they be?), I'm again in the situation where I'm not sure, logically, how I could tell whether the player (or enemies) is colliding with a tile that I want to be impassable, as opposed to ones that are just in the background. Can I check to see if a tile at a certain location is a tile of a certain ID and determine whether I want it to be a passable tile or not based on that? If so, then that could lead to an awful lot of if/then or case-switch statements to check for all possible variations of collision-enabled tiles, so could I maybe reorder the tiles in the font set so that collision tiles would all have sequencial IDs, allowing me to do something like:

 

if (tileID >= 0 && tileID <= 31)
{
// collision-positive code here
}

 

...?

alley.zip

Share this post


Link to post
Share on other sites

One alternate way to do collusion is using a table.

 

const byte Room1COLLUSION = {
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,
1,1,1,1,1,1,1,1,1,1,1,0,0,1,2,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

This just a sample. 1 would be passable, 0 would be inpassable, then 2 would be a special tile like a door. The table could be 32x24, for that screen. The Colecovision only has 1024 bytes of RAM, so keeping table constant, which can be read from ROM.

 

That way, your comparison statement is much smaller since it is reading from a table. I have not use the table collusion method in my Colecovision project yet. I have done this above on another system. I wish I could explain better. I just need to get some sleep.

 

You can see videos on this channel. http://www.youtube.com/user/newcoleco/videos. If you make it down to the bottom of the video list, there's 2 videos that explains the Texas Instruments 9918 Colecovision's graphic chip.

Share this post


Link to post
Share on other sites

The table concept makes sense. I forget that there's plenty of space now compared to the 2600. :)

 

Is there any way to design levels larger than a single screen using that ICVGM tool or another, similar one? I absolutely love the way it lets me place tiles, but I want to draw out a full, scrollable screen instead of just being limited to a single screen size. Is there any tool that allows me to do this?

Share this post


Link to post
Share on other sites

Is there any way to design levels larger than a single screen using that ICVGM tool or another, similar one? I absolutely love the way it lets me place tiles, but I want to draw out a full, scrollable screen instead of just being limited to a single screen size. Is there any tool that allows me to do this?

 

Think about what you're saying here: You're talking about doing background scrolling on the ColecoVision.

 

Since the CV doesn't offer hardware scrolling (like the NES) you have to design and program some kind of scrolling engine all by yourself. Since there are several ways to do it (none of them really easy) the content and structure of your graphic data will necessarily depend on the scrolling method you select, mostly because of speed optimization issues.

 

So in effect you're asking for a graphic design tool, made by someone else, in the past few years, that will match your particular way of implementing scrolling. That doesn't make much sense, now does it? :)

 

You like ICVGM? I love it too. But you have to consider yourself lucky just to have this tool available, because you're not going to find a whole lot of other useful CV dev tools like this online. If you believe that using a software graphic tool will help you save time for your CV game project, then you have to program this tool yourself.

 

People around here can help you with precise programming questions, but for the most part, you're on your own, buddy. ;)

Share this post


Link to post
Share on other sites

8. What are the odds of a Coleco player having a non-Coleco controller? From what I've heard, the Coleco controller is pretty awful and I'd much rather program for the use of a SMS gamepad or something, but can one expect most to have additional controllers, or is it pretty rare?

 

Since Atari 2600, Atari 7800, SMS and compatible controllers work fine with Coleco, just program your game to use a single button (2600 and SMS) or two buttons (7800 or standard Coleco controller). If you want to use keypad and your making a single player game, then allow standard Coleco controller connected to port 2 to be used for keypad entry, this will allow many different controllers to be used as the primary input device on port 1. Main thing to get right is if your game will use 8 directions (space shooter) or 4 directions (Pac-Man type game).

 

Only a few games require 4 buttons of the Super Action Controller, so you might want to avoid using 4 buttons unless it really effects game play in a negative way.

Edited by grips03

Share this post


Link to post
Share on other sites

Well, ICVGM does help with scrolling a bit. Lay out the tiles for the screen, save and RLE export it to c. Then hit the side button, which borders the screen data, to shift all the tile over by 1, lay the new tiles over the old one. Then make a new save and export it to C. Repeat until you're satified with it.

 

Copy the rle'd name table from each c file you generated from ICVGM to your project. When declaring the tables, be sure to add const, others CCI3 will put table to RAM not ROM.

 

const byte sc01NAME[] = {data};
...
const byte sc12NAME[] = {data}; //table data
void main(void)
{
cls();
disable_nmi();//disables nmi if doing major VRAM writes
rle2vram(sample1PATTERN,0x0000);
rle2vram(sample1PATTERN,0x0800);
rle2vram(sample1PATTERN,0x1000);
rle2vram(sample1COLOR,0x2000);
rle2vram(sample1SPRITE,0x3800);
delay(1);
rle2vram(sc01NAME,0x1800);
delay(50);
rle2vram(sc02NAME,0x1800);
delay(50);
rle2vram(sc03NAME,0x1800);
delay(50);
rle2vram(sc04NAME,0x1800);
delay(50);
rle2vram(sc05NAME,0x1800);
delay(50);
rle2vram(sc06NAME,0x1800);
delay(50);
rle2vram(sc07NAME,0x1800);
delay(50);
rle2vram(sc08NAME,0x1800);
delay(50);
rle2vram(sc09NAME,0x1800);
delay(50);
rle2vram(sc10NAME,0x1800);
delay(50);
rle2vram(sc11NAME,0x1800);
delay(50);
rle2vram(sc12NAME,0x1800);
delay(20);
enable_nmi();
}

 

Only downside, this method will take up a lot more ROM. There are other ways to do scrolling. There's always more than one way to do something in this programming world ;).

Share this post


Link to post
Share on other sites

when you do program a Coleco game please make non playable border black. Colored borders look bad.

Share this post


Link to post
Share on other sites

when you do program a Coleco game please make non playable border black. Colored borders look bad.

What do you mean?

Share this post


Link to post
Share on other sites

there's a border around the screen to ensure overscan of crappy tv's available in the 80's would not cut off the edges, think like a C64, if you make them puke green and your main screen is blue it just looks awful

 

make them black

  • Like 1

Share this post


Link to post
Share on other sites

Just to add one thing that i think has not have been mentionned yet.

 

the Colecovision hardware is very close to the MSX hardware. And there is tons of very good graphic tool done for MSX developpement that can be used for colecovision. Also the Texas Instrument TI 99/4A use the same video chip and here also you can find usefull graphic tools.

 

Personnaly , i learnt a lot about colecovision programming by buying MSX book and browsing MSX forums....

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...