Questions about Coleco graphics capacity?

[BladeJunker]

Hello just looking for an abridged layman explanation of how much graphics data Colecovision games hold, I know it has 16 KB DRAM as graphics memory. Maybe I'm missing the terminology as different systems call the same things different names. Was working on a pixel art guide for the system but it needs more information to complete it properly.

 

-Is that 16KBs a generic chunk of memory that either sprites or background tiles can divide from in non equal ways at run time or is there a set size of bitmap one can use for either layer IE. the Nes and its two 128X128 CHRs?

 

-The Colecovision can't bank switch but the MSX can, does the ADAM or TI/994A allow bank switching?

 

-Do many Colecovision games use Mode II or is that something better suited to the MSX or Super Game Module? Also dumb question but is Mode II all or nothing or can it be applied liberally in just key areas of the screen graphics?

 

Any help would be most appreciated.

[Tony Cruise]

The Coleco (like the MSX and other similar systems) have a separate graphics processor that has it's own work RAM of 16k, along with this the Coleco has 1k of normal RAM for the CPU (Z80) to use.

The standard cartridge can have a maximum ROM size of 32k, which can contain, code, graphics and sound data mixed in any order (most launch titles only used 16k Rom cartridges - thus why titles such as Donkey Kong are missing a level). With compression it is amazing what you can fit in a 32k cartridge.

As the main CPU is a Z80 it is capable of bank switching and there is a bank switching cartridge available that allows much large ROMS (up to 1Mb?), which can once again contain code, graphics and sound data.

[Rybags]

Bank switching within a cartridge isn't really a capability that's dependant on the host system, although it can help.

 

2 examples: The Atari 8-bit computer has a specific line CCTL, that goes active whenever a specific 256 byte range of addresses is accessed. Practically all bank-switching schemes use this as part of the logic for bank-switching.

 

Atari 2600 - no special control line, in fact not even a write line is provided. But there's ways around it. Bank switching can be achieved by using logic that senses access to a small range of addresses. That is sufficient to provide what's needed although often a bit more expensive in terms of logic required in the cart.

[usar666]

Hello just looking for an abridged layman explanation of how much graphics data Colecovision games hold, I know it has 16 KB DRAM as graphics memory. Maybe I'm missing the terminology as different systems call the same things different names. Was working on a pixel art guide for the system but it needs more information to complete it properly.

 

-Is that 16KBs a generic chunk of memory that either sprites or background tiles can divide from in non equal ways at run time or is there a set size of bitmap one can use for either layer IE. the Nes and its two 128X128 CHRs?

 

-The Colecovision can't bank switch but the MSX can, does the ADAM or TI/994A allow bank switching?

 

-Do many Colecovision games use Mode II or is that something better suited to the MSX or Super Game Module? Also dumb question but is Mode II all or nothing or can it be applied liberally in just key areas of the screen graphics?

 

Any help would be most appreciated.

 

Vram on coleco (like MSX or other systems using the same VDP) is a 16K block.There is no imposed organisation, you can store everything (sprites pixels,tiles pixels,attribute table, color table,sprite table and if you want unrelated to VDP data) where you want (with some limitations caused by pointers alignements).Vram is private and can not be seen directly by Z80.

Afaik mode II affects the whole screen.

 

Btw , Z80 is able to address only 64K and is not able of bank switching alone , this job is done with external (to Z80) logic on other systems.

Edited January 17, 2014 by usar666

[+Gemintronic]

So, are there any carts that had extra features that appeared to improve graphics? Things like more memory?

 

I'm one of those who think the Coleco could have gone way farther had they adopted the big Ns policy of just stuffing more hardware into the cart.

[Pixelboy]

 

So, are there any carts that had extra features that appeared to improve graphics? Things like more memory?

It depends what you mean by "improved". The CV's graphic chip is what it is. You can't change the 16 colors or the available graphic modes.

[Kiwi]

So, are there any carts that had extra features that appeared to improve graphics? Things like more memory?

 

I'm one of those who think the Coleco could have gone way farther had they adopted the big Ns policy of just stuffing more hardware into the cart.

 

Only way to improve the graphic capability is to add another video chip to the Colecovision.

 

 

The NES is different since there's 2 source of chip on the cartridge for the NES to see. It can see 32KB of ROM at a time, 8KB of Char ROM at a time. So it accessible immediately upon boot up. Some cartridges have 8KB of Char RAM so graphics would load from the Game ROM to this pool of memory. The mapper helps bankswitch the char ROM by chunk of 4KB, 2KB, 1KB, depending what the mapper is. This save CPU cycle and can be for more game logic.

 

Even with the mapper chip, it still have to respect NES limitation.

 

Colecovision, you have to set the register and load the graphic from ROM to the appropiate VRAM section. You can have the graphic compressed on ROM and it'll decompress into VRAM. So a full tileset that is about 400-600 bytes expands to 2048 KB.

[BladeJunker]

So graphics space use just varies per game then, depending on the needs of not specifically the bitmap data itself? Would 256X128 pixels worth of image space be practical on a Colecovision, like for example cross platforming a roughly equal amount of graphics content, give or take an extra color overlay?

I guess it's smaller bitmaps being 1-bit color rather than 2-bit. Guess I'm asking about a 'safe' or maybe a good standard amount of memory to dedicate to graphics.

 

Well nice to hear cartridge size has boosted to upwards of 1MB and that there's a hardware based solution, usually faster than dumping it all on to the Z80 to do.

 

Does the 1K of system memory act as a bottleneck of data transfer IE. a bunch of data in the VRAM but slow transfers or shuffling?

[Kiwi]

You can have up to 784 unique tiles on screen on Screen_mode_2_bitmap which uses most of VRAM. There only 2 colors per 8x1 pixel a row. There's 3 banks of 2KB for tiles, and there's 3 banks of 2KB for colors, so 12KB of VRAM needed plus the 784 byte name table for tile definition. Leaving 256byte for sprite table and 784bytes for the 2nd screen. And lastly 2 KB for the Sprite tileset

The memory map usually goes by

0x0000 - char table 1

0x0800 - char table 2

0x1000 - char table 3
0x1800 - name table 1 - which is on at default

0x1b00 - sprite data which holds the x,y,pattern, and color information for up to 64 sprites, but only 32 sprite maximum can be displayed on screen

0x1c00 - name table 2 - you can swap to this table. I think this would be useful for inventory screen, and act like double buffer if you don't want to change anything in name table 1.

0x2000 - color table 1

0x2800 - color table 2

0x3000 - color table 3
0x3800 - sprite tileset/generator

 

I use screen_mode_2_text that newcoleco fixed that leaves color table 2 and 3 free, 4KB free. I can use that space to decompress extra graphics to and can be read from. I have 128 bytes buffer for transferring graphic from the VRAM to the VRAM that is used by the TI-chip. The transfer is almost instant. It is being used in real time in Computer Space 2nd player graphic. You can upload from ROM to the VRAM location. I think it 100-300 bytes a frame transfer.

 

Here's some informational videos of the TI-chip that newcoleco made

 

 

This thread have some mock-up of people made to see how game would have looked on the Colecovision.

http://atariage.com/forums/topic/216119-colecovision-mockups-war/

Edited January 18, 2014 by Kiwi

[BladeJunker]

Well background graphics space is quite roomy on the Coleco compared to the Nes and faster too out of the box. I think that would quite handy for fonts, on the Nes the space used by text characters always eats up a lot of space especially if you want lowercase. I aim for frugality in graphics IE. save space, so the tile space on this platform is like a warehouse compared to what I usually work with.

 

Thanks for the videos Kiwi, I'm very visual so it helped me absorb the basic structure of things well.

 

I saw some posts saying it was hard to design graphics for the Coleco compared to the Nes but to me its apples and oranges, not harder just different. The 2600 was much more challenging from a graphics standpoint, very frugal.

[BladeJunker]

How about the sprite space of 32 out of a library of 64, at 16x16 does that come out to 128X128 pixels of space and does that just shrink to 64X64 in 8X8 mode? Or do I have that all backwards and the 64 library is what you have sitting in ram ready for use on screen at one time while sprite space is variable in total space used?

[+nanochess]

How about the sprite space of 32 out of a library of 64, at 16x16 does that come out to 128X128 pixels of space and does that just shrink to 64X64 in 8X8 mode? Or do I have that all backwards and the 64 library is what you have sitting in ram ready for use on screen at one time while sprite space is variable in total space used?

 

In 8x8 mode or 8x8 magnified you have 32 sprites in screen choosen from a library of 256 in VRAM (2K table aligned in 2K boundary)

 

In 16x16 mode or 16x16 magnified you have 32 sprites in screen choosen from a library of 64 in VRAM (also 2K table aligned in 2K boundary)

 

Anyway you're not limited to have only 64 sprites in library, most games redefine sprites in the go.

 

The important difference versus NES is that each sprite only has one color, so you need to mount one sprite over other to get multicolor sprites, also you cannot have more than 4 sprites per line (the others disappear automatically)

[BladeJunker]

 

In 8x8 mode or 8x8 magnified you have 32 sprites in screen choosen from a library of 256 in VRAM (2K table aligned in 2K boundary)

 

In 16x16 mode or 16x16 magnified you have 32 sprites in screen choosen from a library of 64 in VRAM (also 2K table aligned in 2K boundary)

 

Anyway you're not limited to have only 64 sprites in library, most games redefine sprites in the go.

 

The important difference versus NES is that each sprite only has one color, so you need to mount one sprite over other to get multicolor sprites, also you cannot have more than 4 sprites per line (the others disappear automatically)

Alright so that is pretty much 128X128 pixels of sprite space by default with options to shuffle graphics around as it rendering on screen? Is 2K the maximum and could I use less if I wanted to like for really small games?

 

Is redefining sprites on the go a fast or expensive process?

 

Yeah I grasp whole color layer aspect. Mostly it seems like there isn't a lot of room for layering much and I should try to make as many sprites as I can into the Char Set instead?

[+nanochess]

Alright so that is pretty much 128X128 pixels of sprite space by default with options to shuffle graphics around as it rendering on screen? Is 2K the maximum and could I use less if I wanted to like for really small games?

 

Is redefining sprites on the go a fast or expensive process?

 

Yeah I grasp whole color layer aspect. Mostly it seems like there isn't a lot of room for layering much and I should try to make as many sprites as I can into the Char Set instead?

 

Yep, technically it could be seen as a 128x128 bitmap. You don't need to use it all.

 

The VDP is relatively slow for accessing VRAM, technically you can change 2130 bytes in VRAM in each frame if you don't use CPU for other things. A sprite definition sizes up to 32 bytes and the screen to 768 bytes, so make your numbers.

 

If you can you should try to define all most static elements using the char set.

[Kiwi]

It's more like 64 columns x 128 rows pixel sprites with 16x16 sprites sewn together.

 

With 8x8 sprites, it 32 columns x 128 rows pixel. Even with 8x8 sprites, you're still limited to 4 sprites in a row.

 

There's a magify feature that double all the sprite pixel size so each sprites is 32x32. 128x256 pixel is possible.

 

Some game that need more than 4 sprites in a row, the programmer have to reorder the sprites to make the sprites flicker. Like the game I'm working on right now.



The animated GIF runs at 16 fps, but it's quicker in real-time.

So what I'm doing is sprite 0-19 is fixed, but the x,y,color,pattern variables advance up the slot by four every frame. In this way, the player can see the trees and can shoot or avoid crashing into them.

Also, the Colecovision doesn't have scrolling register so sprites is smoother to use than char, which is more difficult to move smoothly. The grass is process via CPU and written to it dedicated tile slot. So I'm using sprite to make the trees scroll smoothly. The witch and her shooting star as tile, which move more choppy. I'm avoiding putting a lot of task in one frame by splitting the tasks across 16 frames. The trees have to be updated every frames so the flicker would be fastest. The grass and tree move every 2 frames. The witch 4 frames.

 

I ramble too much. It different between games and it up to the developer to make the game engine work within restraint and also avoid video corrupt due to NMI.

Edited January 20, 2014 by Kiwi

[BladeJunker]

It's more like 64 columns x 128 rows pixel sprites with 16x16 sprites sewn together.

 

With 8x8 sprites, it 32 columns x 128 rows pixel. Even with 8x8 sprites, you're still limited to 4 sprites in a row.

 

There's a magify feature that double all the sprite pixel size so each sprites is 32x32. 128x256 pixel is possible.

 

Some game that need more than 4 sprites in a row, the programmer have to reorder the sprites to make the sprites flicker. Like the game I'm working on right now.

 

Witch3a.gif

 

The animated GIF runs at 16 fps, but it's quicker in real-time.

 

So what I'm doing is sprite 0-19 is fixed, but the x,y,color,pattern variables advance up the slot by four every frame. In this way, the player can see the trees and can shoot or avoid crashing into them.

 

Also, the Colecovision doesn't have scrolling register so sprites is smoother to use than char, which is more difficult to move smoothly. The grass is process via CPU and written to it dedicated tile slot. So I'm using sprite to make the trees scroll smoothly. The witch and her shooting star as tile, which move more choppy. I'm avoiding putting a lot of task in one frame by splitting the tasks across 16 frames. The trees have to be updated every frames so the flicker would be fastest. The grass and tree move every 2 frames. The witch 4 frames.

 

I ramble too much. It different between games and it up to the developer to make the game engine work within restraint and also avoid video corrupt due to NMI.

I don't quite understand the columns and row description, columns are vertical and rows are horizontal but how would that look in a "ripped" format? What I'm trying for is a 'canvas' of sorts, pixel art forums can work in defined image constrictions but they work better with a doodle space or bitmap dimension especially with graphics spread over several blocks.

 

Yeah I like the magnify option, I've been trying it out with mockups in Multicolor mode using sprite overlays to create a mock 128X96 with 64x48. Also tried 64X48 using sprites in an ANSI like manner to create more color shades with dither blocks.

 

Are you actually moving the grass tile like advancing the tilemap in memory? If you just need moving grass wouldn't a prerendering of panning animation of the grass tile be easier and relatively cheap?

[Kiwi]

I don't quite understand the columns and row description, columns are vertical and rows are horizontal but how would that look in a "ripped" format? What I'm trying for is a 'canvas' of sorts, pixel art forums can work in defined image constrictions but they work better with a doodle space or bitmap dimension especially with graphics spread over several blocks.

I was thinking how the sprite is displayed. So this is 64x128 pixels with 32 sprites at 16x16 mode.

 

left side is how it look in VRAM. Right side is how the 16x16 sprite is ordered.

 

Are you actually moving the grass tile like advancing the tilemap in memory? If you just need moving grass wouldn't a prerendering of panning animation of the grass tile be easier and relatively cheap?

I have the Colecovision load the tiles first, and then grab that single tile and put into 16 byte of RAM memory with 2 copy of that tile. It is written offset to the dedicated tiles. If I do need to have the tile static on ROM, then I can use 64byte of tables in rom for the Colecovision to pull from. So this method saves ROM space. So I might try that method to gain more cycles.

Edited January 20, 2014 by Kiwi

[BladeJunker]

Sprites.jpg I was thinking how the sprite is displayed. So this is 64x128 pixels with 32 sprites at 16x16 mode.

No I get how its displayed on screen at maximum size as a sprite but how much image space when expressed as a bitmap dimension is there for sprites in VRAM per game? Like the size of space available for sprites when not displayed, on the Rom. Thanks btw for the VRAM picture.

Edited January 22, 2014 by BladeJunker

[Kiwi]

No I get how its displayed on screen at maximum size as a sprite but how much image space when expressed as a bitmap dimension is there for sprites in VRAM per game? Like the size of space available for sprites when not displayed, on the Rom. Thanks btw for the VRAM picture.

 

There's 64 patterns of 16x16, or 256 pattern of 8x8, that a developer can choose from. Usually 256x64 pixels, which is 2048 bytes. On ROM in my projects, they are compressed and partially finished sets. It isn't required that the tilesets in ROM has to be 2048 bytes.

 

 

ICVGM is Daniel's tileset tool. This is how the tileset look with color and charset combined. Outputting them to C or ASM will split into 2 tables along with 1 name table. This is the same size that sprite table will pick from.

 

You can download ICVGM from http://ccjvq.com/newcoleco/ under software > programming tool > homebrew kit. The program is located z80 > tools > graphics > ICVGMcomplete.zip . This program also helps force video chip restriction when regular paint program couldn't.

 

I use ICVGM for tileset and then use CV Sprite 2 to make the sprites. ICVGM have sprite table support if you wish to make sprites from that program.

[BladeJunker]

 

There's 64 patterns of 16x16, or 256 pattern of 8x8, that a developer can choose from. Usually 256x64 pixels, which is 2048 bytes. On ROM in my projects, they are compressed and partially finished sets. It isn't required that the tilesets in ROM has to be 2048 bytes.

 

Samplerygar.jpg

 

ICVGM is Daniel's tileset tool. This is how the tileset look with color and charset combined. Outputting them to C or ASM will split into 2 tables along with 1 name table. This is the same size that sprite table will pick from.

 

You can download ICVGM from http://ccjvq.com/newcoleco/ under software > programming tool > homebrew kit. The program is located z80 > tools > graphics > ICVGMcomplete.zip . This program also helps force video chip restriction when regular paint program couldn't.

 

I use ICVGM for tileset and then use CV Sprite 2 to make the sprites. ICVGM have sprite table support if you wish to make sprites from that program.

So the sprites are all on one 256X64 table, is that the biggest it goes? Tried out CV Sprite which made the image pattern arrangement make more sense, I see why nanochess said it technically could be expressed as 128x128 but that's not how a Coleco reads sprite or tile tables.

 

What happens with unused space in the tables, is it clipped from VRAM or just ignored in the pipeline?

 

What is the nature of Mode 2s use of more memory, can you counteract the increase with less graphics?

 

Couldn't get ICVGM going, some sort of error at start-up but I'll keep trying.

 

I admit generic paint programs don't restrict anything but drawing with restrictions is a discipline practiced on pixel art forums, most take it pretty seriously. Pixel art is a peer review forum so I kind of need to stick to PNG or GIF format for submissions and being able to draw in any program suits most people since everybody has their favorites. Its a decent system since if you have a console in mind people spot betrayals of hardware limitations and help you fix them along with art tips, wish more Flash based games using pixel art would post submissions more and get some help since they are all over the place with their graphics standards creating things neither 8-bit or 16-bit. :\

 

I agree when the actual work of making a Colecovision game is done its best to work in native formats but a lot of pixel art is just well meaning concepts which might never become games but aid in putting different consoles into the mindshare of the internet. Even if so many "8-bit" mockups are bogus it gets people thinking about retro game consoles, Colecovision could use some of that hype the Nes enjoys.

 

My personal workflow kind of needs more freeform creation to start with which I whittle down to appropriate limits. I find if I think about the restrictions too much then it becomes all I can see, then I fiddle with minutia too much and work eventually stops. I admit it sounds slow and messy when I explain it but I adapt and roll with the punches when things have to be changed for technical reasons.

[Kiwi]

So the sprites are all on one 256X64 table, is that the biggest it goes? Tried out CV Sprite which made the image pattern arrangement make more sense, I see why nanochess said it technically could be expressed as 128x128 but that's not how a Coleco reads sprite or tile tables.

It's the biggest it could read. It can be express in 128x128, but the Colecovision and NES don't mind what size, as long as it fit 2KB or 4KB, then they'll take it. NES is 2 bit per pixel while CV is 1 bit per pixel so it requires 4KB for the NES to read the entire table while it require CV 2KB per table. So 2 bit per pixel double that size from 2KB to 4KB. The pattern aptitude for both is 8-bit variable so it can only get 256 patterns.

 

What happens with unused space in the tables, is it clipped from VRAM or just ignored in the pipeline?

Ignored by the video chip, but still can write data and read from the unused space.

 

What is the nature of Mode 2s use of more memory, can you counteract the increase with less graphics?

For our project, we're using undocumented screen mode 2. The actual screen mode 2 color if set up using the TI-chip book is different than the screen mode 2 we use for our Colecovision project. The 256x64 comes in play here since each row of 64 can only use 2 colors while MODE1 the 32(grouped with 8 pixels) columns can only use 2 colors. So MODE1 only use 32 bytes for colors while book instruction screen mode 2 uses 64 bytes. So the undocument screen mode 2 uses the entire 2048 bytes, thus making the games much more colorful.

 

Also the TI-chip has a 4KB mode with system that has only 4KB of video RAM.

 

If using mode 2 you can counter act only using 1 pattern table and 1 color table, which I prefer. There's a bug with the chip regarding using sprite number above 8. So right now I'm using 3 pattern table with the duplicate_pattern() function with 1 color table. You can have partial filled pattern table and color table. ICVGM encode graphic to RLE format which compresses the graphics. The function decompress to vram.

 

I admit generic paint programs don't restrict anything but drawing with restrictions is a discipline practiced on pixel art forums, most take it pretty seriously. Pixel art is a peer review forum so I kind of need to stick to PNG or GIF format for submissions and being able to draw in any program suits most people since everybody has their favorites. Its a decent system since if you have a console in mind people spot betrayals of hardware limitations and help you fix them along with art tips, wish more Flash based games using pixel art would post submissions more and get some help since they are all over the place with their graphics standards creating things neither 8-bit or 16-bit. :\

I did make mistake when making NES mock-up. I thought the color resolution was 32x24 with 4 color set, but NES color resolution is 16x12 of 4 color sets. It is hard to find out the specific limitation. C64 comes to mind is pretty difficult to figure out, like the sprites. What I know when sprites are double horizontal resolution, it uses 1 gray scale color, one shared color that use for all sprites, and 1 unique color. I'm obsess with system limitation so I do read a lot about it.

 

I agree when the actual work of making a Colecovision game is done its best to work in native formats but a lot of pixel art is just well meaning concepts which might never become games but aid in putting different consoles into the mindshare of the internet. Even if so many "8-bit" mockups are bogus it gets people thinking about retro game consoles, Colecovision could use some of that hype the Nes enjoys.

Raccoon Lad

made http://www.studiopinagames.com/sydney.html which uses the TI-chip limitation in mind. The graphics are very close to the limitation. The sprite itself will have to be redefine in real time since it won't fit on 64 pattern table all by itself along with the enemies, boomerang and etc.

 

My personal workflow kind of needs more freeform creation to start with which I whittle down to appropriate limits. I find if I think about the restrictions too much then it becomes all I can see, then I fiddle with minutia too much and work eventually stops. I admit it sounds slow and messy when I explain it but I adapt and roll with the punches when things have to be changed for technical reasons.

You have the mock-ups to compare to. I did put the mock-up I made and put it on a ROM to be display on a real Colecovision. I use CVsprite 2 to place sprite. I'm not sure if ICVGM requires Java but cvtoolkit does. You can post them here and we're help you with it.

 

General information:

For sprites, 64 16x16 patterns. Colors are unique for one 16x16 sprite on screen, which can chose from 64 pattern.

 

Tileset, 256 pattern max, 1x8 2 colors max each line, which one single 8x8 can have all 16 colors(color invisible) but with 2 colors per line.

[hardhat]

ICVGM requires the visual basic 5 runtime environment. I believe it is available at Microsoft at:

 

http://support.microsoft.com/kb/180071

 

And it is a tool worth using for sure.

 

Sometimes limits can make you excessively distracted, but sometimes they can be exploited to make great art.

[BladeJunker]

ICVGM requires the visual basic 5 runtime environment. I believe it is available at Microsoft at:

 

http://support.microsoft.com/kb/180071

 

And it is a tool worth using for sure.

 

Sometimes limits can make you excessively distracted, but sometimes they can be exploited to make great art.

Thanks for the link, got ICVGM running now. I think the restrictions help the pixel art in many ways, having a particular color depth for bitmaps keeps everything consistent, without it colorspace gets kind of lob-sided in many Flash based pixel art games IE. using X number of colors here Y number of colors there.

[BladeJunker]

It's the biggest it could read. It can be express in 128x128, but the Colecovision and NES don't mind what size, as long as it fit 2KB or 4KB, then they'll take it. NES is 2 bit per pixel while CV is 1 bit per pixel so it requires 4KB for the NES to read the entire table while it require CV 2KB per table. So 2 bit per pixel double that size from 2KB to 4KB. The pattern aptitude for both is 8-bit variable so it can only get 256 patterns.

I think I'll still suggest 256X64 for pixel art forums, it's a good visual indicator of the platform and makes sense with the 3 Char Set to screen aspect of Graphic Mode 2.

 

For our project, we're using undocumented screen mode 2. The actual screen mode 2 color if set up using the TI-chip book is different than the screen mode 2 we use for our Colecovision project. The 256x64 comes in play here since each row of 64 can only use 2 colors while MODE1 the 32(grouped with 8 pixels) columns can only use 2 colors. So MODE1 only use 32 bytes for colors while book instruction screen mode 2 uses 64 bytes. So the undocument screen mode 2 uses the entire 2048 bytes, thus making the games much more colorful.

 

Also the TI-chip has a 4KB mode with system that has only 4KB of video RAM.

 

If using mode 2 you can counter act only using 1 pattern table and 1 color table, which I prefer. There's a bug with the chip regarding using sprite number above 8. So right now I'm using 3 pattern table with the duplicate_pattern() function with 1 color table. You can have partial filled pattern table and color table. ICVGM encode graphic to RLE format which compresses the graphics. The function decompress to vram.

This will take me some time to understand, read it a few times but I'll keep trying.

 

I did make mistake when making NES mock-up. I thought the color resolution was 32x24 with 4 color set, but NES color resolution is 16x12 of 4 color sets. It is hard to find out the specific limitation. C64 comes to mind is pretty difficult to figure out, like the sprites. What I know when sprites are double horizontal resolution, it uses 1 gray scale color, one shared color that use for all sprites, and 1 unique color. I'm obsess with system limitation so I do read a lot about it.

Yeah the isolation of one palette per 16X16 pixel tile can be tricky on the Nes, small sprite games are the worst since they can come out muted in color sharing the larger space.

 

Yeah the C64 uses double wide pixels, only mistake I saw someone make with that aspect was thinking the bitmap was stored twice as wide rather than just being displayed that way, turned out he had only used half the sprite space in his pixel art designs but he thought he was running out of space. ^_^

 

The color limit of C64 sprites is 4 colors, 1 for transparency, 2 shared colors used for all sprites, and one unique color. The gray scale isn't enforced by hardware, its more as a suggestion to cope with the shared color limitation.

http://wayofthepixel.net/index.php?topic=10784.0#post_c64

 

 

Raccoon Lad

made http://www.studiopinagames.com/sydney.html which uses the TI-chip limitation in mind. The graphics are very close to the limitation. The sprite itself will have to be redefine in real time since it won't fit on 64 pattern table all by itself along with the enemies, boomerang and etc.

Thanks for the link, good game, having fun with it. Nice graphics.

 

You have the mock-ups to compare to. I did put the mock-up I made and put it on a ROM to be display on a real Colecovision. I use CVsprite 2 to place sprite. I'm not sure if ICVGM requires Java but cvtoolkit does. You can post them here and we're help you with it.

Thanks, yeah I've seen your mockups and your topic thread, all great stuff. What do you use to make the ROM, flash cart?

 

General information:

For sprites, 64 16x16 patterns. Colors are unique for one 16x16 sprite on screen, which can chose from 64 pattern.

 

Tileset, 256 pattern max, 1x8 2 colors max each line, which one single 8x8 can have all 16 colors(color invisible) but with 2 colors per line.

So only the Char set can do 2 colors per line in Graphics Mode 2 but not the sprites which are only one color always?

[hardhat]

So only the Char set can do 2 colors per line in Graphics Mode 2 but not the sprites which are only one color always?

Sprites can be layered if you're careful. But you can layer 2 or 3 or 4 sprites at a time. There is a rule that you can have at most 4 visible sprites on each scanline.

 

In graphic mode 2, each 8x8 tile can have at most 2 colours per horizontal line. But every tile is independent of all of the other tiles.

 

In mode 2, you can have a different char set for each 1/3 of the screen, so that means you can do pixel art that has a bitmap 256x192, if you want.