Had an extra day of hotel room time, so I went ahead and did some exploring of color potential on the Propeller. IMHO, it's not bad at all! Just using the reference video output circuit, I was able to get 400 colors on screen, by over clocking the pixel clock to twice it's normal NTSC running rate. Essentially, it's two pixels into what would otherwise be a single pixel Atari style NTSC color clock.

Initial results were pretty decent. There are plenty more colors possible, given some serious thought to choosing palette choices, etc...

This is a 320x96 image, which consumes nearly all the RAM. Looks like I'll likely either need to generate video on the fly, or get the SRAM addon to do more than just plot some dots.

One other thing that could be done is interlace this color, so that the effective resolution would be 320x192.

Edit: Another user helped me with the timing stuff. Was far simpler than I thought it might be. Turns out, the only real requirement is that the overscan must be a multiple of the pixel clock. Of course this makes perfect sense, after having seen it in action... arrgh.

In any case, the prop can display 400 colors no problem. This does allow for overlay graphics, more than one generator rendering the same scanline at the same time, more greys, etc...

Edit: I think I'm gonna work through a simple Breakout game. This technique does make overlay graphics possible, but they are or'ed with the graphics underneath in a fashion similar, but not quite like a PM overlay. Breakout can have a solid background, so this is not a problem just to explore two generators working together to produce a display. Since the high color depth consumes pretty much all the prop RAM, what I want to do is a 2600 style scenario where the background graphics are fairly low resolution (maybe 48, 64 or 80 pixels horizontal and 4 scanlines high), and a higher resolution object for the ball. (Maybe a 160 pixel resolution object, also 4 scanlines high)

I'll use timing to position the ball object, in a fashion similar to how it's done on the 2600, so it's gonna consume very little RAM. I'm also thinking collision detection might be possible, but tricky to get right. Essentially, the video generators are gonna be drawing the main game graphics. The ball video generator cog, could look at the pins, right when it's about to output it's pixel and store a value. Problem is that case won't really occur until the exact moment a pixel needs to be drawn. At lower resolutions, there might be enough time, but at higher ones, no way... Gonna ignore this for the first pass, but it's something to think about. I suppose a third cog could be watching for collisions, but that's three freaking COGs. Maybe dealing with a hardware collision detection emulation is just not worth it. The prop is fast, so detecting for collisions in the usual way, based of off the game state is just the way things need to happen.

All things considered, I'll build a display kernel that has score, number of remaining balls, level and whatever else in the top scanlines. These will either be a bitmap, or maybe character mode style graphics for easy, in game manupulation from the higher level spin language. Then will come the playfield, at the low resolution, high color depth. This will be followed by a high resolution (160 pixels horizontal x 3 scanlines vertical) area for the paddle, followed finally by nothing but blank scans. This will consume perhaps a 5th of the ram that would otherwise be consumed drawing these objects as a full on high-color bitmap. The ball overlay will just be a small bitmap that is positioned via timing that is keyed off of two position memory locations.

From there, it's just the game logic and some sound, to be done by another COG.