Propeller limited in colors...how did vintage consoles do it then?

cbmeeks

I've read the P1 is limited to around 90-120 (IIRC) colors. Usable colors anyway. Maybe more using the aural trick.

Anyway, I was reading that the Sega Genesis had a palette of 512 colors and the SNES had a palette of 32,768 with 256 on-screen at once.

How were such massive palettes possible? Especially for NTSC systems.

I could perhaps see having 5-5-5 bit RGB palette (32x32x32 = 32,768) that maybe gets converted to NTSC composite somehow.

Thanks for any tips.

potatohead

All it takes is a few more Luma levels, and some better control over the color signal. The Propeller employs the very basics. It can do considerably more color. I've coaxed 400 plus colors out of it by combining the standard signal with artifacting.

Eric Ball did color a few ways.

Those old consoles just needed a bit more of a circuit and enough memory throughput to make use of it.

As soon as the clocks got past the early speeds, a lot more became possible. The Atari computers did some 40 to 60 bytes of screen DMA per scanline. That is barely enough to make use of the nice color palette. 256 colors in the early 70's is quite a lot.

By the time we got the Genesis, many times that much per scanline became possible.

IMHO, that's one good way to measure this stuff. But there is the case of having separate VRAM too, which helped some machines to do more at a lower clock.

As for NTSC, it's quite capable of displaying 16 bit color and more, depending. After all, we did watch TV on it.

And NTSC is slow. The time per scanline impacts all of this. Faster sweeps can get us better resolution and framerates, but that also demands faster circuits too.

Remember early VGA? Some modes, like 13h, used the same slow sweep NTSC does, and that means more time to fetch data and deal with colors, among other things.

VGA today does not support the slow rates. The closest one is about 2x or so. Still pretty slow. Component video can still use the slow TV sweep rates and it's color potential is great. First Gen DVD looked fantastic on a component connection, just as it did on RGB monitors.
http://www.polygon.com/features/2015/2/3/7952705/sega-genesis-masami-ishikawa

It appears dual port memory helped get Sega to the Genesis capabilities.

potatohead

The Propeller has 16 chroma phases, and those are presented at a fixed level.

That means 16 base hues. The fixed level means no saturation control, but the color gets overdriven when high Luma values are used, so we get two saturation levels on composite. Moderate, and very seriously oversaturated. When a Prop is driving S Video signals, the oversaturated colors do not appear.

The 3 bit DAC yields 6 grey or Luma values. If you want, you can build a bigger DAC and get more shades of those 16 base hues.

If color is done in software, more colors can be had, and more control over them too.

On a Prop, it comes down to RAM and what kind of circuits make the most sense. Some people have made 8 bit DAC circuits to get something like 160 grey levels and no color, for example.

We don't do too much of that due to the high HUB ram cost.

localroger

Some designs, like Bill Henning's Morpheus, use external memory driving wider DACs to get more resolution, but those designs create challenges in updating the video image without disrupting its display.

Mark_T

Or you can drive an SDRAM directly to a TFT display (which typically take 5-6-5 or 6-6-6 digital colour). A neat
trick since you can use the video generator to drive SDRAM command signals, without having to deal with
the datapath for display. During frame-blanking time you can write to the SDRAM if you are careful. Burst
writes of the same pixel colour can be very efficient as you go at the speed of the SDRAM, not PASM. The
video control registers handle most of the sequencing and counting, but the details are tricky.

ericball

Part of the reason the Propeller has fewer colors than old consoles is how it uses the bits. The Atari 2600 VCS uses a similar Y+phase system, but it gets a full 128 colors from 7 bits.

In "native" TV mode, the Propeller uses 3 bits for luma amplitude, 1 bit for color enable and 4 bits for color phase.

So 5 bits are used to generate 17 colors (16 hues + B&W). On the 7800 color 0 is B&W and there are 15 hues generated via a tapped delay line. So on the Propeller the colors will be more consistent but it's only 53% efficient.

Additionally, on the Propeller two of the luma values are below black (for sync generation), whereas on the Atari 2600 this was generated automatically. So again some of the possible byte values don't provide usable colors. (OTOH one of the below black values generates the super-saturated colors.)

Consoles like the NES & SMS have a LUT between the pixel bytes and the video generator which means they can pick colors from a much wider gamut. It might be possible to do something similar with the Propeller with external circuitry - use VGA mode to push out bytes and output the PLLA clock to a pin.


Idea expanded: the 8 bits drive an 11 bit LUT which is divided into a 1 bit frequency selector, 4 bit hue value, 3 bit low output and 3 bit high output. The 4 bit hue value is use to provide from the PLLA output a divide by 16 with phase shift output similar to the Propeller. The 1 bit frequency selector selects between this hue output and the raw PLLA output. The output of the frequency selector then muxes the high and low output values to the 3 bit output DAC. The LUT has the following contents:
$00 1,-,0,0 // sync output
$01 1,-,1,1 // -20 IRE
$02 1,-,2,2 // 10 greyscale values
$03 1,-,2,3 // PLLA output provides frequency dithering
$04 1,-,3,3
$05 1,-,3,4
$06 1,-,4,5
$07 1,-,5,5
$08 1,-,5,6
$09 1,-,6,6
$0A 1,-,6,7
$0B 1,-,7,7
$0C - $0F // not used

$1x 0,x,1,3 // colorburst +20/-20 IRE
$2x 0,x,1,4 // 14 shades per hue
$3x 0,x,2,4
$4x 0,x,1,5
$5x 0,x,2,5
$6x 0,x,3,5
$7x 0,x,1,6
$8x 0,x,2,6
$9x 0,x,3,6
$Ax 0,x,4,6
$Bx 0,x,1,7
$Cx 0,x,2,7
$Dx 0,x,3,7
$Ex 0,x,4,7
$Fx 0,x,5,7

So that's a total of 234 colors.

cbmeeks

Thanks for the information, everyone.

I'm having a terrible time understanding how the Propeller actually works with color. I have a pretty good 2-color driver that I've drafted together that uses external SRAM. But when I try to make it a 4-color driver, nothing seems to work.

I cannot seem to find any clear documentation on how the Propeller generates color...other than forum posts.

I get the 3-bit DAC is sort-of "hardwired" in the propeller. And, how normally you would get 8 values but because a couple of them dip below "black", we only get 6 luma values.

But I'm still confused on how the color works.

Years ago, I built a color circuit using an SX48 and some muxes. I used a delay tactic that is probably similar to what @ericball said when he mentioned:

On the 7800 color 0 is B&W and there are 15 hues generated via a tapped delay line

Basically I would push a 3.58MHz crystal through a 4-16 mux and depending on which 16 bit value I would choose, the propagation delay would render different colors. That actually made a little more sense to me than how the Propeller does it.

Maybe because I cannot find good instructions for the Propeller.

I would love to not even use hub RAM at all and drive everything from external SRAM. But I know that's pretty much impossible if I want sprites, tiles, etc. because I need that concurrency.

potatohead

Well, there is an option to output the color signal on its own pin that may help clarify how the Prop does it.

That 4 pin DAC sees three pins used, with 4th pin reserved for audio.

You can use VCFG to tell the Prop to put the color by itself of that 4th pin. That is the svideo option.

The color signal is output as a one DAC level signal that gets added to the signal formed by the three pin DAC. This is why some dac values result in super bright colors! After the addition, the signal is over spec, but most all displays will take it anyway. Value 07 is white, but if color is specified, it becomes a higher value still!

Look at a TV driver, and in the Hsync, there is the colorburst. A color gets specified there, and that one DAC level signal gets added to the blanking level, which is value 01. It toggles at the colorburst and phase specified in the color data bits. A little phase counter in the video generator does it.

Just a square wave, nothing fancy.

When VCFG is used to put the color signal on DAC Pin+3, that pin toggles at the colorburst frequency, and it's phase is determined by the data bits Eric described above.

This would go into the color signal input on an svideo setup, and the 3 pin DAC would go into the Luma input.

ericball

The video output circuit is fairly simple:

if color[3] == 0 then
  out[0..2] := color[0..2]
else
  if (phsa + color[7..4] >> 4) & 8 then
    out[0..2] := color[0..2] + 1
  else
    out[0..2] := color[0..2] - 1
endif

So if the color enable bit is zero, then the luma is output directly. But if the color enable bit is one, then the luma value plus/minus one is output. (This is why luma = 0 & 7 gives super-saturated colors as they effectively output 4 or 3 plus or minus three.)

ericball

See https://en.wikipedia.org/wiki/List_of_video_game_console_palettes

Note: any console with RGB colors would have used an RGB to composite conversion step to generate the actual output.