Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 

Kansas City

Retrosys v3 Graphics Concept - Part 1: Overview


My blog contains posts on various projects I'm working on, coding ideas, and pure random this-and-that.


Retrosys v3 Graphics Concept - Part 1: Overview

Shayne Helms

256 x 192 px NTSC with 24-bit, 256 paletted color at 30fps on a single Propeller chip? How does that all work? Let's take a look at the conceptual design for the Retrosys v3's graphics subsystem to find out.

One of the biggest limitations I fought with on the v2 revision of Retrosys was getting the graphics at a level I wanted them. The more I worked with this design, based on utilizing a single Propeller chip for the whole system, the more the device's constraints began to weigh in.

 The Parallax Propeller

The Parallax Propeller

For starters, the chip features 32 KB of RAM. This isn't too shabby for a retro-style console (I view it as a challenge rather than a pain point), but that RAM space starts dropping fast when you start stacking all your video and audio buffers, game metadata, drivers, and program in there. For the v3 edition of the Retrosys, I knew from the get-go that I wanted to create dedicated subsystems, each with their own Propeller, for graphics, audio, and primary operations.

Secondly, there are some limitations to the Propeller's on-chip video generators. The base NTSC tile driver provided by Parallax only supports four unique colors per tile of the display. While this is great for some simple games and quick prototyping, it doesn't really provide the level of graphics fidelity most games call for.

Several people have written custom drivers for the Propeller that push pixels off to the video generator in such a fashion as to allow for no limitation on unique colors per area of the screen. So what's the catch? The video generator is still restricted to a limited color bit depth, and thus has a limited and fixed palette.

I wanted to setup a solution akin to something from the 16-bit era. 256 color graphics, at least 256 px of horizontal resolution, and lots of VRAM for tiles and sprites. I wanted 24-bit color depth that allowed the program to dictate the palette to the hardware, not the other way around.

First off, I am not using the Propeller's built-in video generator - there's no way around the palette restrictions that I am aware of. So instead, I'm generating my own NTSC signal on the fly using the Propeller's frequency generators. 

Analog Devices' AD725 operational schematic

To assist with intermixing the signal, I am utilizing the fabulous AD725 chip from Analog Devices. The AD725 is an RGB to NTSC encoder that accepts a sync signal and separate R, G, and B color signals, and intermixes the color component to output composite or s-video NTSC.

Three of the Propeller's cores will be running a driver for a color generator. The color generator driver will accept a palette value for the current pixel from external SRAM, and output an analog voltage from 0 to 0.7V using the Propeller's frequency generators to each of the R, G, and B inputs on the AD725. A fourth core will be generating the sync signal and controlling an external SRAM buffer that contains the current frame to blit onto the screen.

In the next article, we're going to take a look (and set the record straight!) at what's involved in generating a valid NTSC signal from scratch. After that we'll look at a full screen blit cycle for the graphics subsystem, and then explore some of the other functions of the subsystem like chip-to-chip communication and rendering.