On Mon, 3 Jan 2000, Ravi wrote:
> Hello,
>
> >While doing "sciunpack sound.xxx" with all the games I have, I noticed
> >some strange stuff. The byte which is use for delay time will somtimes be
> >0xf8 (or LSL3 sound.213 0xfc), sometimes followed by more 0xf8. This
> >special chunk ends with a byte which is not 0xf8. If there is a running
> >status it seems to be carried right through this chunk. I ignore this as a
> >delay = 0 in my latest midi.c
>
> IIRC, 0xF8 is a system real-time MIDI message, meaning that the first one
> is NOT actually a delta time value. The drivers supported some real-time
> messages, but I left them out of the specification because I hadn't seen
> any "in the wild". My fault.
Some sound resources to look at:
Conquest of Camelot:
9,12,35,47,109,110,122
Codename Iceman:
1,3,44,59,60,71,88,92,99
Space Quest 3:
9,12,22,41,52,59,87
Larry 3:
213,217,218,250,253,260,375,487,530,550,631
Hero's Quest:
25
> If I'm understanding this, there should be 24 clock synchronization
> messages sent to signify a quarter note. I'm not sure what's getting
> synchronized though.
sound.213 in LSL3 have FC F8 F8 78 FC at the end, thats the only place
I've seen that has 0xfc at this place.
What's the last byte after a series of 0xf8 doing, is it a real delta
time?
0xfc is also a system real-time MIDI message, but it does follow a delta
time value.
I don't recall seeing the MT-32 driver atcually dump the 0xf8 through the
midi port.
/Rickard Lind
