Some audio interrupt problem on winaue with RollingThunder?
 

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.

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 :nervous

Only Toni can help us :)

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 :D
But as so bad could be interesting for emulation oddity.

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?

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).

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!!

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

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

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...)

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).

Attached.

Cheers.

effectively.

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

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

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

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.

:great

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

@CFOU!
There is small mistake, I removed only one instruction. :)
Now I need to learn more about audio state machine and understand why solution works.

@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.