AGA FMODE & BPLCON1 Scrolling
 

Morning!

I've since moved onto getting some sort of hardware scrolling working with some tile data, and I've got something moving:

https://www.the-snakepit.co.uk/asset...e_1x_debug.gif

Obviously I have some background restore and offset issues with the player but that's easy to fix so we'll ignore that for now. If anyone's following the other threads, another addition is I've also added two more layers of parallax with the two rows of clouds sprites at the top.

As you can see, I have some sort of raster time analysis going on with the colour bars which for this top example is running about a half of the way down the screen.

This is FMODE 1, with all 8 sprites (in attached mode) which are multiplexed vertically into 4 strips, covering the whole screen using SSCAN2.

Now because I've read several times that you can't use FMODE 4 with all 8 sprites, and hardware scroll I thought I'd try it anyway:

https://www.the-snakepit.co.uk/asset...e_4x_debug.gif

The raster lines have halved when I switch to this mode, and it all still works.

So my question for tonight is, how is this possible if after all of the discussions I've seen here, you can't do this. Or, is it because I'm only using a 288x256 window with a 320x256 screen buffer? Either way, there's a definite decrease in raster time being spent.

Initial copper setup looks like this:

With DDFSTRT=$38 you don't lose sprites, but then try to scroll the screen 63 pixels with BPLCON1..
You will understand that you would be forced to use a view to much on the righ of the screen.

Cool, thanks for the info Ross, so it's to do with scrolling using the finer half and quarter pixel modes where the problems start arising.

On that note, I'm good to proceed with just using the old full pixel scroll with this setup... and nothing will go bang and there'll be no nasty surprises down the line? ;)

No, nothing to do with quarter pixel scroll :)
With FMODE=3 you have a fetch of 64 pixels at a time and you need to use 64 values in BPLCON1 for the usual lo-res fine pixel scroll.
Then you need to change the value of the bitplane pointers and you can only do it in 8-byte increments (because you have to be aligned with the fetch).

@daniel which means that you need the first fetch to be 64 pixels *before* $38, and that's where you lose the sprites..

Right, I think I understand the 64 pixels beforehand logic, and the 8 byte for the bitplane pointer adjustment... but that just makes me more confused as to why this seems to be working and scrolling around as expected.

What I’m doing is a legit solution? If so then I’m gonna leave it because of the extra free time I’m getting. If it’s wrong, then why does it appear to work as I expect it to?

Yes, it might be useful to know why you've not actually noticed any problems. The reason for that is that your example doesn't actually show any bitplane GFX in the left most part of the screen. The right side of the screen (64px after the left edge onwards)* will not have issues, only the left most 64 pixels* will.

Edit: I changed this to be a reply to your post, I hadn't seen it when I wrote this but it happens to be perfectly in sync with your question ;)

*) in your case it's actually 48 pixels because you show only 288px wide, it's the 64 pixels after the fetch that will have issues.

Thanks for the insight roondar, I appreciate people taking the time to answer my dumb questions.

Are you suggesting that once I fully scroll my bitplanes across the left side of the screen I should start seeing issues with the bitplane data?

https://www.the-snakepit.co.uk/asset...ane_scroll.png

This above has been scrolled all the way across and looks and scroll fine? Or will things start to get hairy when I scroll back the other way?

:confused *sigh* Maybe it's time I took another break from my ASM nightmare and got back to some of my other high-level projects.

The only thing which I can compare writing this stuff to in terms of massive delight when it goes right and huge disappointment and dejection when it doesn't is learning how to play the guitar. You must stick to it and push through the hard times I guess.

Yes, that's what I'd expect. Oh and by the way, your questions aren't dumb - Amiga HW is tricky and all of us had similar lack of understanding at one point. You're already further along than I ever got back in the 1990's :great

Basically there should be values of BPLCON1 where you get the wrong result when scrolling (plus GFX in the leftmost part of the screen). However, I don't quite know what the issues should look like as I've not tried this. Nor do I know if FS-UAE correctly emulates this.

But I do know this is a real problem (the HW should not be able to display the data as it's not fully fetched yet). Perhaps others can give additional insights here.

Only COLOR00 on the left side (sprites visible normally).

Ah, of course!
It's just that the bitplanes are delayed by x pixels when using BPLCON1, this hasn't changed from OCS/ECS. Only the maximum delay has. So if you delay by 64 pixels and have a DDFSTRT of $38, you'd get 48 empty pixels (actually 64, but the display width here = 288 pixels so the first 16 are cut off regardless).

The following workaround should be possible:

- Set the DDFSTRT values to allow display DMA fetch the extra 64 pixels and 8 sprites
- Enable variable beam counters, program a screen mode which replicates PAL/NTSC timing
- Program horizontal sync to start/end 64 pixels later as expected, shifting the screen 64 pixels to the left

Coding scrolling on AGA can be a nightmare ... but yes, once it works it feels like it was worth the many bad hours and days ... almost :-)

Whatever you do, test on real hardware as FS-UAE does not always handle AGA-scrolling right. There are issues with subpixel scrolling and with datafetch in 2x and 4x-fetchmodes: FS-UAE is fine with bitplane-pointers at addresses dividable by 2 or 4, whereas real hardware is not and will output repeated bitmap patterns.

Yes, this was exactly what happened when I ran my engine on real hardware: FS-UAE didn't handle the different fetch modes correctly, which is why it looks fine on these videos.

I think it's fixed in the latest version of WinUAE and the beta version (4) of FS-UAE, but yes, it was a bit of a downer when I ran it on my A4000.