Shop OBEX P1 Docs P2 Docs Learn Events
Can the STREAMER be stopped anytime? — Parallax Forums

Can the STREAMER be stopped anytime?

I'm wondering for video related purposes. Thinking about using the timer interrupt to set timing and insure a solid frame no matter what happens with the pixels.

Ideally, it can be stopped and a steady, until next stream value, can be quickly written to the DACS.

Comments

  • cgraceycgracey Posts: 14,133
    Yes, it can be stopped and started, always continuing from where it left off.
  • TubularTubular Posts: 4,620
    edited 2015-10-06 04:29
    Yeah it can, Chip's demo code does a high frequency then low sine frequency burst with seamless continuity between the cycles. You can set how many repeats it does

    So yes you can do the porches & sync, then fire off a single 512 pixel line, which then releases the cog to do other things while those 512 pixels stream out at the NCO defined rate. I don't see why that can't be initiated from a timer interrupt, which could also handle the vertical blanking

    In the code OzPropDev just posted you'll see there's a commented out 'waitx ##3150, which is where code can go to perform other functions while the streamer is doing its thing in the background

    I'm sure there will be other modes, but we can already do this much.




  • Ok cool. I'm happy, well as happy as I'll be until I get back to my FPGA. Business travel sucks when you don't or can't take toys...
  • After thinking about this some more, I think you're onto something PH. Let the timed interrupt handle verticals and kick off each scan line.

    That leaves the entire foreground processing for mouse cursors, text overlay, sprites etc.
  • I'm actually thinking of the whole frame. Hsync, vsync, and porches.

    Once that is done, the display happens no matter what the user does with the pixels.

  • jmgjmg Posts: 15,140
    potatohead wrote: »
    I'm actually thinking of the whole frame. Hsync, vsync, and porches.

    Once that is done, the display happens no matter what the user does with the pixels.

    That's a little wasteful of memory, but could be practical for NTSC/PAL monochrome, where memory is not pushed to the limits, and Colourburst handling is not needed (or done separately).


  • potatoheadpotatohead Posts: 10,253
    edited 2015-10-06 20:58
    Actually it's not. Doing it that way also sets the flags and other bits needed for dynamically drawn displays. Those are as lean as you can get.

    In many cases only partial, or a few scanline of buffer would be needed.

    Or a user might just scan a region of HUB memory to serve as a tile or bitmap.

    A few bits of standard code and constant data, including timing, define and display an empty frame. User is left with pixel clock, depth and source decisions much like we do on P1 now.

    On P1, waitvid latched these critical events, making video work fairly easy and robust. Hot did a lot more. On this one, the timer interrupt gets us to the same basic place, IMHO, and I'm itching to write code... almost there.

  • potatoheadpotatohead Posts: 10,253
    edited 2015-10-06 21:37
    Basically, one puts the frame sync pixels in the cog, ideally computing them once per frame for variations in interlace, porches, pixel clocks, etc...

    Hub memory is all pixels, tiles and bitmaps as needed. Can be full on buffer, which is expensive, or tiles, sprites, or procedural graphics, all of which are much leaner, or can be, depending on what people actually do.

    I kind of want to get to where we've got a thing others can drop pixel code into and go from there. Maybe supply a few known, can't miss options.

  • Yeah I like it. Look forward to seeing whatever you come up with.

    Would you do the porch/sync transitions as timed interrupts as well, to allow max foreground processing? Or would you use a version of the streamer to handle these in between active video, even though its overkill
  • I don't know yet. Probably default to what eris most robust.
Sign In or Register to comment.