Daniel Bass's RAINBOW - 240 additional colours for your Inty

[decle]

Hey all,

 

As I think is reasonably well-known Daniel Bass pioneered colour multiplexing for use on the Intellivision when he was creating Tower of Mystery / Tower of Doom.  This technique, named "bi-color" by Daniel, gives the illusion of more than 16 hues by toggling the colour of tiles every frame (1/60th second).  The persistence of the slow phosphors on old CRTs (which were geared to smoothing the 60 fields/second of interlaced NTSC TV into 30 frames/second) would then blend the two basic colours into a third hue.

 

Well, it turns out that quite a bit of work was done on this, which was then written up in an internal Mattel memo:

 

rainbow.pdf

 

As always, a hat tip to Daniel and Karl Morris for their work, and to Tom and Braxton at UCI for sharing this document from the BSR archives.  As you can see, an extensive exploration was done of the 240 new colours that the technique afforded, looking at how stable they were and comparing them with standard Pantone shades. Talking to Daniel, this analysis was completed by Karl.  Daniel then wrote the program RAINBOW to demonstrate some of the "best" colours that Karl found and allow developers to test how they interacted with different background colours as the level of flicker could vary significantly.

 

We think that the original RAINBOW is probably lost to time, however, I thought it might be fun to try to re-create something similar based on the description in Daniel's instructions to show off the colours that Karl found.  The results of this can be seen below (Warning - some background colours result in lots of potentially seizure inducing flicker - this is not nearly as bad in real life without YouTube doing its thing.  You also have to force YouTube to 1080p60 to see the bi-color effect properly)

 

 

rainbow.zip

 

The zip archive above contains both the ROM and the source code of the RAINBOW replica, which is largely written in IntyBASIC.  Instructions for the use of the ROM can be found on page 2 of Daniel's memo.  As I come from the land of PAL, if anyone has an LTO Flash and a CRT I'd be very interested in seeing a video of the program in action on authentic US hardware.

 

Whilst I have talked to Daniel about RAINBOW, there are a number of areas where artistic licence has been applied in putting together the replica.  As a consequence, whilst the colour changing algorithm is replicated and should display correctly on an NTSC CRT, the UI is not accurate.  Specifically, Daniel does not recall trying bi-colors on MOBs, so it is unlikely that the pattern on the right of the screen was animated (I left this in for reasons that will become apparent below) and the following are not known:

• Whether or not the columns and rows were labelled
• The shape and size of the colour swatches on the left side of the screen
• What static pattern was shown on the right side of the screen to illustrate the selected colour against the current background
• The shape and colour of the cursor
• How the cursor moved (whether it glided smoothly or jumped from one swatch to another)
• Whether any information was reported about the selected colour

 

Having played with the RAINBOW replica a bit using JzIntv, I have found it takes JzIntv / Windows / Linux a few seconds to sort their respective lives out and get to a point where the frame rate stabilises and the flicker is minimised.  Once things settle down, I agree with Daniel that the bi-color effect works well with small areas of the screen (and by extension probably less so with larger solid blocks of colour).  However, I would add that when combined with the motion of a sprite the effect is very convincing, even in an emulator running on a modern monitor.  Therefore, the bi-color technique might be best suited to use with MOBs in fast moving action games.

 

This may already have been noted elsewhere, but a small extension to Daniel's technique also seems plausible.  It may be possible to get 3 hues for the price of 2 MOBs with minimal flicker by using a single basic colour on one MOB, and then multiplexing a second MOB between two different highlighted areas over the top of the first, as shown below:

For this to work one of the two components of each of the MOB2 bi-color shades would have to be same as the basic colour used for MOB1, and MOB2 will need to be repositioned and / or reprogrammed between each frame.

 

Anyway, despite the replica UI being less than accurate, I think this is another nice little glimpse into the kind of tools and techniques that the Intellivision developers were using towards the end of the Mattel era.

 

Thanks once again to Daniel, Karl, Tom and Braxton.

 

Cheers

 

decle

 

 

 

 

 

Edited August 21, 2020 by decle

[intvnut]

If you recorded an AVI, I believe jzIntv shouldn't drop any frames in the AVI itself.  If you're seeing frame drops in the AVI, let me know.

 

As for the actual display, I seem to get more consistent display synchronization in full-screen than in windowed mode.  Also, SDL2 is lightyears better than SDL1 so far in my experience.

Edited August 21, 2020 by intvnut

[artrag]

About 3 colour MOBs, use two sprites, one on layer 0 in colour A, another on layer 1 in colour B

Make the shapes in order to have a region of the two sprites is overlapping

Swap their planes at each frame. The non overlapping areas will stay in colour A and colour B, but the area of overlap between the two sprites will appear in a 3rd colour given by the blend between A and B.  

You can see 3 colour sprites in this MSX game

 

 

 

[skywaffle]

This is a very interesting concept and neat to see in action.   I'd love to see this used for higher color still pictures, as you can draw quite a bit and still maintain 60 frames per second.

 

Out of curiosity, is there a way to to apply only the color information to portions of the screen without altering the GRAM card reference at a similar speed?