OS3.x - Open a screen with 1x bandwidth

[dissident]

Again something special.

Is there a smart way to open a screen on OS3.x with the 1x bandwidth?

The only solution I know is poking in the graphics base like this:

  move.l	_GraphicsBase,a6
  move.b	#BANDWIDTH_1X,gb_MemType(a6)

And after that open the screen. But you have to disable multitasking with Forbid() to be sure that the bandwidth won't be changed.

Not very system friendly. I did some investigations in the autodocs, but did not find a way to change the bandwidth, after the screen is opened or before with a special tag. Looking in the vieport/viewport extra structure didn't help.

[dissident]

Do you have any hints for me, Thomas Richter?

[Ernst Blofeld]

Originally Posted by dissident

Do you have any hints for me, Thomas Richter?

You need to say his name three times for him to appear.

[aros-sg]

Maybe create your own screen bitmap with manually allocated planes that are misaligned (address multiple of 2, but not 4 or 8) such that only 1x is possible. And then open screen with custom bitmap (SA_Bitmap tag).

[dissident]

Originally Posted by aros-sg

Maybe create your own screen bitmap with manually allocated planes that are misaligned (address multiple of 2, but not 4 or 8) such that only 1x is possible. And then open screen with custom bitmap (SA_Bitmap tag).

Not a bad idea. I guess I have to explain what should be the purpose of this screen. It‘s part of a display downgrader to get BPL1MOD / BPL2MOD to 0 values. I doubt that the system is smart enough to detect misaligned bitmaps. There must be a reason for the global entry in the graphics base for the bandwidth.

[Thomas Richter]

Originally Posted by Ernst Blofeld

You need to say his name three times for him to appear.

Not really, but I was busy with PCI workings and finish a driver for PCI-based S3 graphics cards...

No, the FMode is nothing the Os allows you to set or play with. Your best option is probably BestModeID() of graphics to request modes with certain properties. However, what exactly is the application here?

[aros-sg]

Originally Posted by dissident

Not a bad idea. I guess I have to explain what should be the purpose of this screen. It‘s part of a display downgrader to get BPL1MOD / BPL2MOD to 0 values.

Open screen with a width which is multiple of 64?

I doubt that the system is smart enough to detect misaligned bitmaps. There must be a reason for the global entry in the graphics base for the bandwidth.

It needs to be smart enough, otherwise it would break old software. OpenScreenTagList (-> SA_Bitmap) exists since AOS 2.x but the AllocBitMap() only since 3.x. Before that everyone created bitmap and bitmap planes manually. Also in things like double buffering (animation player). AllocRaster() only does 16x alignment, not 32x or 64x as required by higher fetchmodes. It again would break things, if it did.

[Thomas Richter]

Originally Posted by dissident

I doubt that the system is smart enough to detect misaligned bitmaps. There must be a reason for the global entry in the graphics base for the bandwidth.

Actually, graphics goes through multiple functions for computing what the best possible FMode could be, not only depending on alignment but also on the number of reserved sprites and adapts to the requirements. But the algorithm is opaque and undocumented.

[dissident]

Originally Posted by Thomas Richter

No, the FMode is nothing the Os allows you to set or play with. Your best option is probably BestModeID() of graphics to request modes with certain properties. However, what exactly is the application here?

Originally Posted by Thomas Richter

Actually, graphics goes through multiple functions for computing what the best possible FMode could be, not only depending on alignment but also on the number of reserved sprites and adapts to the requirements. But the algorithm is opaque and undocumented.

Well, I did some further tests and found out that in my case doing a LoadView(Null) after the screen is open, the BPLMOD-Registers are never 0 independent from the bndwidth (-2 for 1x and -8 for 4x).

So I better keep my hands off the gfx base and initialize the BPLMOD registers manually after LoadView(Null)

[paraj]

What are you trying to degrade for? If it's a system friendly application won't you run into issues if the user switches to another screen after you've changed BPLMOD? I'm not too familiar with system friendly coding to be honest, but shouldn't you be setting up something that has a user defined copperlist that sets the register values to the values you need?

[pipper]

How about adding a user copperlist that resets FMODE to what you like it to be? Or is FMODE out of reach for Copper?

[dissident]

Originally Posted by paraj

What are you trying to degrade for? If it's a system friendly application won't you run into issues if the user switches to another screen after you've changed BPLMOD? I'm not too familiar with system friendly coding to be honest, but shouldn't you be setting up something that has a user defined copperlist that sets the register values to the values you need?

I'm rewriting/revisiting an old project completely: https://aminet.net/package/util/app/RSE-ADL16b

In my case this means that I question every routine of my app.

Very old OCS intros rely on the fact that the standard screen has BPL1MOD/BPL2MOD set to zero. They didn't initialize these registers themself and need these values for a proper display.

The screen is for configs with a graphics card. A standard lores screen is openened in front of a potential graphics card screen. This screen has a window with a cleared sprite pointer to avoid a vertical bar for those OCS intros which don't turn off the sprite DMA correctly.

Then a LoadView(Null) is done to get ECS settings for the custom display registers. FMODE=0, BPLCON3=$0011, BEAMCON=$0020 on a PAL nachine.

Mainly it‘s other people’s stuff which cause the problems on non-OCS machines. To make this stuff run on AGA even with a 68060 card is one of the main tasks of my degrader routines.

My knowledge is based on articles in the Amiga Plus 05/1994 and 12/1994.

[dissident]

Originally Posted by pipper

How about adding a user copperlist that resets FMODE to what you like it to be? Or is FMODE out of reach for Copper?

You could also initialize the FMODE register by the CPU. No, this register can also be reached by the copper. It‘s not in the range of blitter registers.

[paraj]

For this use-case I don't think you need to create a screen or anything. Just LoadView(NULL), and set the HW copperlist to your own compatible one (null sprites all round, other HW registers setup as you like) like you would in a system takeover. Just make sure at least one VBL has passed before starting the demo.

[dissident]

Originally Posted by paraj

For this use-case I don't think you need to create a screen or anything. Just LoadView(NULL), and set the HW copperlist to your own compatible one (null sprites all round, other HW registers setup as you like) like you would in a system takeover. Just make sure at least one VBL has passed before starting the demo.

I will check this. If I remember correctly there must haben a reason for this screen. It had to do with graphic cards which use their own screen. I have to check the articles of my old Amiga Plus magazines on the attic. and do some tests with my Picasso Win-UAE config.

[paraj]

Originally Posted by dissident

I will check this. If I remember correctly there must haben a reason for this screen. It had to do with graphic cards which use their own screen. I have to check the articles of my old Amiga Plus magazines on the attic. and do some tests with my Picasso Win-UAE config.

FWIW only RTG capable HW I've used is pistorm, and LoadView(NULL) works there, but WHDLoad opens a 320x200x1 screen before switching system off (rather than LoadView(NULL)), so perhaps there is a good reason to do so.



(WHDload way is problematic at least on pistorm though in the way it switches off system since a 1BPL screen still messes with BPLCON3 to set palette, so turning off copper at unfortunate time is a problem)