AMPS - Ample Music Playback System

Discussion in 'Utilities' started by Natsumi, Apr 28, 2019.

  1. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    699
    Location:
    Long and dangerous river
    [​IMG]

    AMPS
    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!


    Credits
    • 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. EMK-20218

    EMK-20218 Eduardo Knuckles Member

    Joined:
    Aug 8, 2008
    Messages:
    1,028
    Location:
    Jardim Capelinha, São Paulo
    Nats... seriously, marry me. (just kidding)

    I need to use this. Although I'm not sure about how I could insert it in my hack or if it would even be compatible with it due to certain internal modifications that my hack's engine suffered accross the years. As for what did I read, it seems very flexible and seems to show a bunch of functions that would be very useful to me. I'm not sure if I'll be able to implement it with the very low ASM knowledge I have, but I'll give it a try. This is a real great present for music lovers like me. Thank you very much! :)
     
    Trickster and Natsumi like this.
  3. Nat The Porcupine

    Nat The Porcupine Active Member Member

    Joined:
    Jun 23, 2017
    Messages:
    30
    Location:
    Harrisburg, Pennsylvania (USA)
    Alright, so I gave the driver a quick glance & I have to say that I'm very excited to play around with it. Nicely done, it was definitely worth the wait.
     
    Trickster likes this.
  4. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    699
    Location:
    Long and dangerous 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.
     
  5. SMS Alfredo

    SMS Alfredo Compact Disc Enthusiast Member

    Joined:
    Sep 3, 2018
    Messages:
    27
    Location:
    Little Planet
    Not sure if this is the correct place to put this, but I have a bug in AMPS I would like to report.

    So, I am attempting to create a streamed song using 3 DAC samples strung together and repeated. The samples are long enough that they don't fit into the $7F range of waiting time. Normally this wouldn't be a problem, as adding more wait time afterwards usually works and the sample continues as long as I meant it to. However, it seems that in this driver, adding extra wait time beyond the initial one set by the sample itself does not work. Instead, for every extra value of wait time, the sample restarts itself. Not sure if this is how it acts in vanilla Sonic 1, but I know for certain this is not how it acted in the MegaPCM Driver.

    Here's the asm file if you want to try replicating the problem yourself.

    Hope this will be helpful.
     
  6. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    699
    Location:
    Long and dangerous river
    I don't have access to the ASM file because of Google drive, however I think I know the issue. DAC channel is bit of a special case in Sonic 1, it does not act like a normal channel, it follows slightly different rules. I am not 100% clear on the rules but likely playing note, delay, delay will not restart a sample. AMPS adheres to the rules of FM and PSG channels, note, delay, delay causes 2 notes to play in succession. This is why the sHold flag exists, it skips a few steps in playing a note, notably the part where the note is restarted, resetting a few variables, and other channel-specific things. For DAC, this means that your sample will keep playing despite playing more delays. You want to add sHold before each additional delay beyond the initial delay.
     
  7. ValleyBell

    ValleyBell Well-Known Member Member

    Joined:
    Dec 23, 2011
    Messages:
    152
    On the DAC channel, note, delay, delay always plays 2 notes. In SMPS 68k/Sonic 1, the only difference to FM and PSG channels is, that the sHold flag doesn't work.
    Instead you're unable to stop a sample, because playing a rest doesn't do anything.

    You can have longer DAC samples by playing: note, delay, rest, delay, delay, ...