awuwunya / amps

Ample Music Playback System development project

Ample Music Playback System - Test Program

AMPS is a sound driver software package aimed at making Mega Drive audio development easier and more comfortable for musicians and programmers. The driver is a Motorola 68000 & Zilog Z80 based software, that is responsible for managing the audio hardware on the Sega Mega Drive. It can be controlled via 68000 software and does not need a lot to set up. Currently, there are variations available for the ASM68K and AS Macro Assembler, with great portability of tracker files across both assemblers as well. AMPS aims to be faster, more reliable, feature richer, and easier to use than previous sound drivers. It is based on Sound-Source which was commonly used by Japanese game developers at the time. Unlike Sound-Source, AMPS has a single standardized version that allows porting music from other formats to best of its ability without sacrifising the features the driver supports. AMPS also aims to build a repository of tools to eventually make native music development for AMPS easy for everyone. See the Releases tab for stable versions, or the source code for unstable development versions.

Example implmentations

• AMPS test program
• Sonic 1 2005 implementation
• Sonic 1 Git implementation
• Sonic 2 Git implementation

Features

• Highly optimized code, that will ensure that no unnecessary 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. There are various features you can enable/disable to control this.
• Documented source code for easier modification.
• Comprehensive sound driver documentation.
• 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 and modulation envelope end commands. This makes porting envelopes easier.
• Full 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.
• Song back-up support. This is used in Sonic games for the 1-up sound, where the previous music fades in gradually.
• 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.

amps's Issues

Fancy GUI for playback program

Lets be honest, it looks like shit, and is not at all user-friendly. It should have an UI that is easy to look at, but provides all the necessary information. Additional code could be added to the sound driver to make display more accurate as well (specifically relating to the envelopes)

Request: SMPS to AMPS converter?

As far as I'm aware, the only method which exists for converting SMPS binaries to AMPS format seems to be using SMPS2ASM (as described in the docs). By default, the output isn't compatible with AMPS. The documentation describes a general idea of how to adjust tracks, but a more direct conversion process would be ideal.

TL envelopes

This would be a FM-only feature, that would allow for more complex sounding instruments without having to worry about modify the TL values by hand each frame. However, it would probably take a lot of CPU time and would be difficult to get right. A lot of thought should be put into this to make sure its useful and wouldn't waste time and space.

PSG ADSR

ADSR (Attack, Decay, Sustain, Release) is simplified form of how FM voices operate regarding volume. This allows for more control over how the notes sound, and indeed would help PSG sound a little more natural while also allowing Volume Envelopes be used for more complex effects on top of that. This feature would make it possible to also have PSG do a more natural fade-out after a note is released.

7-bit volume for PSG

This is one of these "nice to have" things. It would make dealing with PSG volume much easier, at the cost of extra CPU time and more difficulty porting music over. However, it would bring PSG in line with FM and DAC which have volume range of 00 to 7F. This would make volume envelopes cross-compatable as well, which will be good if FM & DAC volume envelopes are implemented.

FM3 special mode

FM3 special mode is a very useful technique for making more interesting sounding instruments or simulating up to 4 channels at the same time. However, it will also be more difficult to program this effectively, as to take full advantage of the features you essentially need 4 trackers with control over TL and frequency of each operator. Also, there will be some issues to be considered with SFX, like should 1 SFX channel override effectively 4 channels? Should SFX be able to use FM3 special mode?

Implement FM & DAC VolEnv

Extend support for using VolEnv's for FM and DAC through a switch. Currently hardcoded to only support PSG, make the ability to support FM and DAC as well at the cost of 2 bytes of RAM and an extra tracker command.

PSG4 channel

Having PSG4 be able to work as an independent channel would make it possible to have greater control over the PSG chip and make use of 4 PSG channels at once (even with PSG3 playing a note and PSG4 playing noise using PSG3's frequency), but also complicate a lot of tracker and driver related things. It may not be worth implementing.

Fractional note frequency

This feature would make all frequency work as note.fraction as opposed to frequency. Lets say you want to modulate: Instead of adding x to the note frequency, you add x to the note.fraction value. This will later be converted into a frequency, where note is just the note to use, and fraction represents a fraction of the difference between the next note - current note difference in frequency. For example, fraction of $40 may mean current note + ((next note - current note) / $100 * $40). This would make modulation, portamento and other effects be effectively exponential as opposed to linear, and make them sound more "realistic". It would make the driver more accurate in production of notes at the cost of extra CPU time and more work to port songs correctly. It would also make code more complex (especially when dealing with how FM splits its octaves; dome frequency values actually overlap between octaves), but it would also bring many advantages and make it easier to create interesting effects in music.

Support a raw frequency mode

This is a feature in SMPS and may be used by songs that are to be ported from SMPS games. This would provide additional control over the tracker at the cost of using more space. The details will have to be thought out since DAC frequency can be negative as well...

Outdated Discord Invite link in documentation

So I wanted to enter the project's official Discord to try and get some help with bringing AMPS into my Project Sonic 1: Two Eight Git disassembly project, but the provided invite link in the documentation is expired. Can this be updated so I can properly get some much needed tech support for my project?

EDIT: Well, I found the updated invite link in the Sonic Retro thread, but it should still be updated in the docs :P

Improve safe mode error detection

There needs to be more thought put into error detection in safe mode. Although many common cases are already detected, more uncommon mistakes may not be covered. To work effectively, all errors should be detected

Please stop calling SMPS 'Sound-Source'

I've gone over here why 'Sound-Source' likely isn't SMPS's name - rather, it appears to merely be a placeholder string for the name of the game that the driver is inserted in. Specifically 'Source' appears to be a corruption of 'Sorce', which is possibly short for 'Sorcerian', a game which uses SMPS Z80 and was released around the time the leaked source code is dated.

Retroactively 'correcting' SMPS to Sound-Source like this is not only potentially factually-incorrect, but also extremely confusing to anyone who only knows SMPS by its unofficial name.