P2 DVI/VGA driver

roglohrogloh Posts: 1,461
edited 2019-11-22 - 00:15:34 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.

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?
    Formerly known as TonyB
  • 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,461
    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,328
    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.
    Formerly known as TonyB
  • 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,461
    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,825
    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. )


    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • 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:
    Melbourne, Australia
  • 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,461
    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.
Sign In or Register to comment.