AMPS - Ample Music Playback System

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

  1. Natsumi


    Miss Fox Tech Member
    Long and dangerous river
    Navigating said river

    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 68k-based SMPS-like sound driver, designed to be used with ROM hacks and Sega Mega Drive software. Although similar to SMPS, AMPS is fundamentally different in many aspects. It is also very customized, RAM efficient and cycle efficient. AMPS is additionally 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 created for the sound driver can sound better, and the music and game program can interact with each other. To ensure this, AMPS has a very robust codebase built to allow future expansion and customized programming for game-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. This release of the sound driver uses only $29A bytes of RAM.
    • 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.
    • Support for most common volume envelope end commands. This makes porting volume envelopes easier.
    • 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.
    • 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 space. 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 SMPS-based sound driver which makes possible to integrate the music more deeply with gameplay or graphics of the game 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:
    • Documentation relating to various aspects of AMPS, along with the technical reference manual for Dual PCM FlexEd.
    • Example Hivebrain 2005 project with AMPS pre-installed, and all music and sfx converted. You should be able to use this for your hacks out of the box.
    • A folder containing an example setup for AMPS, with a few custom goodies.
    • Another folder containing a sample playback program, which also shows some debug info about AMPS. This can be used, for example,to debug your custom music before installing it into your game. This can also be used to play back the custom music from the example setup.
    • A folder containing a slightly customized version of Vladikcomper's error debugger. These customizations allow for scrolling menus.

    Few extra notes

    • The installation instructions come with the download of AMPS, in the doc folder.
    • If you want to report a bug, or ask for help with an issue, please provide me 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. 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.
    • 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.
    • 1-up jingles are not supported in the driver, because they are a rather complicated feature and require a lot of RAM. This may change in the future.

    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 raw frequency mode.
    • Add support for special FM3 mode, along with dedicated trackers for each of them.
    • Add support for modulation envelopes.
    • Add support for TL modulation or envelopes.
    • Few performance optimizations I have in mind.
    • Few tracker size optimizations.
    • Better support for volume filters.
    Follow the development of AMPS at its GitHub page!


    • Natsumi - 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, 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.
    • FoxConED - Playtesting and suggestions.
    • VAdaPEGA - Suggestions and helping with documentation.
    • Hyper - Helping with documentation.
    • SEGA & Sonic Team - Original SMPS 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...
  2. Wafer


    Member 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.
  3. Natsumi


    Miss Fox Tech Member
    Long and dangerous river
    Navigating said river
    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


    Member 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


    a.k.a. DelayHacks Member
    Planet Earth
    Sonic: Uncharted Island
    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

    Member Member
    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.
  7. Natsumi


    Miss Fox Tech Member
    Long and dangerous river
    Navigating said river
    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.
  8. Natsumi


    Miss Fox Tech Member
    Long and dangerous river
    Navigating said river
    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.