VDU 23,7 behaviour change

VDU 23,7,extent,direction,movement,0,0,0,0,0

On a RiscPC (tested on RO5.23 and 3.71), using this to scroll the screen when the backbuffer is selected for VDU, causes the backbuffer to scroll onto the frontbuffer. On a Pi however it doesn’t appear to do anything.

Repro

*SHADOW 1
MODE 13
FOR A%=0 TO 31:PRINT TAB(0,A%);"Front: ";A%;:NEXT
*FX 112,2
FOR A%=0 TO 31:PRINT TAB(0,A%);"Back: ";A%;:NEXT
FOR A%=1 TO 20:VDU 23,7,1,7,1:WAIT:WAIT:NEXT
*FX 112,1

Yes. Hardware frame buffers (VIDC, OMAP…) can roll around. The Pi goes via the GPU so behaviour is a bit different. I think (though expect Jeffrey to correct me) that the framebuffer on the Pi is more like a sliding window in a larger memory area, so what is pushed off the bottom won’t appear at the top (or vice versa).

There are actually three different types of framebuffer:

• VIDC style framebuffers, where you have the start, end and init addresses, and the DMA wraps around within the buffer
• “Flat” framebuffers where you just have the init address
• 2D framebuffers where you specify the X,Y coordinates within a 2D surface/texture

On VIDC machines, the fact that the OS doubly-maps screen memory means that the screen can be scrolled in any direction, including wrapping around, without needing to move any pixels around.

The Pi falls into the 2D framebuffer category. To support multiple screen banks and scrolling we create a surface that’s taller than the displayed area. So we can scroll up and down within the extent of that surface, but we can’t scroll sideways, and we can’t wrap around.

All other machines have “flat” framebuffers, which allow for scrolling vertically and horizontally, but again there’s no support for wrap around (although there is some scope for faking the wrap-around by using multiple overlays, for the platforms with overlay-based GPUs)

On platforms which lack VIDC-style hardware scrolling, when asked to scroll the screen the OS typically falls back to the behaviour it uses when the screen has been redirected to a sprite, which is to copy/move pixels around, rather than adjust the DMA addresses of the screen. So if you scroll the screen up then any pixels which vanish from the top will be lost forever, and the “new” pixels at the bottom will be cleared to the background colour (see HardScrollUp).

Bit 6 of the mode flags or the “Supports hardware scroll” flag of GraphicsV 8 can tell you whether the OS is going to use hardware scrolling or not.

For a while I’ve been thinking that it would be good to allow the OS to support limited hardware scrolling on modern systems. E.g. when scrolling the screen up, do a hardware scroll until you hit the limit of screen memory, and then reset back to the start of screen memory and copy the relevant pixels up. When you’re scrolling large amounts of text (e.g. *help) this should make things a lot better. But no promises on when I’ll do that, or exactly what restrictions may be in place!

Yes. Hardware frame buffers (VIDC, OMAP…) can roll around. The Pi goes via the GPU so behaviour is a bit different.

Ah, so in layman’s terms the reason hardware scrolling is disabled is because it might wrap and GPU’s don’t support wrapped buffers. Now that I know it’s disabled, I probably just need force the hardware scrolling bit when my GraphicsV driver takes over…modifies code…yep, that works.

On platforms which lack VIDC-style hardware scrolling, when asked to scroll the screen the OS typically falls back to the behaviour it uses when the screen has been redirected to a sprite, which is to copy/move pixels around

That explains the black bar that appears then.

For a while I’ve been thinking that it would be good to allow the OS to support limited hardware scrolling on modern systems. E.g. when scrolling the screen up, do a hardware scroll until you hit the limit of screen memory, and then reset back to the start of screen memory and copy the relevant pixels up. When you’re scrolling large amounts of text (e.g. *help) this should make things a lot better. But no promises on when I’ll do that, or exactly what restrictions may be in place!

Yes, scrolling text is painfully slow on the Pi – it’s like using my A310…very nostalgic. I’m sure there are more pressing things to worry about than hardware scrolling support though.

Yes, scrolling text is painfully slow on the Pi

I noticed. Thankfully we have a zippy alternative – TaskWindows.