Questions about Coleco graphics capacity?

[BladeJunker]

What "column" are you referring to?

That's why I included the dat file, when I color one pattern the whole column uses those 2 color only. I'm just asking if that's the editor or a VDP limit, I thought I could make every block with individual color pairs. The only unusual thing I did was start in the Mode 2 version of the editor and load the dat into the Mode 1 editor, I can't corrupt the dat that way can I?

 

Daniel's not really around anymore...

That is too bad but I'm sure he has good reasons, I've only come across some information on his absence to sympathize with. Hope he comes back.

 

The default ColecoVision text font is part of the BIOS, so it's ROM.

Yeah thought so but needed confirmation, thanks.

 

Mode 1 has 2 char sets? I beg to differ...

Differ away my friend if that is wrong, just making sure I have it straight. Double checking to see if there isn't any undocumented methods, 768 down to 256 is quite a drop in the number of patterns. More reason Mode 2 is favored so much, no?

 

Also, can you define what you mean by "sprite space"? That kind of vocabulary is confusing because there are two distinct sprite tables in VRAM, namely the sprite pattern table and the sprite attribute table, and I don't know which table you're referring to when you use the term "sprite space".

Sorry, those are just generic terms by pixel art people, "sprite space" is the amount of image space we draw sprites on and "tile space" is the same thing but for background layers. Many systems call the same things different names so sprite and tile became standard terms. I see how having 2 sprite properties makes that confusing for you, how about 'sprite canvas size'? Fonts, tables, bitmaps, patterns, lots of terms, lots of confusion.

 

Also, where does the "128x64" thing come from? I find your posts a little hard to follow, BladeJunker...

That's just the collective canvas resolution, just a difference of perception, I don't see it as 256(8X8) or 64(16X16) patterns, its just a 4:1 canvas to me.

Like Kiwi says the 4KB mode shrinks the 256X64 to half or 128X64 if you choose that setup of reserve VRAM, I certainly don't know what extra VRAM is good for but I bet you could think of some uses.

[BladeJunker]

 

If you were working with system that has 4KB of VRAM, then you would have only half a sprite pattern table to work with. The video chip can be set in 16KB or 4KB mode. The video chip is used in other system like TI-99, SG-1000, and etc. I was thinking why would developer use mode 1 for the Colecovision. If it is set in 4KB mode in Colecovision, then you could use 12KB or VRAM or other stuff.

 

Anyway, the Colecovision BIOS routine "CALL MODE1" will preset information to the video register. Colecovision Mode 1 shared the similar memory map that MODE 2. I think the only difference is the color table, which is 32 bytes. Also, it allows full set of sprite pattern, 256x64. If it is in 4KB mode, then the sprite pattern is in half 128x64, which is 1KB. Sorry for the confusion.

 

Only 1 pattern table allowed in this mode.

Thank you for the clarification, wow so many options and modes to use. Curious option, hmm...

[Pixelboy]

That's why I included the dat file, when I color one pattern the whole column uses those 2 color only. I'm just asking if that's the editor or a VDP limit, I thought I could make every block with individual color pairs.

Oh, that's what you mean by column, okay. It's a VDP limit. In mode 1, tiles are grouped by 8, and a single color pair is applied to all 8 tiles.

 

The only unusual thing I did was start in the Mode 2 version of the editor and load the dat into the Mode 1 editor, I can't corrupt the dat that way can I?

Not really sure. Sorry to sound silly but... there's actually a mode 1 version? I've never seen it! I've always used the mode 2 version from day one!

 

 

That is too bad but I'm sure he has good reasons, I've only come across some information on his absence to sympathize with. Hope he comes back.

Well, you can send him an e-mail if you want. I contacted him recently and he replied to me.

 

Differ away my friend if that is wrong, just making sure I have it straight. Double checking to see if there isn't any undocumented methods, 768 down to 256 is quite a drop in the number of patterns. More reason Mode 2 is favored so much, no?

There's only one pattern table of 256 tiles in mode 1, with the color limitation I mentioned above. Generally speaking, CV programmers who do their games with mode 1 do so because they need the unused VRAM space to store game data. Such games as Destructor and Gateway to Apshai are examples of this. If a game is simple enough that it only needs 1K of RAM, then you use graphic mode 2 for better visuals.

 

Sorry, those are just generic terms by pixel art people, "sprite space" is the amount of image space we draw sprites on and "tile space" is the same thing but for background layers. Many systems call the same things different names so sprite and tile became standard terms. I see how having 2 sprite properties makes that confusing for you, how about 'sprite canvas size'? Fonts, tables, bitmaps, patterns, lots of terms, lots of confusion.

How about if you're going to stick with the ColecoVision for a while, use the terms everyone else is used to:

 

- Tile/character pattern table: One single pattern table of 256 tiles in mode 1, three pattern tables of 256 tiles in mode 2.

 

- Tile/character color table: 32 bytes in size in mode 1, three color tables in mode 2 (mirroring the pattern tables so same sizes in video memory).

 

- Sprite pattern table: Same size as a tile pattern table (256 tiles), and the tiles are united in groups of 4 to form 16x16 sprites. So you can define a maximum of 64 sprite patterns. (Not sure what the constraints are when working with 8x8 sprites, I've never tried it.)

 

- Sprite attribute table: Static table of 128 bytes, which contains the display information for up to 32 sprites: Y position on screen, X position on screen, sprite pattern number (in the sprite pattern table) and sprite color (0 to 15).

 

You will notice that you can define up to 64 sprite patterns, but the sprite attribute table only lets you display 32 of them simultaneously on the screen.

 

That's just the collective canvas resolution, just a difference of perception, I don't see it as 256(8X8) or 64(16X16) patterns, its just a 4:1 canvas to me.

Like Kiwi says the 4KB mode shrinks the 256X64 to half or 128X64 if you choose that setup of reserve VRAM, I certainly don't know what extra VRAM is good for but I bet you could think of some uses.

You can read and write to any byte in VRAM directly, it's just slower than regular RAM. So you could put any game data you want in VRAM, as long as you know which parts of VRAM are currently unused by the VDP.

[BladeJunker]

Oh, that's what you mean by column, okay. It's a VDP limit. In mode 1, tiles are grouped by 8, and a single color pair is applied to all 8 tiles.

Oh okay, guess I'll have to use more horizontal groupings to get more consistent color throughout. Yeah I started with the Mode 2 editor, then switched to the Mode 1 version when I realized it was the wrong one for my test, I was just using mono color to input the Char Set but when it came to coloring it the column aspect showed up and I thought something went wrong. Kind of oddly named applications, I guess ICVGM means something but even if it were named 'Waffle & Catfunk' I'd be able to tell them apart better than a version number lol.

 

Not really sure. Sorry to sound silly but... there's actually a mode 1 version? I've never seen it! I've always used the mode 2 version from day one!

That's a shame, you should try every road, that's certainly what the C64 scene is like since there isn't a screen mode or rendering option someone hasn't tried on that thing.

 

Well, you can send him an e-mail if you want. I contacted him recently and he replied to me.

Alright I'll do that sometime, got to separate my petty complaints from more real concerns by using it some more. For example the pattern scroll buttons seemed obtrusive at first but I started to see the advantage in composition when I had offset something wrong.

 

There's only one pattern table of 256 tiles in mode 1, with the color limitation I mentioned above. Generally speaking, CV programmers who do their games with mode 1 do so because they need the unused VRAM space to store game data. Such games as Destructor and Gateway to Apshai are examples of this. If a game is simple enough that it only needs 1K of RAM, then you use graphic mode 2 for better visuals.

Thanks for the examples, nice to have something to indicate how or why Mode 1 is used for a game design.

 

How about if you're going to stick with the ColecoVision for a while, use the terms everyone else is used to:

 

- Tile/character pattern table: One single pattern table of 256 tiles in mode 1, three pattern tables of 256 tiles in mode 2.

 

- Tile/character color table: 32 bytes in size in mode 1, three color tables in mode 2 (mirroring the pattern tables so same sizes in video memory).

 

- Sprite pattern table: Same size as a tile pattern table (256 tiles), and the tiles are united in groups of 4 to form 16x16 sprites. So you can define a maximum of 64 sprite patterns. (Not sure what the constraints are when working with 8x8 sprites, I've never tried it.)

 

- Sprite attribute table: Static table of 128 bytes, which contains the display information for up to 32 sprites: Y position on screen, X position on screen, sprite pattern number (in the sprite pattern table) and sprite color (0 to 15).

 

You will notice that you can define up to 64 sprite patterns, but the sprite attribute table only lets you display 32 of them simultaneously on the screen.

I will try to do so in the future. I have included the specific Coleco terms in my evolving text description so I am accounting for that. Interesting how finely defined the graphics are on Coleco, things like color tables and sprite attribute tables are very prominent on this platform than I've seen described on other platforms.

They all have there quirks and requirements, when I looked into INTV graphics it took some back and forth for me with some helpful people to understand its 'Card' sprite system. Compact and compartmentalized setup is what I gathered from that system.

 

You can read and write to any byte in VRAM directly, it's just slower than regular RAM. So you could put any game data you want in VRAM, as long as you know which parts of VRAM are currently unused by the VDP.

Wish I had a better grasp on how slow that is like you understand on a coding level, I described it as 'Butt Slow' when compared to the system memory and that the information you store in VRAM can't be anything you would process instantly in real time. Do you think that is a fair assessment?

[Kiwi]

 

Wish I had a better grasp on how slow that is like you understand on a coding level, I described it as 'Butt Slow' when compared to the system memory and that the information you store in VRAM can't be anything you would process instantly in real time. Do you think that is a fair assessment?

It is kinda unpredictable. Computer Space 2nd player pattern is decompressed to unused VRAM due to the 64 sprite pattern limit since I needed 48 for 1st player pattern, 2 for UFO, 1 for the shot so one slot is dedicated for 2nd player sprite. So each time that the 2nd player turn, the pattern is copied from the VRAM to RAM, and then back to VRAM which draws itself to it cell. It was fine and no visible slowdown. Once I added sound effects, then there's lag if both player turn at the same time.

 

I had problem with Pletter decompression because the processor is too fast for the VDP to catch up, so I was able to modify that code to add NOP whenever the VDP get accessed.

 

So yea, Pixelboy's correct ^_^. The VDP is slow, but I enjoy working with it.

[Hakogame 箱亀]

I have a question about graphics mode 2.

 

As I understand it, you can have up to 3 different pattern tables, but can those patterns be placed anywhere on-screen, or are you limited to displaying patterns from those tables in their respective 1/3 of the screen?

 

For example, if I wanted to make a card game that used different art for each card, could I just load all the card graphics into vram and then place the card anywhere on screen, or would I need to update vram every time the screen was updated?

[Pixelboy]

I have a question about graphics mode 2.

 

As I understand it, you can have up to 3 different pattern tables, but can those patterns be placed anywhere on-screen, or are you limited to displaying patterns from those tables in their respective 1/3 of the screen?

Each pattern table (and associated color table) is wired to one third of the screen.

 

For example, if I wanted to make a card game that used different art for each card, could I just load all the card graphics into vram and then place the card anywhere on screen, or would I need to update vram every time the screen was updated?

You'd need to update VRAM every time.

[Kiwi]

I have a question about graphics mode 2.

 

As I understand it, you can have up to 3 different pattern tables, but can those patterns be placed anywhere on-screen, or are you limited to displaying patterns from those tables in their respective 1/3 of the screen?

 

For example, if I wanted to make a card game that used different art for each card, could I just load all the card graphics into vram and then place the card anywhere on screen, or would I need to update vram every time the screen was updated?

In screen mode 2 bitmap, the pattern are loaded into 3 banks of VRAM 0x0000,0x0800,0x1000, and the color table is loaded into 3 banks of VRAM 0x2000,0x2800,0x3000. 0x0000 and 0x0000 is for top 1/3 screen,0x0800,middle 1/3, and 0x1000 for the bottom 1/3 screen. For example, my Spunky Title screen uses 2 pattern and color table. The first pattern table goes into 0x0000, and 0x0800. While the color table is loaded is loaded into 0x2000 and 0x2800. Since I filled up all 256 patterns, I had to make a 2nd set to load into 0x1000, and 0x3000.

 

And yes, you'll have to update the VRAM if you need to change something on screen.

[youki]

For a card game , i would use "unofficial" mode the Screen Mode 2 TEXT.

 

In that mode you have 1 name table, 1 pattern table , 1 color table.

 

But you have to make in sort that all your Art can fit in one pattern/one color table.

 

I used that mode is each of my games.

[cbmeeks]

I've read most of this thread and found it really entertaining.

 

One theme I saw a few times was about the 4 sprite per horizontal line limitation. Some even called it stupid.

 

It's understandable, not stupid. First, the TMS99x8 was designed in the 70's. Second, it's easy to understand why the limit was there. Bandwidth. So in text mode, we have 40 characters which equals 320 pixels of bandwidth. But no sprites. In mode 1/2, we have a resolution of 256. 320-256=64. 64/16 pixels (max sprite width) = 4. Bam. 4 sprites.

 

Now, why can't we have 8 sprites at 8 pixels? My guess is because there is overhead in changing sprite pointers, colors, etc. and that tiny bit of overhead wouldn't fit in the 320 pixel bandwidth.

 

Anyway, just my $0.02.

[youki]

I've read most of this thread and found it really entertaining.

 

One theme I saw a few times was about the 4 sprite per horizontal line limitation. Some even called it stupid.

 

It's understandable, not stupid. First, the TMS99x8 was designed in the 70's. Second, it's easy to understand why the limit was there. Bandwidth. So in text mode, we have 40 characters which equals 320 pixels of bandwidth. But no sprites. In mode 1/2, we have a resolution of 256. 320-256=64. 64/16 pixels (max sprite width) = 4. Bam. 4 sprites.

 

Now, why can't we have 8 sprites at 8 pixels? My guess is because there is overhead in changing sprite pointers, colors, etc. and that tiny bit of overhead wouldn't fit in the 320 pixel bandwidth.

 

Anyway, just my $0.02.

 

Except that the colecovision even in Text Mode has only 256 pixel of bandwith. Characters are 6pixels of width in Text Mode

[cbmeeks]

You sure? It may be 6 pixel fonts but 256/6 != 40.

It may be shifting the chars over 2 pixels to get 6 pixel fonts but the bandwidth should still be 320.

 

But I could be wrong.

[cbmeeks]

Thinking about this a little more....I think it's more accurate to say that instead of "320 pixel bandwidth" to say "active display bandwidth" from the 63.55uS NTSC scan line.

 

So, to draw 40 chars at 6 pixels leaves no more bandwidth left for sprites.

 

Either way, the active display area is the same in all modes but at 256 pixels there is barely enough time left to deal with sprites.

 

Again, amazing for 70's technology.

[Pixelboy]

Text mode only uses 6 pixels out of 8 for every tile, so you still end up with 256 pixels horizontally.

 

Also, sprites are not available while the VDP is in text mode.

 

EDIT: It seems you're right: 6 pixels x 40 chars = 240 pixels. I never noticed that before.

[Kiwi]

That does make sense that there are no sprites in text mode. Also it got my answer why there are sprite limitation. NES and SMS have similar 256 pixel horizontal resolution, each have 64 pixels towards the sprites.

[Mike Harris]

Could someone send me this file because his sites DL is 404 now.
ICVGMcomplete.zip

 

If anything it would be great if someone could post a complete dev kit that everything is in one file where you can edit and press compile without all this installing 20 programs and moving libraries around.

 

Is Daniel even still around?

Edited November 25, 2018 by Mike Harris