21 replies to this topic

[newcoleco]

Description
To render a fluid animation that needs to update (almost) the entire screen, a good practice is to prepare (render) the next screen(s) into available video memory space to be displayed later, that's called buffering. This sample project uses this technic in order to show an animation composed of 6 distinct frames played according to a script. To make this even more interesting to watch, the animation is a spinning ambigram I drew with the words COLECO and VISION.

Technical Details
The default Graphic Mode 1 is used in this sample code, but it needs 2 charsets (PATTERN TABLES [0000-0FFF]) and 6 frames (NAME TABLES [2400-3BFF]) into video memory in order to quickly show the frames and then create the wanted fuild animation effect of a spinning COLECO VISION ambigram logo. The NMI is used in order to update the video registers 2 (NAME) and 4 (PATTERN) at a constant speed and when it's appropriate (to avoid video corruption) to show all the wanted frames based on a script : 16 cycles for frame#1, 16 cycles for a clock-wise spin, 16 cycles for frame#1 again, and 16 cycles for a counter-clock-wise spin). The 2 charsets are slightly optimized to avoid encoding chars that are (almost) the same. No data compression is used in order to optimize even more the rom size, but raw data is easier to visualize and understand which is what I want for this project. PUT_FRAME and INIT_TABLE are used in this code in order to show a way to use these Coleco BIOS routines for your projects, in this case each FRAME is composed of 16x16 characters and printed on each screen at the (offset) coordinates (x=8,y=4). Considering that the screen resolution is a 32x24 characters, and each frame is 16x16 characters, it's quite easy to understand that each frame is centered on screen by using the coordinates x=(32-16)/2,y=(24-16)/2.

Feel free to use this technic for your own projects, but the spinning logo is my creation so credit properly.

The following zip file contains the (commented) source code (for use with tniAsm) and the binary rom file.
 ambigram.zip   7.24K   59 downloads

Please rate and write comments! Have a nice day!
I'm expecting as many comments as the number of downloads...

[Yurkie]

I loaded the rom on the SD multi-cart and don't get anything other than a static screen that says Coleco and Vision in white. The e in Coleco looks like the s in vision too.

[newcoleco]

Yurkie, on Wed Jan 26, 2011 6:11 PM, said:

I loaded the rom on the SD multi-cart and don't get anything other than a static screen that says Coleco and Vision in white. The e in Coleco looks like the s in vision too.

That's the idea of an ambigram, if you turn the logo 180 degrees, Coleco become Vision and Vision become Coleco... and that's what this animation sample is supposed to be, well I can see it spinning.

[Yurkie]

newcoleco, on Wed Jan 26, 2011 6:31 PM, said:

Yurkie, on Wed Jan 26, 2011 6:11 PM, said:

I loaded the rom on the SD multi-cart and don't get anything other than a static screen that says Coleco and Vision in white. The e in Coleco looks like the s in vision too.

That's the idea of an ambigram, if you turn the logo 180 degrees, Coleco become Vision and Vision become Coleco... and that's what this animation sample is supposed to be, well I can see it spinning.

It's doesn't move when I try it.

[5-11under]

The ambigram looks pretty cool. Nicely done.

Works in BlueMSX (spins back and forth), but not Virtual ColecoVision (static image, just like Yurkie gets, it looks like).

[newcoleco]

Well, I made a mistake... my first version is TOO FAST, it needs NOP codes between "out($bf),x" lines.

To fix this issue, I've decided to replace my costum "out($bf)" instructions by the ColecoVision BIOS routine WRITE_REG ($1fd9)... which I'm already using to enable NMI and turn on screen (both in video register#1).

I've decided to take this opportunity to extend the animation by adding a full (and slower) 360 degrees clock-wise spin. To do so, I've packed the animation script data (pairs REG# and VALUE) into BYTEs instead of WORDS (2 BYTES), and I've coded a subroutine with appropriate instructions (BITS ROTATIONs, AND MASKs) to set the REG# and VALUE pairs properly for the WRITE_REG routine.

Here a video showing the result :


This new version should works for everyone... except maybe Yurkie or VirtualColeco.

 ambigram2.zip   7.39K   47 downloads

I'm expecting as many reactions to this code sample as the number of downloads...

Edited by newcoleco, Wed Jan 26, 2011 11:17 PM.

[Kiwi]

newcoleco, on Wed Jan 26, 2011 10:59 PM, said:

Well, I made a mistake... my first version is TOO FAST, it needs NOP codes between "out($bf),x" lines.

To fix this issue, I've decided to replace my costum "out($bf)" instructions by the ColecoVision BIOS routine WRITE_REG ($1fd9)... which I'm already using to enable NMI and turn on screen (both in video register#1).

I've decided to take this opportunity to extend the animation by adding a full (and slower) 360 degrees clock-wise spin. To do so, I've packed the animation script data (pairs REG# and VALUE) into BYTEs instead of WORDS (2 BYTES), and I've coded a subroutine with appropriate instructions (BITS ROTATIONs, AND MASKs) to set the REG# and VALUE pairs properly for the WRITE_REG routine.

This new version should works for everyone... except maybe Yurkie or VirtualColeco.

ambigram2.zip

I'm expecting as many reactions to this code sample as the number of downloads...

I threw this one on the SD cartridge and this one works.

[Yurkie]

newcoleco, on Wed Jan 26, 2011 10:59 PM, said:

This new version should works for everyone... except maybe Yurkie or VirtualColeco.

I don't know why you would say this, after admitting there was a problem with the first rom.

Anyway the revision works playing on the sd multi-cart.

Could rotation speed be slowed? Could it paused for a second or 2 after each rotation? Could it move around to different screen locations? Change colors? Be multi-colored like the ColecoVision logo?

Pretty cool. Makes me think of a ColecoVision screensaver.

[newcoleco]

Yurkie, on Wed Jan 26, 2011 11:49 PM, said:

newcoleco, on Wed Jan 26, 2011 10:59 PM, said:

This new version should works for everyone... except maybe for Yurkie or VirtualColeco.

I don't know why you would say this, after admitting there was a problem with the first rom.

That's irony... just forgot to add a smiley face! here

Yurkie, on Wed Jan 26, 2011 11:49 PM, said:

Anyway the revision works playing on the sd multi-cart.

Could rotation speed be slowed? Could it paused for a second or 2 after each rotation? Could it move around to different screen locations? Change colors? Be multi-colored like the ColecoVision logo?

Pretty cool. Makes me think of a ColecoVision screensaver.

Answers :

1. YES. For example, it could be slowed by a factor of 2 if you update the animation only once per 2 NMIs.

2. YES, it depends on the way you deal with the refresh rate and the animation script.

3. YES. In the way this sample code is made, each frame is fixed and centered, but you can make each frame not centered like making the entire logo rotating around the screen in the opposite direction of its spinning effect. But for something more flexible, you have to think diffently, by using 2 NMIs to clear a screen and then put the wanted frame at the wanted new coordinates before showing it, which is the classic double-buffering technic.

4. YES. you can alter the COLOR table in VRAM. It's a Graphic Mode 1, so it's only 32 bytes max to change, not a big deal. Another option is to use the transparent color for the graphics in order to let show in it the background (backdrop) color set in video register#7.

5. Maybe, but not this version because I drew it by not considering the multiple colors aspect.

* GIFT *
 ambigram3.zip   7.63K   53 downloads


I'm still expecting as many reactions to this code sample as the number of downloads...

Edited by newcoleco, Thu Jan 27, 2011 1:07 AM.

[Yurkie]

Very Cool! +1

When I loaded this on the SD and ran it. I got color bands on the top and bottom of the screen that changed colors also. This version is very cool, I didn't see the bands on your youtube video, but it is a nice addition.

This is probably difficult to do, but would could you change the words coleco vision to a clock? Have the program start with a setting feature, then press fire and the clock would begin. I love clocks and wrist watches and a program that made the ColecoVision into a time piece would be awesome.

I am talking about a digital clock like "11:14 AM" would be displayed, not an analog clock face.

[newcoleco]

Yurkie, on Thu Jan 27, 2011 8:45 AM, said:

Very Cool! +1

When I loaded this on the SD and ran it. I got color bands on the top and bottom of the screen that changed colors also. This version is very cool, I didn't see the bands on your youtube video, but it is a nice addition.

This is probably difficult to do, but would could you change the words coleco vision to a clock? Have the program start with a setting feature, then press fire and the clock would begin. I love clocks and wrist watches and a program that made the ColecoVision into a time piece would be awesome.

I am talking about a digital clock like "11:14 AM" would be displayed, not an analog clock face.

The bands you see is normal... it's where the characters on screen can't be, it's right outside the 32x24 chars (256x192 pixels). And you didn't see these bands in my video because I've focused on the "printable" screen only. BlueMSX shows not only the top and bottom but also left and right which is a little bit too much in my taste, but it's fine I can cut them off before publishing my videos for Youtube.

But I hope you not just only vote because it's cool to watch, but also because it's a source code that you (may) have an interest in to check it out.

Edited by newcoleco, Thu Jan 27, 2011 9:35 AM.

[Yurkie]

I think it is very impressive.

Is the clock display possible?

Very difficult to program?

[newcoleco]

Yurkie, on Thu Jan 27, 2011 11:34 AM, said:

Is the clock display possible?

Very difficult to program?

Unlike some Coleco ADAM computers, there is no internal clock inside the ColecoVision. If you want to display time on screen you need to ask first what time it is, or use a default one like midnight. Then you can update your counters representing time according to the NMI interrupts and the FREQ value stored in the Coleco BIOS at $0069 (50:PAL,60:NTSC). You know that each time 50(or 60) interruptions are done, one second just passed, the rest is mathematics and display numbers on screen.

[Pixelboy]

I'm very interested in the technique used in your demo.

Just one question: Let's say I wanted to define a similar rendering engine (using graphic mode #1) using 4 sets of 256 character patterns (defined once in VRAM and almost never touched afterwards) and one or two name tables (to be updated very frequently at run-time), would there be any problem where VDP registers are concerned?

[newcoleco]

Pixelboy, on Thu Jan 27, 2011 1:29 PM, said:

Q : Let's say I wanted to define a similar rendering engine (using graphic mode #1) using 4 sets of 256 character patterns (defined once in VRAM and almost never touched afterwards) and one or two name tables (to be updated very frequently at run-time), would there be any problem where VDP registers are concerned?

A : No problem. In Graphic Mode 1 it's more a question of free memory blocks in VRAM than what the graphic needs to work properly.

You can use 4 charsets (PATTERN = 2KB each) with their (4) color tables (32 bytes each), 2 screens (NAME = .75KB each), and the "maximum" sprites (64 patterns 16x16 pixels = 2KB, 32 sprites on screen (4 bytes per sprite = Y,X,PATTERN,COLOR).

Proposed solution for Pixelboy's question

Fit the 4 COLOR tables after one of the NAME table to complet a block of 1KB, put the SPRITES Attributes table (128 bytes) at the end of the second NAME table for another block of 1KB. These two 1KB can be one after the other, forming a block of 2KB. You have four 2KB blocks for the PATTERN tables that can be combined logically as a big 8KB block. And a last 2KB block needed for the sprites patterns you put alone right after the block with the NAME tables. You still a block of 4KB free for maybe an alternate pattern table for the sprites or ANY OTHER NEEDED DATA like what I've done with screen-levels in GhostBlaster.

VRAM - PROPOSED COSTUM MEMORY MAP, GRAPHIC MODE 1 WITH 4 CHARSETs and DOUBLE-BUFFER SCREENs

0000-07FF  PATTERN#1
0800-0FFF  PATTERN#2
1000-17FF  PATTERN#3
1800-1FFF  PATTERN#4
2000-22FF  NAME#1
2300-231F  COLOR#1
2320-233F  -
2340-235F  COLOR#2
2360-237F  -
2380-239F  COLOR#3
23A0-23BF  -
23C0-23DF  COLOR#4
23E0-23FF  -
2400-26FF  NAME#2
2700-277F  SPR_ATTRIB
2800-2FFF  SPR_GEN
3000-3FFF  - (free 4KB, note : same size as a GhostBlaster level)


VRAM - VIDEO REGISTERS TO SET FOR THIS COSTUM MEMORY MAP

#2 := NAME (NAME#1 = 8, NAME#2 = 9)
#3 := COLOR (COLOR#1 = 140, COLOR#2 = 141, COLOR#3 = 142, COLOR#4 = 143)
#4 := PATTERN (PATTERN#1 = 0, PATTERN#2 = 1, PATTERN#3 = 2, PATTERN#4 = 3)
#5 := SPR_ATTRB ( = 78)
#6 := SPR_GEN ( = 5)
#7 := BACKDROP COLOR AS LOW NIBBLE

I hope I've calculated everything properly based on your question.

Have fun!

Edited by newcoleco, Thu Jan 27, 2011 7:34 PM.

[Pixelboy]

Alright, allow me to explain where I'm going with this. I don't mean to highjack this thread, let's just consider this as a tangent discussion.

First, let's establish some basic vocabulary for what will follow:

1) A "tile" is a character pattern of 16x16 pixels. Forget about 8x8 tiles for now. When I say "tile", I always mean a 16x16 tile.

2) A "tile pair" is a set of two horizontally adjacent tiles. For example, a sky tile followed by a wall tile, or a wall tile followed by another wall tile, or a coin tile followed by a sky tile, you get the idea.

With the ColecoVision, you can fit 16 tile pairs to cover the entire width of the screen. If we reserve one row of 16 pixels at the top of the screen to display scores, high scores, remaining lives, etc., then we can fit 11 rows of tiles on the rest of the TV screen.

Now imagine a system that allows 16 different tile pairs to be defined at any one time, for the entire screen. For each tile pair, patterns are defined in each of the four pattern tables in VRAM: In the first pattern table, the 16x16 pattern contains only the left tile; in the second pattern table, the same corresponding pattern contains 6 pixels of the left tile and 2 pixels of the right tile (horizontally-speaking); in the third pattern table, the same corresponding pattern contains half the left tile and half of the right tile; and in the fourth pattern table, the same corresponding pattern contains 2 pixels of the left tile and 6 pixels of the right tile.

I'm sure you can see where I'm going with this: Set the data in the name table properly, and you can create a horizontal scrolling effect by simply setting the proper VDP register to cycle through the four pattern tables. However, it's pretty limited so far, and it's really only the beginning.

If you want to create a real horizontal scrolling system, you need two more things: First, define 11 groups of 8 bytes in RAM, for a total of 88 bytes. Each group of 8 bytes in this table will be used to store the tire pair numbers for a row of tiles covering the width of the screen (each byte contains two tile pair numbers, 4 bits per number). Secondly, set up two name tables in VRAM. One name table will display a screen, and the other will display the same screen, but shifted left by 8 pixels.

With all of the above in place, the programming challenge is to implement a rendering engine that updates the 11 groups of 8 bytes (with level data stored in the cartridge), and then uses these 11 groups of 8 bytes to update the contents of the two name tables, as the screen scrolls toward the right.

With this system, not only can a horizontal two-pixel-increment scrolling system be implemented, but the on-screen elements are also fully destructible/changeable, with controlled updates of the 11 groups of 8 bytes in RAM. If the programmer can manage to allocate 176 bytes of RAM instead of 88, then up to 48 tile pairs can be defined, instead of just 16 (with one full byte per tile pair, instead of just 4 bits).

This is basically all that's needed to implement a Super Mario Bros clone.

Edited by Pixelboy, Fri Jan 28, 2011 10:05 AM.

[newcoleco]

Pixelboy, on Fri Jan 28, 2011 9:32 AM, said:

Alright, allow me to explain where I'm going with this. I don't mean to highjack this thread, let's just consider this as a tangent discussion.

I saw you coming, and I understand fully what you are describing... Why do you think I've replied to you by mentionning GhostBlaster? Because it's also related to what you want to do, simply different for the scrolling concept.

The quick answer is "it's totally possible to program the way you suggest"

The long answer is unknow for the moment because you need to code it to see if you can make it... or you are not planning to code it yourself, so you will only expect something running as fast as GhostBlaster but different visually because of the smooth horizontal scrolling.

Let me give you my honnest opinion on your game engine concept : use a 4 pixels scrolling instead. If you remember last summer, you presented a bunch of new (WIP) ColecoVision games during the ADAMCon and one of them was a racing car game that was running fast and smoothly because it was using a 4-pixels scrolling technic. I think the same scrolling at 4 pixels should be fine for a game like Super Mario Bros for the ColecoVision : Mario runs quite fast anyway and you may end up with a 20fps or slower game engine depending of the details you want to add in the game.

Now, any comment about the Ambigram multiscreen demo? Do you find it interesting enough to take a look at the source code or it's just fun to watch?

Edited by newcoleco, Fri Jan 28, 2011 8:40 PM.

[Pixelboy]

newcoleco, on Fri Jan 28, 2011 8:36 PM, said:

Pixelboy, on Fri Jan 28, 2011 9:32 AM, said:

Alright, allow me to explain where I'm going with this. I don't mean to highjack this thread, let's just consider this as a tangent discussion.

I saw you coming, and I understand fully what you are describing... Why do you think I've replied to you by mentionning GhostBlaster? Because it's also related to what you want to do, simply different for the scrolling concept.

The quick answer is "it's totally possible to program the way you suggest"

The long answer is unknow for the moment because you need to code it to see if you can make it... or you are not planning to code it yourself, so you will only expect something running as fast as GhostBlaster but different visually because of the smooth horizontal scrolling.

I would definately like to code this engine myself, once the BasicVision project has been completed. In fact, coding such a timing-sensitive engine using the BasicVision language would be a good test of its usability and flexibility.

In any case, I wouldn't want the demo to run as fast as GhostBlaster. Seriously, after playing the game, one might think you named it GhostBlaster because you were trying to replicate the Genesis's Blast Processing on the CV!!

Quote

Let me give you my honnest opinion on your game engine concept : use a 4 pixels scrolling instead. If you remember last summer, you presented a bunch of new (WIP) ColecoVision games during the ADAMCon and one of them was a racing car game that was running fast and smoothly because it was using a 4-pixels scrolling technic. I think the same scrolling at 4 pixels should be fine for a game like Super Mario Bros for the ColecoVision : Mario runs quite fast anyway and you may end up with a 20fps or slower game engine depending of the details you want to add in the game.

A 4-pixel increment system may work very well for something else than SMB, but for a straight SMB clone, I would need a 2-pixel increment. The reason is simple: In SMB, Mario can either walk (2-pixel scrolling) or run (4-pixel scrolling). So for SMB, I would really need both.

On the other hand, several other games could use this scrolling engine: Mr Turtle, Parsec II, perhaps even The Dreadnaught Factor...

Quote

Now, any comment about the Ambigram multiscreen demo? Do you find it interesting enough to take a look at the source code or it's just fun to watch?

I had a look at the source code just now, and it seems like a very good study subject for a Z80 ASM beginner like me. So I'll keep it in my personal archive until I get around to learn Z80 assembly, which should happen later this year, after the BasicVision language parser has been programmed. I tried your ROM file, and I think it's very cool.

Thanks for your input, Daniel!

[retroclouds]

Nice work Daniel!

I always liked the Colecovision BIOS. It has these nice VDP subroutines one can easily use.

EDIT: ... and not only that; I find the OS7 sound routines very cool. Pretty advanced if you ask me.

Edited by retroclouds, Sat Jan 29, 2011 3:35 AM.

[retroclouds]

ok, couldn't resist

I translated the Z80 assembly code to TMS9900 assembly language. It took me about 4 hours to get the demo working on the TI-99/4A (same VDP as the colecovision).
It was basically a test for my spectra² library. This library acts as an OS7 for the TI-99/4A

The biggest challenge was the write register from nibbles, because the TMS9900 has 16 bit registers.
There's some stuff you'd do differently on the TI, but I wanted to stay close to the Z80 code.

Hope you don't mind I ported your code over to the TI-99/4A. It's an excellent demo you did there.

You can read more about my port here.

Here's a short video

Edited by retroclouds, Sun Jan 30, 2011 5:42 AM.

[newcoleco]

TI99/4a and some other computers (and consoles) from the 80s are using TMS9918/9928... because of that, seeing what are the differences and how to deal with them is very interresting.

Thanks to not resist this time and code this conversion of this Coleco Ambigram demo.

[Tursi]

Pixelboy, on Fri Jan 28, 2011 9:32 AM, said:

I'm sure you can see where I'm going with this: Set the data in the name table properly, and you can create a horizontal scrolling effect by simply setting the proper VDP register to cycle through the four pattern tables. However, it's pretty limited so far, and it's really only the beginning.

It's a little off tangent, but this is exactly what I do in Super Space Acer to get 2-pixel resolution movement of the bosses. Only half the character set is reserved for the bosses, the other 128 characters are unchanged so that the text and starfield always look the same no matter which pattern table is selected. It's a nice trick and like you, I envisioned extending it to the whole screen for a SMB clone. It'd sure be sweet to see it going full-screen!