This is going to be a fun one to implement, as I need to check both the conversion results and the original data in order to properly handle this. Plus, I don't think I'll be able to do this one perfectly because the pointers themselves are part of the problem with the readahead and with one of the VCMDs in particular, the next VCMD's parameter instead causes the problem.
Affects only carol's MORE.bin:
$E6 has an incorrect readahead length when used on song IDs $20 and above because it introduces a parameter byte.
Affects carol's MORE.bin and Addmusic405:
$E5, when used as the sample load command, gets relocated to $F3. This causes a desynchronization in readahead by going one byte too far. Critically, if there's a pointer involved immediately afterwards, then this is impossible to deal with as pointers are the least consistent compiled data that can be run into. All other conversion cases will have to be dealt with on a case-by-case-basis.
Affects only Addmusic405:
$ED $80 causes readahead to read one byte too few.
$ED $82 and $ED $83 are special. Within the context of Addmusic405 (as long it is the last known version of it for my own sanity's sake), the pointers are predictable. However, the conversions will naturally break some things, the pointers being among them, so I'll have to figure out how to handle this specific situation.
In all cases...
This conflicts big time with the hot patch created for #6. Naturally, both can be running at the same time... which I shudder to think what that can do. My pre-defined hot patches are either for past Addmusics or for quirk-related fixes to prevent playback inconsistency, and this special case is one where I don't want both of them running at the same time.
$F3 and up will cause readahead to run into undefined territory because the length table only goes up to $F2, as in vanilla SMW. To make matters worse, the Y register will likely wrap around because there's an 8-bit limitation (this one was taken care of as part of #5), and the song data will not be identical and/or we may run into pointers, which are naturally inconsistent to begin with. The full array that I will have to use for this special scenario is shown below, straight out of vanilla SMW:
This is going to be a fun one to implement, as I need to check both the conversion results and the original data in order to properly handle this. Plus, I don't think I'll be able to do this one perfectly because the pointers themselves are part of the problem with the readahead and with one of the VCMDs in particular, the next VCMD's parameter instead causes the problem.
Affects only carol's MORE.bin:
$E6has an incorrect readahead length when used on song IDs$20and above because it introduces a parameter byte.Affects carol's MORE.bin and Addmusic405:
$E5, when used as the sample load command, gets relocated to$F3. This causes a desynchronization in readahead by going one byte too far. Critically, if there's a pointer involved immediately afterwards, then this is impossible to deal with as pointers are the least consistent compiled data that can be run into. All other conversion cases will have to be dealt with on a case-by-case-basis.Affects only Addmusic405:
$ED $80causes readahead to read one byte too few.$ED $82and$ED $83are special. Within the context of Addmusic405 (as long it is the last known version of it for my own sanity's sake), the pointers are predictable. However, the conversions will naturally break some things, the pointers being among them, so I'll have to figure out how to handle this specific situation.In all cases...
$F3and up will cause readahead to run into undefined territory because the length table only goes up to$F2, as in vanilla SMW. To make matters worse, the Y register will likely wrap around because there's an 8-bit limitation (this one was taken care of as part of #5), and the song data will not be identical and/or we may run into pointers, which are naturally inconsistent to begin with. The full array that I will have to use for this special scenario is shown below, straight out of vanilla SMW:F4 80 F0 0C 09 48 5C E8 40 8D 02 9B 80