Copper HALT

[ross]

I'm patching an old game to make it fully system compliant and found some strange copper behaviour.

After the LoadView(NULL) i used AddIntServer(VBL) to setup my first copper list.. but do not have worked properly.
So after investiganting i've found that COPJMP2 is set to execute a 'void' copper list.
I was expecting total garbage on screen but nothing.. screen clean.
I remembered reading something about the copper that stops in some situation and writing to "dangerous register" (with COPCON zeroed) is one of these.

But what amazed me is that it is used by the system!
So is it considered a feature? or is it just a huge bug?

[meynaf]

Originally Posted by ross

I'm patching an old game to make it fully system compliant and found some strange copper behaviour.

After the LoadView(NULL) i used AddIntServer(VBL) to setup my first copper list.. but do not have worked properly.
So after investiganting i've found that COPJMP2 is set to execute a 'void' copper list.

Setting COPJMP2 to some bogus address, huh ? Totally unimportant if main coplist just touches COP2LC and doesn't actually trigger COPJMP2.

Originally Posted by ross

I was expecting total garbage on screen but nothing.. screen clean.

Screen clean because number of bitplanes is set to zero, probably.
Have you checked this in main coplist ?

Originally Posted by ross

I remembered reading something about the copper that stops in some situation and writing to "dangerous register" (with COPCON zeroed) is one of these.

Are you sure it actually stops and doesn't just ignore the writes ?

Originally Posted by ross

But what amazed me is that it is used by the system!
So is it considered a feature? or is it just a huge bug?

It doesn't need to. Simple CEND is enough. I see no reason why the system would do something really not clever like this.

Did you verify that :
- copper DMA is activated
- screen bitplane DMA is activated

[StingRay]

Originally Posted by ross

After the LoadView(NULL) i used AddIntServer(VBL) to setup my first copper list.. but do not have worked properly.

Why AddIntServer to setup a copperlist?

Originally Posted by ross

So after investiganting i've found that COPJMP2 is set to execute a 'void' copper list.
I was expecting total garbage on screen but nothing.. screen clean.

If "void" means just a copperlist containing a wait to end the copperlist, there shouldn't be any garbage on screen.

What does the first copperlist look like?

[ross]

A better description, sorry.

System: bare A1200, KS3.0, boot from floppy with no SetPatch.
Some init then LoadView(NULL).
AddIntServer is really not significative, i've noticed the problem using it because i've used high priority (20) so copper is still on the first video lines executing the instructions launched by COP1LC.
I've used COP1 but.. strangeness, so investigated.

Situation (setup by LoadView): COPI1LC = $BF8, COP2LC -= $CA0

00000BF8 00E0 0000 0100 8201 0106 0C00 0180 0AAA
-- cut --
00000C88 013C 0000 013E 0CA4 0C01 FFFE 0C01 FFFE
00000C98 008A 0000 FFFF FFFE, 0000 0000 0000 0000
;
00000CA0 0000 0000 0000 0000 0000 0000 0000 0000

You can see that after $0c01 CWAIT COP2JMP is triggered and copper continue to the illegal $0000,$0000 and ... HALT
No more instruction executed, all stuck (restart next VB logically).
Screen clear

[meynaf]

Odd, some internal voice tells me the secret lies in the -- cut -- part

[ross]

Nah, in the --cut-- part only some boring CMOVE

But solved! It's really a bug!

On KS3.1 the copper list is the same but:
COP1LC=$C00, COP2LC=$CA4

00000C00 00E0 0000 0100 8201 0106 0C00 0180 0AAA
--cut--
00000C90 013C 0000 013E 0CB0 0C01 FFFE 0C01 FFFE
00000CA0 008A 0000, 0106 0C00 FFFF FFFE 0000 0000
->
00000CA4 0106 0C00 FFFF FFFE 0000 0000 0000 0000

Now i need to support the bugged KS3.0 copper list

Thanks Maynaf and StingRay for the interest

[Toni Wilen]

Copper stops (until next frame) when it attempts to write "dangerous register" and CDANG=0. (even if it is "skipped" move to dangerous register)

[ross]

Ok Toni, thanks.
What surprised me is that this "feature" (read: bug) is in system copper list in this particular situation.
I've not tried in a Setpatched system or KS <3.0.

Well, i'll check it

[EDIT:
mixed results
2.x and 3.1 is working properly, 1.3 and 3.0 copper HALT, <=1.2 same as 1.3/3.0 but different HALT code.
Actually if you use full compliant code (OpenScreen and company) or a full takeover you don't get this corner case.
But i'm constrained to a different solution. Anyway the patch is simple
]

[dissident]

Originally Posted by ross

I'm patching an old game to make it fully system compliant and found some strange copper behaviour.

After the LoadView(NULL) i used AddIntServer(VBL) to setup my first copper list.. but do not have worked properly.
So after investiganting i've found that COPJMP2 is set to execute a 'void' copper list.
I was expecting total garbage on screen but nothing.. screen clean.
I remembered reading something about the copper that stops in some situation and writing to "dangerous register" (with COPCON zeroed) is one of these.

But what amazed me is that it is used by the system!
So is it considered a feature? or is it just a huge bug?

Hi ross, maybe this info might help you. Loadview(0) behaves different on <=KS 1.3 and >= KS 2.0. I once read in the German "Amiga Plus" magazine (1/95) about this. Loadview() with a NULL argument isn't supported on the old KS-versions and may lead to a guru. The non-support of the NULL argument is confirmed in the description of LoadView() in the both Abacus books from 1989 for KS 1.2/1.3 and from 1992 for KS 2.x. See attached screenshots.

[ross]

Thanks Dissident!

This thing happened to me a few minutes ago (LoadView (NULL), KS1.2 -> Guru) and I wondered why it happened!
Only in particular conditions (repeatable), not normally..

Now I need a different solution.

[EDIT: the problem seem not in LoadView(0) per-se but on successive WaitTOF,
however I will try to understand more]

[dissident]

Originally Posted by ross

Thanks Dissident!

This thing happened to me a few minutes ago (LoadView (NULL), KS1.2 -> Guru) and I wondered why it happened!
Only in particular conditions (repeatable), not normally..

Now I need a different solution.

[EDIT: the problem seem not in LoadView(0) per-se but on successive WaitTOF,
however I will try to understand more]

I guess I know what happens, if you call LoadView(NULL) under KS 1.2/1.3. The systemfunction thinks, your view-structure-pointer is the address $00000000 and so the view structure is initialized in the CHIP-memory area $0000000-$00000012. It fetches from the offset v_LOFCprList ($00000004) the potential pointer to the initialized copperlist, but it's the vector address of the exec-base. You can imagine what it means to do a COPJMP1 to this address. Unpredictable results which could mess it all up.

To make it clearer, here's the view-structure of KS 1.3:

STRUCTURE View,0
   LONG       v_ViewPort
   LONG       v_LOFCprList
   LONG       v_SHFCprList
   WORD       v_DyOffset
   WORD       v_DxOffset
   WORD       v_Modes
LABEL   v_SIZEOF

To solve this, why not always initializing a view-structure regardless of any KS-version which contains a pointer to a custom copperlist created with the gfx-libary with only two commands: a CMOVE $0200,$0100 and a CEND. So after the system has executed your list, the display is blanked. Or you add other commands to this custom copperlist to reset AGA registers to OCS default values, if needed, like LoadView(NULL) on KS 3.x does.

I hope this may help you solving your problem.

[hooverphonique]

Originally Posted by dissident

To solve this, why not always initializing a view-structure regardless of any KS-version which contains a pointer to a custom copperlist created with the gfx-libary with only two commands: a CMOVE $0200,$0100 and a CEND. So after the system has executed your list, the display is blanked. Or you add other commands to this custom copperlist to reset AGA registers to OCS default values, if needed, like LoadView(NULL) on KS 3.x does.

I hope this may help you solving your problem.

The whole point of using LoadView(NULL) is to avoid having to explicitly set all sorts of gfx-related registers (which depend on chipset version) to reset the display

[robinsonb5]

Originally Posted by hooverphonique

The whole point of using LoadView(NULL) is to avoid having to explicitly set all sorts of gfx-related registers (which depend on chipset version) to reset the display

The simplest answer is probably just to skip the LoadView(NULL) under KS1.3 or earlier. It should be reasonably safe to assume that KS1.3 won't have left the chipset in a non-compatible state.

[hooverphonique]

Originally Posted by robinsonb5

The simplest answer is probably just to skip the LoadView(NULL) under KS1.3 or earlier. It should be reasonably safe to assume that KS1.3 won't have left the chipset in a non-compatible state.

Yes, that is probably a reasonable compromise..

[dissident]

Originally Posted by hooverphonique

The whole point of using LoadView(NULL) is to avoid having to explicitly set all sorts of gfx-related registers (which depend on chipset version) to reset the display

Yes hooverphonique, I know this, but ross seems to want a blank display also on KS 1.2/1.3. That's why I made this suggestion.

[dissident]

Originally Posted by robinsonb5

The simplest answer is probably just to skip the LoadView(NULL) under KS1.3 or earlier. It should be reasonably safe to assume that KS1.3 won't have left the chipset in a non-compatible state.

I agree with you, robinsonb5. For KS 1.2/1.3 you don't need a LoadView(NULL) to reset CUSTOM CHIP registers. It's superfluous. Checking the KS version before LoadView(NULL) is called would be a smarter solution.

[Asman]

Originally Posted by ross

Thanks Dissident!

This thing happened to me a few minutes ago (LoadView (NULL), KS1.2 -> Guru) and I wondered why it happened!
Only in particular conditions (repeatable), not normally..

Now I need a different solution.

[EDIT: the problem seem not in LoadView(0) per-se but on successive WaitTOF,
however I will try to understand more]

You can try following approach. I use following code in my system overtake function. I don't know if it helps - but who knows.

;a5 - _custom
;a6 - gfx base
;reset display
		sub.l	a1,a1
		move.w	#DMAF_RASTER,dmacon(a5)
		bsr	OsViewLoad
 ...
OsViewLoad:
		jsr	-222(a6)	;gfx LoadView(a1 - view)
		jsr	-270(a6)	;gfx WaitTOF()
		jmp	-270(a6)	;gfx WaitTOF()

[ross]

Originally Posted by Asman

You can try following approach.

Thanks Asman, maybe this can be useful on KS1.x because a bug leave in the first frame BPLxPT uninitialized and garbage on screen.

But at the end i've understood why a guru on my routine and why on WaitTOF().
There is another bug, only on KS1.2, in AddIntServer()..

When the system calls the specified interrupt code, the registers are
    setup as follows:

        D0 - scratch
        D1 - scratch (on entry: active
                      interrupts -> equals INTENA & INTREQ)

        A0 - scratch (on entry: pointer to base of custom chips
                      for fast indexing)
        A1 - scratch (on entry: Interrupt's IS_DATA pointer)

        A5 - jump vector register (scratch on call)
        A6 - Exec library base pointer (scratch on call)

        all other registers must be preserved

A warning: if you set high priority you've to propagate A0 in chain because is expected to low priority services.
And this is clearly specified.
At some point i've changed from high to low priority.

But i'm "transparent" to A0 so i'm not expecting problems (I use it but I do not change it).
My priority is so low that i'm last in chain and ... last system service in

KS1.2

do not propagate A0! (all ok in successive release)

So at the WaitTOF() I have already performed my routine and corrupted some system data and GURU!

Phew.. at the end i've solved everything but so many bugs!

Patches was for:
http://eab.abime.net/showpost.php?p=...7&postcount=45

[dissident]

Originally Posted by ross

Thanks Asman, maybe this can be useful on KS1.x because a bug leave in the first frame BPLxPT uninitialized and garbage on screen.

But at the end i've understood why a guru on my routine and why on WaitTOF().
There is another bug, only on KS1.2, in AddIntServer()..

When the system calls the specified interrupt code, the registers are
    setup as follows:

        D0 - scratch
        D1 - scratch (on entry: active
                      interrupts -> equals INTENA & INTREQ)

        A0 - scratch (on entry: pointer to base of custom chips
                      for fast indexing)
        A1 - scratch (on entry: Interrupt's IS_DATA pointer)

        A5 - jump vector register (scratch on call)
        A6 - Exec library base pointer (scratch on call)

        all other registers must be preserved

A warning: if you set high priority you've to propagate A0 in chain because is expected to low priority services.
And this is clearly specified.
At some point i've changed from high to low priority.

But i'm "transparent" to A0 so i'm not expecting problems (I use it but I do not change it).
My priority is so low that i'm last in chain and ... last system service in

KS1.2

do not propagate A0! (all ok in successive release)

So at the WaitTOF() I have already performed my routine and corrupted some system data and GURU!

Phew.. at the end i've solved everything but so many bugs!

Patches was for:
http://eab.abime.net/showpost.php?p=...7&postcount=45

Good work, ross.

[Asman]

Originally Posted by ross

Thanks Asman, maybe this can be useful on KS1.x because a bug leave in the first frame BPLxPT uninitialized and garbage on screen.

That was idea behind this code - to omit garbage on screen when I overtake system - but you must remember to set DMAF_RASTER when system is restored. I really hate this garbage on screen which sometimes occurs.