Turrican 2 MS-DOS AGA conversion

[zero]

Originally Posted by Muzza

It is all coded from scratch by playing and observing the original.
The exception is the TFMX music player. I found code for playing TFMX in an Amiga music app which appeared to have been the ASM ripped from the original game and then modified to play through the OS. I undid the modifications and then made additional changes to work with Roondars audio mixer (used for playing sound effects) and to work with my own interrupts etc.

Wow, that's really impressive. Congratulations on that!

[Apollon]

Originally Posted by Muzza

I'm confused, if you use a joypad, you just hold down fire - you don't need to use an autofire switch.
Are you saying the player shoots faster when using a joypad with an autofire switch, than it does if you use a CD32 joypad and just hold down fire?

I have expressed myself somewhat confusingly. I use a sega mega drive pad for the Turrican games, which I can set to an additional button with autofire. So far so good. I like the CD32 PAd more (more buttons). But the frequency of the autofire button could be a little higher. Do you understand what I mean now? It's higher on the mega drive pad (which only has 2 buttons instead of 7). But on the other hand. It's fine the way it is, I don't want to confuse you.

[Muzza]

Originally Posted by jotd

I noticed that the main music was a bit off on my machine. This is because of broken TFMX replay routine which doesn't wait enough when writing to DMACON. You have to insert delays after writing.

Can you be more specific about where it sounds wrong and what the DMACON issue is?

I've compared it to the original and can't detect any differences myself. I did make changes to the player routine way back when I adapted it.
In places where INTENA is set, followed by INTREQ being set, I set INTREQ twice.
In places where INTENA is set on its own, I do a tst.w DMACONR immediately afterwards.
It was some time ago that I added these. I believe they were listed somewhere as being required to avoid bugs on the A4000.

[Muzza]

Originally Posted by Apollon

I have expressed myself somewhat confusingly. I use a sega mega drive pad for the Turrican games, which I can set to an additional button with autofire. So far so good. I like the CD32 PAd more (more buttons). But the frequency of the autofire button could be a little higher. Do you understand what I mean now? It's higher on the mega drive pad (which only has 2 buttons instead of 7). But on the other hand. It's fine the way it is, I don't want to confuse you.

Holding down green on the CD32 pad should give you the maximum possible firing rate, as the fire button is registering on every frame.
Are you sure that it is slower that using a hardware auto-fire on a different joypad? It doesn't seem possible. A video might be helpful.

[jotd]

Originally Posted by Muzza

Can you be more specific about where it sounds wrong and what the DMACON issue is?

I've compared it to the original and can't detect any differences myself. I did make changes to the player routine way back when I adapted it.
In places where INTENA is set, followed by INTREQ being set, I set INTREQ twice.
In places where INTENA is set on its own, I do a tst.w DMACONR immediately afterwards.
It was some time ago that I added these. I believe they were listed somewhere as being required to avoid bugs on the A4000.

This has nothing to do with INTENA. When you write to DMACON (mostly to stop the sound ex: $0004), you have to wait a few rasterlines before issuing the new command on that channel, else the order is given on the wrong sample (the old one).

It sometimes only shows with fast machines, using fastmem. It shows on my real amiga A1200/060.


Toni emulates it too by adding a line in your winuae config

chipset_hacks=0x8

[ross]

Originally Posted by Muzza

Can you be more specific about where it sounds wrong and what the DMACON issue is?

I've compared it to the original and can't detect any differences myself. I did make changes to the player routine way back when I adapted it.
In places where INTENA is set, followed by INTREQ being set, I set INTREQ twice.
In places where INTENA is set on its own, I do a tst.w DMACONR immediately afterwards.
It was some time ago that I added these. I believe they were listed somewhere as being required to avoid bugs on the A4000.

Hi Muzza, I state that I have not looked at the TFMX routine used.
But I think jotd refers (EDIT: oops, just noticed that I basically wrote together with jotd ) to the re-start or re-trigger of a note and the relative restart of the DMA channel (so nothing to do with INTxxx).

Usually when you stop audio DMA (and you need to restart it), you have to wait 'some time', that depends of previous period (Audio State Machine need to be in idle state).
Of course to make the wait generic (which should be done with a CIA timer via IRQ..) you can consider the worst period; let's say around 500 e-clock is an adequate wait.

Then you can re-enable DMA using eventually the new (latched) sample pointer and length.

[CFou!]

Originally Posted by ross

Hi Muzza, I state that I have not looked at the TFMX routine used.
But I think jotd refers (EDIT: oops, just noticed that I basically wrote together with jotd ) to the re-start or re-trigger of a note and the relative restart of the DMA channel (so nothing to do with INTxxx).

Usually when you stop audio DMA (and you need to restart it), you have to wait 'some time', that depends of previous period (Audio State Machine need to be in idle state).
Of course to make the wait generic (which should be done with a CIA timer via IRQ..) you can consider the worst period; let's say around 500 e-clock is an adequate wait.

Then you can re-enable DMA using eventually the new (latched) sample pointer and length.

an example of the TFMX player fix can be found in the WHDLoad's slave source code of Turrican 2 (in WHDLOAD's installer package)...

[jotd]

I usually perform a busy wait of 4 rasterlines. If it's not enough, I can raise it up to 7.

A busy wait is easy and lame because it costs cycles, and can be a problem with in-game fixes. There's a glitch in Oscar triggered by that fix (flickering sprites).

Using a CIA wait is better but difficult to adapt to an already existing SFX engine. Replacing it altogether (with phx ptplayer for instance) is a better solution, but you need to understand how the sfx system works!

In the case of Turrican 2, it only happens in the intro, so a busy wait it can be safely done. Not much happening here.

[Don_Adan]

Originally Posted by jotd

I usually perform a busy wait of 4 rasterlines. If it's not enough, I can raise it up to 7.

A busy wait is easy and lame because it costs cycles, and can be a problem with in-game fixes. There's a glitch in Oscar triggered by that fix (flickering sprites).

Using a CIA wait is better but difficult to adapt to an already existing SFX engine. Replacing it altogether (with phx ptplayer for instance) is a better solution, but you need to understand how the sfx system works!

In the case of Turrican 2, it only happens in the intro, so a busy wait it can be safely done. Not much happening here.

TFMX 7V replayer was used for intro, outro and hiscore, if I remember right.

[Don_Adan]

About Turrican 2 music.
Muzza can use better rate for TFMX 7V mixing routine for 68020+. Originally Turrican 2 used 16-18 kHz (I dont remember exactly). Original TFMX 7V replay has 22 kHz limit and this is safe to use up to 22kHz. I dont know which version of TFMX 7V replayer he used for T2 AGA. I enhanced original mixing routine to 28 kHz, and later (after some code modifications) to 29kHz. Then he can use this replayer, if he want. I dont remember if TFMX 7V replayer needs DMA wait, but original mixing routine uses SMC, perhaps it can sounds like DMA problem on fastest 68k CPU-s.

And finally it will be nice, if Muzza can add Turrican 2 music box (press space on title screen to access on Amiga T2). All musics can be easy tested on all AGA configs, i think.

[Muzza]

Thanks for all the information about the DMACON/TFMX issue. Knowing how to emulate it in WinUAE, and what the problem was made it an easy fix.

Originally Posted by Don_Adan

About Turrican 2 music.
Muzza can use better rate for TFMX 7V mixing routine for 68020+. Originally Turrican 2 used 16-18 kHz (I dont remember exactly). Original TFMX 7V replay has 22 kHz limit and this is safe to use up to 22kHz. I dont know which version of TFMX 7V replayer he used for T2 AGA. I enhanced original mixing routine to 28 kHz, and later (after some code modifications) to 29kHz. Then he can use this replayer, if he want. I dont remember if TFMX 7V replayer needs DMA wait, but original mixing routine uses SMC, perhaps it can sounds like DMA problem on fastest 68k CPU-s.

I did use the Eagle Player source as the main reference when adapting TFMX, and I had still had remnants of the 'new mixer' in there. It was all disabled, but I've taken the time to get it working. It appears to be working at 28khz instead of 18, but I can't hear any difference at all.

[Don_Adan]

Originally Posted by Muzza

Thanks for all the information about the DMACON/TFMX issue. Knowing how to emulate it in WinUAE, and what the problem was made it an easy fix.



I did use the Eagle Player source as the main reference when adapting TFMX, and I had still had remnants of the 'new mixer' in there. It was all disabled, but I've taken the time to get it working. It appears to be working at 28khz instead of 18, but I can't hear any difference at all.

You are good. You will able to use adapted and modified by me original Chris Huelsbeck and Jochen Hippel TFMX 7V source. Ok, then no SMC problems. This player was tested on 68000 7 MHz, 68030 50 MHz, 68040 25 MHz and 68060 50 MHz. And no problem was known me. Maybe jotd and Ross can check replay source for possible problems?

Seems i dont enhanced mixing range to 29kHz. Only for Mugician II and Jochen Hippel 7V i made this. Then this player has 28 kHz limit. For mix quality You can check 6 or 10 kHz too. My ears also dont hear differences for very high mixing rates, but musicians can hear differences.

[Don_Adan]

And i forget then some TFMX 7V songs has mixing value set by effect command. If i remember right it was $ef03 command. I dont remember exactly, if Turrican 2 7V songs used this command to choose/set mixing rate. But if yes, you can modify replay source (like me for EP) or modify/edit mdat file to use 28 kHz mix rate.

[ross]

Originally Posted by Don_Adan

Maybe jotd and Ross can check replay source for possible problems?

Nah, your code is always great

About the DMAWait this is the relevant code (TFMX 7V player module V1.3, versionnum = $0892):

	move.l	4.W,A1				; exec base
	tst.b	$129(A1)			; CPU check
	beq.b	MC68000
	lea	CPUType(PC),A0
	clr.w	(A0)
MC68000
....
.nodwait
	tst.w	CPUType
	bne.b	.NoWait
	bsr.w	DMAWait
.NoWait
....
DMAWait
	movem.l	D0/D1,-(SP)
	moveq	#8,D0
.dma1	move.b	$DFF006,D1
.dma2	cmp.b	$DFF006,D1
	beq.b	.dma2
	dbeq	D0,.dma1
	movem.l	(SP)+,D0/D1
	rts

So if you don't have a superfast bare 68k you don't have any problems
(but I don't know that Wait used Muzza).

About the mixing code and inaudible audio differences at higher frequencies: this is probably due to the fact that existing modules are optimized to use the default frequency because they use samples that are already at the best quality at that frequency (and similar frequencies betweeen samples).
Since the mixing does not use any kind of interpolation or oversampling (but a simple possible duplication in the case of higher frequencies) it is difficult to hear much difference if you do not have fine ears..

I think this is the reason, then there is probably also the thing said by Don in his last message

[jotd]

a value of 8 is most of the time too much and wastes too many cpu cycles. I got away with 4 most of the time. It depends on what the routine is doing right afterwards

[Don_Adan]

Originally Posted by jotd

a value of 8 is most of the time too much and wastes too many cpu cycles. I got away with 4 most of the time. It depends on what the routine is doing right afterwards

Then maybe this is not DMA wait problem? But not perfect/good interrupts handling in my version or Muzza attempt?

And about wait for 8 lines. My players are not for games, but for Amiga OS. For Amiga OS and for some players even wait for 8 lines can be not enough. You must remember about double graphics modes, like DoublePAL, DoubleNTSC, Euro72 etc

If i will use wait for 8 lines for game or demo. I will use Nicolas Pomarede method. You must read line number in one place (then add 8 lines) and wait before DMA access (if i remember right). Then for some cases and slow Amigas you even dont wait for 1 line, but for fast Amigas you can wait up to 8 lines for same code.

[Don_Adan]

Originally Posted by ross

Nah, your code is always great

About the DMAWait this is the relevant code (TFMX 7V player module V1.3, versionnum = $0892):

	move.l	4.W,A1				; exec base
	tst.b	$129(A1)			; CPU check
	beq.b	MC68000
	lea	CPUType(PC),A0
	clr.w	(A0)
MC68000
....
.nodwait
	tst.w	CPUType
	bne.b	.NoWait
	bsr.w	DMAWait
.NoWait
....
DMAWait
	movem.l	D0/D1,-(SP)
	moveq	#8,D0
.dma1	move.b	$DFF006,D1
.dma2	cmp.b	$DFF006,D1
	beq.b	.dma2
	dbeq	D0,.dma1
	movem.l	(SP)+,D0/D1
	rts

So if you don't have a superfast bare 68k you don't have any problems
(but I don't know that Wait used Muzza).

About the mixing code and inaudible audio differences at higher frequencies: this is probably due to the fact that existing modules are optimized to use the default frequency because they use samples that are already at the best quality at that frequency (and similar frequencies betweeen samples).
Since the mixing does not use any kind of interpolation or oversampling (but a simple possible duplication in the case of higher frequencies) it is difficult to hear much difference if you do not have fine ears..

I think this is the reason, then there is probably also the thing said by Don in his last message

This is very lazy code. Perfect Gaelan G. always told me that i missed support for 68000 with 6888x card (if exists any FPU card on Amiga for 68000), but i was lazy. And after many years perhaps it can dont works good for 68000 50 MHz turbo cards and for 68010 (i dont know if any bit is set for this CPU in new kickstarts).

[meynaf]

Originally Posted by Don_Adan

This is very lazy code. Perfect Gaelan G. always told me that i missed support for 68000 with 6888x card (if exists any FPU card on Amiga for 68000), but i was lazy. And after many years perhaps it can dont works good for 68000 50 MHz turbo cards and for 68010 (i dont know if any bit is set for this CPU in new kickstarts).

Yes there exists AFB_68010 bit for AttnFlags so the above code will indeed fail in that case.

If you use very long wait you take the risk of having more sample triggering clicks and you waste cpu time.
So the best way is to adapt the wait to the used frequencies.
For this i recommend using the audio irq.

[Don_Adan]

Originally Posted by meynaf

Yes there exists AFB_68010 bit for AttnFlags so the above code will indeed fail in that case.

If you use very long wait you take the risk of having more sample triggering clicks and you waste cpu time.
So the best way is to adapt the wait to the used frequencies.
For this i recommend using the audio irq.

Ok, if i will back to life i will change lazy code to btst #1,$129(A1) in 7V players.
I dont use longer waits than 8 lines. For some players, like Sonic Arranger i dont used scan lines waits.
CPU time is not important for 4 channel soundformats under Amiga OS. More important is working on all CPUs and screen modes without problems.
When i was young, dont exists Amigas with 68000 50 MHz, 68060 100 MHz, 68010 or 68080.
Anyway seems that if Muzza is using 8 lines wait from my TFMX 7V replay then it must works for jotd 68060 too, if 4 lines is enough on jotd config.

[Muzza]

I used the Turrican 2 WHDLoad source for the DMA delay code. It looks like this:

DMADelay:

     move.w  d0,-(a7)
    move.w    #8,d0
.bd_loop1
    move.w  d0,-(a7)
    move.b    $dff006,d0    ; VPOS
.bd_loop2
    cmp.b    $dff006,d0
    beq.s    .bd_loop2
    move.w    (a7)+,d0
    dbf    d0,.bd_loop1
    move.w    (a7)+,d0
    rts