[Caverns 4]

Oh, okay then. I must have made a mistake or something before then.
I'll give it a go again later.

EDIT: Also, an idea I've had: What about moving SoundPriorites and such to the external file where sounds are included as well?

This post has been edited by Caverns 4: 14 August 2014 - 07:20 PM

[Clownacy]

I suppose. I guess I'll have an s1.code.asm and s1.otherstuff.asm thing going on, just to keep the number of seperate files down while keeping everything update-friendly.

[Clownacy]

Now to fix something that's been bugging me for a while.

v2.2.3

• Added S3K's additional PSG frequencies
  
• Added S3K's continuous SFX system
  
• Split sound priorities and speedup tempos from main asm into s1.sounddriver.other.asm

Many months ago, a user asked about a problem he'd experienced with the driver: S3's credits theme was seemingly missing a channel. It was that faint noise channel you'd hear a few seconds into the song. It seems that it relied on S3K's additional frequencies to work, so, adding them has fixed it. Thanks to Flamewing for this one, his addition to the Port Knuckles guide brought attention to one SFX's reliance on a unique frequency, without that this problem will probably have gone unfixed. This may have fixed some other audio quirks with S3K songs, but I haven't tested my S3K+Clone v2 disasm in ages.

Updating:
You must overwrite _smps2asm_inc.asm with the new one. It contains a new feature.

Also. note the presence of a new file, s1.soundriver.other.asm. It, like sound and music.asm are not to be overwritten when updates are applied. It contains the sound priorities and speedup tempos, so they can be retained between updates.

Find VintRet and replace the jsr to UpdateMusic with this:

	jsr	(UpdateMusic).l			; update Sonic 2 Clone Driver

VintRet_NoMusic:

Then go to loc_748 and replace the rts with this:

	addq.l	#4,sp
	bra.w	VintRet_NoMusic

And go to loc_1072 and, after this...

	bsr.w	Do_Updates

...add this:

	jsr	(UpdateMusic).l

This post has been edited by Clownacy: 27 February 2015 - 08:23 AM

[ValleyBell]

Clownacy, on 11 September 2014 - 04:07 PM, said:

• Added S3K's additional PSG frequencies and broke the PSG noise in S1/S2 songs

Fixed.

Sorry, but you can't always just port things and expect them to work correctly with everything. (That also is true for FM frequencies and the modulation algorithm.)
90% of the PSG frequencies in S1 and S3K (or SMPS 68k and Z80 in general) are compatible, but the white noise is an exception.
I'd recommend to make the table end with $11, 0, $10, 0. This way you still have all PSG frequencies from S3K, but S1/S2 songs will still work.

btw: The next-to-last PSG frequency in S3K doesn't seem to be used by any song (they all use the last 0 in the table) and I think frequency $10 isn't used anywhere either.

[Clownacy]

Right, thanks for that. Looking back at Flamewing's work, 10h is absent. Didn't think that 0 was used by anything in S1/S2, looked like an unequated 'even'.

[Caverns 4]

Okay, so I've got a question, and I think it's a very good one:

Quote

Free up that $600 through however you choose. Then slap the label "Clone_Driver_RAM" before it.

I was just implementing this into a fresh disassembly of Sonic 2, and I didn't bother to free up any RAM, because I was feeling lazy, so I just went here:

				ds.b	$500	; $FFFFF100-$FFFFF5FF ; unused, leftover from the Sonic 1 sound driver (and used by it when you port it to Sonic 2)

and put the "Clone_Driver_RAM" label before that.When testing, I had literally no issues, and just to be safe, I put the underwater palette tables after that $500 bytes so I could observe it in Regen's VDP viewer. Doing so, I noticed that at no point did the water's palette colours get corrupted, nor did the music or audio act up.

Now, later on in your guide, you say this:

Quote

v2 only requires $5A0 bytes of RAM

That would be the $500 bytes I gave the Clone Driver RAM, $80 bytes for the first underwater palette table, and another $20 for the first line of the second underwater table, so in theory, Sonic's underwater palette would bug out at the very least, but it doesn't seem to.

So, finally, I went into the Sound Driver Constants file, and looked at your equates. The highest active one is $340, and the highest inactive one is $3A0.
I think you know what I'm asking at this point, but I'll say it anyway:
Am I correct in surmising that $600 or $5A0 is an oversight? Do we even need $400 bytes?

[Clownacy]

Get an extra life. Then it'll bug out.

Somehow you overlooked that the RAM at the end is a (massive) save state of the currently playing song. When the extra life jingle is set to play, the currently playing song is backed up, the jingle plays, and the song is restored, then faded in.

This post has been edited by Clownacy: 25 September 2014 - 02:03 PM

[Caverns 4]

Ah, yes. You're right. That is one thing I never checked.

[Clownacy]

So, turns out the Extra Life system really doesn't like FM6. We know about this bug (and fix), right? Well, turns out there's a second half.

Ever get a 1UP in an S1 special stage? Or, at least, whenever an FM6-using song is playing? FM6 doesn't fade back in. The fix? Make Resume_NoDAC enable FM6. You see, MJ's code checks for if DAC is playing, and if it isn't, it branches to an rts. It's safe to assume that if the DAC isn't playing, then FM6 must be.

So, taking a little code from the header reader, specifically the part that handles whether to enable FM6 or DAC (above PBGM_SilenceFM6), and adding it to MJ's code should fix it. Here's my version:

FadeIn_FadedDone:	; Modified version of MJ's original DAC fade-in fix
	bclr	#2,v_dac_playback_control(a6)	; Clear SFX overriding bit
	bclr	#f_fadein_flag,misc_flags(a6)	; Stop fadein	; Clownacy | Changed to use a bit instead of a byte
	tst.b	v_dac_playback_control(a6)	; is the DAC channel running?
	bpl.s	FadeIn_FM6			; if not, branch
; FadeIn_DAC:
	move.b	#$B6,d0		; AMS/FMS/panning of FM6
	move.b	v_dac_amsfmspan(a6),d1 ; MJ: load DAC channel's L/R/AMS/FMS value
	bra.w	WriteFMII	; MJ: write to FM 6

FadeIn_FM6:
	moveq	#$2B,d0			; DAC enable/disable register
	moveq	#0,d1			; Disable DAC
	bra.w	WriteFMI
; End of function DoFadeIn

I'd added the rest of the DAC initialisation/FM6 shut up-er just in case, but you get the idea.

Next up, cfFadeToPrevious. You might know this in SMPS2ASM lingo as smpsFade. What if you wanted an FM6 extra life jingle? This flag will make you regret it. You see, the flag is designed for use on DAC tracks only. This is evident through the stack meddling, which lines up with UpdateDAC only, and not the FM/PSG equivalent. The problem is that you need to use the flag on a DAC track that you likely don't have. Fixing this is simple: Add a check for f_updating_dac, and adjust the stack pointer accordingly. Here's my version:

At the end of cfFadeInToPrevious, near cfFadePrev_NextPSG, remove the addq.w #8,sp. Then, at the beginning of cfFadeInToPrevious, add this:

	addq.w	#8,sp				; Tamper return value so we don't return to caller?
	btst	#f_updating_dac,misc_flags(a6)	; Clownacy | Is this running on the DAC channel
	bne.s	.dactrack			; If so, branch
	addq.w	#4,sp				; Tamper return value so we don't return to caller ; Clownacy | FM/PSG requires three addresses be stripped off
.dactrack:

This post has been edited by Clownacy: 28 September 2014 - 01:42 PM

[KingofHarts]

So forgive my ignorance... is this something I could apply to my non-Clone Driver S1? Or is it something that requires your driver, or a similar one to it as a pre-requisite?

[Clownacy]

No, I get why you'd be confused. I was so preoccupied with confirming the fix that I didn't appropriate it for other versions of the driver. Yes, it's something you can apply to the stock S1 driver. The labels will just be different.

This post has been edited by Clownacy: 29 September 2014 - 11:50 AM

[Clownacy]

Anyone who followed the earlier post, please undo that. I've found a better (read: real) fix:

For those who've followed the guide before, remove (cut) the added 3 instructions. They're in the wrong place. Their current location means that FM6 will only resume AFTER the song has fully faded back in. That's bad, we want it restoring with the rest of the channels!

Go to cfFadeInToPrevious, and after this line:

	movea.l	a3,a5

Add your three additional lines, along with a check, giving you this:

	movea.l	a3,a5
	tst.b	v_dac_playback_control(a6)	; is the DAC channel running?
	bmi.s	.DAC				; if it is, branch
	moveq	#$2B,d0				; DAC enable/disable register
	moveq	#0,d1				; Disable DAC
	bsr.w	WriteFMI
.DAC
	bset	#f_fadein_flag,misc_flags(a6)	; Trigger fade-in	; Clownacy | Changed to use a bit instead of a byte
	move.b	#$28,v_fadein_counter(a6)	; Fade-in delay
	clr.b	f_1up_playing(a6)
	addq.w	#8,sp				; Tamper return value so we don't return to caller
	rts

And, yes, you guys that followed the guide earlier can move the addq.w #8 from the top to the bottom of the code. I don't know why I moved it in the first place.

This post has been edited by Clownacy: 30 September 2014 - 07:42 AM

[Clownacy]

So, who remembers this thing? Looking at it, it needed all the cycles it could get, but not all chances were taken, so the code is pretty unoptimised because of it.

Here's the old version currently in the Clone Driver v2 with cycles-used added:

PlaySega:
	stopZ80
	lea	(SegaPCM).l,a2			; 12(3/0)
	move.l	#(SegaPCM_End-SegaPCM),d3	; 12(3/0)
	move.b	#$2A,(ym2612_a0).l		; 20(4/1)
.loop:	  
	move.b	(a2)+,(ym2612_d0).l		; 20(4/1)
	moveq	#$13,d0				; 4(1/0)
.idle:
	dbf	d0,.idle			; 10(2/0) (loop), 14(3/0) (not looped)
	subq.l	#1,d3				; 8(1/0)
	beq.s	.endloop			; 10(2/0) (taken), 8(1/0) (not taken)
	lea	(Ctrl_1).w,a0			; 8(2/0)
	lea	(HW_Port_1_Data).l,a1		; 12(3/0)
	jsr	(Joypad_Read).w			; 18(2/2)
	btst	#7,(Ctrl_1).w			; 4(1/0) + 8(2/0)/8(2/0) + 8(2/0) (?)
	beq.s	.loop				; 10(2/0) (taken), 8(1/0) (not taken)
	startZ80
.endloop:
	addq.w	#4,sp
	rts

And here's an optimised version I cooked up.

PlaySega:
	stopZ80
	lea	(SegaPCM).l,a2			; 12(3/0)
	lea	(ym2612_d0).l,a3		; 12(3/0)
	lea	(Ctrl_1).w,a4			; 8(2/0)
	lea	(HW_Port_1_Data).l,a5		; 12(3/0)
	move.l	#(SegaPCM_End-SegaPCM)-1,d3	; 12(3/0)
	move.b	#$2A,(ym2612_a0).l		; 20(4/1)
.loop:	  
	move.b	(a2)+,(a3)			; 12(2/1)
	moveq	#$18,d0				; 4(1/0)
.idle:
	dbf	d0,.idle			; 10(2/0) (loop), 14(3/0) (not looped)
	movea.l	a4,a0				; 4(1/0)
	movea.l	a5,a1				; 4(1/0)
	jsr	(Joypad_Read).w			; 18(2/2)
	btst	#7,(a4)				; 4(1/0) + 4(1/0)/8(2/0) + 4(1/0) (?)
	bne.s	.endloop			; 10(2/0) (taken), 8(1/0) (not taken)
	dbf	d3,.loop			; 10(2/0) (loop), 14(3/0) (not looped)
.endloop:
	startZ80
	addq.w	#4,sp
	rts

Joypad_Read can be tweaked a little too. Replace the 'move.b #0' with a 'clr.b', and the 'lsl.b #2,d0' with a pair of 'add.b d0,d0's.

This post has been edited by Clownacy: 03 October 2014 - 08:49 AM

[MarkeyJester]

Ahh, optimising the old fix routines, very nice! I'm glad someone's actually taking the time to do this...

A few things to note though, are;

		move.l	#(SegaPCM_End-SegaPCM)-1,d3

This could be made into a word instead, since the sample is small enough.

	move.b	#$2A,(ym2612_a0).l
.loop:	  
	move.b	(a2)+,(a3)

You may need a delay between these two instructions as the YM2612 might not be quick enough on hardware (Not to say one missed byte will make a noticeable difference mind), perhaps move one or two of the above instructions down in-between them...

	movea.l	a4,a0

You'd only need to perform a word move since it's sign extended (Though I wouldn't imagine that'd be any quicker, so it could probably be disregarded).

	btst	#7,(a4)
	bne.s	.endloop

Try using tst with a bmi instead. Since it's only the start button you want checking.

[flamewing]

MarkeyJester, on 03 October 2014 - 05:21 PM, said:

	movea.l	a4,a0

You'd only need to perform a word move since it's sign extended (Though I wouldn't imagine that'd be any quicker, so it could probably be disregarded).

You are right, it isn't any faster: moving between registers always takes the same time because the 68k's internal bus is 32-bits in size. It is only when data enters or leaves the 68k which word vs long makes a difference.