AMK Beta Remote Gain/Anticipation Gain Revamp #232
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In order for the upcoming modification to work with AMK beta's handling of gain, we need to split the remote code clearings into two types. The reason for this is that the slot normally reserved for KON remote commands is going to be used due to the requirement of remote gain and anticipation gain being able to run at the same time. This commit mentions #225.
…n branch Source commit: 79483fd This is going to come in handy for our new utilization. Normally it's reserved for KON events, and previously there was only one ever implemented, with this branch containing a second one. Now, for AMK beta conversions only, it's going to gain a different purpose. This commit mentions #225.
Event type 5, which was reserved for gain conversions in the first place, now acts like a type 2 event. However, that's not all: it contains a special auto restore feature that normally had to be done separately. This will be critical, as the C++ side is going to have its conversions simplified as a result of doing this. Stay tuned, because we have one more new remote code event type that will have this kind of special purpose... This commit mentions #225.
Type 6 works like a type 3 remote code event, but it also has auto-restoration. In addition, because of conflicts that normally occur, this uses up the slot normally used by the KON remote code events. This will act as our anticipation gain substitute, whereas remote code event type 5 will act as our remote gain substitute. This commit mentions #225.
This is required in order to make things easier on the parser so that it doesn't have to keep track of gain or timer values. This commit mentions #225.
With our new event types ready to go, it is now possible to simplify the conversion process to not have to account for either $FA $05 or $FC having previously been executed: they can now be independent of each other. This is because both can now be stopped individually, rather than having to restore one of the gain values after executing a type 0 remote code event. This commit mentions #225. It does not close the issue because of #25, in addition to the conversions being more optimizable. Because the original code used direct DSP register writes, a different solution may be required to avoid conflicts with music playback from other VCMDs.
This is required for event type 6: otherwise, neither event will run. This commit mentions #225.
KungFuFurby
added
c++-side
KungFuFurby
force-pushed
the
0225-amk-beta-remote-anticipation-gain-conversion-revamp
branch
from
d0f35b3
to
0a786dd
Compare
KungFuFurby
added
the
addmusick-beta
|
This is currently dependent on #25 to be fully functional. Because of how AddmusicK Beta handled this situation (via a direct DSP register write), there could be a conflict with other VCMDs that depend on the other behavior. Therefore, this is bleeding-edge exclusive for now. |
… $FC VCMDs Some additional notes were created in order to explain the purpose of the two reserved remote code events inside both of these VCMDs.
A minor optimization can be done here by incrementing a, but only if this call is placed before setting the volume to $FF.
18 tasks
KungFuFurby
added
the
new-remote
20 tasks
Accidentally left the zero check in there where it was supposed to be gone.
This section of code is required because otherwise type 6 will never be able to be properly checked. This was previously accidentally omitted.
In addition, by setting the accumulator to $06 and comparing against a memory location, a subsequent comparison for a $05 in one location can instead directly decrement the accumulator, saving an additional byte.
This not only makes things easier for me to properly restore the original remote gain-like functionality, but by assigning it to a high byte of $01 in the pointer, it ensures it only blocks off variable ARAM only from being used... including where the stack is located. This commit closes #88.
Now that the code is back in action, we need to do some optimizations.
I realized that the accumulator did not contain the actual gain parameter, thus I have to adapt the preceding RunRemoteCode code instead to send that over to the target register earlier. As a trade off, the storages to $30+x are done in one go with A and Y. The gain parameter being stored in Y as a side effect ends up saving a byte.
This was present for #amk 2 in order to prevent usage of it due to its purpose having been changed from AMK beta from remote gain to remote code. All of the other hex commands that used raw pointers were noticeably NOT blocked in this kind of manner, so I feel this is fair game. I won't be doing the same for anticipation gain's blockage removal, though.
…-anticipation-gain-conversion-revamp
…AMK Beta All of this generation for the remote gain routines are now null and void since there is a more exact replica that can be used.
KungFuFurby
deleted the
0225-amk-beta-remote-anticipation-gain-conversion-revamp
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contains a revamp of the remote gain/anticipation gain conversion from the beta version of AddmusicK. In particular, four new remote code types have been introduced: two of them are reserved for the conversions, while the other two are not.
This merge request closes #225.