18 November 2021, 07:30 | #1 |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
BPLCON0 causing hang
I've been looking at a hang that occurs on the first frame of my game on my real hardware A1200 but not in emulation.
After cutting things out bit by bit, I've narrowed down to a case where I can change one tiny copper list to make it hang or run. This is the first frame of the game, so there is no display initialised yet. Hangs: Code:
BPLCON0 = 0 0xfffffffe Code:
COLOR0 = F00 0xfffffffe Or is there some genuine reason setting BPLCON0 in this way could cause hang? |
18 November 2021, 07:56 | #2 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Maybe this copper/blitter bug. From quick search in forums: "If the copper is WAITing and the blitter is running and the CPU touches COPJMP to strobe the address of a new copper list into the copper's instruction pointer, a blitter channel pointer can be updated instead.". So try blit wait, before starting copper list.
|
18 November 2021, 08:32 | #3 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
How are the BPUx bits previously set? (in practice some race condition because the code is possibly executed in advance in the first case) Is this BPLCON0 write the first instruction in the copper list? Are you forcing the copper list to restart by writing in COPJMP (see previous message from aros-sg)? It is not recommended for several reasons, unless you know what you are doing. Can you post a small exe where it happens? |
|
18 November 2021, 09:34 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
BPLCON0 write can only cause hang directly if ERSY (bit 1) is set without connected genlock.
|
18 November 2021, 09:57 | #5 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
Quote:
I recently had a sporadic bug on real hardware that did not occur on emulation and it was exactly this. I was well aware of the COPJMP strobe bug, but even so I managed to forgot that the Blitter could still be running at the time in my code where I wrote to COPJMP with the CPU. It's best to make 100% sure that any CPU write to COPJMP is done in such a way the Blitter can't be running. Or bad things might happen. |
||
18 November 2021, 11:29 | #6 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
Anyhow it is a good habit to 'let complete the frame' to the copper, otherwise, as happens very often, you will find glitches on the video very visible for at least the initial frame. Since the copper does auto-reload the pointer at frame start I don't see the reason to manually force a restart (ok, ok maybe laziness ). (the problem arose when old initialization code spread that contained this setting and others continued to use it without asking why...) Even in the case of deactivation of the copper DMA there is no need for a COPJMP if you wait for the start of the next frame (yes, even with the DMA off, COP1PRT is forced in COPPTR). In that case the reactivation of the DMA must be done synced with frame beginning as not to generate glitches in your own frame... (or risking to restart a partial copper list perhaps overwritten by decompression code or other data). Moral: always make these settings well synchronized with the beam (frame start or not), sure that the old work of the blitter (perhaps performed by some system process) is completed |
|
18 November 2021, 15:08 | #7 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
On a side note: the COPJMP1 CPU strobe bug is only one possibility here, it's possible something else is going on of course - but it's unlikely to be dependent on the actual write to BPLCON0 (as Toni pointed out, writing to BPLCON0 normally doesn't lead to crashes/hangs). |
|
18 November 2021, 15:59 | #8 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
If for some reason the missed fetches due to BPL DMA non-executed (BPLCON0=0) define a race condition, here is a possible explanation (some chip memory access coud be delayed because of this, i.e. a previous BPUx value that continue to fetch data, delay CPU execution and 'hide' the race problem only by chance). Muzza specified that "there is no display initialised yet"; what this *exactly* means? Which is an unknown situation because it derives from the state of the system prior to the takeover? Or that the system has been properly deactivated in advance, including therefore IRQ and DMA? I think that only an executable that presents the problem in a replicable way can clarify the situation. |
|
18 November 2021, 16:39 | #9 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
|
18 November 2021, 17:10 | #10 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
|
18 November 2021, 21:58 | #11 |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Thanks for the replies, I'm going over everything but I don't write to COPJMP using the CPU (only the copper), so I don't think it can be the COPJMP strobe bug.
|
18 November 2021, 22:10 | #12 |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
One thing that I have wondered about is the way I chain my copper lists together for triple buffering.
Each copper list ends with this: Wait for VPOS 303 COP1LC = pointer to top of THIS copper list COP2LC = points to label N COPJMP2 COP1LC = pointer to the top of NEXT copper list [Label N] END OF LIST This means that a copper list will repeat itself forever, but when the next frame is ready to go, I overwrite COPJMP2 with COPPER_NOP, so that it will start the next frame as soon as the existing frame is complete. I did wonder what happens if the copper happens to be reading the COPJMP2 when the CPU changes it to COPPER_NOP. It's a single word write, so would this be atomic? I also tried adding protection around the CPU write so that if VPOS is at 302/303 it will wait, but this did not fix my hang problem. Also if this really was a race condition I would expect to see if every so often during the game, and not just on the first frame. Last edited by Muzza; 18 November 2021 at 22:16. |
18 November 2021, 22:41 | #13 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Yes, it's atomic.
But why you need to rewrite COP1LC with THIS copper_list? You can simply setup a small list that set the new COP1LC just in case the new list is needed. Something like: Wait for VPOS near_the_end (even 312) COP2LC = points to chainN COPJMP2/NOP END OF LIST chainN COP1LC = pointer to the top of NEXT copper list END OF LIST |
18 November 2021, 22:47 | #14 | |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Quote:
At this point, no display registers have been set at all, so they are whatever it was from Workbench before I did a system takeover. This setting of BPLCON0 will be the first display setting modified. I've just tried having the CPU set BPLCON0 to zero immediately after system takeover, and that fixes it. So either it coincidentally fixes a race condition, or you're right that it is something to do with the previous values. Are there any other display registers it would be good practice to set to a 'neutral' value immediately after system takeover? |
|
18 November 2021, 22:51 | #15 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
Then set the BPLxxx registers as you need/want. |
|
18 November 2021, 22:54 | #16 | |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Quote:
COP1LC gets set a few times because I do some 'go-subs' to other copper lists, so at the very end I reset it to the start to ensure it is valid. Wouldn't the COPJMP2 in your list start running ChainN immediately, rather than at the start of the next frame? |
|
18 November 2021, 22:57 | #17 | |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Quote:
I do LoadView(NULL), but I wasn't setting any BPL registers until after some initialisation work had been done (so potentially some vblanks had passed) |
|
18 November 2021, 23:02 | #18 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
It remains to be understood why zeroing BPLCON0 immediately there is not the race condition.. |
|
18 November 2021, 23:05 | #19 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
(I would do it this way simply because it's slightly faster, but that's okay as well as you do ) EDIT: hmm, I reread and here too I would do different: Quote:
That's also why I'd use line 312 for the last selection for chainN. But of course it's just an implementation detail Last edited by ross; 18 November 2021 at 23:19. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Behavior with BPLCON1 shifts and mid-scanline BPLCON0 change | losso | support.WinUAE | 11 | 21 November 2021 13:46 |
Could the PSU be causing these problems? | -Acid- | support.Hardware | 5 | 07 March 2016 21:39 |
Sram causing flickering | daznic | support.Hardware | 6 | 11 February 2009 06:05 |
WHDLoad causing havoc(!) | Iznougoud | Retrogaming General Discussion | 0 | 08 November 2007 01:29 |
AmiBlitz causing havoc | jobro | support.Apps | 17 | 07 December 2005 17:18 |
|
|