[Caverns 4]

I'm reminded that I still have yet to do anything with my guide to point them to your Clone Driver instead. I probably should do that now.

And honestly, I've studied the original Sound Driver a lot since I'd made that guide anyway, and knowing what I know now, that old thing is just embarrassing at this point. The old Clone Driver was really hacked together, and I could've benefited to actually make AT LEAST a few teaks to it.

I think I'll keep the old stuff there for.. I don't know, historic purposes, but I'm going to put in a note that my guide's version of the clone driver is obsolete, and to use your version instead.

[MarkeyJester]

Clownacy.

I would like to congratulate you on your fantastic exertion here thus far, you have shown a vast amount of familiarity on not only the 68k variant sound driver, but its Z80 counterpart too. You have shown some heavy research alongside forums and wikis alike, and have put that knowledge into slowly progressing practical releases. I am ever so pleased to hear the Launch Base Zone samples in that video are as crystal clear as reasonably possible. I shall be obliged to pester the staff along a strong recommendation towards a green lable your way, I feel you deserve it.

On subject now. There is (and always has been) a strong grudging misconception based around the decision on (and I quote) "which sound driver is better", of course, these things progressively steer to the side of the "opinion" of the speaker in question, and often without (or lack of) facts or reasoning for both sides, at least not until the facts are shown in that they cannot be evaded or ignored. I am of course, pleasantly surprised to find this...

Clownacy, on 04 July 2014 - 03:57 PM, said:

is 3.2% really that much?

...my own research acknowledged and brought into the discussion. Of course, I do hope those who read it proceeded onwards to the end of the post and pick up on the futher point I was extensively attempting making (which got ignored on the initial round).

There are pros and cons to all drivers, and I am not simply restricting to "SMPS" in the argument, I am of course regarding all possible (software only) drivers for the machine, for no matter how in-depth your dexterity is in programming, you will always hit certain limitations that may only be overgrown through sacrifice of another limitation. My advice here of course, is to form your decision based around the sacrifices that you are willing to make, and those sacrifices you will benefit more from if they are based upon what your actual game needs, and what you want to allow yourself the freedom of.

A Z80 based sound driver is benefitial for a series of reasons; the release of a small percentage of processing time and 68k work RAM, which complies to you a modest (but nevertheless noteworthy) freedom to achieve something on the graphical or gameplay side, with subordinate implications as a result. It is also compact, smaller, and selfcontained on a seperate processor to the main 68k, the benefit here is the shortfall of interruptions during loading loops on the 68k side, in order to attend to the sound driver to preserve the sound. While it is not impossible for a 68k sound driver to achieve this, you do have to be a clever individual and willing to accommodate with the attentance on every occurance, that of which you'd have no problem with via the Z80 variant. The Z80 contains a window into 68k memory filled through half of its PC range, thus allowing it to access almost as much data that a 68k driver could access. Tempo has more variation too.

Of course, a 68k based sound driver is benefitial for its own number of reasons; the lack of interruptions on the Z80 PCM playback side to deal with tracking information proves substantial to quality, even the very best Z80 sound drivers that are very well executed cannot live up to the expectational quality accommodated by the release of the tracker handling. It is also an understanding elaboration here, that the 68k could potentially handle tracking information for BGM, SFX or VFX of all possible channels without descending speed. With the 68k's help, it is possible to have two PCM samples playing back simultaneously, that's not to say the Z80 on its own (along with tracker handling) cannot achieve double playback, but there are limits you are forced into, such as keeping all the samples you wish to use under a single 0x8000 byte section in 68k memory. Since the Z80 cannot set the bank address very quickly (even with the vast attempts to speed the process up by means of self rewriting instructions), it is simply not able to play back any two samples anywhere in 68k memory at a decent enough quality above 8000hz (aprox), without sounding horrendous. You are practically forced to keep it all under one bank. One requiring a game with a character who has a lot of vocal lines to say, and a lot of percussional instruments to play, will find the 68k's assistence highly sufficient.

But let's forget the benefits for just one moment. Remember, you want to do what's best for your game/hack, don't just think sounds, think gameplay, think graphics, think of other aspects that selecting a sound driver may have a vicious effect on. In essence, there is no "better" sound driver, that is completely delusional and it is reckless to charge in without looking at the bigger picture. I'd also like to remind everyone that we (as a scene) are forgivable when it comes to limitations, whether there are a few areas that lag, or there are samples that sound choppy, we take it with a grain of salt, we know the machine is old, we know there are limits, and we accept things as they go under the assumption that "you tried your best", if you can go that extra mile, great! But don't put yourself out too much.

And it is that argument that I throw to defend the production of these 68k sound driver based researches, they may very well come in handy in the future should we need them. Likewise towards the Z80.

[Clownacy]

Wow, I don't know what to say. Though I guess it goes without saying that I wouldn't have gotten this far without the help of other members, you've seen the basic Q&A topic.

I do wonder what you meant by "Tempo has more variation too [on the Z80]". Both the 68K and Z80 are tied to V-Int, which both the S1 and S3K (and probably S2's) drivers update according to. ValleyBell told me of a type of Z80 SMPS that times its music and SFX according to the YM2612's timers, which could stand as an exception, but from what I've seen, S3K's driver isn't that, meaning that the tempo's left solely to a coded algorithm. Ever since I ported S3K's tempo algorithm to the Clone V2, the two should have identical tempo variation.

[vladikcomper]

Quote

I do wonder what you meant by "Tempo has more variation too [on the Z80]". Both the 68K and Z80 are tied to V-Int, which both the S1 and S3K (and probably S2's) drivers update according to. ValleyBell told me of a type of Z80 SMPS that times its music and SFX according to the YM2612's timers, which could stand as an exception, but from what I've seen, S3K's driver isn't that, meaning that the tempo's left solely to a coded algorithm. Ever since I ported S3K's tempo algorithm to the Clone V2, the two should have identical tempo variation.

He was speaking about Z80 drivers in general. Many of them actually use YM timers for timing, which is certainly more beneficial than tying to a Vertical Interrupt.

Unfortunately, the YM2612 cannot generate interrupts on Sega Genesis (which many people consider a design failure, since the chip has the corresponding pin to generate interrupts; it simply wasn't implemented), so a programmer has to check if timers are expired manually in a continuous loop. The later means the processor cannot do anything besides checking for interrupts in its main loop. The MC68000C obviously can't be occupied with that sort of job, since it has to process game logic during the main loop, it is only possible with a Z80 driver.

Using YM timers allows for much more flexible timing. You can update music faster than every 1/60th of second (1/50th on PAL machines). Tempo becomes much easier to handle programming-wise: you can adjust it by only adjusting timer period on the YM2612; no need in tempo managing routines like when static timing is used. But the main benefit is that there will be no tempo change between PAL and NTSC machines. Unlike Vertical Interrupts that have different time periods depending on the region to match PAL and NTSC television standards, YM timers work the same on either machine. Of course, there are certain workarounds for the tempo change issue that some sound drivers used back in the day. One workaround was calling update sound code twice every 6th frame on PAL machines, while works, this may have some side effects at times: since the sound driver code is run twice, this may overload processor, causing lag at times, and the fact sound is updated two times in a row without a proper delay will distort note durations.

But like always, all the benefits described above are achieved at the cost of putting certain limitations. Like it was said earlier, the processor has to check for timers expiration in a continuous loop. That means, when YM timers are used, Z80 cannot process DAC playback at all, since the main loop is occupied. Which is why all Z80 drivers that aim to handle DAC samples playback, including Sonic & Knuckles' driver, never rely on YM timers.

[Clownacy]

I never thought of a cause-and-effect relationship between YM timing and FM drums/lack of DAC. Very interesting.

I had heard some kind of distortion in PAL mode back when experimenting with the tempo algorithm and a modified version of Moonwalker's PAL mode. I wonder of the possibility of just having a faster tempo allocated to songs during PAL mode, staying away from the hackish idea of having everything update twice on one certain frame. Then again, there'd probably be the same problem as getting S2's speed shoes working with S1's tempo algorithm, the original tempos might already near a limit, and trying to increase the tempo will only be met with the tempos reaching a cap and not going high enough.

[ValleyBell]

vladikcomper, on 10 July 2014 - 08:59 PM, said:

Like it was said earlier, the processor has to check for timers expiration in a continuous loop. That means, when YM timers are used, Z80 cannot process DAC playback at all, since the main loop is occupied. Which is why all Z80 drivers that aim to handle DAC samples playback, including Sonic & Knuckles' driver, never rely on YM timers.

That's not entirely true, actually. Games like Battletoads (and any other game I classified as "SMPS Z80 Type 1 DAC") and Komani's Hyperstone Heist sound driver use YM2612 Timer A for timing. They check the timer after processing every DAC sample, so it makes the DAC loop slightly slower, but it works quite well.
(Battletoads DAC loop: 341 cyles, Sonic 3 DAC loop: 297 cyles)

btw: The Data East sound driver uses YM2612 Timer B for music timing on the 68k. That means that it can't update more than once a frame though.

[nineko]

The Z80 Cube driver also seems to rely on the YM timers (there's a field for that in the song header) while allowing for DAC.

[Clownacy]

Update time: Link in the usual place

v2.2.2

• Added fourth sound queue
  
• Replaced all 'jsr's with 'bsr.w's, and most 'jmp's with 'bra.w's
  
• Made small optimisations under PBGM_BGMLoadMusic, PSGUpdate_NoteGoing, SetVoice_SendTL, UnpausedAllFM, FadeIn_FadedDone, FM_UpdateFreq
  
• Renamed Snd_FadeOutSFX and Snd_FadeOutSFX2
  
• Changed bcc into bhs under PSFX_TimerActive
  
• Optimised some of the Spin Dash rev code
  
• Optimised waitYM macro (nothing uses d2 afterwards, and bit instructions can affect memory)
  
• Restored cfUnused1 (cfSetCommunication)
  
• Removed Size_of_SegaPCM macro (unused leftover from V2.0 :P)
  
• Fixed error made while removing Special SFX code under FadeOut_TrackPSG
  
• Fixed (my) error in the smpsStopSpecial macro
  
• Optimised some code around PSFX_SFXInitPSG (code was made less efficient back when I was trying to fix the $40+ index bug)
  
• Fixed Sound_PlaySpecial (it didn't support absolute voice pointers, and also has the $40+ index bug)

I was pretty paranoid lately about the number of sound bugs I'd noticed while playtesting, and decided to rewrite the Clone Driver V2. It didn't end well.

To start off, the S1 Community disasm's local labels can die in a fire. At least S2's disasm's temporary labels don't care if you place a unique label between them! Also, because of the S1 disasm's lack of advanced macro usage, getting the driver working on there is a mess of hardcoding and stock sound flag locations! I didn't expect bugtesting on the S1 driver's native game to be more difficult than just porting the entire thing to S2 and working from there. The entire point of rewriting the driver was to neaten up the code and to see if the sound bugs were caused by some profound mistake I made while editing the code. Irony happened. The local labels were a mess and a burden, and I found that all of the bugs I had noticed were in the original S1 driver to begin with, except for the one that I wound up introducing in the rewrite. Though I did find some errors I had made in the Clone V2, only one was actually related to sound, the other was some macro that should never be used. The rewrite was ditched and I put what little I learnt from it into slightly improving the original build. Yay, old stuff.

Anyhow, being distracted by rewriting the Clone V2, I paid too little attention to logging all of my changes in this update. Given how small most of these changes are, some of them probably escaped me.

Main focus of this update... four queues and the jsr-to-bsr conversion. The fourth queue is there so that Stereo SFXes have their own queue (considering how often Stereo SFXes play (*Ring* *ring*), it seems like they'd really need their own queue), and the jump-to-branch conversion seems to save some space, maybe processing time too.

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

Replace everything from PlayMusic to PlaySample with this:

PlayMusic:
	tst.b	(Clone_Driver_RAM+v_playsnd1).w
	bne.s	+
	move.b	d0,(Clone_Driver_RAM+v_playsnd1).w
	rts
+
	move.b	d0,(Clone_Driver_RAM+v_playsnd4).w
	rts
; End of function PlayMusic


; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||

; sub_1370
PlaySoundLocal:
	tst.b	render_flags(a0)
	bpl.s	+
PlaySound:
	move.b	d0,(Clone_Driver_RAM+v_playsnd2).w
+	rts
; End of function PlaySound


; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
; play a sound in alternating speakers (as in the ring collection sound)
; sub_1376:
PlaySoundStereo:
	move.b	d0,(Clone_Driver_RAM+v_playsnd3).w
	rts
; End of function PlaySoundStereo

; ---------------------------------------------------------------------------
; Subroutine to play a DAC sample
; ---------------------------------------------------------------------------

PlaySample:
        stopZ80
        move.b  d0,(z80_dac_sample).l
        startZ80
        rts
; End of function PlaySample

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

[Clownacy]

A 'meh' update:

v2.2.2.1

• Made slight optimisation around the branch to TempoWait by removing the branch altogether :P
  
• Optimised some lsl into add
  
• Optimised some clr.l into move.l
  
• Optimised some branches from .w to .s
  
• Made a bunch of bsr.w into bsr.s
  
• Fixed (my) error in _smps2asm_inc.asm that caused missing coordination flags to not be detected

This update's been collecting dust for around a month, waiting for me to add some feature or another, but nothing's come of it. Tried some instruction optimisation and fixed I bug I should have fixed ages ago.

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

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

[Hitaxas]

Will be upgrading to this version in a little bit here. Are you still planning to add the S3/S&K continuous SFX system at some point? That would be awesome (and help me alot considering I need something similar to pull off what I want. )

[Clownacy]

Oh yeah, thanks for reminding me! The fully working feature is buried in an old prototype somewhere. If my understanding of it is correct, I might be able to replace the S1 Special SFX (looping GHZ waterfall sound) system with S3K's Continuous SFX system, and save that $60 bytes of RAM that the former uses.

[Caverns 4]

So, before I even think about updating, to the latest version, some of the optimizations do look appealing, but I have to ask.

How easy/hard is it to convert proper ASM songs to the format for this version?

[Xeta]

You don't have to convert them; Clownacy didn't switch to an entirely different format or anything. The only modification to anything smps2asm-related was fixing a bug where it plays a missing coordination flag. It's still the same song format.

[Caverns 4]

Xeta, on 14 August 2014 - 05:22 PM, said:

You don't have to convert them; Clownacy didn't switch to an entirely different format or anything. The only modification to anything smps2asm-related was fixing a bug where it plays a missing coordination flag. It's still the same song format.

What I mean is SMPS2ASM music. Last I remember (it's been a while), it came out with some weird tempo issues or something, and I wanted to know what the status is on stuff like that.

[Clownacy]

Whatever you experienced was a bug on your end. IIRC, it was probably your _smps2asm_inc.asm being outdated. S3 tempo-related stuff is handled during the build process, with no input from the user needed.

This post has been edited by Clownacy: 14 August 2014 - 05:29 PM