P2 DVI/VGA driver

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).

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,446
    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,325
    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.
Sign In or Register to comment.