English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 28 February 2021, 13:46   #1
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
OS Friendly AGA FMODE Issues

I'm exploring some OS friendly AGA functionality and coming unstuck with FMODE; if I up the FMODE past 1x the bitplanes go awry. I have attached 3 grabs of 1x, 2x, and 4x to demonstrate what I am seeing.

The framebuffers are allocated with AllocBitMap and the BMF_DISPLAYABLE flag. I have confirmed all bitplane pointers are on 8 byte boundaries and the framebuffers are multiples of 64 wide.

Is there a correct way to define FMODE when creating a Screen via Tags or similar? Debugging the OS generated copperlist I see fmode being set to 0 by default and so I'm currently jamming a value into the fmode register via the user copperlist, and it feels not very OS friendly...

Also does the FMODE affect anything other than DMA? Do I have to take any extra considerations when blitting for example?

FYI I am just starting out with Amiga dev so be kind if I'm missing something obvious or being naive
Attached Thumbnails
Click image for larger version

Name:	aga_fmode_1x.PNG
Views:	76
Size:	92.9 KB
ID:	71062   Click image for larger version

Name:	aga_fmode_2x.PNG
Views:	64
Size:	86.3 KB
ID:	71063   Click image for larger version

Name:	aga_fmode_4x.PNG
Views:	64
Size:	75.7 KB
ID:	71064  
bork is offline  
Old 28 February 2021, 14:18   #2
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 1,003
I'm not programmer, but for what reason You are trying mess with FMODE in Lo-Res 4bit (or less) screens?
Solo Kazuki is offline  
Old 28 February 2021, 14:46   #3
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,265
You’ll need to adjust your modulo too.

Expected value -4 if fmode x2
Expected value -8 if fmode x4

It’s in the Randy Aga programming text.
mcgeezer is offline  
Old 28 February 2021, 15:17   #4
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by bork View Post
I'm exploring some OS friendly AGA functionality and coming unstuck with FMODE; if I up the FMODE past 1x the bitplanes go awry. I have attached 3 grabs of 1x, 2x, and 4x to demonstrate what I am seeing.
Screen bitmaps are allocated with all system limitations in mind, so may I ask why you allocate bitmaps yourself?


Quote:
Originally Posted by bork View Post
The framebuffers are allocated with AllocBitMap and the BMF_DISPLAYABLE flag. I have confirmed all bitplane pointers are on 8 byte boundaries and the framebuffers are multiples of 64 wide.
Ehem. The "framebuffers" you find in Screen->RastPort.Bitmap. No need to allocate anything, and no need to worry about system internals.
Thomas Richter is offline  
Old 28 February 2021, 17:24   #5
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by Solo Kazuki View Post
I'm not programmer, but for what reason You are trying mess with FMODE in Lo-Res 4bit (or less) screens?
I intend to ramp it up to 8-bitplane/256 colours in the longer run; I'm also just poking and learning...
bork is offline  
Old 28 February 2021, 17:32   #6
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by mcgeezer View Post
You’ll need to adjust your modulo too.

Expected value -4 if fmode x2
Expected value -8 if fmode x4

It’s in the Randy Aga programming text.
Thanks for the pointer - I'll try it out.

I did wonder however if there was something a little higher level, like on the screen or window level saying "hey I want the faster AGA data fetch modes please" and it does all the hard work for me?
bork is offline  
Old 28 February 2021, 17:37   #7
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by Thomas Richter View Post
Screen bitmaps are allocated with all system limitations in mind, so may I ask why you allocate bitmaps yourself?
I allocate them as extend them past screen/window dimensions a little for scrolling. As I understood it AllocBitmap with the BMF_DISPLAYABLE flag takes the same system limitations into consideration.

Quote:
Originally Posted by Thomas Richter View Post
Ehem. The "framebuffers" you find in Screen->RastPort.Bitmap. No need to allocate anything, and no need to worry about system internals.
Yah I call them framebuffers as there are two set up for double buffering.
bork is offline  
Old 28 February 2021, 22:01   #8
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by bork View Post
I allocate them as extend them past screen/window dimensions a little for scrolling. As I understood it AllocBitmap with the BMF_DISPLAYABLE flag takes the same system limitations into consideration.
You are confused. BMF_DISPLAYABLE is for displayable bitmaps. But the screen does not display your bitmaps. It displays its own bitmaps, namely screen->RastPort.Bitmap. All you need is a friend bitmap of the screen bitmap and blit that to the screen, e.g. BltBitMap().


If you want the screen to be scrolling (instead of copying your bitmap to the screen bitmap), just make the screen width and/or screen height larger.



Quote:
Originally Posted by bork View Post
Yah I call them framebuffers as there are two set up for double buffering.
For double buffering, use intution/AllocScreenBuffer() and intuition/ChangeScreenBuffer(). DO NOT allocate bitmaps yourself.
Thomas Richter is offline  
Old 28 February 2021, 22:37   #9
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by Thomas Richter View Post
You are confused. BMF_DISPLAYABLE is for displayable bitmaps. But the screen does not display your bitmaps. It displays its own bitmaps, namely screen->RastPort.Bitmap. All you need is a friend bitmap of the screen bitmap and blit that to the screen, e.g. BltBitMap().


If you want the screen to be scrolling (instead of copying your bitmap to the screen bitmap), just make the screen width and/or screen height larger.




For double buffering, use intution/AllocScreenBuffer() and intuition/ChangeScreenBuffer(). DO NOT allocate bitmaps yourself.

I do use AllocScreenBuffer and ChangeScreenBuffer, but they wrap a Bitmap provided to a screen created with SA_Type, CUSTOMSCREEN, and SA_BitMap, <my_bitmap created with BMF_DISPLAYABLE> and the 2nd created with that custom Bitmap as a friend. My screen does display the custom bitmaps and they display/swap as expected (logic was taken from doublebuffer.c). Everything works as expected with FMODE at 1x. If this is however the source of the issues I will change it out and test!

*UPDATE*
Changing over to larger Screen allocated bitmap and AllocScreenBuffer with SB_SCREEN_BITMAP and SB_COPY_BITMAP behaviour is identical to previous implementation also with FMODE changes. However a new issue is introduced when I try to call ScrollVPort(); at FMODE 4x I get major display corruption and on FMODE 2x I get major display corruption along with:

WARNING: BPL fetch at hpos 0xE1!
WARNING: BPL fetch conflicts with strobe refresh slot 1!
WARNING: BPL fetch conflicts with strobe refresh slot 3!
WARNING: BPL fetch conflicts with strobe refresh slot 5!

I think my problem is letting Intuition know I want to use higher FMODEs on a low res screen so it can build it into the generated copperlists. At present it's blind to it as the generated/merged copperlist has this entry before DIWSTRT (I tried stupid hacks like manually setting custom->fmode before creating the screen/calling MakeScreen etc. to see if that was a thing):

L000C030: $0000104c: $01fc,$0000; FMODE = $0000

This gets overridden later by my user copperlist to a different value and hence all the blowups. I also cannot address BPLxMOD as mcgeezer recommended because the merged copperlists introduce their own values further down the chain.

The reason I think there should be a solution is a comment from the CD32 Developer Notes:

"A low-resolution, 8-bitplane display does not involve any cycle stealing from the CPU assuming that the OS has been left in place so that the higher fetch-bandwidth modes of the system are in effect."

Last edited by bork; 28 February 2021 at 23:46.
bork is offline  
Old 01 March 2021, 07:51   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by bork View Post
Is there a correct way to define FMODE when creating a Screen via Tags or similar? Debugging the OS generated copperlist I see fmode being set to 0 by default and so I'm currently jamming a value into the fmode register via the user copperlist, and it feels not very OS friendly...
Normally you shouldn't need to set FMODE yourself. The OS does. It will use 4x even on lowres modes.
This only requires AGA modes to be activated, which is done upon startup by SetPatch command.
meynaf is offline  
Old 01 March 2021, 09:55   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by bork View Post
I do use AllocScreenBuffer and ChangeScreenBuffer, but they wrap a Bitmap provided to a screen created with SA_Type, CUSTOMSCREEN, and SA_BitMap, <my_bitmap created with BMF_DISPLAYABLE> and the 2nd created with that custom Bitmap as a friend. My screen does display the custom bitmaps and they display/swap as expected (logic was taken from doublebuffer.c). Everything works as expected with FMODE at 1x. If this is however the source of the issues I will change it out and test!
I'm sorry. Do you or don't you allocate bitmaps yourself? You shouldn't, because AllocScreenBuffer() does this for you.


No, you don't worry about FMODE. That is the system to care about.


Quote:
Originally Posted by bork View Post
I think my problem is letting Intuition know I want to use higher FMODEs on a low res screen so it can build it into the generated copperlists.
You don't generate copperlists your own, and you please use the FMODE the system provided for the screen mode you selected. If you work around or bypass intuition and/or graphics, all kinds of odd problems will arise. The copper is not your concern, do not worry about it.
Thomas Richter is offline  
Old 01 March 2021, 10:37   #12
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,980
I'd advise to not mix OS and non OS stuff.

In the end, it always leads to tears.
Steril707 is offline  
Old 01 March 2021, 10:54   #13
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Quote:
Originally Posted by steril707 View Post
i'd advise to not mix os and non os stuff.

In the end, it always leads to tears.
+1
roondar is offline  
Old 01 March 2021, 14:20   #14
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by Thomas Richter View Post
I'm sorry. Do you or don't you allocate bitmaps yourself? You shouldn't, because AllocScreenBuffer() does this for you.
I used to. Now I don't on your advice.

Quote:
Originally Posted by Thomas Richter View Post
You don't generate copperlists your own, and you please use the FMODE the system provided for the screen mode you selected. If you work around or bypass intuition and/or graphics, all kinds of odd problems will arise. The copper is not your concern, do not worry about it.
I created a user copper list for the blue gradation in the background and I'm pretty sure that's supported functionality. This is set to viewPort->UCopIns then merged into the system copperlists on a call to MakeScreen.
bork is offline  
Old 01 March 2021, 14:24   #15
bork
Registered User

 
Join Date: Jan 2021
Location: Birmingham, UK
Posts: 7
Quote:
Originally Posted by Steril707 View Post
I'd advise to not mix OS and non OS stuff.

In the end, it always leads to tears.
Yep I'm totally on board - I just thought FMODE was maybe a thing you could tweak with the OS's blessing. It seems very clear that it is not and I'm gonna leave this one be!

Really appreciate everyone who has weighed in.

As I said at the start, I'm just starting out with Amiga dev and we have to learn somehow... and in my experience it's by lots of mistakes
bork is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
AGA FMODE & BPLCON1 Scrolling DanielAllsopp Coders. Asm / Hardware 10 24 February 2021 12:56
FMODE 0 to FMODE 1 Auscoder Coders. Asm / Hardware 11 28 January 2020 16:37
FMODE=2 is useless? Toni Wilen Coders. Asm / Hardware 8 01 May 2017 22:07
Making Silly Putty AGA friendly? TenLeftFingers support.Games 15 07 July 2015 11:44
Gauntlet III AGA and HD friendly? XDelusion request.Old Rare Games 4 05 July 2011 21:46

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09063 seconds with 15 queries