Speed optimization (framebuffer scrolling)

[HenrikOlsson]

Bank 6 (or 7) doesn't work at all. I don't know what it's doing exactly. It does display the text but it does not scroll it.

Bank 5 (or 25) works - sort of.
I can scroll it left OR right continously without issues but when I change direction whatever is in the non visible part the buffer comes back on to the display shifted down by one row - at least I think that's what happening.

But it's fast, that's for sure.
* Mine was like 7ms or something like that
* tumblweeds was more than twice as fast at 3ms.
* Richards comes in at 0.2ms - amazing.

Mine and tumbleweeds simply scrolls the display, anything that's shifted outside of the buffer is lost while Richards rotates it so they're not exactly the same.

/Henrik.

[tumbleweed]

On most of the Q family the SFR registers are in banks 0-4, and the start of user ram is in bank 5.
That's where the access bank is (0x500-0x55F). The other part of the access bank is at 0x460-0x4FF, but that's for the fast SFR registers so you can't use that.
So, the "default" setting for 'banksel' should be 5 and not 0.

If you use the MOVFF instruction both the source and destination must be in the first 4K of ram space.
If either are outside that you need to use MOVFFL, which is a three-word instruction so it's more code (and slower) than MOVFF.

The K42/K83 force you to use MOVFFL to access SFR registers outside the access bank since on those the SFR regs are at the very top of ram.
That's one reason to skip the K42 and use the Q43 instead.

[richard]

I can scroll it left OR right continously without issues but when I change direction whatever is in the non visible part the buffer comes back on to the display shifted down by one row - at least I think that's what happening.

i expected to have had the buffer cleared out and reset before a direction change . however that sort of behavior is unanticipated

* Richards comes in at 0.2ms - amazing.

i get 0.1mS , maybe my oscilloscope is off



one of my clients sent me a test jig for q43 chips yesterday. i need to get into them soon i guess
no more excuses

@tumbleweed for confirming what i thought

[richard]

just for interest i tried my code on the st7920 buffer for rows 8 to 15 for the full 16 byte width of course



works as expected even when direction reversed midstream

[richard]

or a window to scroll
[i just can't help myself]

[HenrikOlsson]

i get 0.1mS , maybe my oscilloscope is off

Your scope is fine. All my quoted measurements are for my current configuration with 81 displays, so roughly double your measurement.

works as expected even when direction reversed midstream

It clearly does. Do you have a non visible are in the buffer? I can't see how it would matter but again, in my system it does weird things with what's outside the actual display.

The scrolling window was cool!

[richard]

Do you have a non visible are in the buffer?

no , i'm using a pointer into the the actual frame buffer of the display so i can't hide any data.
its vital that -
the width is in whole bytes ie for a 128x64 display thats 16 bytes
if i had a hidden byte each end then it would be 18
if you are short or long then the data will appear to move up or down at the wrap around
this may be clearer and can be applicable anywhere

note bank dependence has been eliminated

   
    width  con 128     ;display buffer width  and 
    height con 64      ;               height
    bcnt       VAR BYTE  
    dcnt       VAR BYTE   
    WindowWidth   CON 5     ;window is 5 bytes wide    scrolling window
    windowHeight  CON 8         ;window is 8 bits high             "     "
    @windowPad     =     _width/8 - _WindowWidth  ;number of bytes to get to start of next row
    @dspbuff =    _fbr+16*8+5       ;window start address row8 byte 5
;  fbr is the display frame buffer
rotate_r:  ' pic18
asm
    banksel _bcnt  ;ROW
    movlw   _windowHeight    
    movwf   _bcnt
    movlw   high (dspbuff)  ;BOTTOM OF BUFFER
    movwf   FSR0H    
    movlw   low  (dspbuff)
    movwf   FSR0L
    movlw   low((_WindowWidth )*_windowHeight-1) ;TOP OF BUFFER
    ADDWF   FSR0L 
    movlw   high((_WindowWidth )*_windowHeight-1)    
    ADDWFC  FSR0H
    MOVLW   _WindowWidth 
RROW
    banksel _dcnt 
    movwf   _dcnt        ;display
    bcf     STATUS, C
Rcol
    rrcf    POSTDEC0 ,f  ;PER display
    DECFSZ  _dcnt ,F
    BRA     Rcol
    BNC     RBNC
    bsf     PLUSW0,7     ;max would be 127 to use plusw
RBNC 
    banksel _bcnt 
    DECFSZ  _bcnt ,F
    BRA     RROW
    ;banksel 0
    return
endasm






rotate_l:  ' pic18
asm
    banksel _bcnt              ;ROW
    movlw   _windowHeight 
    movwf   _bcnt
    lfsr    0, dspbuff
LROW
    MOVLW   _WindowWidth 
    banksel _dcnt 
    movwf   _dcnt         ;
    comf    WREG
    incf    WREG
    bcf     STATUS, C
Lcol
    rlcf    POSTINC0 ,f   ;
    DECFSZ  _dcnt ,F
    BRA     Lcol
    BNC     LBNC
    bsf     PLUSW0,0       ;max  would be 127 to use plusw
LBNC 
    movlw   windowPad
    addwf   FSR0L ,f
    bnc     Lrnc
    incf    FSR0H ,f
Lrnc    
    banksel _bcnt 
    DECFSZ  _bcnt ,F
    BRA     LROW
    banksel 0
    return
endasm

ps window is rotate_l only . not done rr yet

[HenrikOlsson]

Aha, then that might be it as I have 81 displays so buffer is 83 bytes wide.
But again, it does not move down as it wraps around, only as it changes direction.