Some audio interrupt problem on winaue with RollingThunder? - Page 2

Asman · 23 January 2020, 12:59

@CFOU!
But and.w d5,($96,a3) cause read from write only hardware register.

Quote:

But now i don't understand why it's work on real amiga with MOVE!!

perhaps its about some kind of side effect like in this EAB thread Amiga audio hardware trivia

Tomislav · 23 January 2020, 13:01

Quote:

Originally Posted by CFOU!

@Asman
I think i have understand , but in my opinion is better to replace:

move.w d5,($96,a3)

by

AND.w d5,($96,a3)

To enable good audio channel without switch off another channels

and it's works fine too on Winuae.

But now i don't understand why it's work on real amiga with MOVE!!

PS/
I will test this evening on real Amiga to verify it works fine with "AND" too.

No! "AND" reads what is on that address and DFF096 (DMACON) is write only.

Read more here http://amiga-dev.wikidot.com/hardware:dmaconr

CFou! · 23 January 2020, 13:08

Quote:

Originally Posted by Asman

@CFOU!
But and.w d5,($96,a3) cause read from write only hardware register.

you are right!

CFou! · 23 January 2020, 13:15

in fact AND is without effect because DMACOM can not be read.... so is like a NOP!

sorry!

stupid! as the Lemmings would say

CFou! · 23 January 2020, 13:21

Quote:

Originally Posted by Asman

]
perhaps its about some kind of side effect like in this EAB thread Amiga audio hardware trivia

interesting.

Tomislav · 23 January 2020, 13:53

Bit 15 of DMACON sets/clears bits marked by 1 (bits which are 0 are unaffected).

Maybe timing. ADD reads and writes, while MOVE only writes to an address in this case. Maybe to do something like this:

Code:

lbC0000E4
        move.w d5,($96,a3)
        addi.w #4,(a1)          ; Moved addi.w here for little delay
        move.w d6,($9A,a3)
        move.w d6,($9C,a3)
                                ; Here was addi.w
        move.w d2,($A6,a4)
        lsl.w #3,d1
        lea ($AC02),a0
        move.l (a0,d1.w),($A0,a4)
        move.l (4,a0,d1.w),d0
        move.w d0,($A4,a4)
        move.w #$8000,d0
        or.w d6,d0
        move.w d0,($9A,a3)
        move.w #$8000,d0
        or.w d5,d0
        move.w d0,($96,a3)
        rts

hooverphonique · 23 January 2020, 14:04

Quote:

Originally Posted by CFOU!

in fact AND is without effect because DMACOM can not be read.... so is like a NOP!

sorry!

stupid! as the Lemmings would say

It's not a NOP - it will read whatever was leftover on the bus, and it with d5, then write the result to dmacon.

Asman · 23 January 2020, 14:17

If I understand correctly. This is what is happen first time when IRQ4 occurs.

1. IRQ4 triggered, DMA audX is on. -> ams (audio machine state) is iddle (000).
2. audX intreq cleared --> ams is changed to main loop ??? (state 010 or 011)
3. kill the interrupts in ugly way ($4000 --> intena)
4. go to lbC0000E4
5. DMA audX cleared --> ams reset back to iddle (000)
6. audX intreq cleared --> ams is changed to main loop ???
7. audX intena cleared
8. write data to audio registers --> ams is changed to ???
9 set audX to intena
10. set DMA audX --> ams state 001
11 back from lbC0000E4
12. loop for other audx
13 allow interrupts ($c000 --> intena)

am I correct ?

Toni Wilen · 23 January 2020, 18:55

No

Audio state almost never changes immediately after DMA is switched on or off. Only exception is 0 to 1. Usual conditions are: period must count to zero first or Agnus needs to do AUDxDAT write. CPU writes makes no difference (except if DMA is off and AUDxDAT is written. CPU writes to AUDxDAT do nothing if DMA is on)

Audio state diagram conditions need to be followed exactly. Text inside parenthesis are conditions. dot is AND, + is OR, line above text is NOT.

For example audio state can't be in idle state if interrupt is result of DMA mode audio. Only way to idle state is DMA off and also period counter must count to zero first. Period count down can not be canceled or aborted and also only state 3->0 change is possible. 2 to directly 0 is not possible. (It becomes 2->3->0 = extra period countdown needed)

(I'll try to debug this more later this week..)

Toni Wilen · 08 February 2020, 14:18

I finally checked this quickly bit but I am not really sure how it is supposed to work, code makes no sense, most likely because coder didn't understand how audio interrupts work.. You can't simply switch off DMA and then switch it back on and expect it to work without side-effects.

There is state variable that gets set to 999 ($3e7) but where does it get cleared? (If it is set, channel's interrupt is ignored = interrupt stays active forever) Or is this situation that isn't supposed to happen?

Asman · 08 February 2020, 21:25

@Toni
Great that you find some time to checked this. According to your question about clearing the variable 999 I checked resourced game from ipf version 2640 and extracted whole 'sound.s'

Code:

;
; sound.s
;

lbB004CAC:	DC.B	0
	DC.B	1
	DC.B	0
	DC.B	0
	DC.B	0
	DC.B	0
	DC.B	0
	DC.B	15
	DC.B	0
	DC.B	4
	DC.B	0
	DC.B	0
	DC.B	0
	DC.B	0
	DC.B	$1B
	DC.B	$28
	DC.B	0
	DC.B	4
	DC.B	$36
	DC.B	$50
	DC.B	0
	DC.B	0
	DC.B	2
	DC.B	$E6
	DC.B	0
	DC.B	4
	DC.B	$3C
	DC.B	$1C
	DC.B	0
	DC.B	0
	DC.B	9
	DC.B	$F6
	DC.B	0
	DC.B	4
	DC.B	$50
	DC.B	8
	DC.B	0
	DC.B	0
	DC.B	$1E
	DC.B	$72
	DC.B	0
	DC.B	4
	DC.B	$8C
	DC.B	$EC
	DC.B	0
	DC.B	0
	DC.B	2
	DC.B	$80
	DC.B	0
	DC.B	4
	DC.B	$91
	DC.B	$EC
	DC.B	0
	DC.B	0
	DC.B	$1C
	DC.B	$20
	DC.B	0
	DC.B	4
	DC.B	$CA
	DC.B	$2C
	DC.B	0
	DC.B	0
	DC.B	$1F
	DC.B	$5E
	DC.B	0
	DC.B	5
	DC.B	8
	DC.B	$E8
	DC.B	0
	DC.B	0
	DC.B	7
	DC.B	$F3
	DC.B	0
	DC.B	4
	DC.B	$3C
	DC.B	$1C
	DC.B	0
	DC.B	0
	DC.B	1
	DC.B	$F4
lbW004CFC:	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1BF
	DC.W	1
	DC.W	$1AB
	DC.W	1
	DC.W	$1AB
	DC.W	$3F
	DC.W	$3F
lbW004D20:	DC.W	3
	DC.W	$1BF
	DC.W	3
	DC.W	$190
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
lbW004D30:	DC.W	4
	DC.W	$1BF
	DC.W	4
	DC.W	$1BF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	5
	DC.W	$1BF
	DC.W	5
	DC.W	$1BF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
lbW004D50:	DC.W	2
	DC.W	$1BF
	DC.W	2
	DC.W	$1BF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
lbW004D60:	DC.W	6
	DC.W	$1BF
	DC.W	6
	DC.W	$1BF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
lbW004D70:	DC.W	7
	DC.W	$1BF
	DC.W	7
	DC.W	$1BF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
	DC.W	$FF
lbB004D80:	DC.B	0
	DC.B	8
	DC.B	1
	DC.B	$BF
	DC.B	0
	DC.B	8
	DC.B	1
	DC.B	$BF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
lbB004D90:	DC.B	0
	DC.B	9
	DC.B	1
	DC.B	$BF
	DC.B	0
	DC.B	9
	DC.B	1
	DC.B	$BF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
	DC.B	0
	DC.B	$FF
lbL004DA0:	DC.L	0
	DC.L	0
	DC.L	0
	DC.L	0
	DC.L	0
	DC.L	0
	DC.L	0
lbW004DBC:	DC.W	999
	DC.W	999
	DC.W	999
	DC.W	999
lbW004DC4:	DC.W	0
	DC.W	0
	DC.W	0
	DC.W	0
	DC.W	0

lbC004DCE:	lea	$DFF000,a0
	move.w	#15,$96(a0)
	move.w	#$780,$9A(a0)
	move.w	#$780,$9C(a0)
	lea	lbW004DBC,a0
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	lea	lbL004DA0,a0
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	rts

lbC004E0C:	moveq	#1,d5
	move.l	#$80,d6
	lea	lbW004DBC,a1
	lea	lbL004DA0,a2
	lea	$DFF000,a3
	lea	$DFF000,a4
	move.w	#$4000,$9A(a3)
lbC004E32:	cmp.w	#$3E7,(a1)
	bne	lbC004E5A
	move.w	d0,8(a1)
	and.w	#$3F,d0
	move.w	d0,$A8(a4)
	clr.w	(a1)
	move.l	a0,(a2)
	bsr	lbC004E7A
	move.w	d6,$9C(a3)
	move.w	#$C000,$9A(a3)
	rts

lbC004E5A:	addq.l	#4,a2
	addq.l	#2,a1
	add.l	#$10,a4
	lsl.l	#1,d5
	lsl.l	#1,d6
	cmp.l	#$10,d5
	bne	lbC004E32
	move.w	#$C000,$9A(a3)
	rts

lbC004E7A:	move.w	(a1),d0
	move.l	(a2),a0
	move.w	0(a0,d0.w),d1
	move.w	2(a0,d0.w),d2
	cmp.w	#$3F,d1
	bne	lbC004E96
	move.w	#4,(a1)
	bra	lbC004E7A

lbC004E96:	cmp.w	#$FF,d1
	bne	lbC004EB2
	move.w	#$3E7,(a1)
	clr.l	(a2)
	move.w	d5,$96(a3)
	move.w	d6,$9A(a3)
	move.w	d6,$9C(a3)
	rts

lbC004EB2:	move.w	d5,$96(a3)
	move.w	d6,$9A(a3)
	move.w	d6,$9C(a3)
	add.w	#4,(a1)
	move.w	d2,$A6(a4)
	lsl.w	#3,d1
	lea	lbB004CAC,a0
	move.l	0(a0,d1.w),$A0(a4)
	move.l	4(a0,d1.w),d0
	move.w	d0,$A4(a4)
	move.w	#$8000,d0
	or.w	d6,d0
	move.w	d0,$9A(a3)
	move.w	#$8000,d0
	or.w	d5,d0
	move.w	d0,$96(a3)
	rts

lbC004EF2:	movem.l	d0-d7/a0-a6,-(sp)
	lea	$DFF000,a0
	move.w	$1E(a0),d0
	btst	#3,d0
	beq	lbC004F0C
	bsr	lbC000C20
lbC004F0C:	moveq	#1,d5
	move.l	#$80,d6
	lea	lbW004DBC,a1
	lea	lbL004DA0,a2
	lea	$DFF000,a3
	move.w	#$4000,$9A(a3)
	lea	$DFF000,a4
lbC004F32:	move.w	$1E(a3),d0
	and.w	d6,d0
	beq	lbC004F52
	move.w	d6,$9C(a3)
	cmp.w	#999,(a1)
	beq	lbC004F52
	tst.w	(a1)
	beq	lbC004F52
	bsr	lbC004E7A
lbC004F52:	addq.l	#4,a2
	addq.l	#2,a1
	add.l	#$10,a4
	lsl.l	#1,d5
	lsl.l	#1,d6
	cmp.l	#$10,d5
	bne	lbC004F32
	move.w	#$C000,$9A(a3)
	movem.l	(sp)+,d0-d7/a0-a6
	rte

lbC004F76:	move.w	#3,d0
	lea	$DFF000,a0
	lea	lbW004DC4,a1
lbC004F86:	move.w	(a1)+,d0
	cmp.w	#$40,d0
	bcs	lbC004FAA
	addq.w	#1,d0
	move.w	d0,-2(a1)
	and.w	#$3F,d0
	move.w	d0,$A8(a0)
	cmp.w	#$28,d0
	bcs	lbC004FAA
	move.w	d0,-2(a1)
lbC004FAA:	add.l	#$10,a0
	dbra	d0,lbC004F86
	rts

Check routine at lbC004E0C there you can find clr.w (a1). Routine lbC004E0C is called about 9 times with a0 - table, d0 - volume. Resourced game in the zone. Labels names and comments taken from original source codes which you can easily find if you disksalv original ipf image.

jotd · 08 February 2020, 22:32

CFou! custom chips are write only. You cannot AND on DMACON. You have to read DMACONR and write to DMACON. Else you get random bits, and probably different stuff on winuae

(sorry, didn't see the other messages stating the same thing, but that would differentiate winuae from real amiga I think)

Toni Wilen · 09 February 2020, 09:06

Thanks, now it is more clear. "lbC004EB2: useless move.w d5,$96(a3)" detects too short DMA wait hack because it looks like missing DMA wait (switch off DMA, [too small delay would have been here normally], load new sample, re-enable DMA again). Because hack detected it as a missing DMA wait, it starts sample from the beginning, generating new interrupt almost immediately (next audio DMA slot).

But in reality game only wants to play new sample after previous sample has finished, not immediately.

I added one more condition to DMA hack test: only detect DMA wait fix hack if CPU executed at least 60 instructions (=commonly used CPU delay loop runs few hundred times) between DMA off and DMA on. If JIT is enabled, it works like previously, JIT can't count executed instructions. This should work around the problem with programs that don't know what they are doing...

jotd · 09 February 2020, 10:31

it would be cool if you could log something about it in winuae log, so we poor code fixers may know that there's an issue in the code.

great work, as always!

ross · 09 February 2020, 11:48

Quote:

Originally Posted by Toni Wilen

I added one more condition to DMA hack test: only detect DMA wait fix hack if CPU executed at least 60 instructions ...

Can't the DMA hack be completely avoided?
I guess it was inserted for performance reasons (or are there other reasons?).

So a flag for even greater compatibility could be added (there is also the recent case one regarding the delay in the IPL), similarly to the flags for full collisions.

Toni Wilen · 09 February 2020, 11:50

Ok, it will be logged but only first 100 or so log messages because this could cause huge log flood with bad players in fastest possible mode.

This is quite special hack because it is so common problem and most users (that use config that appears to mostly work but which is not really correct config..) would blame emulation if it is not automatically enabled.

EDIT: It is enabled if: CPU is 68020+ or CPU speed is not approximate/cycle-exact.

23 January 2020, 13:15	#24
CFou! Moderator Join Date: Sep 2004 Location: France Age: 50 Posts: 4,277	in fact AND is without effect because DMACOM can not be read.... so is like a NOP! sorry! stupid! as the Lemmings would say Last edited by CFou!; 23 January 2020 at 13:37.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Blitter interrupt during VERTB interrupt	phx	Coders. Asm / Hardware	38	01 October 2021 19:54
A1200 audio problem	elspero	support.Hardware	57	12 October 2020 17:57
audio device in use problem	Hungry Horace	project.WHDLoad	14	28 January 2019 11:41
A1200 audio problem	jonun	support.Hardware	7	31 January 2017 11:53
E-uae audio problem	lomdav	support.OtherUAE	0	27 August 2010 10:01

23 January 2020, 14:17	#28
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 828	If I understand correctly. This is what is happen first time when IRQ4 occurs. 1. IRQ4 triggered, DMA audX is on. -> ams (audio machine state) is iddle (000). 2. audX intreq cleared --> ams is changed to main loop ??? (state 010 or 011) 3. kill the interrupts in ugly way ($4000 --> intena) 4. go to lbC0000E4 5. DMA audX cleared --> ams reset back to iddle (000) 6. audX intreq cleared --> ams is changed to main loop ??? 7. audX intena cleared 8. write data to audio registers --> ams is changed to ??? 9 set audX to intena 10. set DMA audX --> ams state 001 11 back from lbC0000E4 12. loop for other audx 13 allow interrupts ($c000 --> intena) am I correct ?

23 January 2020, 18:55	#29
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	No Audio state almost never changes immediately after DMA is switched on or off. Only exception is 0 to 1. Usual conditions are: period must count to zero first or Agnus needs to do AUDxDAT write. CPU writes makes no difference (except if DMA is off and AUDxDAT is written. CPU writes to AUDxDAT do nothing if DMA is on) Audio state diagram conditions need to be followed exactly. Text inside parenthesis are conditions. dot is AND, + is OR, line above text is NOT. For example audio state can't be in idle state if interrupt is result of DMA mode audio. Only way to idle state is DMA off and also period counter must count to zero first. Period count down can not be canceled or aborted and also only state 3->0 change is possible. 2 to directly 0 is not possible. (It becomes 2->3->0 = extra period countdown needed) (I'll try to debug this more later this week..)

08 February 2020, 14:18	#30
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	I finally checked this quickly bit but I am not really sure how it is supposed to work, code makes no sense, most likely because coder didn't understand how audio interrupts work.. You can't simply switch off DMA and then switch it back on and expect it to work without side-effects. There is state variable that gets set to 999 ($3e7) but where does it get cleared? (If it is set, channel's interrupt is ignored = interrupt stays active forever) Or is this situation that isn't supposed to happen?

08 February 2020, 22:32	#32
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	CFou! custom chips are write only. You cannot AND on DMACON. You have to read DMACONR and write to DMACON. Else you get random bits, and probably different stuff on winuae (sorry, didn't see the other messages stating the same thing, but that would differentiate winuae from real amiga I think)

09 February 2020, 09:06	#33
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	Thanks, now it is more clear. "lbC004EB2: useless move.w d5,$96(a3)" detects too short DMA wait hack because it looks like missing DMA wait (switch off DMA, [too small delay would have been here normally], load new sample, re-enable DMA again). Because hack detected it as a missing DMA wait, it starts sample from the beginning, generating new interrupt almost immediately (next audio DMA slot). But in reality game only wants to play new sample after previous sample has finished, not immediately. I added one more condition to DMA hack test: only detect DMA wait fix hack if CPU executed at least 60 instructions (=commonly used CPU delay loop runs few hundred times) between DMA off and DMA on. If JIT is enabled, it works like previously, JIT can't count executed instructions. This should work around the problem with programs that don't know what they are doing...

09 February 2020, 10:31	#34
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,172	it would be cool if you could log something about it in winuae log, so we poor code fixers may know that there's an issue in the code. great work, as always!

09 February 2020, 11:50	#36
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,507	Ok, it will be logged but only first 100 or so log messages because this could cause huge log flood with bad players in fastest possible mode. This is quite special hack because it is so common problem and most users (that use config that appears to mostly work but which is not really correct config..) would blame emulation if it is not automatically enabled. EDIT: It is enabled if: CPU is 68020+ or CPU speed is not approximate/cycle-exact.

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