English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 05 February 2018, 23:47   #1
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Copper HALT

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?
ross is offline  
AdSense AdSense  
Old 06 February 2018, 08:30   #2
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,965
Quote:
Originally Posted by ross View Post
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.


Quote:
Originally Posted by ross View Post
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 ?


Quote:
Originally Posted by ross View Post
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 ?


Quote:
Originally Posted by ross View Post
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
meynaf is offline  
Old 06 February 2018, 09:38   #3
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,957
Quote:
Originally Posted by ross View Post
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?

Quote:
Originally Posted by ross View Post
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?
StingRay is offline  
Old 06 February 2018, 10:05   #4
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
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
ross is offline  
Old 06 February 2018, 10:28   #5
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,965
Odd, some internal voice tells me the secret lies in the -- cut -- part
meynaf is offline  
Old 06 February 2018, 10:42   #6
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
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
ross is offline  
Old 06 February 2018, 14:15   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,512
Copper stops (until next frame) when it attempts to write "dangerous register" and CDANG=0. (even if it is "skipped" move to dangerous register)
Toni Wilen is online now  
Old 06 February 2018, 15:30   #8
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
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
]

Last edited by ross; 06 February 2018 at 16:30.
ross is offline  
Old 06 February 2018, 18:04   #9
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 134
Quote:
Originally Posted by ross View Post
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.
Attached Thumbnails
Click image for larger version

Name:	Abacus_1989_Advanced_System_Programmers_guide.jpg
Views:	51
Size:	67.6 KB
ID:	56665   Click image for larger version

Name:	Abacus_1992_Amiga_Intern.jpg
Views:	45
Size:	47.7 KB
ID:	56666  
dissident is offline  
Old 06 February 2018, 18:30   #10
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
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]

Last edited by ross; 06 February 2018 at 18:39.
ross is offline  
Old 07 February 2018, 09:54   #11
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 134
Quote:
Originally Posted by ross View Post
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:
Code:
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.

Last edited by dissident; 07 February 2018 at 12:28.
dissident is offline  
Old 07 February 2018, 13:09   #12
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 777
Quote:
Originally Posted by dissident View Post
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
hooverphonique is offline  
Old 07 February 2018, 13:28   #13
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 576
Quote:
Originally Posted by hooverphonique View Post
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.
robinsonb5 is offline  
Old 07 February 2018, 14:52   #14
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 777
Quote:
Originally Posted by robinsonb5 View Post
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..
hooverphonique is offline  
Old 07 February 2018, 14:58   #15
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 134
Quote:
Originally Posted by hooverphonique View Post
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 is offline  
Old 07 February 2018, 15:02   #16
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 134
Quote:
Originally Posted by robinsonb5 View Post
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.
dissident is offline  
Old 13 February 2018, 21:42   #17
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 642
Quote:
Originally Posted by ross View Post
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.
Code:
;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()
Asman is offline  
Old 13 February 2018, 23:37   #18
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Asman View Post
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()..

Code:
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
ross is offline  
Old 14 February 2018, 07:34   #19
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 134
Quote:
Originally Posted by ross View Post
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()..

Code:
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.
dissident is offline  
Old 14 February 2018, 08:22   #20
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 642
Quote:
Originally Posted by ross View Post
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.
Asman is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Copper ASM LeCaravage Coders. Asm / Hardware 5 30 January 2018 12:35
Using the Copper guy lateur Coders. C/C++ 22 26 July 2017 19:29
Best way to mix blitting with copper and copper effects roondar Coders. Asm / Hardware 3 12 September 2016 13:12
copper ? turrican3 Coders. Asm / Hardware 10 27 January 2016 09:10
Combining copper scrolling with copper background phx Coders. Asm / Hardware 14 16 June 2013 07:26

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 22:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09635 seconds with 16 queries