Opened 11 years ago

Closed 7 years ago

Last modified 7 years ago

#3804 closed defect (invalid)

DOTT: MIDI stuck after exploding cigar

Reported by: raziel- Owned by:
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Day of the Tentacle


ScummVM 0.12.0svn (Jul 12 2008 07:07:53)
Features compiled in: Vorbis FLAC MP3 zLib MPEG2

After Hoagie gives the exploding cigar to George W.
and lights it, there is an explosion and right on the
climax of the sound output (MIDI/MT32 hardware used)
the MIDI output is stuck and a humming sound is all
that is played after that.
Changing screens or reloading a saved game doesn't
cure it.
I have to turn the MT32 off and on to get it working
again, although only of i restart ScummVM in it's
whole. Speech is working fine.

Day of the Tentacle (CD/English)

gcc version 4.0.2 (AmigaOS build 20051012)

Ticket imported from: #2016549. Ticket imported from: bugs/3804.

Attachments (3)

tentacle.s08 (31.1 KB) - added by raziel- 11 years ago.
give the cigar to georgie
DOTT MT-32 Hardware Lockup_MIDI Commands.log (56.0 KB) - added by raziel- 8 years ago.
DOTT_MT-32_Hardware_Lockup_MIDI_Commands.diff (1021 bytes) - added by raziel- 7 years ago.

Download all attachments as: .zip

Change History (15)

Changed 11 years ago by raziel-

Attachment: tentacle.s08 added

give the cigar to georgie

comment:1 Changed 8 years ago by raziel-

With the latest revision
ScummVM 1.3.0svn54951 (Dec 18 2010 13:33:12)
Features compiled in: Vorbis FLAC MP3 RGB zLib Theora
i get
20 times the line

WARNING: Trying to use unsupported effect level value 64 in native MT-32 mode.!

AFTER loading the saved game and

8 times the same line

WARNING: Trying to use unsupported effect level value 64 in native MT-32 mode.!

after the cigar exploded.

On the MT-32 there is


printed stuck on the display, but this is probably only the state where the hardware locked up.

A recurring hanging note can be heard until i completely take the hardware off the power.
Reset (Master Volume + Part 5) is not possible as the hardware doesn't react to anything anymore.

Hope that helps a bit

comment:2 Changed 8 years ago by bluegr

Owner: set to bluegr

comment:3 Changed 8 years ago by bluegr

This issue has probably been fixed with r55256, can you please check if it still occurs?

comment:4 Changed 8 years ago by raziel-

Unfortunately not fixed, but it changed behaviour

Now "1:Wind-2 |Sax 4" is stuck on the hardware display and the sound after the digar exploded sounds like it's following the flying cigar,say, it sounds like its playing an ascending curve with a low humming until it gets to the climax where it stays stuck and recurring.

Hardware is stuck again, need to hard reset

comment:5 Changed 8 years ago by bluegr

Right. Quite odd, to say the least. Thus this isn't related with the change to MidiParser

comment:6 Changed 8 years ago by bluegr

Owner: bluegr deleted

comment:7 Changed 8 years ago by raziel-

Not that i know what i'm talking about, but there seems to be either an overload on notes which are sent to the hardware producing an overrun (which would explain the completely hanging hardware) or there is a wrong command sent to it while the sound (non-MIDI) of the explosion is played resp. too fast sent, so the hardware cannot work with it/react to it.

Is there some way i can debug this?

comment:8 Changed 8 years ago by raziel-

ok, i (think i) found the cause of all of this.

My MT-32 device has the serial number 871166 which, according to Wikipedia (, is one of the "old" devices.

MT-32 (Old)
LA32 sound generation chip is an 80-pin PGA. Control CPU is an Intel C8095-90 in ceramic DIP48 package. DAC is a Burr-Brown PCM54; the input signal having a resolution of 15 bits (see below). Line outs are unbalanced 1/4″ TS (L/R). No headphones jack.
MT-32 with revision 0 PCB, used in units up to serial number 851399.
The PGA LA32 chip is later replaced with a 100-pin flat type.
MT-32 with "old-type" revision 1 PCB, used in units with *serial numbers 851400 - 950499.*

On the same site Wiki mentions that "old" devices suffer in certain cases from a buffer overrun which results in the exact behaviour i'm getting in DOTT.

Compatibility problems

First generation units, having control ROM versions below 2.00, *require* a 40 millisecond delay between system exclusive messages. Some computer games which were programmed to work with the compatible modules (see above) or later ROM versions that do not require this delay, fail to work with these units, producing incorrect sounds or causing the firmware to lock up due to a buffer overflow bug, requiring turning the unit off and on. However, some games were designed to exploit errors in earlier units, causing incorrect sound on later revisions.
Also, some games were written to use instruments not found in the MT-32 models, and require a compatible module, such as a CM-32L, for proper sound playback.

I attached a commands list, read out while DOTT was running, with some seconds of MIDI playing before, while and after the lockup. (The list unfortunately does not stop at the offending command, because the data is still being sent while the hardware locked up already).
I have yet to find a way to read the hardware's output.

Please, could any dev with knowledge of MIDI commands read the list and confirm or neglect that the commands are not sent with a 40 ms delay, but shorter?

The explosion and following lockup starts around the first "Control" command, line 409

Thank you very much

Changed 8 years ago by raziel-

comment:9 Changed 8 years ago by raziel-

Adding a delay before _ICamd->PutMidi(_midi_link, data); in backends/midi/camd.cpp line 120 makes the lockup go away.

Due to the fact that i only need to set a delay of 1(!) ms to make it work (even setting it to 0 will work, but i'm unsure if it will work everytime) makes me think that such a delay is already in place somewhere in the source...
Unfortunately i have no idea where.

I added a .diff to work around the lockup which is more or less a hack
If someone with more insight in the audio parts please help me out here

Thank you

Changed 7 years ago by raziel-

comment:10 Changed 7 years ago by raziel-

I re-added a (now hopefully useable) diff.

Could a dev please comment and if possible integrate?
I have tested this and it does not break anything.
N.B. it seems it only affects me anyway (even on my platform noone but me uses real MT-32 hardware) :-)

Thank you

comment:11 Changed 7 years ago by raziel-

Just to add the last bit of information i can come up before i get rid of this :-)

Right before the MT-32 is sent into hiatus there is a jingle played (which marks the start of the exploding cigar sequence) parallel to the normal MIDI background music.

The MT-32 hardware is not able to cope with such many notes and breaks (it is even stated in the MT-32 manual that some music pieces may need to be "OVERFLOW"ed)
o This function allows the MT-32 to generate MIDI notes beyond its
capacity and send the excess out of the MIDI OUT port to the
input of an additional external MIDI instrument.

If one sets OVERFLOW on the hardware by hand before encountering the scene it will not break the MT-32 (missing second MIDI hardware will make that jingle vanish into nothing of course) and one can play along.
(One needs to do this everytime the hardware is switched on, though...this is not really a solution or fix)

I will close this as Invalid as (i think) this is clearly a hardware limitation/bug and nothing ScummVM can do against it.

Feel free to reopen if anyone wants to add a workaround

comment:12 Changed 7 years ago by raziel-

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.