iCC - Interleaved ChronoColour - how it works

[+Andrew Davie]

On the Zeropage Homebrew show yesterday I introduced a "new" display technology that I call "interleaved ChronoColour", or iCC for short. I thought I'd give a bit of an overview here at to what's actually going on with this display system.  First, have a peek at the longplay video demonstrating pretty much how iCC looks to the human eye...
 

I linked to mid-video as there's a bit of an issue at the start with the different frame rate of my screen capture and the iCC display.  So, iCC is leaning heavily on the way the human eye perceives things, combined with phosphor refresh on a CRT (or as emulated here in Gopher2600 emulator).  Essentially, there's a bit of blending going on here, and iCC takes advantage of persistence of vision (on a per-scanline resolution) and CRT persistence.  By modifying the colour on any scanline, and the on/off pixels on any scanline - and thus changing the screen content every single frame, it's possible to display effectively 8 colour (at least as perceived by the eye) with minimal flicker;  in fact flicker is a poor word here, and I like to use "shimmer" to describe it.

So, normal ChronoColour displays on/off pixels on triplets of scanlines. Consider three "primary colours" such as red/green/blue.  ChronoColour sets the playfield colour to these colours on successive scanlines, repeating down the screen.  So, R/G/B/R/G/B/R/G/B... etc.  And our eye perceives on-pixels on these lines as being a colour that's "blended" with the on pixels on both the scanline above, and the scanline below.  Of course red, green, blue are only one possibility. in fact, ChronoColour uses arbitrary colours on the successive lines - whatever works to produce a nice blending of R+G or R+B or G+B or R+G+B and of course R, G, B alone.  So if we're displaying red, we can only see red every 3 scanlines, and black on the G/B lines (i.e., no pixel).  So this all works just fine, and was used in the original Boulder Dash and many of my ChronoColour demos such as the chess demo, the Rubik's cube, Sokoboo, and others.

 

iCC works on the same principle, but instead of 3 scanlines being used for the R/G/B colours, just a single scanline is used - but over successive frames.  So we have R on frame 0, G on frame 1 and B on frame 2 (for any single scanline). But also, on frame 0 the next line is G and the line after that is B.  So frame 0 is exactly a ChronoColour frame as described at the start of this post.  But the next frame, frame 1... is a ChronoColour frame shifted up by one scanline (effectively).  More accurately, each triplet of frames (frames 0, 1, 2) are now three chronoColour frames shifted in "phase" by one colour.  And frame 4 is the same as frame 0.  So the display is rotating colours through a single scanline (R/G/B) over time, and over triplets of scanlines (R/G/B) over space.

Now this sounds expensive, as you would initially think you'd need to triple the graphics data to define stuff.  But actually it's not - I realised that in the draw systems I could use just one shape definition, but when drawing map triplets of lines to the appropriate scanline they need to be drawn on.  So line 0 of a shape might end up being drawn on lines 0 of the RGB triplet on screen, but in the next frame, line 1 would be drawn on line 0 of the RGB triplet on screen. It's kinda hard to describe this all, and sounds very complex... but the code to do it is actually incredibly (and surprisingly) simple.

 

Here's a close-up study/video showing the iCC in action, slowed down many many times and zoomed way in.  What you're looking at is (for example) how the parallax pixels in the blank areas are "shifting" in a 3 pixel position vertically. This is their blue colour being shown on all 3 "RGB" lines spatially, and also temporally (over multiple frames in different vertical positions).  This is happening so quickly (20Hz frequency for displaying on all 3 lines) at normal speed that, combined with the phosphor persistence and the eye's blending... it just appears as a 3-scanliine-deep blueish dot.  

Hopefully that makes sense.  In summary, pixels are now effectively 3 scanlines deep, and the colour of that pixel is displayed on all 3 scanlines, but at different times, or at least not always on every frame.  So in the video this looks very sparse and admittedly very very odd and unattractive.  But, run it at normal speed, and it looks like the video above where everything looks kinda solid - a bit shimmery (depending on the colours, really) - but really not too bad at all.  iCC.
 

 

The lovely thing about this new system is that it's cheap. You can turn it off easily by simply not rolling the colours over successive frames, just keeping the original R/G/B on successive scanlines. When you do that you have the original ChronoColour system.  I put it on an option switch in my new tech demo. Extra cost for including this technology is very very low - just a few lines of code, literally, so its essentially just as fast to draw; just one indirect to vector to the correct line in the bitmap draw system.

 

[+Philsan]

Awesome Andrew!

[Thomas Jentzsch]

Thanks for the explanation. I vaguely remember that we experimented with this during our Boulder Dash development too.

[+Andrew Davie]

6 hours ago, Thomas Jentzsch said:

Thanks for the explanation. I vaguely remember that we experimented with this during our Boulder Dash development too.

There is a very very early single-screen representation of a Boulder-Dash what-if using it, but it required triple the graphics data definitions. Only recently I realised iCC could be done using the original single-data but indexing into the shape in "triplet reorganising" mode, and it became feasible to use it after all.  That's why my demo can switch between iCC and ChrnoColour - it's exactly the same graphics data, just which scanline is drawn where varies over time.

[+fdr4prez]

Is this what you were doing for your Chess game?

[+Andrew Davie]

19 minutes ago, fdr4prez said:

Is this what you were doing for your Chess game?

Visually yes, but implementation no.  The chess game had triple the shape definitions; it was very expensive in ROM.  For each piece for each colour for black squares and white squares for three colour phases, a shape was defined. It was gobs and gobs of memory.  iCC combines the three colour definiitions into a single definition and uses the same ROM footprint as ChronoColour.

 

Edit: Most versions of chess were not iCC.  I do recall doing an iCC version for the 6-sprite/asymmetric playfield display. But yes, around the time of Chess I was exploring how to make iCC feasible. Only in this BD demo was I able to do that and make it switchable between iCC and ChronoColour at "no extra cost".

[Thomas Jentzsch]

41 minutes ago, Andrew Davie said:

There is a very very early single-screen representation of a Boulder-Dash what-if using it, but it required triple the graphics data definitions. 

I thought there was a version/idea where you could self-mod the code to change the order of colors processed. But most likely you are right here. Way too long ago for me.  

Edited January 29 by Thomas Jentzsch

[+Andrew Davie]

Just now, Thomas Jentzsch said:

I thought there was a version/idea where you could self-mod the code to change the order of colors processed. But most likely you are right here. Way to long ago for me.  

I do not remember either way, and any source code is long gone.

[Thomas Jentzsch]

Just now, Andrew Davie said:

I do not remember either way, and any source code is long gone.

I have a lot of the old source code and ROMs (back to late 2002) on my SSD.  

[m.o.terra kaesi]

You guys are all like magicians! 🙌

[+Andrew Davie]

10 hours ago, Thomas Jentzsch said:

I have a lot of the old source code and ROMs (back to late 2002) on my SSD.  

There was an iCC ROM I released back in maybe 2003ish... it was just a single screen (4K) version showing a boulder-dash "what if" screen using "interleaved chronocolour" back then. The difference being that it required triple the graphics data compared to the current implementation. Wish I could find it.

 

[Thomas Jentzsch]

37 minutes ago, Andrew Davie said:

There was an iCC ROM I released back in maybe 2003ish... it was just a single screen (4K) version showing a boulder-dash "what if" screen using "interleaved chronocolour" back then. The difference being that it required triple the graphics data compared to the current implementation. Wish I could find it.

One of these?

notBoulderDashPAL.bin

Boulder Dash (2005) (Andrew Davie) (WIP).bin

Boulder Dash Demo (05-04-2003) (AD).a26

Edited January 30 by Thomas Jentzsch

[+Andrew Davie]

30 minutes ago, Thomas Jentzsch said:

One of these?

notBoulderDashPAL.bin 8 kB · 3 downloads

Boulder Dash (2005) (Andrew Davie) (WIP).bin 4 kB · 1 download

Boulder Dash Demo (05-04-2003) (AD).a26 4 kB · 2 downloads

 

TY.  Yes, the last two of those. They're surprisingly good, at least to my eye. I recall them being "bad", at least relatively-so.

They are *triple* the vertical resolution of the current iCC system.  That is, a "pixel" in those last two binaries is one scanline in vertical size.

In my iCC implementation in BD2 demo, a "pixel" is 3 scanlines deep.  The difference is really down to how much data you want to use to represent the graphics. In BD2 I felt the lower vertical resolution was a reasonable compromise.  It's good to see once again the "quality" of the earlier implementation.

I wonder if I might have a play with higher resolution once again and see how that works out. I have no time pressure, after all.  I'd probably have to move to a larger ROM size and that would mean CDFJ+, I think....  But interesting.... thanks for digging them up.

 

[+sramirez2008]