BPLCON1 scroll values in HiRes

[Yragael]

Hi guys,


I forgot how the horizontal scroll values (PF2Hx bits in BPLCON1) work in HiRes (bit 15 HIRES of BPLCON0 is set). It seems that the maximum scroll value is 7 Hires pixels ?


$0000 => 0 HiRes pixels shift
...
$0077 => 7 HiRes pixels shift
$0088 => 0 HiRes pixels shift
...
$00FF => 7 HiRes pixels shift



I could not find the info in the HRM ?

[roondar]

That's really odd. I'd expect the playfield shift in hires to work exactly the same as in lores, with both shifting up to 15 lores pixels and neither allowing for shifting in hires pixels (assuming you're using OCS, AGA changes a few things).

This seems to me to be what the HRM means here:

Originally Posted by HRM

You can have up to 15 pixels of delay. In high resolution mode, scrolling is in increments of 2 pixels.

So, I'd expect a shift of $FF to have a 15 pixel lores delay for both playfields. No idea why that's not working...

[ross]

Yes, this is an OCS limit, soft scroll only in low-res increments.
AGA enhance this giving you more granularity (two more bits, the famous quarter pixels scroll).

But it is not a problem at all: ignore the upper bit, do a soft scroll and every 8 increments change the pointers
(not as soft as it could be but not so ugly).

Anyway the same happens also on AGA.
Try to raise resolution in 4x fetch mode and do a 64bits soft scroll: the high bits of BPLCON1 are ignored .
In shi-res you move 4 pixels at a time using the normal bits, fortunately they have added bits for 35ns delay steps
and therefore for the 64bits scroll you use exclusively [the new named] PFxH0-5.

[Yragael]

Originally Posted by ross

Yes, this is an OCS limit, soft scroll only in low-res increments.
AGA enhance this giving you more granularity (two more bits, the famous quarter pixels scroll).

But it is not a problem at all: ignore the upper bit, do a soft scroll and every 8 increments change the pointers
(not as soft as it could be but not so ugly).

Would this not mean setting the bitplanes addresses to odd addresses?

[ross]

Originally Posted by Yragael

Would this not mean setting the bitplanes addresses to odd addresses?

No, because after 8 shift you've exhausted all 16 pixels (you scroll by 2 at a time).

[fstarred]

I ve recently come across this issue about different lores and hires behaviour, so I ve made two simple example of h scrolling with blcon1

https://github.com/fstarred/amiga_pl...scroll_hires.s

https://github.com/fstarred/amiga_pl...scroll_lores.s

Basically as said by Ross, hires scroll by 2 pixels per value, so a value of $77 is the last useful byte if you want to scroll both even and odd bitplanes