don't click here

Utility Sonic 2 Clone Driver v2

Discussion in 'Engineering & Reverse Engineering' started by Clownacy, Mar 31, 2014.

  1. Clownacy


    Tech Member
    More updates, woooooo... Wish I was this productive with my hack.

    • Removed 68K-freeze code in PlaySega, it has negative effects in Sonic 2
    • Added coordination flag cfSilenceStopTrack
    • Added coordination flag cfPlayDACSample
    • Added coordination flag cfPlaySound
    • Added coordination flag cfSetKey
    • Added coordination flag cfSetVolume
    • Removed two unused coordination flags
    • Redone PAL mode
    • Replicated S2's ability to force PAL slowness on certain songs

    • Optimised PAL mode
    • Ported S2's PAL timer system
    • Made PAL_Audio_CountDown part of the Clone Driver's RAM

    The 68k halt code caused the SEGA screen to overstay its welcome.

    Added some pointless and gimmicky coordination flags as an exercise in porting from Z80 ASM. I'm not too sure of the intended function and use of cfSetKey and cfSetVolume, but they're ported as literally as possible, while being optimised for 68k. I can't find any S3K songs to test these on, except the S&K credits, whose playback is broken in this driver, but that probably goes all the way back to S1 bugs or S3K's weird note reading bugs/features.

    Does anyone remember how in S2, if on a PAL system, most of the game's music would play at non-PAL speeds, yet the drowning theme played at PAL speed? That was so the drowning theme was synchronised with the gameplay. In v2.2.1, I replicated the feature. Well, it's more of a port, but the way the music index is set to determine if a song should play at PAL speed was my own method. Because the music has to begin on an even address, the indexes never make use of the odd/even bit of the addresses. I now use that bit as a PAL mode on/off flag. To make use of it, just append your song's index entry with "+1". See for an example.

    I had some problems with using jumps to achieve PAL mode, so v2.2.1 contained a hackish way of processing the same code twice. For some reason whatever made jumps problematic doesn't exist in v2.2.1.1, so the code's been optimised to use them again.

    MJ's Moonwalker's PAL mode code has been replaced with S2's. Moonwalker's updated the entire driver twice on every fifth frame. S2's only updates the music channels twice. S2's is also better synchronised, as Moonwalker forces the PAL timer to 5 in SoundDriverLoad, S2 does that whenever new music is played.

    When updating to v2.2.1(.1), you need to append the drowning theme's index entry with "+1", like this:

    Code (ASM):
    1. ptr_mus9F:  dc.l Music9F+1
    This forces the song to play at PAL speed on PAL consoles, for synchronisation.

    Remove the PAL_Audio_Countdown constant from s2.constants.asm. It's been relocated to Clone_Driver_RAM.
  2. Hitaxas


    Retro 80's themed Twitch streamer ( on hiatus) Member
    Just updated my test disassembly. PAL_AUDIO_COUNTDOWN is a duplicate in the constants files for the game itself and the sound driver. Not difficult to work around though, I removed the line in the s1.sounddriver.constants.asm and the game builds no problem.
  3. Clownacy


    Tech Member
    Yeah, I eliminated the addition of that constant from the installation guide when I updated it. Looks like I forgot to add that to the update guide though.
  4. Clownacy


    Tech Member
    Just uploaded an emergency update. Those jumps I mentioned? They weren't fixed. It's complicated, but all that needs to be known is that it ruins whatever code tries reading from the Stack in not-so-normal ways. So I've switched back to some less-efficient-but-more-efficient-than-what-was-in-2.2.1 code which uses a single bit of RAM.

    In other news:

    Oh god, what have I done, SO MUCH LAGS

    Nah actually. The game performs just fine.

    So, I thought I'd pick up where Bobesh8 left off and port a 68K SMPS sound driver to Sonic 3 & Knuckles. In order to free up the RAM for the new sound driver, I decompressed the level Blocks and had the game load them from ROM as uncompressed data. Just as MarkeyJester had recommended in Bobesh8's topic.

    S3K's disassembly hasn't been developed enough for a switch to a new driver to happen smoothly. Because of this, I never fixed the sound effects, otherwise I'd be doing that forever. Music/SFX IDs help big time in these situations.

    This was a good learning experience. Outside of the hardcoded nonsense regarding sound effect and music calls, porting the sound driver is incredibly easy. The method being extremely similar to porting the driver to Sonic 2. Porting this to S3K is actually easier, due to that game's driver being not as deeply integrated as Sonic 2's, allowing easier removal.
  5. RetroKoH


    Project Sonic 8x16
    I've actually been working on this lately. When it's done I'll post the list on THIS thread and everyone can take a look, offer their two cents, etc.

  6. amphobius


    doing more important things with my life Member
    ..While I understand the point of this as a technical exercise, I fail to see why anyone'd actually use this for practical reasons primarily since the Clone Driver is based off Sonic 1's sound driver. Sonic 3's sound driver is excellent and far better than Sonic 1's sound driver, and with flamewing's mod of it it becomes extremely easy to use with any program that outputs to ASM (read: most of them except mid2smps, which can then be converted via smps2asm). It running on a Z80 based sound driver additionally makes the game itself run better even if sample quality takes a hit.

    I still see the Clone Driver as an archaic mod made for those who didn't understand Sonic 2's sound driver. Sonic 2's sound driver does support uncompressed files (the credits!), and while yes, there are some nuances that are a pain to work with, I'd rather use something that doesn't require both overhauling the entire game and potentially breaking the game and is instead more powerful than what's being used.

    That being said, I'm intrigued by the modifications you've made to the sound driver yourself (particularly actual PAL support; that's really neat) so I'll keep an eye on how this progresses.

    (particularly referring to Clone Driver in S3K in this post, if it wasn't clear, but Clone Driver in S2 is still something I see as unnecessary today)
  7. Clownacy


    Tech Member
    My goal with the Clone Driver V2 was the same as that of the original Clone Driver, to create a 68K sound driver that can work as a total replacement for S2's Z80 driver, which is apparently just a modified port of Sonic 1's 68K driver to Z80. Were the original Clone Driver never made, I probably never would have developed this. Look at the beginning of the original post, the original Clone Driver was still being used despite it being, from my observations, "made with old components and older methods", along with outright not being at all close to fully imitating S2's driver. I knew I could do better, so I did. Not out of spite of course, but for the sake of those that were using the driver, not aware of its many shortcomings. Just read through the feature list, the original Clone Driver had a custom DAC driver, with S2's DACs, "ported" S2 music and SFXes and nothing else! Well, that and a messy workaround for a simple yet nasty bug.

    When I first released the Clone V2, back in its 2.0 days, I didn't have much faith in it. Back then, it had flaws, flaws inherent from Sonic 1's driver. The tempos would never match S2's, the speed shoes would be forever broken, it was missing a sound flag, StopSFX. So, in my own hack, when the lack of coord flags in S2's driver got in the way of my music porting, I switched to Flamewing's S3K driver. A case of a boxing coach that bets against his own fighter :P. But now, the S3K driver's limitations have gotten in my way, and guess what I'm switching to? And if any missing flags get in my way, I'll port them. What I'm saying is, I feel that the 68K SMPS driver has more potential. If the only true limitation in software is hardware, then I don't wanna get comfortable with the Z80.

    Installation doesn't require a total overhaul, where'd you get that from? You have a sound ID relay/input, which any SMPS-using game has, a Z80 DAC driver loader, and a jump to the driver in V-Int. That's all. That's the minimal amount you need. Compare that to S3K's driver, what, the only thing the S3K driver doesn't need is the jump in V-Int. Real minimal...

    SMPS2ASM support isn't exclusive to Flamewing's driver, you could get it working with the stock buggy S3K driver. Even S2's driver, or S1's, or this one. But how is S3K's driver better? It has space limitations, bizarre note reading "bugs", lacks an FM6 channel, and you can't go crazy with the DAC channel. And I'm not talking 'Jester's Challenge' kind of DAC usage, even the more minimal of things such as Ristar's usage seems to have justified the use of a 68K driver. So what if the 68K looses some cycles to the driver? What good is all the effort put into optimising our hacks if we aren't gonna cash in on the free cycles? What, is Sonic Classic Heroes bad for using an additional AI? Anyway, S3K's so optimised that I never encountered slowdown, S2 runs just as crap as it always does, is 3.2% really that much? I'll assume that's what you meant by the driver "breaking the game".

    The port to S3K was mostly a joke and a test to see if there's any truth to this "but think of the lag!" thing that gets passed around whenever someone uses something that isn't the S3K driver. The Clone V2 was always intended for S2, just with S3K features for any music ports users were planing to do. But with the mimicking of S2's driver nearing perfection, the cloning of S3K looks like an interesting end goal for next time.

    Let's step back for a bit. S1's driver is a modified 68K SMPS sound driver. It was stripped of a significant amount of code during S1's development (PSG flags, coordination flags), while containing some additions of its own (extra life system, speed shoes(?)). S2's driver, according to some sources, is Sonic 1's modified 68K SMPS driver ported to Z80 and modified (quite extensively). S3K's driver is a modified native-Z80 (unlike S2's) SMPS sound driver. It too was stripped of functions (FM6 :argh:/> , songs being loaded into RAM), and had additions of its own (same as before). At their core, they're all variations of SMPS that have been meddled with. These modifications could be ported between them: I could get S3K's Spin Dash code working in S2's driver just as I did the latter's PAL mode in S1's. I could get S1's to load its songs into RAM, just as S2's did, even use Saxman compression. At their core, the only difference is the processor, and I'm bored of the LAGZ debates. Besides, why should I work on Z80 drivers when Flamewing seems to have that covered? An improved S2 driver is redundant. Might as well have the variation of both an improved Z80 and an improved 68K driver.
  8. flamewing


    Emerald Hunter Tech Member
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    Well, I was going to reply that a perfect clone driver (not the version everyone was using before) with MegaPCM is a perfectly good choice -- you are trading 68k cycles for vastly better PCM playback quality while keeping all the capabilities of the S2 driver. I have been thinking of making a S3&K driver with Mega PCM myself, which may end up being picking one of the equivalents ValleyBell has studied and modifying it for full S3&K capabilities and MegaPCM. But I don't know if I would use it myself yet, so it has been pushed back.

    I would, however, like to nitpick that the 3.2% of frame time is used during V-Int, which lasts 5.7% of an NTSC frame: this is a full 56% of V-Int. V-Int is also when DMA transfers are done because they have higher bandwidth; when delayed, the DMA transfers can end up happening out of V-Int. Since they stall the 68k for their duration, they will stall the 68k for longer out of V-Int. Also, this may cause graphical glitches due to partially transferred art. But that is me, nitpicking. The nitpick, by the way, is a caution on using the 3.2% figure. It is interesting, but it has to be interpreted properly or you will come to bad conclusions.

    Edit: Striked out some technically irrelevant information (I had forgotten that music is updated after DMA).
  9. amphobius


    doing more important things with my life Member

    Don't take it as an insult to you! My feelings are more than mixed about this but I personally feel that whillst the Clone Driver is cool for what it is, I still would recommend other options that are available, like how I'd recommend SonED2 over SonLVL, it's a preference thing. I'm aware of the mods you've done to it - I made particular mention to them and I found them pretty interesting! Use of MegaPCM in it is a great addition and I'm a huge fan of what it does myself to the point where I have the entire DAC table filled up in my own hack. This is a fun little project and I'm aware of the technical stuff you've done in it and I'd have loved to use this three years ago when I was working on my old Sonic 2 hack. Personally I think for someone who might just want new music in a Sonic 2 hack might find this unnecessary considering that it's a lot less difficult to just make the music Sonic 2 friendly over replacing the sound driver for just a bit of new music.

    As an aside, my own feelings is that a 'perfect' SMPS driver for end users would need to be both optimized and be flexible, but also customizable to what the end user requires for what they're doing, including the option of being either Z80 or 68K based (some people actually like the bitcrushing that Z80 drivers bring with them and see it as an iconic sound characteristic of the Mega Drive to the point where it's emulated in FM Drive). It certainly would be nice to see this dream a reality at some point!

    By the way, when I mentioned breaking the game, many years ago when I tried installing the Clone Driver I distinctly remember it going pretty badly - the guide was a little unclear and I wasn't paying too much attention admittedly, but there was still a good bit of risk in messing up the installation of the Clone Driver. :p I haven't looked too deeply in this, but if the installation is pretty easy now then what do I have to worry about? :v
  10. Clownacy


    Tech Member
    An insult? No, no I didn't take it as that at all. Don't worry about that.

    Well yeah even I'd recommend a good Z80 SMPS driver over this one to the average hacker that just wants more music. They probably won't run into the Z80's limitations anyway. But, if anyone were to try something that the Z80 can't handle, then there's always a 68K driver that isn't bugged and missing features available. Though I still need to work on the bugs, I hear there are more in there.

    I don't really know about replacing the sound driver being particularly difficult. The guide's meant to be easy to work with, and the driver is practically plug-and-play. But 'installation of this driver' VS 'porting the song, adding all S3K DACs, adding Uni Voice Bank support, adding S3K PSGs'... if you're porting S3K music, you'll have to port this or the S3K driver anyway.

    Breaking the game because of installation... This thing was very vague on how to remove the old S2 driver. I tried to make my guide as friendly as possible to avoid that stuff.
  11. Caverns 4

    Caverns 4

    Sonic: Retold
    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.
  12. MarkeyJester


    Original, No substitute Resident Jester

    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... 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.
  13. Clownacy


    Tech Member
    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.
  14. vladikcomper


    Tech Member
    Sonic Warped
    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.
  15. Clownacy


    Tech Member
    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.
  16. ValleyBell


    Tech Member
    researching PC-98/X68000 sound drivers
    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.
  17. nineko


    I am the Holy Cat Tech Member
    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.
  18. Clownacy


    Tech Member
    Update time: Link in the usual place

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

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

    Replace everything from PlayMusic to PlaySample with this:

    Code (ASM):
    1. PlayMusic:
    2.     tst.b   (Clone_Driver_RAM+v_playsnd1).w
    3.     bne.s   +
    4.     move.b  d0,(Clone_Driver_RAM+v_playsnd1).w
    5.     rts
    6. +
    7.     move.b  d0,(Clone_Driver_RAM+v_playsnd4).w
    8.     rts
    9. ; End of function PlayMusic
    12. ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
    14. ; sub_1370
    15. PlaySoundLocal:
    16.     tst.b   render_flags(a0)
    17.     bpl.s   +
    18. PlaySound:
    19.     move.b  d0,(Clone_Driver_RAM+v_playsnd2).w
    20. +   rts
    21. ; End of function PlaySound
    24. ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
    25. ; play a sound in alternating speakers (as in the ring collection sound)
    26. ; sub_1376:
    27. PlaySoundStereo:
    28.     move.b  d0,(Clone_Driver_RAM+v_playsnd3).w
    29.     rts
    30. ; End of function PlaySoundStereo
    32. ; ---------------------------------------------------------------------------
    33. ; Subroutine to play a DAC sample
    34. ; ---------------------------------------------------------------------------
    36. PlaySample:
    37.         stopZ80
    38.         move.b  d0,(z80_dac_sample).l
    39.         startZ80
    40.         rts
    41. ; End of function PlaySample
  19. Clownacy


    Tech Member
    A 'meh' update:

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

    You must overwrite _smps2asm_inc.asm with the new one. It contains bugfixes.
  20. Hitaxas


    Retro 80's themed Twitch streamer ( on hiatus) Member
    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. :) )