Full Color Tile Driver Thread

1234568»

Comments

  • Dr_AculaDr_Acula Posts: 5,482
    edited July 2011 Vote Up0Vote Down
    Thanks for that. 33ms for a frame and say a frame has 320x240 which is 77kilobytes. Number of bytes per second is 320*240*1000/33 which is 2.3 megabytes a second. Approx 429 nanoseconds per pixel. The SRAM is a 55ns part and needs one NOP in PASM.

    This should be well within the limits of the ram chip.

    I'm thinking of buffers so that timing is not so critical - eg one cog is reading data off the ram into hub, and the video cog is reading data from hub. Maybe enough of a hub ram buffer for a few lines of the picture. So that should avoid color artifacts.

    As was pointed out on another thread, this is not going to work very well for fast moving graphics as there is limited time to update the sram with new video information.

    Although, thinking this through, if at 320x240 the sram is nearly 10x faster than it needs to be, that might leave plenty of time.

    The refresh rate for a video signal is 30x a second, and the frame rate for a movie with the sd card running flat out is around 7-8 frames a second. So there should be enough time to
    1) keep a video buffer topped up from the sram
    2) feed data into the sram from another buffer and
    3) keep data coming into the input buffer.

    With 24 pins devoted to running the sram, if the sram is disabled then that leaves all those propeller pins free to do other things, eg read data off an sd card. Or establish a fast parallel link with another propeller (maybe a 16 bit wide link?).

    I have some boards on the way to test some of this - hopefully soon.

    ericball - I've heard you have a high resolution driver available. I have the driver code but not the 'main' demo program. Do you have any code you might be able to share?

    PS - as an aside, is your avatar a CRO tracing of a NTSC signal?
    Answers: 1) A quadcopter. 2) Very high. 3) The internet. 4) A lot. 5) No.
Sign In or Register to comment.