Tv out with more colors and more pixels

fezmonkey

What would it take to display a 256 color 320x240 image on a tv? Is ram the only problem? Is there a project somewhere showing how external SRAM is used with propeller?

Can I use SPI SRAM or I need parallel SRAM to keep up with tv output?

Post Edited (fezmonkey) : 6/17/2010 1:52:37 PM GMT

potatohead

RAM is a problem, and you can fetch that image from external RAM.

The other one is the Prop doesn't render 256 colors "out of the box". If a change was made to the DAC, the colors are possible.

At that resolution, the best signals come from Eric's video templates, currently demonstrated in potatotext, my text driver. The other choice is to build off the Parallax video drivers, which produce almost as good of a signal.

What is needed is a few more resistors to get grey scales, or some PWM magic operating in tandem with an ordinary driver, perhaps on the S-video chroma resistor. If a few more resistors are used your driver will take one cog to draw the signal, but it will have to be a modification of an existing driver. If PWM is used to get some more greys out of the reference circuit, it might take two cogs, working in tandem to get the actual 256 colors.

If you bend the spec a bit, 128 colors is doable, no problem with the standard video circuit and the Parallax driver or a bitmap one built off Eric's video templates. Writing that bitmap display isn't hard, requiring perhaps 20 PASM instructions to be added to the template. For the best output, a few more instructions would yield a full interlaced display. You don't need to use the extra vertical resolution, just double up the scan lines. What will occur though, is the display will pick up on the extra color info, making edges and detail a lot sharper.

You may need a COG to fetch from RAM. Maybe that one can do PWM and RAM, while the primary COG does the bitmap display.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 6/17/2010 2:31:16 PM GMT

potatohead

BTW, you could build out the driver code at a reduced vertical resolution. That can happen in the HUB memory. Get the color issue settled, and image code working, video circuit decision made. Then, once that's displaying properly, add the RAM, and do fetches into the smaller buffer you are using for the reduced vertical. Once you can fill it faster than the TV driver consumes it, simply put the vertical resolution back to the desired one, and fill the buffer at the right times.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

ericball

320 pixels per line via composite video is going to generate color artifacts as each pixel will be around 50% of the colorburst duty cycle. So alternating light/dark transitions will be decoded as colors. Some of the 240 lines per field will fall into the overscan of most TVs.

The Propeller video circuit uses a 3 bit DAC with 1 level 4 bit PSK color on a separate pin (S-Video mode) or as +/-1 luma. For composite video luma = 2 is black and luma = 7 is white for six levels of grey. Depending on the TV (and whether you use S-Video or composite output) you could get up to 128 different colors. However, you only get 2 color intensities with composite (dull and bright) and only 1 (dull) with S-Video.

The alternative is to abuse the VGA mode, but that requires a very different way of generating color. See my 240H sprite demo.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

ericball

One new idea I just had is to use the 4th auralsub/S-Video pin to push the 3 luma pins up from sync to black, thereby increasing the number of black/grey/white levels to 8 and making all 128 colors usable. The problem is if you just turn it on it will push the white level from 100 IRE to 140 IRE. So instead we need to use PWM to find the right levels.

On the demoboard the 4th pin resistor is the same as the 2nd, so with all pins on thats 4+2+1+2 = 9 which needs to be 140IRE up from sync - all pins off. Therefore the LSB is 15.555 IRE. So from that we need to work out the following regions:
sync = all pins off (-40 IRE)
burst = normally 1/3 (+/-20 IRE) but in this case we'll have +/-15.555IRE, hopefully the AGC will compensate for the lower saturation
blank = 0 IRE
active = 4th pin on which gives a 0-7 range of -8.888 to 100 IRE. So 0 will be very black, and 1 (6.666 IRE) will be almost black (in fact, officially for North America NTSC black is 7.5IRE). So we've gained one level of grey, not two.

For blank & burst we need to push pin 2 on from 31.111IRE to 40IRE. So that's 8.888IRE or 28.57% of active or PWM FRQA of $4924_9249.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

potatohead

BTW: Using your templates for an interlaced, "scan doubled" display of 320x200, the signal quality is very good. Artifacts cancel out, and newer TV's that do signal processing, render that resolution very clean. I can get 80 columns doing that, and it's readable, and some colors work fine. Not all of them, but a lot of them. I was surprised actually.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

fezmonkey

I completely forgot that TVs have a standard resolution and 320x240 is not a good option.
What would be the reolution I need so I can run on NTSC and pal?
Now, if I use the standard resolution how many colors I can get while not doing anything crazy? Adding external ram can be an option.
The goal is to display a bitmap on screen. I am okay if I use all cogs. The image will be processed on another chip and then transfered to propeller to dsplay on tv

ericball

The difference between PAL and NTSC are the number of lines (625 vs 525), the refresh rate (50Hz vs 60Hz), the pixel aspect ratio and signal encoding details. The horizontal resolution is basically the same. On the Prop, your horizontal resolution is also limited by your WAITVID loop and (if using PSK color) that each pixel must be an integer number of 16xcolorburst subpixels. Each WAITVID specifies the 4 colors which may be used by the next 1-16 pixels. So if you go beyond 4 pixels per WAITVID you have to load both the colors and the pixels each loop.

The palette (using PSK) color is, at most (using my PWM 4th pin idea), black+white+5 grey+128 colors = 135 total.

Hmm... let's take the minimum WAITVID loop. If the pixels are loaded into COG RAM each line then you just need WAITVID, ADD, DJNZ. That's 6+4+4=14 cycles per loop. (Yes, I know the manual says 5+, but my experience says you need to have 6 clocks to account for phase jitter.) At 80MHz that works out to ~363 WAITVIDs per line, which is ~1024 active pixels! So horizontal resolution clearly isn't a problem. (I'm ignoring artifacting, just pre-filter the data as part of the CLUT transform process.)

So the real limitation on horizontal resolution is how fast that COG RAM buffer can be loaded from either HUB RAM or external RAM, i.e. how many words can be read in 63.5555uS (64uS for PAL). With HUB RAM you could get fairly close to 256 words, although the RDLONG loop would need to be unrolled big time. XRAM is going to be harder, especially since you need to guarantee exclusive access. So with HUB RAM you're limited to 32K, but with XRAM you are bandwidth limited.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum