* Handle horizontal scrolling to the left.
* On STE, there're 2 registers that can scroll the line :
* - $ff8264 : scroll without prefetch
* - $ff8265 : scroll with prefetch
* Both registers will scroll the line to the left by skipping the amount
* of pixels in $ff8264 or $ff8265 (from 0 to 15).
* As some pixels will be skipped, this means the shifter needs to read
* 16 other pixels in advance in some internal registers to have an uninterrupted flow of pixels.
* These 16 pixels can be prefetched before the display starts (on cycle 56 for example) when using
* $ff8265 to scroll the line. In that case 8 more bytes per line (low res) will be read. Most programs
* are using $ff8265 to scroll the line.
* When using $ff8264, the next 16 pixels will not be prefetched before the display
* starts, they will be read when the display normally starts (cycle 56). While
* reading these 16 pixels, the shifter won't be able to display anything, which will
* result in 16 pixels having the color 0. So, reading the 16 pixels will in fact delay
* the real start of the line, which will look as if it started 16 pixels later. As the
* shifter will stop the display at cycle 56+320 anyway, this means the last 16 pixels
* of each line won't be displayed and you get the equivalent of a shorter 304 pixels line.
* As a consequence, this register is rarely used to scroll the line.
* By writing a value > 0 in $ff8265 (to start prefetching) and immediatly after a value of 0
* in $ff8264 (no scroll and no prefetch), it's possible to fill the internal registers used
* for the scrolling even if scrolling is set to 0. In that case, the shifter will start displaying
* each line 16 pixels earlier (as the data are already available in the internal registers).
* This allows to have 336 pixels per line (instead of 320) for all the remaining lines on the screen.
* Although some programs are using this sequence :
* move.w #1,$ffff8264 ; Word access!
* clr.b $ffff8264 ; Byte access!
* It is also possible to add 16 pixels by doing :
* move.b #X,$ff8265 ; with X > 0
* move.b #0,$ff8264
* Some games (Obsession, Skulls) and demos (Pacemaker by Paradox) use this
* feature to increase the resolution, so we have to emulate this bug, too!
* So considering a low res line of 320 pixels (160 bytes) :
* - if both $ff8264/65 are 0, no scrolling happens, the shifter reads 160 bytes and displays 320 pixels (same as STF)
* - if $ff8265 > 0, line is scrolled, the shifter reads 168 bytes and displays 320 pixels.
* - if $ff8264 > 0, line is scrolled, the shifter reads 160 bytes and displays 304 pixels,
* the display starts 16 pixels later.
* - if $ff8265 > 0 and then $ff8264 = 0, there's no scrolling, the shifter reads 168 bytes and displays 336 pixels,
* the display starts 16 pixels earlier.
alexh wrote:I don't know. I just googled it and found that comment section in the STeEM code base.
I would imagine that it is 1-shot, maybe not even per VBL. But I'm not an Atari ST programmer.
npomarede wrote:As for the effect, you need to do it on each VBL, but it's not necessary to do it on each scanline. Once started, it will continue on the rest of the screen for the current VBL.
Code: Select all
- to change $ff8264/$ff8265 anywhere, including while display is ON in the middle of the line ? Are the next lines modified in that case
- to check the delay allowed between the 2 writes to $ff8264/$ff8265 ? Do they need to be close enough so that the shifter didn't display more than 16 pixels ? Or does it work if there e.g 60 cycles between the 2 moves ?
MasterOfGizmo wrote:I found this routine that is supposed to trigger the same effect.
The first sets 64+65 using one word access and then clears 64. This is not what you explained here as well ...
npomarede wrote:who is "you" ? What you described is exactly what is described in the Hatari's source comments and what Evil posted above in this thread. I don't see any difference.
Users browsing this forum: No registered users and 9 guests