Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible access to uninitialised memory of rhythm timbres #72

Closed
sergm opened this issue Aug 6, 2021 · 0 comments
Closed

Possible access to uninitialised memory of rhythm timbres #72

sergm opened this issue Aug 6, 2021 · 0 comments
Assignees

Comments

@sergm
Copy link
Member

sergm commented Aug 6, 2021

When using an image of any version of MT-32 control ROM, the internal data structure that holds predefined stock rhythm timbres is not utilised in full. We allocate memory for that structure so that all 64 timbres defined in CM-32L / LAPC-I can fit, but MT-32 only uses 30 of them. During initialisation with a MT-32 control ROM, only 30 stock timbres are placed in the memory in fact, the rest remains uninitialised. This should be OK as the code performs a corresponding check when starting to play a note on the rhythm part.

However, some games practice programming patches with the standard rhythm timbres to be played on the melodic parts instead. The code that performs range checks during defining such patches cannot interfere, because the rhythm timbres which are only defined in CM-32 are still within the valid range 0..63 (that is applied to every timbre bank equally). The code that actually configures a new note to be played also does not contain any validity checks to prevent playing non-existent rhythm timbres on a melodic part. As a result, the behaviour is undefined in case a CM-32L / LAPC-I game attempts to play such an instrument (can vary from being silent to producing unpleasant squeaks).

Interestingly, the new-gen MT-32 devices seemingly contain a fix for this issue, as the table that defines the standard rhythm timbres contains 64 entries, with timbres 30..63 being mapped to OFF. Evidently, the emulation should initialise this part of memory as appropriate to fairly emulate the new-gen units and to avoid undefined behaviour when emulating the old-gen units (even if the latter really do exhibit it).

Update: in case of old-gen devices, the rhythm timbre played seems to be picked from the standard ones modulo 30. But this is not consistent. For example SysEx F0 41 10 16 12 05 00 00 03 3C 3C F7 sets patch 0 so that playing a note on an old-gen unit (with control ROM 1.07) makes it hang. That is, rhythm timbres 0..59 are only "valid" for the old-gen units, because they display more-or-less sane behaviour.

@sergm sergm self-assigned this Aug 6, 2021
@sergm sergm added this to the libmt32emu_2_5_3 milestone Aug 6, 2021
sergm added a commit that referenced this issue Aug 6, 2021
…72)

With control ROMs 2.04 and 2.07, all 64 standard rhythm timbres are now
initialised when the Synth opens. The timbres 30..63 are mapped to OFF.
sergm added a commit that referenced this issue Aug 6, 2021
…72)

With control ROMs 2.04 and 2.07, all 64 standard rhythm timbres are now
initialised when the Synth opens. The timbres 30..63 are mapped to OFF.
sergm added a commit that referenced this issue Aug 6, 2021
…72)

With control ROMs 1.xx, all 64 standard rhythm timbres are now initialised
when the Synth opens. The timbres 30..59 are mapped to 0..29 that should
correspond to the behaviour of real units. The other 4 timbres are muted
to avoid undefined behaviour the real hardware exhibits.
@sergm sergm closed this as completed Aug 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant