Shop OBEX P1 Docs P2 Docs Learn Events
NTSC 8bpp bitmap display driver — Parallax Forums

NTSC 8bpp bitmap display driver

ericballericball Posts: 774
edited 2011-09-24 18:23 in Propeller 1
For everyone who just wants a display simple all-points addressable bitmap on their TV (NTSC only, PAL in progress) - here's an answer.

The NTSC8bpp TV driver displays a i_width x i_height image on a TV using standard 3pin TV DAC. The bitmap is padded horizontally and scaled vertically to i_lines (non-integral vertical scaling supported). Pixels (TV coding) are stored in display order (left to right, top to bottom).

I have also tried to put in as many comments as possible for those interested in developing their own TV driver (either based on NTSC8bpp or from scratch).

I'll upload to ObEx once I finish the PAL version.
zip
zip
NTSC8bpp.zip
13K

Comments

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-09-08 18:20
    This looks very interesting.

    One thing I found writing the 256x224 driver was that when I displayed alternate lines there were some interference effects on the display with dark/light bands every 30 lines or so. This is probably an artifact of interference between the actual number of pixels on the display and the number being displayed. The driver I was using only has vertical lines in multiples of 16, so having the ability to have n lines could be very useful as one could experiment with the number that gives the least artifacts.
  • RaymanRayman Posts: 15,000
    edited 2011-09-09 14:21
    Looks great! Can you say something about the horizontal and vertical resolution? I didn't see the limits anywhere...
  • ericballericball Posts: 774
    edited 2011-09-09 14:44
    Rayman wrote: »
    Looks great! Can you say something about the horizontal and vertical resolution? I didn't see the limits anywhere...

    See the VAR section: 
      LONG i_height       ' number of rows (max i_lines) 
  LONG i_lines        ' number of active lines (max 482, does not need to be integer multiple of i_height)
  LONG i_clocks       ' pixel width in 16x colorburst clocks (256 => i_clocks > 515MHz/CLKFREQ) 
  LONG i_width        ' number of columns, must be divisible by 4 (i_width*i_clocks < 3192-3894MHz/CLKFREQ)
' For "square" pixels 3*i_height*i_clocks = 14*i_lines  
' i_clocks < 10 and i_lines < 2*i_height will generate color artifacts instead of extra detail
' Due to overscan not all of the screen is visible on all TVs.
' "Action Safe" i_width*i_clocks < 2750, i_lines < 433; "Title Safe" i_width*i_clocks < 2444, i_lines < 385
  • SapiehaSapieha Posts: 2,964
    edited 2011-09-09 15:58
    Hi ericball,

    Have You possibility to make even PAL version?

    ericball wrote: »
    See the VAR section: 
      LONG i_height       ' number of rows (max i_lines) 
  LONG i_lines        ' number of active lines (max 482, does not need to be integer multiple of i_height)
  LONG i_clocks       ' pixel width in 16x colorburst clocks (256 => i_clocks > 515MHz/CLKFREQ) 
  LONG i_width        ' number of columns, must be divisible by 4 (i_width*i_clocks < 3192-3894MHz/CLKFREQ)
' For "square" pixels 3*i_height*i_clocks = 14*i_lines  
' i_clocks < 10 and i_lines < 2*i_height will generate color artifacts instead of extra detail
' Due to overscan not all of the screen is visible on all TVs.
' "Action Safe" i_width*i_clocks < 2750, i_lines < 433; "Title Safe" i_width*i_clocks < 2444, i_lines < 385
  • PerryPerry Posts: 253
    edited 2011-09-20 08:49
    ericball wrote: »
    For everyone who just wants a display simple all-points addressable bitmap on their TV (NTSC only, PAL in progress) - here's an answer.

    The NTSC8bpp TV driver displays a i_width x i_height image on a TV using standard 3pin TV DAC. The bitmap is padded horizontally and scaled vertically to i_lines (non-integral vertical scaling supported). Pixels (TV coding) are stored in display order (left to right, top to bottom).

    I have also tried to put in as many comments as possible for those interested in developing their own TV driver (either based on NTSC8bpp or from scratch).

    I'll upload to ObEx once I finish the PAL version.

    I have used your GreyTV with my "Stupid Video Capture" project and have great success. I have a newer version I am using with 108Mhz clock. The display has been boosted to 80x240 pixels. Now I am trying to use your 8ppp driver.

    I can capture pseudo colored videos with this setup even up to 60 fps.

    I now have a platform to actually try to capture the color signals.

    Could it be possible to combine the GreyTV and the 8bpp driver into a combo, call it a 2pin video driver? The GreyTV processes pixels by the byte but the bpp does that by the long....


    Perry
  • ericballericball Posts: 774
    edited 2011-09-21 06:30
    Hi Perry,

    I'm trying to understand your requirements.
    Could it be possible to combine the GreyTV and the 8bpp driver into a combo, call it a 2pin video driver? The GreyTV processes pixels by the byte but the bpp does that by the long....
    GreyTV uses a counter in DUTY mode to generate the video signal using a single pin. It can generate more levels of grey than normal TV objects (although fewer than the 8bpp would suggest) but at fairly low resolution. It uses WAITCNT instead of WAITVID for timing. NTSC8bpp uses the Propeller video generator and 3 pins.

    I'm hoping that NTSC8bpp requires the bytes to be long aligned isn't a serious issue, but you're more interested in something which does color TV using only 2 pins.

    It's possible to use NTSC8bpp with only 2 pins:
    1. The DIRA & VCFG masks will have to be changed to not output on the LSB pin.
    2. DUTY will have to be used on the MSB to push the colorburst up ($2DB6DB6D) and establish the blanking level ($6DB6DB6D).
    3. You will only get [strike]4[/strike] 3 levels of grey. (I did the calculations and there isn't much difference between the two greys.)

    To get more levels of grey will require combining GreyTV with NTSC8bpp. There's two ways of doing it I can see:
    1. Use WAITVID to generate chroma (probably on one pin using S-Video mode) and DUTY for luma. The problem is the horizontal resolution will drop to even less than GreyTV because the WAITVID means the RDBYTE is no longer synchronized.
    2. Use two cogs - one doing NTSC8bpp for chroma using S-Video mode, the other GreyTV using DUTY for luma. The trick will be synchronizing the pixels closely enough. Each driver will also need a separate bitmap (which may be an advantage for your use).

    PS I have the PAL driver mostly working, but I'm running into chroma problems.
  • RaymanRayman Posts: 15,000
    edited 2011-09-21 08:22
    ericball,
    Can you say somehting about the palette? I've seen you do a few different things...
    Is this the same as regular Parallax TV Palette?

    Your driver has me thinking again about a "universal" GUI for TV, VGA, and 3.5" LCD... Thinking about 320x240x8bpp
  • ericballericball Posts: 774
    edited 2011-09-21 09:23
    Rayman wrote: »
    Can you say somehting about the palette? I've seen you do a few different things... Is this the same as regular Parallax TV Palette?
    Standard Propeller TV palette.
    Rayman wrote: »
    Your driver has me thinking again about a "universal" GUI for TV, VGA, and 3.5" LCD... Thinking about 320x240x8bpp
    That will be tough given that 320x240x8bbp would require 75K of HUB RAM. 200x150 is 29K which might be manageable but doesn't leave much space for other code.

    This is the problem with bitmaps - they are memory hungry.
  • PerryPerry Posts: 253
    edited 2011-09-22 13:22
    ericball wrote: »
    Hi Perry,

    I'm trying to understand your requirements.


    To get more levels of grey will require combining GreyTV with NTSC8bpp. There's two ways of doing it I can see:
    1. Use WAITVID to generate chroma (probably on one pin using S-Video mode) and DUTY for luma. The problem is the horizontal resolution will drop to even less than GreyTV because the WAITVID means the RDBYTE is no longer synchronized.

    Eric. Thanks for the suggestions

    I have been trying to do something like this with your drivers. I like your Number 1 option, my horizontal resolution is low enough to manipulate the pixels on the fly. I tried first with the GreyTV driver but forgot about the color-burst ( will look at it again to-night).


    Also I wonder if a different summing network would be needed. What about the PWM on pin 15 and a capacitor to the reference circuit to pick up the color ?

    Ray,
    Eric's demo produces a great palette display, with legend!. very useful for color selection


    Perry
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-09-22 18:07
    Rayman
    Your driver has me thinking again about a "universal" GUI for TV, VGA, and 3.5" LCD... Thinking about 320x240x8bpp

    ericball
    That will be tough given that 320x240x8bbp would require 75K of HUB RAM. 200x150 is 29K which might be manageable but doesn't leave much space for other code.

    This is the problem with bitmaps - they are memory hungry.

    Inspired by propGFX, I have been experimenting with external memory. As eric says, if hub is all used up for video ram there is not much left for code. If you accept that will always be the case for a decent video driver, then may as well accept that you need two propellers - one for code and one for video. In a way, that is not so unusual - I think even back in the olden days there were Z80 computers that had a Z80 also running the screen. So I think it is 'allowed' to use two propellers.

    And then you can think about the best options for a 'video' propeller. prop plus external ram. two or more props etc.

    I haven't pushed the 256x224 driver to its limits yet. I know it can go to about 336 wide before color artifacts get too bad, but I am not sure about the timing. I'd like to go to 298 if possible because that gives a 4:3 ratio without needing prescaling.

    Only problem is that at 256x224 with half the video buffer in hub and half in ram, there is not much code space left. Some can be reclaimed by rewriting the serial driver object and the video object I'm using as they use code that needs a bit of the hub ram to stay constant after the cog has loaded, and so these could be rewritten so the all the hub can be reclaimed afterwards.

    That technique could be relevant here too because then you can write pretty much everything in pasm with only a few lines of spin to launch things, and put all the cog code into the video buffer at startup. Then you could get up to almost 32k of hub ram for a video buffer.

    256x224 is 57344 bytes, half in hub and half in external ram. With a 512k ram chip that leaves a lot of ram free - and I have ideas of using that ram as a place to store sprites, partial screen captures and fonts. There is plenty of time to move things around at the end of each frame - I did an experiment with a delay loop and there are 53000 pasm instructions one can run at the end of each frame so that is lots of time to copy a font onto the screen buffer etc.

    So yes, I think a universal GUI is entirely possible.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-09-24 17:30
    @Rayman - for a GUI, this is getting good enough to be usable
    GUI.jpg
    640 x 480 - 42K
    GUI.jpg 42.4K
  • RaymanRayman Posts: 15,000
    edited 2011-09-24 18:23
    Looks great!

    BTW: I found an old 4x8 pixel font on the web that might be nice for 80 column display...
Sign In or Register to comment.