ECS/AGA Border trick - HELP!

[KevG]

Hi folks.

I remember years ago that there was a GFX library call that allowed you to change the border around your screen to black even though colour 0 might be a different colour inside your screen.

What I have at the moment is a screen setup with a user defined copper-list with a nice rainbow covering the whole screen using colour 0. The rainbow also appears in the border which I dont want. I want to be able to change the border region (around the outside) to black so that the rainbow effect is only displayed inside the main screen and not the border. I hope I explained that O.K.

Anyway, this GFX Library call was only available in Kickstart 2 machines and up. Does anyone know this function call and the appropriate values to set?

Thanks, Kev G.

[meega]

This might not be what you want, but might help anyway.

http://aminet.net/search?query=bblank

[Leffmann]

If there is such a function it would probably reside in the intuition library. Try checking the function reference on http://amigadev.elowar.com/ for it.

The border blank feature is ECS and AGA specific, and what you need to do is enable the ECS feature set by setting bit 0 in BPLCON0 $DFF100 to 1, and also enable the border blanking by setting bit 5 in BPLCON3 $DFF106 to 1.

[Toni Wilen]

graphics.library/VideoControl VTAG_BORDERBLANK

ECS Denise or AGA required.

[KevG]

Thanks chaps.

I have just been trying out some of your tips. I just read quite a bit from the Rom Kernal Ref Manuals as well.


Unfortunately, my Amiga 600 keeps crashing! I thinks it is wise to point out that I am using AMOS and in particular the r=GFXCALL(function). Because of the way AMOS works, I dont think it would be wise to use an Intuition call.

I am using the offsets that Leffman provided me but I understand that I have to first provide control values in the 68000 address and data registers that the GFXCALL uses. I am not sure what these values are.

I know that most people around here use Assembly Language so any ideas that you may have would be grately appreciated.

Cheers, Kev G

[Leffmann]

I'm not sure it will work to call the graphics library for this from inside Amos either. That graphics call needs to be pointed to some underlying data structures, and of course Amos hides these low level horrors so the user doesn't have to bother with them.

I never used my own copper lists in Amos so I'm not sure how that works. Do you create the lists with some convenient Amos commands, or can you actually specify the exact instructions? What sort of screen mode are you using, resolution, single or dual playfields, number of bitplanes/colors etc?

You could also just set color 0 to black and paint the sky/background in another color instead, though if you're using some clever sprite/bitplane priorities or hardware collision there could be some issues. Other than that it's just the same, and will also work on OCS of course.

[KevG]

Hi Leffmann

Thanks for your help in this matter. Your knowledge is worth its weight in gold around here so I appreciate your input.

According to the AMOS manual....

r=GFXCALL(function)

Calls a routine from the graphics library using the control values stored in the DREG and AREG arrays. function is the offset to the relevant function. r is the result of the operation returned in D0.

Now the offsets that I have been using are $100 and $106. I just dont know how to set Bits 0 and 5. I have never mucked around with the graphics library before so its all a bit new to me.

Regarding my copper-list created screen, I just set up a dummy screen 320x256x8 and dump out the copper list that AMOS created for it. I then use the AMOS copper list commands to modify it. Its alot easier than creating one from scratch.

Your last option is the obvious solution I know but it uses another colour. And one more colour out of a palette of only 8 colours is a huge price to pay. I am left with only 6!

I'll have another look later on to see what I am doing wrong. I'll get back to you.

Cheers, Kev G

[Leffmann]

Sorry I was a bit unclear in what I wrote, the $DFF100 and $DFF106 values aren't meant to be passed to the VideoControl call, they are the addresses in the memory map corresponding to the two hardware registers that control the border blanking.

Amos will write the first of these registers in its Copper lists, because it controls the number of colors and screen resolution among other things, but as a first try you can write both registers yourself in your user defined Copper list and hope that they're not getting changed further down the display.

Insert these two instructions first thing in your user defined Copper list to set a 3 color low resolution display with the border blanking enabled: $01003001 and $01060C20

This is ugly but there's no elegant way of doing this since, again, Amos hides all its internals from the user, and going through the Intuition and Graphics libraries is even less certain.