Extreme Video RAM usage like RAM space

[newcoleco]

As you may know, ColecoVision does have only 1KB of CPU RAM, but does also have 16KB of Video RAM (also called VRAM). Depending on your programming skills and how you are using the Video memory to display the graphics, it's possible to use the unused Video RAM as extra temporary storage or in some projects like GhostBlaster as a way to play bigger levels that need to be modify by the player's actions.

 

This may sounds strange but it's possible to do a ColecoVision game with not much graphics but still can be interresting to look at and provide more a lot more than 1KB RAM space to deal with by using the free Video RAM and some restrictions in the graphics.

 

Here I'm presenting an extreme case where I'm freeing up to 12KB of VRAM to be used as almost anything I want including a freaking huge level map pretty much as big as the one in the Coleco ADAM game : ADAMBomb 2.

 

The trick is to use graphic mode 1, not graphic mode 2, which only use 32 bytes for the COLOR table (2 colors per 8 characters). Because the character graphics look pretty much monochrome depending on how you deal with the colors limitation, the following VDP settings might be or not for one of your future ColecoVision projects.

 

Also, these VDP settings restrict to only 32 16x16 patterns for the sprites in Video RAM... which is not a problem for some games, but there's still a workaround solution if you need more by uploading, from time to time, other patterns for sprites during the game depending on your needs... be creative!

 

VDP REGISTERS
-------------
REG#0,$00
REG#1,$82 (Screen Off, no NMI) $E2 (Screen On, NMI)
REG#2,$0F (NAME @ $3C00)
REG#3,$FE (COLOR @ $3F80)
REG#4,$06 (PATTERN @ $3000)
REG#5,$7E (SPRITE ATTRIBUTES @ $3F00)
REG#6,$07 (SPRITE GENERATOR @ $3800)
REG#7,$01 (Black backdrop color)

VIDEO MEMORY MAP
----------------
$0000 - $2FFF = FREE 12KB
$3000 - $37FF = PATTERN (CHARSET)
$3800 - $3BFF = SPRITE GENERATOR (SPRITES PATTERNS)
$3C00 - $3EFF = NAME (CHARS ON SCREEN)
$3F00 - $3F7F = SPRITE ATTRIBUTES (32 times Y,X,#,COLOR)
$3F80 - $3F9F = COLOR (CHARS COLOR, 2 COLORS per 8 CHARS IN THE CHARSET)
$3FA0 - $3FFF = An extra 96 free bytes if needed

12KB USAGE SUGGESTION ALMOST LIKE IN ADAMBOMB2
----------------------------------------------
Each byte can be splited into nibbles (two 4 bits), and each nibble may represent a 2x2 chars tile on screen.
Either if you decide to display screens one at a time or use a smooth scrolling while walking around the map,
this solution provides you pretty much the equivalent of size as what is used in ADAMBomb 2.
The resulting map is 16 screens wide by 12 screens height, each screen is composed of 16 per 8 tiles, and each tile is a 2 by 2 chars on screen (16x16 pixels).

You can use the CPU RAM to get the portion of the map you want to render at a first NMI interuption,
and then render it quickly based on a various manipulations and a dictionnary of tiles (to conver nibble into 2x2 chars),
and then upload to result on screen at the next NMI interrupt.
A similar memory manipulation was done in my ColecoVision project titled GhostBlaster without any problem.

 

Please note that the advantage of using a map in RAM instead of ROM is the possibility to update it. If the player actions need to modify what is on screen and this screen represent part of a huge level or map, the level or map should be in RAM to do so. It's particulary the case if the player is allowed to do actions like collecting objects, destroying or moving blocks (tiles).

 

Another usage for this 12KB free space is to split it for various purpose, like a game composed of an overview map and multiple dungeons, multiple floors of a tall building, free space to let the user make temporary custom levels, or even more. Use your imagination.

 

I'm thinking of using a variant of this solution of extreme extra RAM space for a Coleco project, if I have time to work on it.

 

Thanks for reading and happy programming!

 

- Daniel Bienvenu

Edited May 10, 2011 by newcoleco

[Pixelboy]

Here's my idea for using 12K of VRAM:

 

Yar's Dungeon

 

The (obviously unofficial) prequel to Yar's Revenge, this game tells the story of Yar's escape from the Qotile's dungeon prison. You must guide Yar through a complex maze of interconnected rooms, with items to collect and critters to kill along the way. You would even have short boss fights with the Qotile in certain rooms, and other bosses may appear to attack you as well.

 

The entire prison complex would be a devious gigantic puzzle that the player would have to solve in order to escape, with switches and other elements that open and close different parts of the prison.

 

With the entire game world stored in the unused portion of VRAM, a lot of fun stuff could be crammed into the game.

[newcoleco]

Note : I know that I've made some mistakes while typing, but I can't edit back my previous message(s) so deal with it.

 

I'm very enthusiat while thinking about this topic.

 

I was thinking a little bit more tonight about the extra free RAM we can use by doing some slow but efficient manipulations. A variant of the solution I was suggesting here uses 4KB instead of only 2KB of charset space. By doing so, I put 2 charsets in VRAM and by swaping them slowly and regulary I create nice animated tiles without being too restricted in the graphics. This variant reduces the free VRAM space from 12KB to about 8KB depending on what I do with the other tables too, but 8KB is still plenty of space for a good game project with huge levels... GhostBlaster used only 4KB levels and many of you considered them big already.

 

Have a nice day!

Edited May 11, 2011 by newcoleco

[+retroclouds]

Thanks for talking about this, a very interesting topic

 

Having 1KB of RAM is really a luxery

Coming from the TI-99/4A scene we're kinda used abusing VRAM for storing all kinds of possible stuff.

The reason is that the bare TI-99/4A console only had 256 bytes of real memory (with 32 bytes reserved for 16 general purpose registers), the rest being the 16KB VRAM.

 

Also the "overlapping" of VDP areas is quite common on the TI, in particular when Basic or Extended Basic are used.

The funny thing is that the TI basic interpreter stores the crunched basic program in VRAM and runs it from there.

Due to this they set the VDP registers in such way, it prevented the use of sprites

For a similar reason you can only use 28 sprites out of the possible 32 sprites in Extended Basic.

 

For the Pitfall version I did on the TI, I stored music, some game variables and level map data in VRAM.

Guess that is why I'm more of a screen mode 1 guy than anything else. I'm currently working on an own version of Tutankham for the TI.

Due to the reason mentioned above, I build the map for a full level in VRAM and then copy the required section to the VDP screen area.

It allows for a smaller ROM footprint and you can "update" the objects in VRAM, as you said.

 

Now back to the colecovision. I like your VDP register setup suggestion. You could squeeze even some more bytes out of the SAT table. If you have a game that only uses 16 sprites, you'd have roundabout 63 bytes (64 - 1 byte $D0) more to play with. If you yould move the SAT to the end of VDP memory you'd then have an even bigger continous free memory area.

 

From the VDP programmer's manual

 

Some applications require no sprites or less than 32 sprites to be displayed at a time. A value

of Hex DO in the vertical position of the Sprite Attribute Table will terminate sprite processing.

If no sprites are to be used, Hex DO should be the first entry in the Sprite Attribute Table. If only

one sprite is to be used, then Hex DO should be the first byte in the second sprite’s attribute

entry, which would be the fifth byte in the Sprite Attribute Table. Once the VDP finds a value

of Hex DO as a sprite attribute entry, it terminates processing of that sprite and all lower priority

sprites.

[newcoleco]

True. If you need only 8 sprites on screen at the same time, using $D0 value for a 9th sprite Y coordinates the video chip ends rendering sprites... and yes you can use the unused SPRITE ATTRIBUTES table as RAM for other purpose.

 

It's also true that other tables might not be fully used like the PATTERN table for example which can be updated on the fly when needed and simulate a more complete (or rich) charset. And if we suppose that only half a charset space is really necessary in VRAM, we save then another 1KB of VRAM space. How about that? Sounds even more extreme!

 

Of course, accessing these Video RAM data is slower than the direct access to CPU RAM, and so not adapted for some games... but just looking at how fast GhostBlaster runs is enough to tell me that using a method of data manipulation in VRAM can be fast enough, even if used constantly... it all depends on what you want to accomplish and your programming skills.

[+retroclouds]

Of course, accessing these Video RAM data is slower than the direct access to CPU RAM, and so not adapted for some games... but just looking at how fast GhostBlaster runs is enough to tell me that using a method of data manipulation in VRAM can be fast enough, even if used constantly... it all depends on what you want to accomplish and your programming skills.

 

Depending on your needs you could "split" the VRAM data manipulation accross several frames. If you are scrolling like every 8th frame you could

prepare the level map in VRAM during the previous 7 frames. I think the colecovision OS7 does have some nice routines for doing threads (thinking about TIME MANAGER) here.

 

I find it kinda a shame that there aren't many games using OS7 calls. I know it has been reported that OS7 is slow.

Just wondering if that is more because of the calling program using C instead of hand-written assembler.

Personally I think that OS7 is real nice, you have advanced sound routines & some nice graphic routines.

ok, perhaps some routines are too complex/buggy (PUT_OBJ / PUT_SEMI) ?

[youki]

ok, perhaps some routines are too complex/buggy (PUT_OBJ / PUT_SEMI) ?

 

I would love to see an exemple how to use this routine from C. (even from ASM in fact).

 

They looks very interresting , but i never find the time to dig into that ones.

[hardhat]

Yeah, Youki, I've been meaning to make up a sample that uses PUT_OBJ based on the the ColecoVision game programmer's manual (which documents it clearly). But I think maybe for use in a real game, maybe there are actually better ways. Even the Coleco games didn't seem to use that routine for the most part.

 

Anyway, knowing that someone is interested will motivate me to make a nice sample. Maybe by summer, I'll have something worked out.

[youki]

Yeah, Youki, I've been meaning to make up a sample that uses PUT_OBJ based on the the ColecoVision game programmer's manual (which documents it clearly). But I think maybe for use in a real game, maybe there are actually better ways. Even the Coleco games didn't seem to use that routine for the most part.

 

Anyway, knowing that someone is interested will motivate me to make a nice sample. Maybe by summer, I'll have something worked out.

 

I'm looking foward to see your sample!.