Build Your Own Greeting Cart! Can you type MAKE?

[+Andrew Davie]

Here's one that I did yesterday for someone who requested politely...  it came out looking very nice.

 

 

byo3.bin

[4ever2600]

That looks cool!

[zilog_z80a]

http://web.archive.org/web/20040627231026/http://www.taswegian.com/TwoHeaded/Atari2600/GreetingCart/GreetingCart.html   GreetingCart - Interleaved ChronoColour™ in Action! Your GreetingCart™ demonstrates, for the first time on Atari 2600 hardware, an arbitrary colour image of reasonable quality. This cartridge uses software techniques ('Interleaved ChronoColour'™) to give the impression of full-colour images when, in fact, the rigid and limited capabilities of the Atari 2600 hardware still apply. The hardware of the Atari 2600 is not capable of displaying a TV frame with the image you see produced by this cartridge! The image displayed by this GreetingCart™ is 48 pixels wide by 128 pixels deep, and actually consists of just four colours - red, green, blue and black. There is only a single intensity of each colour (that is, there is a single red available, etc.) By changing the colour of each pixel in the image between red, green, blue or black (in various combinations) in a dynamic fashion (ie: over time), the image is perceived by the human eye as being composed of multiple colours. The two hardware sprites available on the Atari 2600 are each a single (independently) selectable colour, 8 pixels wide and one pixel deep. These sprites may be positioned anywhere on a horizontal line, and automatically repeat their shape and colour at the same position on the next line. The Atari 2600 allows a sprite to be displayed up to three times on any scanline - with preset spacing between each sprite instance. However, the shape displayed remains the same, unless it is changed mid-scanline by software. The famous 6-digit score routine - used for most of the scoring systems on Atari 2600 games - does just this, dynamically modifying the sprite shapes to achieve 6 independent 8-pixel wide sprites per scanline. It's a very neat trick, and forms the basis for the Interleaved ChronoColour™ system. Unfortunately, each of the sprites on the line must be a single colour - there is not enough processing time to change the shape of the sprites and the colour of the sprites- yet alone the colour of individual pixels. In fact, there's barely enough time to even change the shape of the sprites! So, how does Interleaved ChronoColour™ manage to produce a full-colour image? As it turns out, the system uses characteristics of the limitations of the human eye and your TV screen to give the impression of many colours when, in fact, the colour resolution (in both time and space) is quite limited. Your eye does not have high temporal colour resolution, so colours that vary rapidly tend to merge together and are perceived as a single blended colour. The colour resolution of the eye viewing a TV image appears (just from my experiments with the ChronoColour™ effect) to be roughly 18-20Hz - that is, above this rate the eye is unable to discern individual colours as they change. This is slow enough to allow the ChronoColour™ system to display reasonable images. As noted, there is barely enough time to display different shapes for each 8-pixel-wide sprite on any scanline - yet Interleaved ChronoColour™ appears to be displaying different shapes and colours! It appears to be, but it isn't... it just looks like it is. The Interleaved ChronoColour™ system is still using just a single colour for all of the sprites on any scanline - red, green, or blue. The same colour is used for the whole of any scanline. The system is varying the both colour used for any individual line (a single colour for the whole line) and the shapes displayed on that line. Every 3 sequential TV frames you see firstly red components of the pixels on the line, then the green components of the pixels on the line, then the blue components of the pixels on the line. So, any scanline consists of a single colour change for each sprite (to blue, green, or red), followed by (essentially) the body of the standard 6-digit score routine, which changes the shape of each sprite on-the-fly. Subsequent frames display the other colour components for that line. Each scanline must display on successive TV frames the blue, green, and then red components of the image for the ChronoColour™ effect to work. By also varying the colour of scanlines within a TV frame (one red, the next blue, the next green, the next red, etc), and displaying the right shapes for the sprites on those lines (the red pixels, etc), the alternation of red/green/blue is done at the frequency of display of scanlines (ie: many times per TV frame) instead of the frequency of display of the TV frames themselves (ie: at 60Hz). As there are only 4 colours available for any pixel (blue, green, red or black) of a single intensity, shading is achieved by dithering the original separated colour planes to two colours (black or non-black). This dithering distributes the pixels such that the eye perceives different intensities of the original colour. If you look very closely at the image, you may be able to detect a rolling band of red/green/blue scanlines marching up the screen - especially in the white areas of the image, if present. If you move your finger up the TV at the correct speed, watching your finger as you go, this effect becomes much more pronounced. This demonstrates clearly the alternating of colours on a per-line basis, and the interleaving of the colours on a per-frame basis for any scanline. So, that's how the Interleaved ChronoColour™ system works! Behind the display system itself are tools developed to produce data in the correct format. These tools, and the Interleaved ChronoColour™ technology itself, were developed during early 2003 by Andrew Davie, with input from various sources, including helpful advice and suggestions from members of the [stella] mailing list and the AtariAge community.   Creating Interleaved ChronoColour™ Images This example shows the process used for creating data for the Interleaved ChronoColour™ system. First, a suitable image is chosen, and resized to 48 wide by 128 pixels deep. The resizing process should use a filter to preserve as much of the original image colour and detail as possible. This stage of the process may also involve adjusting the brightness and contrast of the image to improve the final image as shown on the Atari 2600. It is sometimes an iterative process to find settings which are pleasing to the eye.   The 48 x 128 pixel image shown at right, above, is separated into three component images - the red, green and blue components of the original image. These components are shown below.   These component images are each 256 shades of a single colour (red, green or blue). The Interleaved ChronoColour™ system is capable of displaying just a single shade of red, green, or blue, and black, so the images are colour-reduced to just 2-colours (including black). By dithering the images during the colour-conversion, detail and shading information is preserved. The images below show the component images after they have been dithered (in this case using error diffusion and 'Stucki' weighted dithering method). Dithered Red Component Dithered Green Component Dithered Blue Component Animated RGB These three images (left, above), displayed on successive TV frames, would essentially appear to the human eye like the original image. However, left at this stage the 20Hz 'flicker' introduced by only displaying each colour on every third TV frame is quite noticeable and annoying. The eye can clearly detect the individual colour frames, though the brain is able to reconstruct the merged colours. The animated GIF, above right, shows the 2-colour dithered images displayed one after the other. Your browser will probably not display this image at full-speed (it should display 1 frame every 1/60th of a second) - but in any case, if it is animating quickly enough you may see that the combination of the separate 2-colour images does give a reasonable reconstruction of the original image, but the flicker is distracting. The next stage in the process, then, is to 'interleave' the red, green and blue images to produce hybrid frames which contain on successive lines a line from the red, a line from the green, and a line from the blue image, etc. Tools written for the purpose create data for these hybrid frames. The result of the interleaving is three frames, the first of which starts with a line from the red image, then a line from the green image, then a line from the blue image, etc. The second image starts with a line from the green, then a line from the blue, then a line from the red, etc. And finally, the third image starts with a line from the blue, then a line from the red, then a line from the green, etc. Interleaved RGB Interleaved GBR Interleaved BRG Animated Interleaved Frames This process produces three images (left, above) which, seen on their own almost appear like the original colour image. But note, each scanline of these images is still only a single colour and intensity (with pixels either red, green or blue). The animated GIF, above right, shows the same 2-colour dithered images as before, but with the lines interleaved as described above. Now, even at a low frame rate, the flickering is much less apparent and the colours easier to discern. A close-up of a section of the one interleaved image, below, shows the interleaved scanlines. When the three interleaved images are displayed on consecutive TV frames, the flickering is no longer noticeable - because each image includes red, green, and blue components. That's the essence of the Interleaved ChronoColour™ process. Close-up of RGB Interleaving The images below show a digital camera image from a monitor, alongside the original image. It's clearly not photo-quality - but given the hardware capabilities of the Atari 2600, Interleaved ChronoColour™ opens up exciting new opportunities in graphics display for future games.   This 4K Binary will run on the real thing, and under emulators such as Stella and Z26.

Copyright ©2003 Andrew Davie