English Amiga Board


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

 
 
Thread Tools
Old 27 November 2018, 18:13   #21
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
Quote:
Originally Posted by ross View Post
Yes.
There could be a 'blitter storm' because of tiny blits or slow CPU response or bus hogged, but only before the queue is emptied,
Indeed, I could understand those problems given what we've talked about. Those would also cause oddities and weird behaviour. Just different ones.

Quote:
and certainly a 'blitter overlap' can not happen like experienced by roondar.
So probably something is wrong elsewhere and i'm very curious about it.
Indeed, I am very curious myself. Part of me thinks that phx's suggestion that something else touches the Blitter or the Blitter finished flag would explain everything, but I just don't think that actually happens. I'll be sure to do a search on all source code to see if I missed something, but what bothers me about that idea is that this is a new development (as in, it only recently started crashing). And I happen to know that the new code I've added definitely does not do it's own Blitting or interrupt handling.

Anyway, I'll give some of the ideas here a try later tonight and let you know how it goes. Maybe I can find the problem with some renewed effort and a bag of tips and tricks.

Still 99% sure I must be doing something silly somehow, somewhere. Now to find it!

Last edited by roondar; 27 November 2018 at 18:22.
roondar is offline  
Old 27 November 2018, 18:45   #22
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 538
If it was just that the RTE came too soon after the IRQ-ACK, then how come the original Commodore devs found this problem and had the fix in the kickstart? I don't think it is likely that the OS interrupt handlers exit that fast after the IRQ-ACK. An 040 was fast but not that fast.
grond is offline  
Old 27 November 2018, 18:55   #23
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
On the A4000/68040/68060/Vampire interrupt ACK problem, I remember a recent thread where Toni Wilen wrote about this. Here is what he had to say about it:

Quote:
Originally Posted by Toni Wilen
Problem is Paula being slow, it needs one more CCK after INTREQ/INTENA write before it changes IPL lines (if RTE finishes during that extra CCK, CPU still sees old interrupt active and it can happen if all the stacked data is in caches).
This is from: http://eab.abime.net/showpost.php?p=...4&postcount=11

IIRC he's made similar comments in the past, so I guess the problem really is Paula being slow and the second ACK is used just to delay the CPU long enough to not trigger this issue.
roondar is offline  
Old 27 November 2018, 22:34   #24
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 199
This might be relevant: http://eab.abime.net/showthread.php?t=91412

Snippet from our blitter interrupt handler after that thread discussion:
Code:
;----------------------------------------------------------------------------------
; Level3 / blitter interrupt callback
;   should be called by the level3 handler in order to trigger multiple consecutive blits

InterruptDrivenStandardBlits_level3BlitterCallback

		; Hack: Sometimes, some OS code can trigger a blitter interrupt.
		; We have observed this happening on KS1.3 when the CIAB TOD counter
		;   triggers an alarm (when counter goes $fff -> $1000, a hardware glitch
		;   makes the counter read out as $000000 for a few cycles, and the comparison
		;   value is set to $000000 - this results in a Lev6 interrupt being signalled).
		; The OS Lev6 interrupt handler does some work, and ends with
		;   writing $8040 to INTENA and INTREQ.
		; It probably does this because it gets confused and thinks it is time
		;   to activate the QBlit blitter queue logic.
		; It does this even if the application has called OwnBlitter.
		; This can happen in the middle of an ongoing blit operation.
		; To protect against such spurious interrupts, we will test whether there is
		;   a blit currently in-progress and, if so, not do anything blitter related
		;   within this interrupt handler.
		; The BLTDONE bit is set while a blit is in-progress.

		btst	#DMAB_BLTDONE-8,$dff000+dmaconr
		bne.s	.blitInProgress
		...
.blitInProgress
		rts
Kalms is offline  
Old 27 November 2018, 23:22   #25
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
@Kalms: that is a very interesting and partially scary bit of information... It wasn't what was going wrong, but thanks for the info!

@Thread:
I fixed it

This is in no small part due to all your hints and tips, so thanks all of you here at EAB - you've been very helpful!

---
For those who want to know the final problem and solutions:
There were two problems in my code. The first was the double acknowledge. It caused the Blitter queue to inevitably stop running after a random amount of time had passed by allowing higher level interrupts to run in between the two acknowledge writes. This code would take longer than the blit and thus, the queue would break.

I had never noted this before, because my earlier blits were fairly big and thus even a relatively long higher level interrupt would fit in the time of the blit.

The second problem was the Blitter interrupt being triggered while. Well, as it turns out, phx gave the conclusive hint here when he questioned whether or not that was triggered elsewhere in my code. I checked all my code and found a botched attempt at an atomic action in my non-interrupt code. During this bugged code, I disabled interrupts - but first read their state in INTREQR. Then when re-enabling interrupts, I also wrote back those earlier values.

I have no idea why I did that, but it sure as <explicative> wasn't the right thing to do . That code could (and in indeed did) get interrupted right after the read of the interrupt status but before they were actually disabled. So, in rare situations, the CPU would read the INTREQ value containing the Blitter interrupt triggering just before the interrupt was actually serviced. And write this value back into INTREQ during a blit after the blitter interrupt rte'd. And boom was the result.

It's all quite logical if you understand how the 68000 and Amiga deal with interrupts, but I clearly didn't when I wrote this code and it caused all this mayhem. In my defence, the bit of code that crashed was two years old

As to why it didn't happen before? Well, that was just pure luck and nothing more. Sooner or later, this code would've crashed the machine. The above rarity is also why changing unrelated code would make the problem appear/reappear - as the timing changed, it became either more or less likely that the above situation could trigger.

---
The fixes are:
1) disable interrupts and re-enable interrupts during the main program without reading and then afterwards writing the interrupt request value.

2) use one interrupt acknowledge write, at the start of the Blitter handler rather than at the end.

I've done both and the program just works now. No more mysterious behaviour. Again, thanks to all who assisted - I learned some new things and now have better idea how to debug these things should they happen again. Should the code for the fixes be valuable, I'd be happy to share it - though it is fairly simple in the end.
roondar is offline  
Old 28 November 2018, 14:05   #26
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 842
I see a potential problem..

I think
Code:
btst	#6,intreq+1(a6)
should be
Code:
btst	#6,intreqr+1(a6)
;-)
hooverphonique is offline  
Old 28 November 2018, 15:44   #27
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
Ah, that is a typo in the copy I made for the thread. The actual code does indeed btst on intreqr+1
roondar is offline  
Old 28 November 2018, 18:01   #28
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 842
Quote:
Originally Posted by roondar View Post
Ah, that is a typo in the copy I made for the thread. The actual code does indeed btst on intreqr+1

Be careful to modify code, you post to get help, to such a detailed degree - you may hide the problem(s) from the people you're asking
hooverphonique is offline  
Old 28 November 2018, 18:54   #29
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 773
Quote:
Originally Posted by hooverphonique View Post
Be careful to modify code, you post to get help, to such a detailed degree - you may hide the problem(s) from the people you're asking
Indeed, you are correct here - a direct copy would've been better.
roondar is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
CIA interrupts... bloodline Coders. System 6 18 January 2018 11:33
UAE on Smart TV Stick ?? SkulleateR support.OtherUAE 4 03 February 2016 00:43
Interrupts and Multitasking: Examples? tygre Coders. General 13 22 December 2015 05:56
smart file system wilch support.WinUAE 5 07 March 2011 10:55
Advice on interrupts and jumps alexh Coders. General 11 20 May 2008 10:42

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 07:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07153 seconds with 15 queries