Shop OBEX P1 Docs P2 Docs Learn Events
HTDV Component 1920x1080p Display :) — Parallax Forums

HTDV Component 1920x1080p Display :)

BaggersBaggers Posts: 3,019
edited 2013-07-08 06:51 in Propeller 2
Here it is, the first 1080p bitmap display driver!

Yes, I know it's got dot crawl, which I'm assuming is to do with the slower clock speed of the emulator, or maybe Chip could shed some light on what's happening.

I used his Simple 1920x1080p Driver as a base, and modified it to feed it data from a bitmap.

HDTV_1920x1080p.zip

Edit: use the runme.bat to run it ( from PC ) assuming you have P2Prep, and P2Load in your path, if not, they are in my Wireworld demo. don't forget to edit the runme.bat to set your com port for p2prep.

Enjoy.
Baggers! :)
zip
zip
HDTV_1920x1080p.zip
538K

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-12 13:55
    Sounds nice but I can't run it from my Mac until you convert it to use the C-based image loader. :-)
  • BaggersBaggers Posts: 3,019
    edited 2013-05-12 14:27
    David, you can write a little C loader to load the Nature bin file, to 0 in SDRAM, then compile the spin as normal :)

    the SDRAM data should stay valid during the restart of the new program :)
  • David BetzDavid Betz Posts: 14,516
    edited 2013-05-12 14:35
    Baggers wrote: »
    David, you can write a little C loader to load the Nature bin file, to 0 in SDRAM, then compile the spin as normal :)

    the SDRAM data should stay valid during the restart of the new program :)
    Yes, I know I could do that. I need to work on P2 XMM cache drivers though. I guess I'll have to live without seeing it.
  • BaggersBaggers Posts: 3,019
    edited 2013-05-12 14:37
    Ok, no worries ;) I'll have to look into setting up the C stuff sometime soon lol
  • potatoheadpotatohead Posts: 10,261
    edited 2013-05-12 14:40
    Nice!!

    I'm gonna start a C related thread...
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-05-24 15:02
    Can't wait to try it!

    (I was off-line May.8-24 due to wifey enforced vacation, so I only found it now)
    Baggers wrote: »
    Here it is, the first 1080p bitmap display driver!

    Yes, I know it's got dot crawl, which I'm assuming is to do with the slower clock speed of the emulator, or maybe Chip could shed some light on what's happening.

    I used his Simple 1920x1080p Driver as a base, and modified it to feed it data from a bitmap.

    HDTV_1920x1080p.zip

    Edit: use the runme.bat to run it ( from PC ) assuming you have P2Prep, and P2Load in your path, if not, they are in my Wireworld demo. don't forget to edit the runme.bat to set your com port for p2prep.

    Enjoy.
    Baggers! :)
  • BaggersBaggers Posts: 3,019
    edited 2013-05-25 03:50
    No worries Bill :D hope the vacation was a great one!
  • bartgranthambartgrantham Posts: 83
    edited 2013-07-03 14:21
    Just reading the forum and getting excited about the P2 and this thread caught my eye. I have some questions about this, if someone has a moment to answer.

    So 1920x1080x30 == 60M pixels a second ... how is this done? This is on the FPGA dev boards? I was under the impression that the P2 is emulated at 60MHz on those systems, is the PLL on the P2 really capable of doing 1080p?

    If I spring for a DE0 will I be able to play with this while we wait for the P2 to be refabbed?
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-07-03 18:15
    bartgrantham: I think you may require the DE2 for this, but will let baggers or others to reply. The DE0 is limited to 1 cog and 32KB of hub ram although there is a lot that can be done with this.
    Oh, and yes, we are only running at 60MHz while the P2 is expected to conservatively run at 160MHz.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-07-03 20:44
    Yes, it's pretty amazing! We can drive displays like this three COGS down and at basically 1/3 clock speed. Investigate the waitvid instruction and how data is buffered for display. It operates in parallel with the normal processing, and typically we will setup one COG to output the video signal, optionally feed a bitmap to the display, and other COGS to perform operations like sprites and such.

    On this one, Baggers is displaying a picture stored in the external SDRAM. The SDRAM is driven by one COG, the video display driver by another COG.

    If you want to output some color bars, or something really basic, I think you can do that with just one COG. There is time during the video signal to do that.
  • BaggersBaggers Posts: 3,019
    edited 2013-07-04 05:19
    Hi bartgrantham, like Cluso99 and potatohead say, it's on the DE2 emulator, so running at 60Mhz, roughly 1/3rd the expected speed of the finished prop.
    It is only drawing a 4bit image, ie choice of 16 colours per pixel, as it's hard pushed to get data through fast enough at 60Mhz.
    And it's one cog drawing the display, and one cog driving the SDRAM.
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-07-04 05:20
    Hi Baggers, Re: Dot Crawl.

    I have a DE0 board and have noticed some strange timing glitches while running my own software.
    I haven't been able to quantify exactly what's going on but like you have put it down to the emulator.
    One experiment was generating composite video without using the internal video function.
    In between the sync pulses I am running a custom byte code interpreter and each snippet falls well short of the sync pulse window ,and yet I get intermittent glitches typical of timing overruns?
    Even with the glitches I am doing a lot of stuff with 1Cog & 32K !
    Cheers
    IMAG0003.jpg
    1024 x 1710 - 176K
  • BaggersBaggers Posts: 3,019
    edited 2013-07-04 07:57
    Hi ozpropdev,

    Could it be because of multi-threaded hub delay slots being missed?

    Nice space invaders display.

    By the way, just out of curiosity, why did you generate a composite video, without the internal video functionality?
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-07-04 17:32
    Hi Baggers,
    In my Prop2 Invaders I am not using the multi tasking mechanism, its all in 1 thread.
    There are 2 reasons why I didn't use the internal video function.
    1. Is my lack of knowledge of its modes and operation (No documentation)
    2. I understand (possibly wrongly) that using the WAITVID instructions to generate the sync stuff would not allow me to do my stuff in between.
    POLVID looks like what I need but without more info on the VID stuff I can't use it.
    I am controlling the DAC's manually for video and sound!
    It's a bit tricky but no major headaches yet!
    It has been a great way of learning all the new Prop2 instructions anyway.
    When I've got it up and running properly I'll post the source on the forum.
    Cheers
  • potatoheadpotatohead Posts: 10,261
    edited 2013-07-04 20:31
    Well, we do have documentation. It's just not very verbose, but the modes and operation are documented for us. I'll go and find the link and post back a bit later in the evening. Chip has been updating a Prop 2 document, and some users are making PDF files out of it too. We are using that, and code as our reference.

    Have you read those files yet?

    Truth is, you can do a LOT while the video generator is writing out a scan line. Generally, it is possible to buffer up an entire scan line, leaving the CPU free to do other things while waitvid is writing it to the screen.

    The video commands are double buffered, meaning you can set one up the moment you can, and it's buffered while the prior one is drawing. Break whatever you want done in to chunks, and issue the required waitvids as you need to. So long as they don't exceed the time of the last one, you are good to go.

    Generally speaking, a scan line consists of a few waitvids, or maybe just one to do sync and a porch (border), then one for the scanline. The current emulation is so fast, you can often fill your scan line buffer before the beam even leaves the porch! That is true for a simple bitmap, meaning there is time to draw on the fly for simple things. If you need more time, you can double buffer the scan lines and be drawing into one, while the prior one is being rendered to the screen too.
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-07-04 22:01
    Hi Potatohead
    I have been dissecting the NTSC driver demo this afternoon and I think I am starting to get a handle on it now.
    I was a bit confused with WAITVID and thought it was like WAITCNT and froze while processing.
    Its making sense now.
    Now I can get some sleep....
    Cheers
  • bartgranthambartgrantham Posts: 83
    edited 2013-07-08 00:29
    Thanks for the information, guys. This is really quite amazing! Looking at the code and comparing it to the unofficial P2 documentation at www.rayslogic.com it appears that you're using the STR4_RGBI4 mode. Is it possible that we'll be able to use the STR32_SRGB26 (full-color) mode on the shipping hardware? It would be a serious challenge to keep the pixel buffer full, you'd have to split it into at least 4 calls if not more. And you wouldn't have much time in between. Still, it would be so much fun!
  • BaggersBaggers Posts: 3,019
    edited 2013-07-08 06:51
    No worries :D I'm hoping it'll be fast enough, Chip said a while ago it will be, so I don't doubt it. it will be a push though to keep it fed with data, and updating the screen would be slow, as most of the bandwidth would be eaten by drawing the thing, maybe just used for static images, or in applications where it doesn't matter how fast the screen is updated.
    I wouldn't use it for a game, for example, except maybe the main menu page.
Sign In or Register to comment.