AMPS - Ample Music Playback System

Discussion in 'Engineering & Reverse Engineering' started by Natsumi, Apr 28, 2019.



    The cute one here Tech Member

    is a sound driver I started developing in mid-2016, to be used for my hacks. I never found any use for it however. Instead, I kept developing it, if ever in the future I would need it. While I was working for this, Dual PCM was released, and with it, I made the driver work around it. After talking with MarkeyJester, I was allowed to use the future version of Dual PCM in the driver, the version which eventually became Dual PCM FlexEd. I worked on the driver every now and then for almost 2 more years, readying it for public release, and waiting for a Dual PCM release version along with it. You may have seen an early version of the driver in my hack, Achi, where it was used to power all the music related things.

    More about the driver

    AMPS is a sound driver based on Sound-Source, that runs on the Motorola 68000, designed to be used with ROM hacks and Sega Mega Drive software. Although similar to Sound-Source, AMPS is fundamentally different in many aspects. It is also heavily customized, RAM-efficient and cycle-efficient. AMPS is powered by Dual PCM FlexEd, meaning that you can use 2 DAC sample channels with pitch and volume control. AMPS was designed to be a well-documented driver with a lot of capabilities so that the music can sound better, and the program and music can interact with each other. To ensure this, AMPS has a very robust codebase built to allow future expansion and customized programming for program-specific circumstances.

    What features does AMPS have?
    • Highly optimized code, that will ensure that no time is wasted in processing the 68k-side code.
    • Lower RAM usage. The driver optimizes the RAM usage, so that it is easier to add into any program.
    • Various flags to control which features are enabled for AMPS. The user can customize the driver to fit their needs, saving RAM and processor cycles.
    • End user documentation with examples and helpful tools, and documented source code for easier modification.
    • Full support for Dual PCM FlexEd.
      • 2-channel PCM playback.
      • Volume and pitch control.
      • Reverse sample playback.
      • Looping sample support.
      • DMA quality loss prevention.
      • Simplistic sample filtering.
    • PCM sound effect channel and 2 music PCM channels.
    • PCM channels can choose between 2 modes; Sample mode where each note is the sample to be played, and pitch mode where each note changes the pitch instead.
    • Portamento effect for smoothly modulating from one note to another.
    • Full support for volume envelopes and modulation envelopes.
    • SMPS2ASM integration. This makes it possible to easily port music and allows for future expansion.
    • Universal sound bank for sound effects.
    • SSG-EG and LFO support.
    • Speed shoes tempo adjustment, and 2 tempo algorithms; overflow-based and tempo-based.
    • Toggleable 50hz "fix" for music.
    • Spindash sound effect support.
    • Special underwater mode. This allows for a cool underwater-esque effect for music and sound effects (as seen in Sonic 2 Recreation).
    • Customizable fading support. The driver supports multiple different types of fades, and they are user-defined, allowing for a huge variety of different ways to fade or manipulate channel volumes globally.
    • Better commands for using communications bytes for 2-way conversation between tracker files and the game code, and conditionally executing tracker code.
    • Continuous sound effects support. These are sound effects in Sonic 3 & Knuckles that instead of restarting, continue to play sound when the sound ID is played.
    • Music back-up support. This is used in Sonic games for the 1-up sound effect.
    • Sound driver debugging support. This feature allows the sound driver to alert the programmer when various errors or possible mistakes happen when playing tracker files. Very useful for finding out when something goes wrong with the sound driver.
    Why should you use AMPS over something else?

    As discussed already, AMPS provides a large set of features, while conserving CPU cycles and RAM usage. Furthermore, AMPS will be developed further with community feedback in mind, and with new features and optimizations. AMPS is also fully open-source, and can be modified for everyone's individual needs. The source code, while large and complicated, is well documented and open for suggestions. Additionally, since AMPS is built around Dual PCM FlexEd, its integration into the sound driver is deep, which allows the sound driver to reap all the benefits from using Dual PCM FlexEd. The improvements to the music and sound effect formats allow for better and more varied music to be made, especially when it comes to PCM channels. AMPS is also the only Sound-Source-based sound driver which makes it possible to integrate the music more deeply with gameplay or graphics of the host program, something which previously was not possible, or had to be custom built. AMPS has received a lot of attention to detail for its features and codebase.

    What the download contains

    The download contains a few things:
    • End-user technical documentation for AMPS, and the technical reference manual for Dual PCM FlexEd.
    • Depending on the package, either Sonic 1 implementation, Sonic 2 implementation, or files for the AMPS test program which helps debug music, and has a few custom goodies.
    • A folder containing a slightly customized version of Vladikcomper's error debugger. These customizations allow for scrolling menus.

    Few extra notes
    • We have a Discord server!
    • If you want to report a bug, or ask for help with an issue, please provide Aurora with enough information to go by, don't just ask why your assembler or the game is throwing up error messages. I need to know what you think is causing the issue, what you did before the error appeared, what you tried to do to fix it, and if applicable, the ROM, any music or sound effect files that are related. I may ask for more things if I can not figure out what is going on.
    • If you want to suggest a new feature or want me to change something, please also explain why, and how it will benefit the driver as a whole.
    • AMPS currently only supports ASM68K and AS. Because of the complexity of porting this to other assemblers, and limited free time, I am unable to provide a download for other assemblers at this time. If anyone is willing to help out in this regard, I am happy to offer the download here.
    • I have a life. (surprising I know)
    • The safe mode is meant to be used only to debug for issues with songs, not for your release ROMs! The safe mode reduces performance and adds more memory usage for the sound driver, meaning that it is most effectively used only when necessary. You can use safe mode for releases without a problem, but it is not recommended.
    • The sound driver does use considerably more ROM space, than other drivers. This is a lot to do with the optimizations I've applied, and Dual PCM FlexEd. Unfortunately, there is not a lot I can do about this currently.
    Future plans

    I have a few things I wanna add in the future into AMPS. Here they are, in no specific order:
    • Clean up the source code more, and make it easier to modify.
    • Add support for PSG4 as a standalone channel.
    • Add support for special FM3 mode, along with dedicated trackers for each of them.
    • Add support for TL modulation and envelopes.
    • Improve underwater mode.
    • Few performance optimizations I have in mind.
    • Better support for volume filters.
    Follow the development of AMPS at its GitHub page!
    Come talk to other users and the devs on Discord!

    • AURORA☆FIELDS - The creator and main programmer behind AMPS, and creator and porting of the example music.
    • MarkeyJester - The creator of Dual PCM FlexEd, help with documentation for Sonic 1's sound driver, helping with bug fixes, documentation, hardware testing, and creating the logo.
    • ValleyBell - Provided the code for underwater mode, and is the creator of SMPS Research Pack.
    • Vladikcomper - The creator of the error debugger used for AMPS, and for helping me learn about sound drivers.
    • LuigiXHero - Help with porting many new additions between branches.
    • Stardust Gear - Small additions and bug fixes.
    • Death Rapunzel - Help with bug fixes.
    • Nat The Porcupine - Help with the documentation and hardware testing.
    • FoxConED - Playtesting and suggestions, teaser video, hardware testing.
    • VAdaPEGA - Suggestions and helping with documentation.
    • Hyper - Helping with documentation.
    • Selbi - Help with the documentation.
    • Ozaleto - Help with testing.
    • Kurk - Help with testing.
    • SEGA & Sonic Team - Original Sound-Source 68k driver that AMPS is based upon.
    Sorry if I missed anyone, I realized I forgot keep notes of everyone who's helped, so I hope my memory doesn't fail me...
    Last edited: Jul 22, 2020
  2. Wafer


    come back when you've learned to code Member
    Disassembling n00bs, WIP
    This is great work, wish it was out when I started working on my current project! At the risk of asking a prickly non-technical question, you've listed the driver under the Apache license and described it as "SMPS-like". Does this mean it's free from proprietary code? The need for a sound driver has previously put me off developing my own games for the MD.


    The cute one here Tech Member
    Actually that's a very good question and I hadn't thought about it before. And it is a very difficult thing to answer as well. I've based the code on SMPS, and particularly the one found in Sonic 1, but at the same time, pretty much every single line at some point has been modified or rewritten, just because of how large the changes are. Yet, its heavily based on the Sonic 1 driver, disassembled from a Sonic The Hedgehog ROM. I don't know exactly how legal this technically, nor is the code belonging to the original authors. The fact that this is also disassembled code from a ROM, further complicates this. I don't want to make it out to seem like its safe to use for your projects: However, as far as I know, SEGA does not care unless it is a commercial product, in which case it may be a bit iffy. You probably want to make sure with lawyers if you intend to make your project commercial.
  4. Wafer


    come back when you've learned to code Member
    Disassembling n00bs, WIP
    Cool, thanks for clarifying what you can. If I ever get round to attempting a commercial release, I'll check with a lawyer first.
  5. JustMe


    Planet Earth
    Being lazy
    Very good driver, I always wanted to port ASM'd music to hack with ASM68K, but I couldn't cuz there wasn't any drivers, etc.
  6. Caverns 4

    Caverns 4

    Sanik Quest: Journey To The Right
    This is fascinating - I'm thinking about using it in my project. I'm not sure how plausable this is, but can you give any general figures on how many CPU cycles this saves compared to say, the vanilla Sonic 1 driver?
    I've been using the clone driver, and been inclined to undo it and use Sonic 2's vanilla z80 driver, but if the footprint on the 68k from this is lighter than the clone driver's, (Which I know the RAM is), I'd be happy to use this.
    Sorry if that's not really a viable request, I'm just really intrigued with the promise of dual PCM AND a litght CPU footprint.


    The cute one here Tech Member
    From my observations, it usually takes half or less CPU time compared to Sonic 1's driver. Of course, you have to remember, that the driver does much more with that CPU time, and if you go all crazy with effects and the PCM channels, it can easily start taking more CPU time. For equivalent music, it should always be less time nonetheless. Its hard to give exact measurements, but given that even the Sonic 1 driver only takes a small fraction of CPU time per frame, you wont see massive improvements in reality.


    The cute one here Tech Member
    So, as I am working on the next release of AMPS, I realize something. To bring the best experience and compromise to everyone, I need to have more options for the user to fine-tune their driver to their liking. This presents a big problem: I will need considerably more time to test each configuration, along with the new features and changes... This will add a lot more time to development only focused on testing and fixing all the immediate bugs, and will make it more likely for bugs to be present in the driver upon release. Given I am going to college again in just over a week, I will have even less time to work on anything. Additionally, keeping documentation up-to-date will be difficult because of this. So what I am thinking is, as I release updates to Github for the driver, I could have you guys help me stress-test it, and report bugs back to me. I also need someone who is willing to re-write the documentation in a nicer format and keep it updated.

    So here is the deal, anyone wanting to help me with testing and bugfixes, you can download the latest source code from Github and play around with it. I will not provide installation instructions nor support for these versions, so use at your own risk! But I will take care of any bugs you report. Preferably, file an issue through the Github website itself on the repository, but you can also DM them to me directly if you don't have an account. I will credit you accordingly on the next release, and will have it out sooner.

    As far as writing documentation, I am afraid, I need someone who actually knows a thing or two about how sound drivers work. I do not have the time to essentially tell you what to write, so I would like that you do your research and I can nitpick what you have written and provide additional details. The documentation should be written in some nice looking format (as opposed to the dodgy solution with text files like currently), and from where you can copy code that preserves formatting (tabs etc). I will provide my help and guidance however, but you'll also need to be able to work independently in a reasonable timeframe.

    By the way, making some progress towards some of the new features currently, so that's something to look forward to.


    The cute one here Tech Member
    So, an update to AMPS. As you've no doubt seen during the contest week, I released AMPS in Sonic 2 to the SHC Expo. This has been something that has been requested from me for a long time, and I never really felt up to the task of porting AMPS to AS. However, because people asked me nicely and promised to help, I decided to go for it. Of course, as it turns out, porting it was a huge mess and some fundamental things about the driver had to change in order to suit a correct port. There are still some kinks to work out (I am really NOT having fun with AS at all), but I am confident that the current release of the driver works competently enough that I can release it for everyone to enjoy! That being said, this is a pre-release version and there may be severe bugs! Use at your own risk as they say. I will work over time to find and fix these issues, so I definitely suggest keeping up-to-date with the Github repo.

    Also, here is a quick rundown of the changes from previous AMPS versions:
    • PSG volumes are now 7-bit as opposed to 4-bit. This means you have to convert them in songs and sound effects, but it allows for far more intercompatibility with FM
    • There is support for FM6 channels. These can be enabled with simultaneously with DAC too, though DAC will always override FM6.
    • Fixed underwater mode algorithm
    • Support for modulation envelopes
    • Support for FM and DAC volume envelopes
    • Portamento flag
    • Support for backing up songs (such as the 1UP-jingle from Sonic games
    • Optimized YM command code which should make the driver noticeably faster to process
    • Fixed some SFX sounding wrong because of bad timings regarding YM writes (Dual PCM technically writes the cue too fast to YM, so some sounds are different as a result. Fixed by adding more "delay").
    • Updated register setup in such a way that the driver does not use d7 or a6 anywhere
    • Some other bugfixes or tiny feature not worth mentioning right now
    As you can see, AMPS has evolved quite far. The normal 68k version also has kept up with the AS version and should have parity with features. I still need help with bugtesting and documentation, as those are mostly the things left before I can do a full release. Unfortunately, as I don't have massive amounts of time, it may still take me a few months to get everything ready for a release without any help. Furthermore, I am running into some.... Limitations with AS to put it nicely. It does not like to cooperate with me on a few issues that I think are really gonna be a problem regarding full release. Solving that may take some time...

    Anyway, here is the repository link
    • Like Like x 2
    • Useful Useful x 1
    • List
  10. Vangar


    Apologies if this was mentioned somewhere but I couldn't see it - Played this on a mega drive 1 today (I've only tried it on there, haven't tried it on emulator) and the badnik pop / monitor pop sound is off. Everything else sounds great though and from what I could tell the game was running smoother.


    The cute one here Tech Member
    It's here folks! The latest AMPS version. The first post has been edited with the new details, so be sure to have a look.

    A lot has changed since the last time. Because of a lot of people requesting it, there is now an AS port and a Sonic 2 branch. 1-up sounds work correctly again, a lot of optimizations have been done, volume envelopes are supported for DAC and FM, modulation envelopes are supported, and FM6 can be enabled as much channel (even while DAC is running! Though, no DAC sample must be played until FM6 can be heard). There are a few custom features, such as portamento and 7-bit PSG volume. A lot of the rough edges from the last version have been smoothed out, and few customizations has been added. Overall, if I can say so myself, its worth using the new version. It's much better than the first release, and there is now a comprehensive documentation included!


    The cute one here Tech Member
    Here is the next version of AMPS. The post, again, has been updated.

    Again, a fair bit has changed. AMPS now uses a generator to assemble the sound drivers, so they're easy to update. Modulation has drastically been changed to further support Z80 versions, and plenty of bugs have been fixed. The documentation is updated to contain all this new information. You may have to edit your music in order to update to 2.1. See the changelog here:
    • sFreqOn and sFreqOff are no longer tracker commands.
    • New tracker commands: ssModFreq and sModReset.
    • Changes to sModAMPS: Only the <wait> and <step> parameters are loaded initially. This only makes a difference when note is held. The modulation parameters are not reset, which allows the user to change how modulation works mid-note without resetting the offset. In order for the old behaviour to work, sModReset can be used after sModAMPS is used. The <count> is also changed. Now, the value is subtracted before being checked, meaning value of $00 will not start by negating the <step>. Additionally, now it is treated as infinite, meaning modulation up and down is possible for unlimited time. If <count> is $01, the value initially is set to $01 instead of $00, making short modulations still possible. When <wait> is counting down, modulation frequency is still accounted for.
    • The frame a note is played, modulation, portamento and modulation envelope are all updated.
    • mfbNoPAL flag is used to check whether or not PAL mode is enabled, instead of checking for the region. The flag is updated based on song header and PAL region by dPlaySnd_Music.
    • Fixed a bug where DAC panning was not reset correctly for music channels, leading to issues with panning.
    • Fixed a bug with modulation envelopes not working as intended.
    • Added a new PSG frequency to match the PSG table exactly with Sound-Source Z80.
    • Added a new FM frequency to help with Sound-Source Z80.
    • Added a feature that allows easier integration with sound test engines.
    • Speed shoes tempo algorithm now works by running the sound driver twice when the timeout occurs. This also means speed shoes has its own timeout instead of using the main tempo.
    • AMPS Includer can list the names of all music and sfx tracks (not commands however!) now.
    Edit: Some stuff is still to come! Wait patiently! Also, portamento algorithm is changing in the next release to be more consistent with how Sound-Source games did it.
    Last edited: Jul 22, 2020


    The cute one here Tech Member
    After a lot of work (and procrastinating), I've finally finished porting all the Sonic 3 & Knuckles music and sfx into AMPS! Both Sonic 3 and Sonic & Knuckles versions of the shared music are available, with the correct DAC and all. Also, the beta music is here too! Although these won't sound perfectly accurate to S3K (thank you, Sound-Source Z80), they sound as close as possible (I challenge you to find any differences =P). You of course need to tweak some of the settings, especially what flags are enabled, DAC, volume & modulation envelopes, and universal voices need to be ported over with any music or sound effect. The files are more or less provided "as is", with minor tweaks to make them play nice with AMPS, and a few major tweaks because again, Sound-Source. Here is a link to the archive containing all the data.

    Oh yeah and there is a Sonic 1 Github version too, I guess I never mentioned it? Go have a look~