Force AmigaOS *not* to update COPxLCH

[neoman]

From the AHRM:

COP1LC  is written at the end of  vertical blanking .
------------------------------------------------------
The  COP1LC  register is written at the end of the  vertical blanking 
period by a graphics interrupt handler which is in the vertical blank
interrupt server chain.  As long as this server is intact,  COP1LC 
will be correctly strobed at the end of each vertical blank.

Is there any way to avoid this behaviour - I need their interrupt servers because I need timer.device and the timer interrupts but I don't need the copper list refresh. I just want force AmigaOS *not* to update these pointers. Since my VBI needs a variable time (due to music playback) I cannot just set COPxLC to my own pointers because they get overwritten on occasion.

Thanks for some help,
neoman/titan

[neoman]

I think I found a way around it. But if someone knows it though, it would be pretty nice to know.

Thanks!

[Toni Wilen]

I don't remember AmigaOS ever writing to COP1LC, many semi-system friendly games (and very old demos) writes to COP1LC taking over the display without disabling interrupts.

But usual LoadView(NULL) should do it.

[neoman]

Thanks so far, I will give it a try.

I add the interrupt using AddIntServer and AmigaOS's VBI also seems to be in that queue because it resets COP2LC after my interrupt has been done (I return from my interrupt with Z condition with intent of course!). It seems to restore them from LOFList/SHFList. But I just cannot set LOFList/SHFList to my COP2LC because I built a copper matrix which edits COP2LC all the time.

[Toni Wilen]

Yeah, COP2LC is updated if system screen mode is interlaced.
LoadView(0); takes care of that too.

[neoman]

_InstallScreen
	movem.l	d0-a6,-(sp)

	*** remove and store OS-view

	move.l	_GfxBase,a6
	move.l	gb_ActiView(a6),_OSView
	sub.l	a1,a1
	jsr	_LVOLoadView(a6)
	jsr	_LVOWaitTOF(a6)
	jsr	_LVOWaitTOF(a6)

That's strange, I already do this...

[JackAsser]

Reviving necro thread. Any solutions to this?

[JackAsser]

Originally Posted by JackAsser

Reviving necro thread. Any solutions to this?

This is the solution:

After chatting with StingRay the solution is simple. Simply also tell graphics.library (offset $32 or gb_LOFlist) to use the COP2LC pointer:

move.l gfxbase,a0
move.l my_copper,gb_LOFlist(a0)
move.l my_copper,$dff084

So while COP2LC _will_ be overwritten in the OS VBlank routine, it will at least be overwritten with _YOUR_ value.

[phx]

You are talking about hitting the hardware while the OS is still alive? This is evil and disgusting!

Take over the system completely and do your stuff - no problems!

Otherwise the solution would be to avoid the execution of the OS VERTB interrupt handler. Insert a handler with AddIntServer(), as neoman mentioned, many years ago, and return with Z-flag set. So lower priority handlers do not execute. Make sure your handler has the highest priority, of course. The GfxBase->vbsrv has priority 10.

When that doesn't work (like neoman indicated - I didn't test it), you could also use SetIntVector() to replace the OS VERTB interrupt server routine with yours.

(BTW, this thread never had anything to do with C/C++ ...)

[JackAsser]

Originally Posted by phx

You are talking about hitting the hardware while the OS is still alive? This is evil and disgusting!

Take over the system completely and do your stuff - no problems!

Otherwise the solution would be to avoid the execution of the OS VERTB interrupt handler. Insert a handler with AddIntServer(), as neoman mentioned, many years ago, and return with Z-flag set. So lower priority handlers do not execute. Make sure your handler has the highest priority, of course. The GfxBase->vbsrv has priority 10.

When that doesn't work (like neoman indicated - I didn't test it), you could also use SetIntVector() to replace the OS VERTB interrupt server routine with yours.

(BTW, this thread never had anything to do with C/C++ ...)

Tried all of the above w/o succes