Thursday, December 31, 2015

Xmas Rush for the MC-10

It's been a while since I've posted on this blog. I guess it is time to change that! A little Retrochallenge action should liven things up for a bit...

Christmas Spirit

Late in 2015 (just before the Thanksgiving holiday in the USA), I started thinking about making a Christmas-themed game for the Tandy Color Computer (CoCo). The original idea was to have a collection of 3 or 4 "mini games" with silly holiday references. I got started on that by putting together a simple game engine that used one of the 4-color modes on the CoCo. I tried to save time by taking the easy choice as often as possible, implementing simple blocky animation mechanisms, etc. Nevertheless, the holiday season brought with it some extra demands on my time...

What's the Rush?

By mid-December or so I had only come-up with one mini-game, a scenario where you have to go into the forest, grab the last Christmas tree, and escape from the evil snowmen guarding the tree. It sounds silly, but it turned-out to be rather fun. With the self-imposed Christmas deadline approaching I decided to polish-up what I had and make the best of things by releasing it. The result was Xmas Rush!

Challenge Accepted

Now we are at the turn of the year. With the New Year comes the next Retrochallenge event, RC2016/01! I have been participating in Retrochallenge events for a number of years, although my entry this past summer was a bit lackluster. Nevertheless, Retrochallenge is generally time well spent. The competition aspect makes for great motivation to get things done and the event provides great inspiration as an opportunity to observe what others are doing. I will continue what has become a tradition for me by entering again this year.

But what is the entry? Well, one regret I had about the Xmas Rush development was that I didn't have time to document any of what I was doing. I suppose I could go back and do that as my entry, but that seems a bit lame. However, it occurred to me that the MC-10 should be able to run Xmas Rush reasonably well. Plus, I have wanted to do an MC-10 project for some time. So for RC2016/01 I will port Xmas Rush to the MC-10, documenting the process along the way. Hopefully everyone will enjoy that!

The MC-10 is a different processor than the CoCo, and it has a number of architectural limitations that make it more challenging as a development target that its more powerful cousin. Plus, I will have to put some work into building an MC-10 development environment that is friendly to my style of work. Hopefully none of those challenges in sure to stay tuned!

Thursday, January 1, 2015

35 Colors On NTSC

Some time ago, I played with a "flicker" technique on the CoCo that alternated screens between a 9-color (8 + black) "Semi-Graphics" mode and a 4-color "Color Graphics" mode on the VDG.  I combined that with a technique for teasing 8 on-screen colors out of the 4-color mode, giving a combined effect of 44 on-screen colors!  I then used this technique as the basis for showing puzzle pictures in Sluzzle, and there was much rejoicing...

Not long after that, I conceived of a similar technique that might solve at least a few of the problems with the 44 color technique at the cost of reducing the palette size a bit.  I let that sit dormant for a while, until I decided to play with it a bit during my 2014 year-end break.  Below I will describe the 35 color technique for those interested in hearing more.

Problems Abound

The main problem with the 44 color "flicker" technique is, of course, the flicker.  The mode toggles between the two base video modes (SG24 and G6C) at the vertical refresh rate (60 Hz on NTSC machines, 50 Hz on PAL machines).  This produces a noticeable flicker effect on the displayed screen, but unfortunately this is inherent to any "flicker" technique -- sorry!

The bigger problem with the 44 color technique is that it uses the aforementioned technique to get 8 on-screen colors from the 4-color modes of the VDG.  This is achieved by switching the colorset select (i.e. CSS) input to the VDG while a line is being drawn on the screen!  This changes between the two 4-color palettes as much as 8 times per line, doubling the amount of available colors on the screen.  (This 8 color technique is also used in the CoCo version of the Imagic game Dragonfire.)  Unfortunately the extra colors come at the cost of eating-up all of the available CPU while the 4- (now 8-)color screen is being drawn.

The other big problem with the 44 color technique is that only one of the base modes offers the (non-)color black.  Since the observed color at a given position is the average of the colors at that position on the two base screens, then no position will ever be observed as fully black.  Although the available dark blue is a workable substitute in many case, the lack of a true black is a big handicap for the 44 color technique.

Another Option

If we accept that we will only get 4 on-screen colors from the 4-color base screen, then we could free-up more CPU time while that screen is displayed.  This would allow more time for implementing a game, playing background music, or whatever else.  But what about black pixels?

It turns out that on NTSC CoCos (and Dragons), there is another option.  Due to how an NTSC video signal encodes color (and how the CoCo video circuit is implemented), the black and white 256x192 VDG mode (G6R) is effectively a 128x192 4-color mode offering black, white, "blue" (cyan?), and "red" (orange?) pixels.  This mode was very popular for commercial games on the Coco, and it is similar to using 4 of the 6 available colors in the high-res video mode of the Apple II.

So now we can use a "flicker" technique to alternate between the G6R (i.e. PMODE4) "artifact color" mode and a Semi-Graphics mode.  Since the G6R mode also offers black and white, both of those colors are still available when using the "flicker" technique!  I will show the available palette below.

Semi-Graphics Palette
G6R "artifact color" Palette
Combined "Flicker" Palette
Issues Remain

As you can see, this technique yields a nice range of usable colors from the VDG.  It does, of course, still have a perceivable "flicker" on the screen.  Also, the technique is limited to being used on NTSC displays.  Of course, the G6R mode can be used as a 2-color mode on PAL machines -- by ignoring the "artifact" colors, this could also be viewed as a 17 color technique...

Sticking with the NTSC world, there is one other problem.  Anyone familiar with the use of "artifact" colors on the CoCo will know that the patterns corresponding to "blue" and "red" switch at random between resets.  That is why so many CoCo games have an introductory screen with a message like "reset until this is blue".  Any program using the 35 color technique described above will need to address the same issue.

Finally, I am seeing some distortion to the colors near the top of the display.  I have not yet determined why that is happening, and it might relate to something else I am doing -- YMMV.  I'm going to downplay this distortion for now, as I believe it is likely caused by something outside the core of the technique described herein.

44 Color Me
35 Color Me
Nevertheless, I am getting decent results in my picture conversions using this 35 color technique.  The availability of a true black makes a huge difference, and that largely compensates for the ~20% smaller color palette available versus the 44 color technique.  With a lot more CPU time available, this technique could be useful for any number of programs on the CoCo including games.

I'm not planning to do anything more with this technique right now, but I hope someone else finds it useful.  I'm happy to consult with anyone that wants to try to make use of it.  In any case, be sure to stay tuned... :-)