Bufferless text video mode?

2»

Comments

  • Here's code that shows a 2bpp image.
    Had to make image as data file.
    2bpp BMP image is possible but can't find any app that can save that way...

    Photo has some weird artifacts from camera, looks better in reality...

    1632 x 1224 - 895K
    Prop Info and Apps: http://www.rayslogic.com/
  • "Missed it by that much!"

    cgracey wrote:
    I think the way to do this is to eliminate one of the two hub RAM lookups. You need to lookup characters and then font scanlines. The characters are contiguous in memory, but the font scanlines are random, as they are dictated by the character data. So, use SETQ+RDLONG to get a row of characters into cog registers. It only takes one clock per long that way. Then, use RDLONG/RDWORD/RDBYTE instructions to lookup the font scanlines. Do it from cog-exec, not hub-exec, of course. I think you could make a fast character-based display that way.
    Inspired by Chip's suggestions I had another attempt at building a text driver without a frame buffer in 1 cog.

    I used "SETQ+RDLONG" instructions to blast text and font data into cogram.
    I also organized font tables for faster sequential flow.
    In addition to these tqweaks I also pre calculated pixel masks and stored them in LUT.

    The target was 40 columns (32 was achieved).

    The killer is the pixel conversion stuff. Silicon at x2 speed obviously would be Ok.

    I also added a test to see the side effects of shared LUT/streamer operation.
    As predicted the "glitch" is visible.
    Experimenting with frequency of access and access length had mixed results.
    Maybe with some syncronization using "COGATN" might be able to disguise the glitch.

    Anyhow here's the code.
    Maybe some fresh eyes can see where more gains can be made.
    :)






    Melbourne, Australia
  • 32x15 text
    1056 x 592 - 257K
    Melbourne, Australia
  • potatoheadpotatohead Posts: 8,665
    edited February 12 Vote Up0Vote Down
    Well, with an 8x8 font, that's a 64 column display, if the color changes can happen 2x. :D

    This code, on YCbCr (component), should perform nicely and deliver 640x400ish lines. 80 column definitely possible.

    Want to get on my FPGA! Grrrr....

    The pixel conversions are expensive! As we all thought.

    Seems like changing the LUT on char boundaries is worth a look.



    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • ozpropdev wrote: »
    I also added a test to see the side effects of shared LUT/streamer operation.
    As predicted the "glitch" is visible.
    Experimenting with frequency of access and access length had mixed results.
    Does this mean two COGS, or live LUT changes ?
    For the two COG case, can a carefully interleaved access solve side effects ?
    It means for a 80MHz SysCLK you limit to 40MHz streamer, and every second slot is possible 'other cog' access ?
    Not sure just how you sync that exactly, I don't think 2nd COG can see any 1st COG streamer info, but they could maybe use a common master timestamp, and pivot off that. A quick test could simply run a few char-rows of each timing.

    What about Two COGS, 'sharing at the pins', to run two streamers, in short char wide bursts ? - how serious are the side effects doing that ?
  • I took the streamer down to 32 bytes. If it can do less, then it's basically a waitvid and a more P1 style technique can be used.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmg wrote: »
    Does this mean two COGS, or live LUT changes ?
    For the two COG case, can a carefully interleaved access solve side effects ?
    It means for a 80MHz SysCLK you limit to 40MHz streamer, and every second slot is possible 'other cog' access ?
    Not sure just how you sync that exactly, I don't think 2nd COG can see any 1st COG streamer info, but they could maybe use a common master timestamp, and pivot off that. A quick test could simply run a few char-rows of each timing.

    What about Two COGS, 'sharing at the pins', to run two streamers, in short char wide bursts ? - how serious are the side effects doing that ?

    The "noise test" was two cogs with the second cog writing to the first cog's LUT.
    A write to LUT from the second cog while the streamer is outputting visible lines causes pixel loss (black) noise.

    Dual streamers would not work as each cog has it's own exclusive DAC set.
    Is that what you meant by 'sharing at the pins'?



    Melbourne, Australia
  • jmgjmg Posts: 9,645
    edited February 13 Vote Up0Vote Down
    ozpropdev wrote: »
    Dual streamers would not work as each cog has it's own exclusive DAC set.
    Is that what you meant by 'sharing at the pins'?
    I was thinking of Digital modes, as in LCD driving, which I think can share at the pins.
    ozpropdev wrote: »
    The "noise test" was two cogs with the second cog writing to the first cog's LUT.
    A write to LUT from the second cog while the streamer is outputting visible lines causes pixel loss (black) noise.
    What pixel clock to sysclk ratios did you try ?
    For ratios not 1:1 it seems to me you could interleave LUT access ?

Sign In or Register to comment.