Some audio interrupt problem on winaue with RollingThunder?

CFou! · 22 January 2020, 00:30

Hi,

I 'am working on Rolling Thunder whdload's patch .

For patch was finished but:

On several real amiga configuration i am not sound trouble:
a1200+Blizzard 1260
a1200+Blizzard 1230
a1200+8Mo 60020

but on Winuae audio interrupt code can freeze or no sound are displayed except with 68000 CPU configuration.

i test several configuration using following options it's all cases:
- CPU: approcimate A500/a1200 or exact-cycle
- Chipset: Wait for Blitter/AGA/Collision level=full/exact-cycle
- Chipset extra/Generic, 1200 or 4000

interrupt code is curiously coded but it seems it works fine on all my real amiga.

have you same problem with winaue or real configuration?

HAve you solution to fix it?

PS: attached installed version of both IPF version of Rolling Thunder for test.

ross · 22 January 2020, 12:10

This is interesting and strictly related to this thread:
http://eab.abime.net/showthread.php?t=100442
I based my code snippet on how the IRQ4 system work on WinUAE.

So sure the slave can be patched.
But since the code of this slave works in every real Amiga tested (000 till 060 and also Vampire) it could be a WinUAE problem.

Practically on WinUAE/020+ (not on bare 000!):
- IRQ4 trigger and code execute
- inside IRQ, DMA is stopped and INTREQ cleared
- then DMA is reactivated
- when Audio DMA fetch new data, INTREQ/AUDx bit is set
- IRQ code exit and immediately a new IRQ4 start
- IRQ storm

Only Toni can help us

Asman · 22 January 2020, 12:52

I checked some old source code from RT. Warning there are some stupid comments - so omit it. Sorry but I don't remember about version of RT. As I checked the source right now, I see some my modifications like disabling sound routines (;A rts ;A)

Code:

;
;sound.s
;
sndSamplesTable:
	DC.L	$10000	;address
	DC.L	15	;ac_len
	DC.L	SOUND_ADR
	DC.L	$1B28
	DC.L	SOUND_ADR+$3650
	DC.L	$2E6
	DC.L	SOUND_ADR+$3C1C
	DC.L	$9F6
	DC.L	SOUND_ADR+$5008
	DC.L	$1E72
	DC.L	SOUND_ADR+$8CEC
	DC.L	$280
	DC.L	SOUND_ADR+$91EC
	DC.L	$1C20
	DC.L	SOUND_ADR+$CA2C
	DC.L	$1F5E
	DC.L	SOUND_ADR+$108E8
	DC.L	$7F3
	DC.L	SOUND_ADR+$3C1C
	DC.L	$1F4

lbL004C52:	DC.L	$101BF
	DC.L	$101BF
	DC.L	$101BF
	DC.L	$101BF
	DC.L	$101BF
	DC.L	$101BF
	DC.L	$101AB
	DC.L	$101AB
	DC.L	$3F003F
sfxShoot:	DC.L	$301BF
	DC.L	$30190
	DC.L	$FF00FF
	DC.L	$FF00FF
lbL004C86:	DC.L	$401BF
	DC.L	$401BF
	DC.L	$FF00FF
	DC.L	$FF00FF
	DC.L	$501BF
	DC.L	$501BF
	DC.L	$FF00FF
	DC.L	$FF00FF
sfxOpenDoor:	DC.L	$201BF
	DC.L	$201BF
	DC.L	$FF00FF
	DC.L	$FF00FF
lbL004CB6:	DC.L	$601BF
	DC.L	$601BF
	DC.L	$FF00FF
	DC.L	$FF00FF
lbL004CC6:	DC.L	$701BF
	DC.L	$701BF
	DC.L	$FF00FF
	DC.L	$FF00FF
sfxDoorUp:	DC.L	$801BF
	DC.L	$801BF
	DC.L	$FF00FF
	DC.L	$FF00FF
lbL004CE6:	DC.L	$901BF
	DC.L	$901BF
	DC.L	$FF00FF
	DC.L	$FF00FF

sndSampleAdress:
		DC.L	0	;channel 0 sample address
		DC.L	0	;channel 1 sample address
		DC.L	0	;channel 2 sample address
		DC.L	0	;channel 3 sample address

	;unused ???
	DC.L	0
	DC.L	0
	DC.L	0

sndSampleOffset:
		dc.w	999	;channel 0
		dc.w	999	;channel 1
		dc.w	999	;channel 2
		dc.w	999	;channel 3

sndVolumes:
		dc.w	0	;channel 0
		dc.w	0	;channel 1
		dc.w	0	;channel 2
		dc.w	0	;channel 3

		DC.W	0	;used as protection for SoundVolumeUp routine (must be zero)

;-----------------------------------------------------------------------------
;TODO something with sound

SoundReset:
;A:
		rts
;A:
	lea	($DFF000).l,a0
	move.w	#DMAF_AUD0|DMAF_AUD1|DMAF_AUD2|DMAF_AUD3,(dmacon,a0)
	move.w	#INTF_AUD0|INTF_AUD1|INTF_AUD2|INTF_AUD3,(intena,a0)
	move.w	#INTF_AUD0|INTF_AUD1|INTF_AUD2|INTF_AUD3,(intreq,a0)
	lea	(sndSampleOffset).l,a0
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	move.w	#999,(a0)+
	lea	(sndSampleAdress).l,a0
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	rts
;
;in	d0 - volume  ( 0 - $3f ) (CheckBreakKeys use $80 check it!!!)
;	a0 - sample address
;

PlaySample:

;A
		rts
;A

	moveq	#DMAF_AUD0,d5
	move.l	#INTF_AUD0,d6
	lea	(sndSampleOffset).l,a1
	lea	(sndSampleAdress).l,a2
	lea	($DFF000).l,a3
	lea	($DFF000).l,a4
	move.w	#INTF_INTEN,(intena,a3)
.loop:	cmpi.w	#999,(a1)
	bne.b	.next
	move.w	d0,(8,a1)	;nasty but works ( access to sndVolumes )
	andi.w	#$3F,d0
	move.w	d0,(aud0+ac_vol,a4)
	clr.w	(a1)
	move.l	a0,(a2)		;store sample address
	bsr.b	lbC004DD0
	move.w	d6,(intreq,a3)
	move.w	#INTF_SETCLR|INTF_INTEN,(intena,a3)
	rts

.next:	addq.l	#4,a2		;next sample address channel
	addq.l	#2,a1
	adda.l	#$10,a4
	lsl.l	#1,d5		;next channel bit for dma
	lsl.l	#1,d6		;next channel bit fot int
	cmpi.l	#$10,d5		;all snd channels 
	bne.b	.loop
	move.w	#INTF_SETCLR|INTF_INTEN,(intena,a3)
	rts

;
;in
;	a1 - sndSampleOffset
;	a2 - sndSampleAdress
;	a3 - _custom
;	d5 - dma bits
;	d6 - int bits

lbC004DD0:	move.w	(a1),d0
	movea.l	(a2),a0
	move.w	(a0,d0.w),d1
	move.w	(2,a0,d0.w),d2
	cmpi.w	#$3F,d1
	bne.b	lbC004DEC
	move.w	#4,(a1)
	bra.b	lbC004DD0

lbC004DEC:	cmpi.w	#$FF,d1
	bne.b	lbC004E08
	move.w	#999,(a1)
	clr.l	(a2)
	move.w	d5,(dmacon,a3)
	move.w	d6,(intena,a3)
	move.w	d6,(intreq,a3)
	rts

lbC004E08:
	;move.w	d5,(dmacon,a3)
	;move.w	d6,(intena,a3)
	;move.w	d6,(intreq,a3)
	addi.w	#4,(a1)
	move.w	d2,(aud0+ac_per,a4)
	lsl.w	#3,d1
	lea	(sndSamplesTable).l,a0
	move.l	(a0,d1.w),(aud0,a4)
	move.l	(4,a0,d1.w),d0
	move.w	d0,(aud0+ac_len,a4)
	move.w	#$8000,d0
	or.w	d6,d0
	move.w	d0,(intena,a3)
	move.w	#$8000,d0
	or.w	d5,d0
	move.w	d0,(dmacon,a3)
	rts

;
;this int should be splitted into two ints ( IntLvlTwoPorts IntLvlFourAudio ) to
;handle this shit correctly
;


IntLvlTwoPorts:
		movem.l	d0-d1/a0-a2,-(a7)
	
		lea	(_custom),a0
		move.w	(intreqr,a0),d0
		btst	#INTB_PORTS,d0
		beq.b	.end
		
		lea	(_ciaa),a1
		btst	#CIAICRB_SP,(ciaicr,a1)
		beq.b	.end

	;read key and store him
		move.b	(ciasdr,a1),d0
		or.b	#CIACRAF_SPMODE,(ciacra,a1)
		not.b	d0
		ror.b	#1,d0
		spl	d1
		and.w	#$7f,d0
		lea	(keytab).l,a2
		move.b	d1,(a2,d0.w)

	;handshake
		moveq	#3-1,d1
.wait1		move.b	(vhposr,a0),d0
.wait2		cmp.b	(vhposr,a0),d0
		beq.b	.wait2
		dbf	d1,.wait1

	;set input mode
		and.b	#~(CIACRAF_SPMODE),(ciacra,a1)

.end		move.w	#INTF_PORTS,(intreq,a0)
		tst.w	(intreqr,a0)
		nop
		movem.l	(a7)+,d0-d1/a0-a2
		rte

;-----------------------------------------------------------------------------
;TODO

IntLvlFourAudio:
		movem.l	d0-d7/a0-a6,-(sp)
		
		moveq	#DMAF_AUD0,d5
		move.l	#INTF_AUD0,d6
		lea	(sndSampleOffset).l,a1
		lea	(sndSampleAdress).l,a2
		lea	($DFF000).l,a3
		;A
		;move.w	#$4000,(intena,a3)
		lea	($DFF000).l,a4
lbC004E88:	move.w	(intreqr,a3),d0
		and.w	d6,d0
		beq.b	lbC004EA8
		move.w	d6,(intreq,a3)		;finish audio int
		cmpi.w	#999,(a1)
		beq.b	lbC004EA8
		tst.w	(a1)
		beq.b	lbC004EA8
		bsr.w	lbC004DD0
lbC004EA8:	addq.l	#4,a2
		addq.l	#2,a1
		adda.l	#$10,a4
		lsl.l	#1,d5
		lsl.l	#1,d6
		cmpi.l	#$10,d5
		bne.b	lbC004E88
		;A
		;move.w	#$C000,($9A,a3)
		;A
		lea	(_custom),a0
		move.w	#INTF_AUD0|INTF_AUD1|INTF_AUD2|INTF_AUD3,(intreq,a0)
		tst.w	(intreqr,a0)
		movem.l	(sp)+,d0-d7/a0-a6
		rte
		
;A}


;int:		movem.l	d0-d7/a0-a6,-(sp)
;		lea	($DFF000).l,a0
;		move.w	(intreqr,a0),d0
;		btst	#3,d0
;		beq.w	.int_audio
;		bsr.w	ports_routine
;
;.int_audio:
;		moveq	#1,d5
;		move.l	#$80,d6	;INTF_AUD0
;		lea	(sndSampleOffset).l,a1
;		lea	(sndSampleAdress).l,a2
;		lea	($DFF000).l,a3
;		move.w	#$4000,(intena,a3)
;		lea	($DFF000).l,a4
;lbC004E88:	move.w	(intreqr,a3),d0
;		and.w	d6,d0
;		beq.w	lbC004EA8
;		move.w	d6,(intreq,a3)		;finish audio int
;		cmpi.w	#$3E7,(a1)
;		beq.w	lbC004EA8
;		tst.w	(a1)
;		beq.w	lbC004EA8
;		bsr.w	lbC004DD0
;lbC004EA8:	addq.l	#4,a2
;		addq.l	#2,a1
;		adda.l	#$10,a4
;		lsl.l	#1,d5
;		lsl.l	#1,d6
;		cmpi.l	#$10,d5
;		bne.w	lbC004E88
;		move.w	#$C000,($9A,a3)
;		movem.l	(sp)+,d0-d7/a0-a6
;		rte


SoundVolumeUp:
		move.w	#4-1,d0		;four audio channels

		lea	($DFF000).l,a0
		lea	(sndVolumes).l,a1
.loop:
	;check if volume is max
		move.w	(a1)+,d0
		cmpi.w	#$40,d0
		bcs.b	.next
	;increase volume
		addq.w	#1,d0
		move.w	d0,(-2,a1)	;store it
		andi.w	#$3F,d0
		move.w	d0,($A8,a0)	;set in audio register
		cmpi.w	#$28,d0
		bcs.b	.next
		move.w	d0,(-2,a1)
.next:		adda.l	#$10,a0		;next audio channel (stupid but works)
		dbra	d0,.loop
		rts

ross · 22 January 2020, 13:07

Quote:

Originally Posted by Asman

I checked some old source code from RT. Warning there are some stupid comments - so omit it. Sorry but I don't remember about version of RT. As I checked the source right now, I see some my modifications like disabling sound routines (;A rts ;A) ...

Yep, IRQ handler is terrible... like the rest of game code

But as so bad could be interesting for emulation oddity.

CFou! · 22 January 2020, 15:56

Quote:

Originally Posted by Asman

I checked some old source code from RT. Warning there are some stupid comments - so omit it. Sorry but I don't remember about version of RT. As I checked the source right now, I see some my modifications like disabling sound routines (;A rts ;A)

you seem to have reworked audio interupt:

IntLvlFourAudio:
movem.l d0-d7/a0-a6,-(sp)

moveq #DMAF_AUD0,d5
move.l #INTF_AUD0,d6
lea (sndSampleOffset).l,a1
lea (sndSampleAdress).l,a2
lea ($DFF000).l,a3
;A
;move.w #$4000,(intena,a3)
lea ($DFF000).l,a4
lbC004E88: move.w (intreqr,a3),d0
and.w d6,d0
beq.b lbC004EA8
move.w d6,(intreq,a3) ;finish audio int
cmpi.w #999,(a1)
beq.b lbC004EA8
tst.w (a1)
beq.b lbC004EA8
bsr.w lbC004DD0
lbC004EA8: addq.l #4,a2
addq.l #2,a1
adda.l #$10,a4
lsl.l #1,d5
lsl.l #1,d6
cmpi.l #$10,d5
bne.b lbC004E88
;A
;move.w #$C000,($9A,a3)
;A
lea (_custom),a0
move.w #INTF_AUD0|INTF_AUD1|INTF_AUD2|INTF_AUD3,(intreq,a0)
tst.w (intreqr,a0)
movem.l (sp)+,d0-d7/a0-a6
rte

have you tested in on real amiga and Winuae to compare?

perhaps had you fixed curious behaviour of original audio code on Winuae?

If it's the case, if so it might be interesting to include it in the Slave file?

Toni Wilen · 22 January 2020, 16:47

It hits hack in UAE that fixes very common problem of stupid CPU delays in "dma wait" routines if CPU is not slow enough.

If DMA gets switched off and then on again too soon: Assume software actually wanted to start sample from the beginning.

I didn't check the disassembly. Not interested enough.

ross · 22 January 2020, 17:11

Quote:

Originally Posted by Toni Wilen

It hits hack in UAE that fixes very common problem of stupid CPU delays in "dma wait" routines if CPU is not slow enough.

If DMA gets switched off and then on again too soon: Assume software actually wanted to start sample from the beginning.

I didn't check the disassembly. Not interested enough.

In this IRQ routine there are 94 involuntary "DMA wait" cycles between Audio stop and restart, on 7MHz 68000.
Obviously in any faster processor they are less.

What's the 'cycles point' in WinUAE emulation where 000 vs 020+ are working the same way? Or this 'hack' is only for pure 68k?

I'd like to understand better why you can't emulate precisely also on fast processors (anyway the 'times' surely depends on DMA cycles and not by CPU cycles).

CFou! · 22 January 2020, 17:24

Quote:

Originally Posted by Toni Wilen

It hits hack in UAE that fixes very common problem of stupid CPU delays in "dma wait" routines if CPU is not slow enough.

If DMA gets switched off and then on again too soon: Assume software actually wanted to start sample from the beginning.

I didn't check the disassembly. Not interested enough.

on real 1200+ blizzard 68060 , i have not audio bugs with original code, only with winuae with all CPU except 68000.

for information if you replace in original code last ;

move.w #$C000,($9A,a3)

by
move.w #$C000,($9C,a3)

sound start correctly but are not stopped and loop infinitely!!

Toni Wilen · 22 January 2020, 17:37

Quote:

Originally Posted by ross

In this IRQ routine there are 94 involuntary "DMA wait" cycles between Audio stop and restart, on 7MHz 68000.
Obviously in any faster processor they are less.

What's the 'cycles point' in WinUAE emulation where 000 vs 020+ are working the same way? Or this 'hack' is only for pure 68k?

I'd like to understand better why you can't emulate precisely also on fast processors (anyway the 'times' surely depends on DMA cycles and not by CPU cycles).

Didn't you say DMA gets switched off and get switched back on. Without no waits.

ross · 22 January 2020, 17:38

Quote:

Originally Posted by CFOU!

sound start correctly but are not stopped and loop infinitely!!

Because there is no more an IRQ4 triggered (so no more DMA audio stop, and the sample repeat forever).

ross · 22 January 2020, 17:46

Quote:

Originally Posted by Toni Wilen

Didn't you say DMA gets switched off and get switched back on. Without no waits.

Code:

- inside IRQ, DMA is stopped and INTREQ cleared
- then DMA is reactivated

I've specified 'then', not knowing on hack related to "DMA wait".
In this case 94 DMA cycles after.

I thought it meant in English 'after some time', but sure my language fault.
(Google traslate italian 'poi' to then/after/later/next...)

Toni Wilen · 22 January 2020, 17:49

Ok. But then that can't be the problem because hack would only mean delay is always long enough to not cause problems even if CPU runs the loop in 1 DMA cycle.

It must be something else. Actual disassembly would still be nice..

I also can't duplicate any hangs which makes it more annoying to debug.

ross · 22 January 2020, 18:01

Quote:

Originally Posted by Toni Wilen

Ok. But then that can't be the problem because hack would only mean delay is always long enough to not cause problems even if CPU runs the loop in 1 DMA cycle.

It must be something else. Actual disassembly would still be nice..

I also can't duplicate any hangs which makes it more annoying to debug.

Ok, so this is not the problem.

Yes, there in no hang, only IRQ storm that slow down the game incredibly.
But is not a constant, because the AUDx bit is set only after DMA fetch, that can also be outside IRQ code (so there is not an immediate IRQ retrigger).

ross · 22 January 2020, 19:12

Quote:

Originally Posted by Toni Wilen

It must be something else. Actual disassembly would still be nice..

Attached.

Cheers.

CFou! · 22 January 2020, 20:05

Quote:

Originally Posted by Toni Wilen

It hits hack in UAE that fixes very common problem of stupid CPU delays in "dma wait" routines if CPU is not slow enough.

If DMA gets switched off and then on again too soon: Assume software actually wanted to start sample from the beginning.

I didn't check the disassembly. Not interested enough.

effectively.

for information, I have just been confirmed that there is no sound bugs on a real A4000 + 040.

CFou! · 22 January 2020, 20:11

Quote:

Originally Posted by Toni Wilen

Ok. But then that can't be the problem because hack would only mean delay is always long enough to not cause problems even if CPU runs the loop in 1 DMA cycle.

It must be something else. Actual disassembly would still be nice..

I also can't duplicate any hangs which makes it more annoying to debug.

to duplicate hangs, you can start game using option:
- CPU/ Fastest possible

and in game change option by:
- CPU/ Approcimate a500/a1200 or cycle exact

CFou! · 22 January 2020, 23:04

Quote:

Originally Posted by ross

Attached.

Cheers.

Asman managed to solve the Winuae audio problem by simply removing these one instruction from this source code:

Code:

IRQ
	movem.l	d0-d7/a0-a6,-(sp)
	lea	($DFF000),a0
	move.w	($1E,a0),d0
	btst	#3,d0
	beq.w	lbC00013E
;	bsr.w	irq2
lbC00013E	moveq	#1,d5
	move.l	#$80,d6
	lea	($AD12),a1
	lea	($ACF6),a2
	lea	($DFF000),a3
	move.w	#$4000,($9A,a3)
	lea	($DFF000),a4
lbC000164	move.w	($1E,a3),d0
	and.w	d6,d0
	beq.w	lbC000184
	move.w	d6,($9C,a3)
	cmpi.w	#$3E7,(a1)
	beq.w	lbC000184
	tst.w	(a1)
	beq.w	lbC000184
	bsr.w	lbC0000AC
lbC000184	addq.l	#4,a2
	addq.l	#2,a1
	adda.l	#$10,a4
	lsl.l	#1,d5
	lsl.l	#1,d6
	cmpi.l	#$10,d5
	bne.w	lbC000164
	move.w	#$C000,($9A,a3)
	movem.l	(sp)+,d0-d7/a0-a6
	rte


	lea	($DFF000),a0
	move.w	#15,($96,a0)
	move.w	#$780,($9A,a0)
	move.w	#$780,($9C,a0)
	lea	($AD12),a0
	move.w	#$3E7,(a0)+
	move.w	#$3E7,(a0)+
	move.w	#$3E7,(a0)+
	move.w	#$3E7,(a0)+
	lea	($ACF6),a0
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	clr.l	(a0)+
	rts

	moveq	#1,d5
	move.l	#$80,d6
	lea	($AD12),a1
	lea	($ACF6),a2
	lea	($DFF000),a3
	lea	($DFF000),a4
	move.w	#$4000,($9A,a3)
lbC000064	cmpi.w	#$3E7,(a1)
	bne.w	lbC00008C
	move.w	d0,(8,a1)
	andi.w	#$3F,d0
	move.w	d0,($A8,a4)
	clr.w	(a1)
	move.l	a0,(a2)
	bsr.w	lbC0000AC
	move.w	d6,($9C,a3)
	move.w	#$C000,($9A,a3)
	rts

lbC00008C	addq.l	#4,a2
	addq.l	#2,a1
	adda.l	#$10,a4
	lsl.l	#1,d5
	lsl.l	#1,d6
	cmpi.l	#$10,d5
	bne.w	lbC000064
	move.w	#$C000,($9A,a3)
	rts

lbC0000AC	move.w	(a1),d0
	movea.l	(a2),a0
	move.w	(a0,d0.w),d1
	move.w	(2,a0,d0.w),d2
	cmpi.w	#$3F,d1
	bne.w	lbC0000C8
	move.w	#4,(a1)
	bra.w	lbC0000AC

lbC0000C8	cmpi.w	#$FF,d1
	bne.w	lbC0000E4
	move.w	#$3E7,(a1)
	clr.l	(a2)
	move.w	d5,($96,a3)
	move.w	d6,($9A,a3)
	move.w	d6,($9C,a3)
	rts

lbC0000E4
 	move.w	d5,($96,a3)
	move.w	d6,($9A,a3)
	move.w	d6,($9C,a3)
	addi.w	#4,(a1)
	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

	end

lbC0000E4
move.w d5,($96,a3)
move.w d6,($9A,a3)
move.w d6,($9C,a3)
addi.w #4,(a1)
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

I tested it on real 1200+ 060 and it works fine too.

ross · 23 January 2020, 00:28

Quote:

Originally Posted by CFOU!

Asman managed to solve the Winuae audio problem by simply removing these two instructions from this source code:
...
I tested it on real 1200+ 060 and it works fine too.

The main code question for me was not the code fixing, but why this instructions sequence give problems on WinUAE

Asman · 23 January 2020, 10:10

@CFOU!
There is small mistake, I removed only one instruction.

Code:

move.w d5,($96,a3) -> nop*2  ;slave src --> PL_NOP	$2377c,4

Now I need to learn more about audio state machine and understand why solution works.

CFou! · 23 January 2020, 12:35

@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 disable good audio channel without disable 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.

23 January 2020, 10:10	#19
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 828	@CFOU! There is small mistake, I removed only one instruction. Code: move.w d5,($96,a3) -> nop*2 ;slave src --> PL_NOP $2377c,4 Now I need to learn more about audio state machine and understand why solution works.

23 January 2020, 12:35	#20
CFou! Moderator Join Date: Sep 2004 Location: France Age: 50 Posts: 4,277	@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 disable good audio channel without disable 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. Last edited by CFou!; 23 January 2020 at 13:08.

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

22 January 2020, 12:10	#2
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	This is interesting and strictly related to this thread: http://eab.abime.net/showthread.php?t=100442 I based my code snippet on how the IRQ4 system work on WinUAE. So sure the slave can be patched. But since the code of this slave works in every real Amiga tested (000 till 060 and also Vampire) it could be a WinUAE problem. Practically on WinUAE/020+ (not on bare 000!): - IRQ4 trigger and code execute - inside IRQ, DMA is stopped and INTREQ cleared - then DMA is reactivated - when Audio DMA fetch new data, INTREQ/AUDx bit is set - IRQ code exit and immediately a new IRQ4 start - IRQ storm Only Toni can help us Last edited by ross; 22 January 2020 at 12:44. Reason: clarified a bit..

22 January 2020, 16:47	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	It hits hack in UAE that fixes very common problem of stupid CPU delays in "dma wait" routines if CPU is not slow enough. If DMA gets switched off and then on again too soon: Assume software actually wanted to start sample from the beginning. I didn't check the disassembly. Not interested enough.

22 January 2020, 17:49	#12
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Ok. But then that can't be the problem because hack would only mean delay is always long enough to not cause problems even if CPU runs the loop in 1 DMA cycle. It must be something else. Actual disassembly would still be nice.. I also can't duplicate any hangs which makes it more annoying to debug.

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