P2 DVI/VGA driver

roglohrogloh Posts: 1,927
edited 2020-01-18 - 03:33:15 in Propeller 2
EDIT: Beta driver code now available below:

Original Post:

In preparation for the release of the source for my P2 DVI/VGA driver that we've been discussing in this thread:

http://forums.parallax.com/discussion/170601/all-pasm2-gurus-help-optimizing-a-text-driver-over-dvi#latest

I am providing some preliminary documentation for any feedback. The driver is now getting close to completion and I may be able to modify it slightly if there are obvious things to do that would fit in the remaining space left.

Not everything is currently implemented precisely as defined here yet but I am heading towards this target, so both the code and this documentation is still subject to change if any problems are found or if I make other alterations or add other features resulting from feedback.

Here's the current documentation. It's formatted as 80 column text so it can be printed out using fixed width fonts for easy reading offline (it's too long for a forum post so I had to post it in a zip file).

UPDATE:

Beta Release 0.8b is now available in the attached zip file. It's included documentation supersedes that in the original early driverdoc.zip originally posted here as there have been changes to some registers, to allow better control from high level languages and other optimizations, plus additional features.
«13456

Comments

  • For consistency, would it be better for the region pointers to be right aligned to match the other memory address fields that start from bit 0?
  • Well I had my reasons. I did it like that because thought it would be best to keep the low part for updating region sizes, while region link pointers may not need to change as much or all. In many cases the region size will be 9 bits or less allowing an optimization changing it with sets or setbyte in some cases for animations etc. If I had the region size left aligned I couldn't do this. But it's funny as I thought the same thing when I looked at it. Nice to be neat and tidy, isn't it.
  • rogloh wrote: »
    Well I had my reasons. I did it like that because thought it would be best to keep the low part for updating region sizes, while region link pointers may not need to change as much or all. In many cases the region size will be 9 bits or less allowing an optimization changing it with sets or setbyte in some cases for animations etc. If I had the region size left aligned I couldn't do this. But it's funny as I thought the same thing when I looked at it. Nice to be neat and tidy, isn't it.

    If you right align the pointer, and then use a setq muxq construct as standard, then you get arbitrary region size changes for a consistent instruction count and no need to test for a special 'optimised' case.
    Probably overall smaller and faster code, although I haven't tried writing it.
  • roglohrogloh Posts: 1,927
    edited 2019-10-27 - 00:42:14
    Well I am still considering changing the field placement for maintaining consistency, but I found it was simple for me the way it currently is designed.

    Here's how I crack it open in the driver. When I need to read in a new region I use the current region register as a pointer to the next region (this is called when the region limit scan line count decrements and hits zero in the calling code - not shown). If I arrange the fields in the other way I think it takes more instructions but maybe I can be proved wrong. I get to shift down the next pointer into its place and test for zero in the same instruction which is nice.

    Manipulating 12 bit quantities is not as simple as bytes, words, or 9 bit quantities, but the nibble instructions saved me.
    newregion
                mov     palselect, defcolour    'set default black colour
                shr     region, #12 wz          'check for any more regions?
    if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
    if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
    if_z        mov     videomode, #nullmode
    if_z        ret     wcz                     'and exit if no more regions
    
                setq    #12-1                   'read region parameters from hub
                rdlong  region, region   
                getnib  regionlimit, region, #2
                rolbyte regionlimit, region, #0
    ...
    
  • TonyB_TonyB_ Posts: 1,415
    edited 2019-10-27 - 02:27:40
    If region pointer right aligned:
    newregion
                mov     palselect, defcolour    'set default black colour
                test    region, ptrmask  wz     'check for any more regions?
    if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
    if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
    if_z        mov     videomode, #nullmode
    if_z        ret     wcz                     'and exit if no more regions
    
                setq    #12-1                   'read region parameters from hub
                rdlong  region, region   
                mov     regionlimit, region
                shr     regionlimit, #20
    ...
    ptrmask     long    $000_FFFFF
    
    region could be used as hub address without clearing size.
  • rogloh wrote: »
    Well I am still considering changing the field placement for maintaining consistency, but I found it was simple for me the way it currently is designed.

    Here's how I crack it open in the driver. When I need to read in a new region I use the current region register as a pointer to the next region (this is called when the region limit scan line count decrements and hits zero in the calling code - not shown). If I arrange the fields in the other way I think it takes more instructions but maybe I can be proved wrong. I get to shift down the next pointer into its place and test for zero in the same instruction which is nice.

    Manipulating 12 bit quantities is not as simple as bytes, words, or 9 bit quantities, but the nibble instructions saved me.
    newregion
                mov     palselect, defcolour    'set default black colour
                shr     region, #12 wz          'check for any more regions?
    if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
    if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
    if_z        mov     videomode, #nullmode
    if_z        ret     wcz                     'and exit if no more regions
    
                setq    #12-1                   'read region parameters from hub
                rdlong  region, region   
                getnib  regionlimit, region, #2
                rolbyte regionlimit, region, #0
    ...
    

    With the fields swapped I think I can match it:
    newregion
                mov     palselect, defcolour    'set default black colour
                zerox    region, #19 wz          'clear region size, check for any more regions?
    if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
    if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
    if_z        mov     videomode, #nullmode
    if_z        ret     wcz                     'and exit if no more regions
    
                setq    #12-1                   'read region parameters from hub
                rdlong  region, region   
                getword  regionlimit, region, #1
                shr regionlimit, #4
    ...
    
    [/quote]
  • Hey I quite like your solution AJL to this with the zerox. It takes the same instructions as I have, while Tony_B's adds that overhead mask. If I used that mask elsewhere it would be okay, but I don't have/need that mask yet, but perhaps might one day. I generally don't mask off those upper pointer bits because I don't need to, and that's why I typically put extra data up there.
  • Now that AJL showed an equivalently fast way to do the 12 region bits from the top, I think I'll change the code and documentation to maintain the consistency of pointers in the low part of all the longs. In any high level user code that is configuring the display region sizes/links, it is not that hard to mask and shift to get/set the data fields and having the pointer in the low part is still similarly useful at times, certainly for dereferencing pointers and traversing the linked list stuff anyway. The only minor potential benefit of my current way was for any PASM clients changing the size and there may not be that many cases where it helps too much, so I'll try to change it.
  • roglohrogloh Posts: 1,927
    edited 2019-11-20 - 18:31:55
    Beta driver code is now available! Just pulled an all nighter to get this out. Check the first post. You will need FASTSPIN to build it, otherwise you'll have to extract the PASM component and wrap it yourselves.

    I hope it works out as I need to sleep now so you're all on your own for a bit. Two demos are in the zip along with the main driver, plus documentation. Patch the VGA/TV pins according to your setup or use DVI if you are game...
  • potatoheadpotatohead Posts: 9,988
    edited 2019-11-20 - 23:49:08
    Awesome! Get your sleep. We are gonna play. Hope you know my productivity at work just tanked big time.

    (my post did take, wrong thread. Oh well, I'm leaving both. )


  • Got to see Roger demo this driver today, simply brilliant!
    I already am thinking of all the cool stuff we can do with it.
    Congrats Roger, a real work of art!
    :smile:
  • Cheers Brian. It should come in handy...
  • ozpropdev wrote: »
    Got to see Roger demo this driver today, simply brilliant!
    I already am thinking of all the cool stuff we can do with it.
    Congrats Roger, a real work of art!
    :smile:

    Roger, could you make a short video showing your driver in action?
  • I will see if I can try to do that, Chip. Now I've caught up more sleep I am hoping to work more on it today and see if I can add anything more to the demo too.
  • My J5create hdmi capture dongle doesn't like the P2's hdmi output

    I'm going to pick up a VGA to HDMI converter from our wholesaler this arvo. Then we should be able to capture the higher res stuff too (hopefully)

  • Given we render most data into external HUB memory it would be rather cool at some point with the P2 to develop a capture COG and pathway to extract the scan line information and somehow create a video file from that directly...though USB serial output to a PC will be a bottleneck. Maybe under clocking and writing data to SD card is another option. This will still be a lot slower than external real-time capture though (or just filming the screen with a phone which is obviously the simplest way, but has the lowest quality).
  • Tubular wrote: »
    My J5create hdmi capture dongle doesn't like the P2's hdmi output

    I'm going to pick up a VGA to HDMI converter from our wholesaler this arvo. Then we should be able to capture the higher res stuff too (hopefully)

    There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.
  • Yeah we'll find it eventually. I hope its not too fussy about voltage levels being sent from the dacs. I suspect that its more to do with Sync etc though.

    Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)
  • roglohrogloh Posts: 1,927
    edited 2019-11-22 - 02:21:03
    Tubular wrote: »
    Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)

    Yeah the FleaFPGA Ohm had it's FPGA pins AC coupled with 0.1uF on each of the 8 HDMI pins IIRC. That worked ok for my devices at least, and adds some degree of galvanic isolation, though some voltage spikes could couple straight through.
    cgracey wrote:
    There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.

    I hope so. Your latest 1.5k pullup method (which is my default in the driver) doesn't work on my Dell. I get a picture but some pixel colours are bad, it's colour dependent, though I did see it working okay yesterday on a Philips monitor that Tubular had. The BITDAC levels I tried failed completely on my setup. I believe I tried levels 0001_0000 up to 0111_0000 and nothing really worked. Not sure why it wouldn't unless the slew rate is affected somehow through the BITDAC, or there might be some additional ringing with those settings. I didn't scope it, I don't have the high end scope needed for the HDMI bandwidths.
  • rogloh wrote: »
    Tubular wrote: »
    Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)

    Yeah the FleaFPGA Ohm had it's FPGA pins AC coupled with 0.1uF on each of the 8 HDMI pins IIRC. That worked ok for my devices at least, and adds some degree of galvanic isolation, though some voltage spikes could couple straight through.
    cgracey wrote:
    There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.

    I hope so. Your latest 1.5k pullup method (which is my default in the driver) doesn't work on my Dell. I get a picture but some pixel colours are bad, it's colour dependent, though I did see it working okay yesterday on a Philips monitor that Tubular had. The BITDAC levels I tried failed completely on my setup. I believe I tried levels 0001_0000 up to 0111_0000 and nothing really worked. Not sure why it wouldn't unless the slew rate is affected somehow through the BITDAC, or there might be some additional ringing with those settings. I didn't scope it, I don't have the high end scope needed for the HDMI bandwidths.

    Maybe we just need to carefully match impedance with an external resistor on each pin.
  • Actually when I retested just now with the BITDAC settings I do see a stable DVI picture, but all red and blue colours, no green at all. Would the BITDAC output be different somehow on the green output pins? I get a red/blue picture from 0011_0000 down to 0001_0000, but no green on the birds image.

    When I go to 0100_0000 I get all green/yellow birds but no blue. Its like each channel needs its own separate bit DAC level ....


  • roglohrogloh Posts: 1,927
    edited 2019-11-22 - 04:05:29
    This BIT DAC setting appears to work by centering the hi/lo voltages to the middle of the range. Not sure if that is good for current use though.

    wrpin ##%10110_1011_0100_10_00000_0, a '123 ohm BITDAC for pins

    Update:
    This also worked for me too.
    wrpin ##%10110_1010_0110_10_00000_0, a '123 ohm BITDAC for pins

    This also worked on my Dell at the upper voltage end which is probably better for less current draw with CML.
    wrpin ##%10110_1111_1100_10_00000_0, a '123 ohm BITDAC for pins

  • I'll give those a try.

    Not having luck with the capture of vga via hdmi, so far.

  • potatoheadpotatohead Posts: 9,988
    edited 2019-11-22 - 04:10:55
    Input impedance is supposed to be 100ohms. What is the impedance on the Eval Board?

    At these pixel rates, ringing especially on a longer or marginal cable, could be a factor.

    Also, I posted the Tektronix basic requirements on one of these threads. I do not fully understand them, but it appears minimum swing can be 100mV and as high as 3.3mV. That seems crazy, unless it is all triggering on zero crossings or something.

    I just picked up an HDMI monitor. What's the risk of damage? I guess I am asking what we think allowable experimentation limits are. Anyone really know?

    I also have a short, good quality cable. Figured that would not hurt.

  • I'd wonder if it needs 5V on the 5V pin or maybe I2C comms for HDMI capture device to work...
  • potatohead wrote: »
    I just picked up an HDMI monitor. What's the risk of damage? I guess I am asking what we think allowable experimentation limits are. Anyone really know?

    This may help you decide (excerpt from DVI 1.0 spec). The P2 pins are acting as the Transmitter. If the AVcc voltage on the equipment is 4V there could be issues. I don't think the P2 should hurt the monitor if it is only powered up to 3.3V, it would be the other way around, if anything, but spikes could be an issue.

    dvi1.png
    dvi2.png
    701 x 569 - 190K
    713 x 414 - 135K
  • Rayman wrote: »
    I'd wonder if it needs 5V on the 5V pin or maybe I2C comms for HDMI capture device to work...

    It might want to see the 5V, we are not driving that, but it can be strapped on the breakout (best done via a small resistor first perhaps). I doubt it would need the I2C, that is more for determining the capabilities of the monitor from the P2 side (DDC stuff).
  • Tubular wrote: »
    I'll give those a try.

    Not having luck with the capture of vga via hdmi, so far.

    Don't worry if it doesn't work Tubular, I am heading off to get a tripod so I can try to film my screen without the jerky cam look. But I think basic VGA capture should work fine from the P2, there's not much different there. Try a real PC's VGA output to see if your new VGA to HDMI capture equipment setup works.
  • Guess what... 1 kohm resistor makes my TCL work with HDMI (DVI?)

    Still doesn't make the capture card work tho

    I may get another capture device from altronics.. failing that blackmagic
  • This is back on %%001001
Sign In or Register to comment.