# Music hardware variants

[Native exports and command inventories](../analysis/audio/variants/index.html).
Reproduce with `python3 tools/extract_music_variants.py`.

There are six music selections, each with five hardware-specific resources.
The driver banners establish these targets:

| Driver resource | Target | Music resources |
| --- | --- | --- |
| 00/33 | Soundblaster multi-channel | 38, 43, 48, 53, 58, 63 |
| 00/34 | Roland SCC1 + Soundblaster multi-channel | 39, 44, 49, 54, 59, 64 |
| 00/35 | Roland LAPC1 + Soundblaster multi-channel | 40, 45, 50, 55, 60, 65 |
| 00/36 | Gravis UltraSound multi-channel | 41, 46, 51, 56, 61, 66 |
| 00/37 | Soundblaster AWE32 | 42, 47, 52, 57, 62, 67 |

## Initial gallery export: format and scope

All thirty are custom Sound Images Generation 2 DOS sequences, rather than SMF
MIDI, WAV, or tracker MOD files. Each has one song, a resource-relative directory
and descriptor, and timed command streams. All parse using the recovered common
command grammar and all parts reach their first loop at the corresponding
SCC-1 arrangement's end tick. Division and initial tempo also agree across the
five versions of each piece.

The new export preserves the entire native resource, including bytes outside
parsed streams, and provides all five original executable drivers. The JSON
inventories retain exact command bytes, operands, source positions, musical
ticks and loop destinations. They deliberately omit a MIDI interpretation:
at the time of this initial export, only the SCC-1 interpretation had been
verified by executing the driver. The later runtime verification below covers
all four sampled arrangements.
Successful parsing of the other variants is structural evidence, not equivalent
to verifying their hardware output.

The main [listening gallery](../analysis/audio/index.html) now has a five-way
hardware selector. The SCC-1 MIDI mapping is verified against its original
driver. The other four variants have **provisional MIDI and Ogg comparisons**:
`python3 tools/render_music_variants.py` applies the recovered SCC-1 mapping to
each native sequence and renders with the same FluidSynth/FluidR3 GM settings.
This allows comparison without waiting for full hardware reconstruction.

These provisional versions preserve source tick positions and the commands
handled by that mapping, but pass native instrument numbers through as GM
program numbers. They omit opcode 97's effect and inherit the SCC-1 treatment
of opcode 99 (last-note release only on channels 0–11). They may therefore have
incorrect instruments, envelopes, pitch behaviour or note releases. They are
not verified emulations of Sound Blaster FM, LAPC-1, GUS or AWE32 playback.
Original command inventories remain separate and preserve commands omitted by
MIDI conversion. All exports stop at the first loop and add all-notes-off;
listening copies include a release tail and no DC blocker or corrective filter.

At that stage, FM instrument/register handling, LAPC-I instrument setup, GUS
instrument loading and AWE32 synthesis setup still needed tracing. Native FM
playback and the LAPC-I upload have since been reconstructed, as described below. No separate instrument or sample bank extraction is claimed by this
pass. Complete native sequences and executable drivers remain available.
Provisional render settings, source/MIDI/audio hashes and omitted opcode-97
counts are recorded in `analysis/audio/variants/previews.json`.

The gallery can be rebuilt without rerendering audio using
`python3 tools/music_gallery.py`. The SCC-1 render script also rebuilds it.

## Measured differences

Number of source sequence parts (including any setup or inactive parts):

| Group | Sound Blaster | SCC-1 | LAPC-1 | GUS | AWE32 |
| --- | ---: | ---: | ---: | ---: | ---: |
| 1 / startup | 9 | 15 | 12 | 15 | 15 |
| 2 | 9 | 15 | 15 | 15 | 15 |
| 3 | 9 | 9 | 9 | 9 | 9 |
| 4 | 9 | 13 | 13 | 13 | 13 |
| 5 | 9 | 11 | 11 | 11 | 11 |
| 6 | 9 | 12 | 12 | 12 | 12 |

Differences are not confined to instrument selection:

- Group 2 has 521 note commands in SCC-1 versus 609 in LAPC-1, GUS and AWE32,
  and 374 in Sound Blaster. These count opcodes 00–7F; they are not counts of
  distinct pitches or a claim about perceived musical complexity.
- Group 6 has 1,264 opcode-95 commands in LAPC-1 versus 2,773 in SCC-1, GUS and
  AWE32. Opcode 95 is pitch bend in the verified SCC-1 driver. Hardware-specific
  semantics still require verification in the others.
- Sound Blaster streams make extensive use of opcode 97, whereas the other
  variants do not use it in these arrangements. Its Sound Blaster meaning needs
  tracing rather than inheriting the SCC-1 handler's meaning.
- SCC-1 and AWE32 use opcode 9D controller pairs; LAPC-1 and GUS arrangements
  omit them. Even variants with matching part and note counts are not assumed
  identical.

`manifest.json` includes resource sizes, SHA-256 hashes, opcode histograms and
end ticks. Native files are byte-for-byte copies of the previously unpacked
resources. The per-part JSON can support detailed arrangement comparisons
without conflating source commands with a particular synthesiser's behaviour.

## Unified output layout

All five hardware variants use `analysis/audio/variants/group-N-HARDWARE.*`:

- `.bin`: unchanged native sequence.
- `.json`: native command inventory, without assumed MIDI semantics.
- `.mid` and `.ogg`: MIDI conversion and listening rendition.
- `-check.json`: source PCM and encoded audio diagnostics.
- SCC-1 additionally has `-events.json`: decoded MIDI events used by the
  original-driver verification harness.

`variants/previews.json` is the single playback/provenance manifest for all 30
renditions. Its file paths are relative to `analysis/audio/`; each entry records
whether driver semantics are verified. Renderers update their own resources
while preserving the other variants. `scc1-sequences.json` and
`scc1-verification.json` retain the SCC-1 extraction summary and verification
results. The top-level `analysis/audio/` contains the gallery and the `variants/`
and `effects/` directories; there are no duplicate top-level music exports.

## FM hardware variants and AWE32 effects

Sound Blaster model names do not uniquely identify the FM synthesiser. The
main historical distinctions are:

| Card family | FM hardware | Relevant capability |
|---|---|---|
| Sound Blaster 1 / 1.5 / 2 | Yamaha OPL2 | Nine-channel mono FM |
| Sound Blaster Pro 1 | Two OPL2 chips | Stereo when the software explicitly drives both chips |
| Sound Blaster Pro 2 | Yamaha OPL3 | More channels, stereo and additional synthesis features |
| Early Sound Blaster 16 | Yamaha OPL3, discrete or integrated | Broadly the same FM capabilities as Pro 2 |
| Later SB16 and some AWE variants | Creative CQM on some board revisions | OPL-compatible programming, with different synthesis characteristics |

Creative's [Sound Blaster programming manual](https://pdos.csail.mit.edu/6.828/2005/readings/hardware/SoundBlaster.pdf)
describes the OPL2/OPL3 distinction. Emulator implementations also distinguish
[Creative CQM from Yamaha OPL](https://86box.readthedocs.io/en/latest/settings/sound.html).
The SB16's 16-bit sampled-audio capability does not automatically improve FM
instruments. Games must explicitly use the additional OPL3 features to benefit
from them. Physical cards can also differ in output filtering, mixing and noise.

Darker's reconstructed FM music path uses OPL2-compatible features. Our DBOPL
and Nuked selections are alternative synthesis implementations, not named
Sound Blaster card profiles. `--music=soundblaster_fm --opl=nuked` uses an OPL3
emulator in its OPL2-compatible mode; it does not emulate an entire AWE32 board.

A Yamaha-equipped AWE32 contains an OPL3 FM synthesiser as well as the separate
EMU8000 sample synthesiser. The existing `soundblaster_awe32` music mode uses
the latter and the game's AWE32 arrangement. It is not an enhanced rendering
of the FM arrangement.

There is, however, an additional AWE32 signal path worth distinguishing:
**OPL FM output can receive EMU8000 reverb and chorus**, depending on the card
configuration. The [Linux EMU8000 driver](https://github.com/torvalds/linux/blob/master/sound/isa/sb/emu8000.c)
explicitly initialises the FM input channels and exposes FM reverb and chorus
depths. This could change the sound heard from an AWE32 while a game is using
its ordinary FM driver. A subsequent trace of Darker's AWE32 library found that it initialises the
FM input channels with **zero reverb and chorus sends**. The additional game
setup call adjusts music volume, not FM effects. See the
[hardware-effects investigation](sound-effects.md#awe32-fm-reverb-and-chorus-dry-configuration).
Externally configured effects in an ordinary FM setup remain a separate
machine-configuration variable; the developers' own settings are unknown.

Our current DOSBox-derived EMU8000 core leaves the incoming OPL audio connection
unimplemented: its source marks the FM memory/input path as unfinished. A
meaningful `soundblaster_fm_awe32` experiment would therefore require implementing
and verifying that connection and selecting documented effects settings. Simply
adding an alias would not reproduce it. That extension remains deferred in light of the zero-send configuration; no
such mode is currently exposed, and no extra reverb or chorus has been added to FM.

## Stereo in the current music modes

All modes feed a two-channel output device, but two channels do not necessarily
contain different signals. The following describes the current default music
backends, rather than every possible historical card or SoundFont override:

| Music option | Music output |
|---|---|
| `soundblaster_fm` | Mono music duplicated into left and right channels |
| `soundblaster_awe32` | Stereo EMU8000 output |
| `gravis` | Stereo GF1 output, using the original UltraMID driver |
| `midi` | Stereo SoundFont output |
| `roland-lapc` | Stereo Munt output |
| `roland-sc55` | Stereo SC-55 output |
| `roland-scc1a` | Stereo SCC-1A output |
| `none` | No music; sound effects remain available |

We checked the rendering paths and compared left and right samples in the
first ten seconds of every available section in the
[complete native FLAC collection](../analysis/audio/native-loops/index.html).
All 13 FM sections had identical channels in those excerpts; every other
exported mode had sections with unequal channels. SCC-1A stereo was additionally
confirmed in the 30-second group-1 comparison render. These are excerpt checks,
not a claim that every instant of every stereo arrangement differs between
channels. Centred instruments and passages can produce identical left/right
signals, while panning and device effects can create stereo elsewhere.

The [original effects hardware detector](sound-effects.md#hardware-detection-and-standalone-music-devices)
can disable effects on a standalone music device without OPL hardware. Our
reconstruction supplies FM effects independently of music-device selection.

Flight sound-effect positioning is separate from music. Mono FM music does
not imply that all game audio is mono. SoundFont overrides may also change the
stereo character relative to the native hardware backend.

## Runtime sequencer verification

The reconstruction offers `--music=none|soundblaster_fm|midi|roland-lapc|roland-sc55|roland-scc1a|gravis|soundblaster_awe32`.
Sound Blaster retains the native FM instrument path. `midi` remains the SCC-1
arrangement through a selectable SoundFont bank; `roland-sc55` plays that
arrangement on an emulated SC-55. LAPC-I uses Munt and the original custom
instrument upload, AWE32 uses its native synthesis library and EMU8000, and
Gravis uses UltraMID and GF1. Explicit SoundFont overrides remain available.
Runtime playback loops continuously rather than stopping at the end of the gallery preview.

The four sampled drivers have now been executed for 16,384 scheduler updates
per arrangement and compared with the C++ sequencer's timed events. SCC-1,
LAPC-I and GUS are captured at their MIDI byte-output routines; AWE32 is
captured at the equivalent note, program, bend and controller calls into its
synthesis library. All 24 streams match, including repeated loops. The original
PIT cadence and Q16 tempo arithmetic are preserved. This verifies the runtime
event mapping beyond the initial provisional gallery conversion described above;
it does not retroactively change the existing MIDI/Ogg exports.

Two differences matter: SCC-1 command 99 releases the previous note only on
channels 0–11, whereas the other three sampled drivers release it on every
sequence channel. GUS also omits the initial channel-volume writes made by the
other drivers. Their command 94 consumes no argument; this differs from the
Sound Blaster version.

LAPC-I initialisation at `07DF–08F9` uploads custom Roland timbres and patch
assignments through SysEx. A generic GM SoundFont cannot reproduce those
uploads. Its rendition therefore preserves the arrangement's note/control
stream but not necessarily the intended instruments. The other sampled
variants likewise depend on the chosen bank rather than the original card's
sample ROM, patches, envelopes, effects and voice allocation. Roland emulation is now available through Munt as described below.


## Original Roland instrument upload

The LAPC-I driver initialiser at `07DF` expands its instrument table at `1A98`
and emits 824 bytes through MIDI output routine `07A7`. The captured
[SysEx upload](../analysis/audio/variants/lapc1-initialisation.syx) and
[decoded message data](../analysis/audio/variants/lapc1-initialisation.json)
contain twelve Roland DT1 messages: six timbres followed by six patch assignments.
The reconstruction reproduces this upload byte-for-byte before Munt playback.

| Program (zero-based) | Memory timbre | Enabled partials | Parameter bytes |
|---|---|---|---|
| 28 | 0 | 2 | 120 |
| 29 | 1 | 2 | 120 |
| 30 | 2 | 2 | 120 |
| 31 | 3 | 1 | 62 |
| 66 | 4 | 2 | 120 |
| 67 | 5 | 2 | 120 |

These are custom synthesis definitions, including oscillator, filter and envelope
parameters, rather than uploaded audio samples. The ten-byte names are skipped,
so the driver does not supply descriptive names. Every patch assignment selects
memory timbres, neutral key shift and fine tuning, twelve-semitone pitch bend,
assignment mode zero and reverb disabled.

`--music=roland-lapc --mt32-rom-dir=/path/to/roms` selects Munt instead of SoundFont
playback. It requires a compatible control/PCM ROM pair supplied separately.
CM-32L is preferred for the LAPC-I driver; MT-32 pairs are also recognised.
The custom instruments survive music changes. Native upload and sequence
comparisons are independent of ROM availability. Six-group PCM checks have
passed with both MT-32 1.07 and CM-32L 1.02 ROM pairs.

## Unmapped Roland percussion notes

Munt's `Rhythm: Attempted to play unmapped key` diagnostic also occurs with
correct CM-32L ROMs and the original LAPC-I sequence events. In the CM-32L 1.02
control ROM, rhythm settings begin at `8580`; entries for MIDI keys 52, 55, 57
and 58 are `[127, 0, 7, 0]`: the timbre is OFF and the output level is zero.
Munt therefore ignores those notes, rather than substituting General MIDI drums.

We executed the full native driver initialiser at `0713`, emulating only the
MPU-401 acknowledgement/command transport and delay, and captured MIDI output
at `07A7`. It produces exactly the same 824 bytes as the instrument uploader
at `07DF`: six timbre definitions and six patch assignments, with no rhythm-map
upload. The unused generic SysEx sender at `07BC` has no direct caller or
function-table entry in this driver.

Native scheduler execution over 16,384 updates per group gives these nonzero-
velocity note-on counts on MIDI channel 10 (status `99h`):

| Music group | Key 52 | Key 55 | Key 57 | Key 58 |
|---|---:|---:|---:|---:|
| 1 / startup | 11 | 0 | 12 | 62 |
| 2 | 123 | 11 | 21 | 0 |
| 3 | 0 | 0 | 0 | 0 |
| 4 | 0 | 10 | 0 | 0 |
| 5 | 0 | 0 | 0 | 0 |
| 6 | 0 | 0 | 0 | 0 |

These events are already covered by the native timed-stream regression checks.
The evidence indicates an original arrangement quirk with factory rhythm
settings, not missing custom-instrument initialisation. Assigning replacement
drums changes the playback; no remapping is applied by default. The optional
experiments below deliberately supply replacements. The diagnostic
is not a ROM loading failure and does not stop other notes playing.

## Opening Roland arrangement: independently looping part

The opening LAPC-I resource (00/40) has twelve sequencer parts. Eleven set their
loop markers at musical tick 3504; part 10 sets its marker at tick 3888. All
first jump at tick 12672. Executing the original 00/35 driver under Unicorn
confirms this is not a static-export artefact: handlers 03B3 (store loop pointer)
and 03AF (restore it) record the expected targets. Both first jumps occur at
scheduler call 4043; subsequent jumps occur at 6968 for part 0 and 6846 for
part 10. No compensating delay is added by the jump handler.

The intro contains the same three-note figure (65, 72, 68) at staggered starts:
part 8 starts at tick 2208, part 9 at 2400, and part 10 at 2592, with the next
two notes 96 ticks apart. Moving part 10 earlier by 384 ticks therefore aligns
it with part 8; that fit alone does not establish incorrect decoding. Whether
the unequal loop lengths reflect intended variation or an authoring error remains
unknown.

[Execution trace](../analysis/audio/roland-gm-percussion-bank/native-loop-trace.json)
and [FLAC inspection stems](../analysis/audio/roland-gm-percussion-bank/README.md)
preserve the evidence. For the opening exports, track1 groups the eleven parts
with the common loop, while track2 contains original part 10; both intros retain
their complete leading silence from time zero.


## Roland GM-bank experiments

The manual's “Roland” selection uses the LAPC-I/MT-32-family driver. It is
separate from the SCC-1/Sound Canvas driver behind “General MIDI”, even though
both hardware families were made by Roland. The LAPC-I initialiser checks the
MPU transport acknowledgement, not the attached synthesiser's identity, and
sends no device reset. A pre-existing synthesiser configuration could therefore
matter; we have no evidence identifying the composer's actual configuration.

Roland supplied an MT-32 General MIDI conversion **bank**, not a replacement
ROM. Its `MTGM.MID` is a setup file containing SysEx. The accompanying instructions
date this version to 7 December 1993. Roland's
[download page](https://www.roland.com/de/support/by_product/all/general_apps_tools/508451ba-ab7a-44bb-979c-a4097dfe1142/)
provides [MT2GM.EXE](https://static.roland.com/assets/media/exe/MT2GM.EXE), which is
an archive readable with `unzip`, despite its extension. The existing control and
PCM ROMs suffice. `MTGM.MID` is 27,607 bytes, SHA-256
`0d0308e00f9045241013f4943c21ba97cb59c3e4e723251ee05f9431b96fdc3c`.

Three optional experiments were implemented, all with `--music=roland-lapc`:

| Option | Processing | Listening observations |
| --- | --- | --- |
| `--roland-gm-percussion-fallback` | Keep native Munt playback; send otherwise-unmapped percussion to a second, SoundFont synthesiser. | Keys 52 and 57 fill convincing gaps. Key 58 is conspicuously rattly compared with the FM arrangement. |
| `--roland-gm-percussion-bank=/path/to/MTGM.MID` | Keep native Munt playback; use a second Munt instance loaded with Roland's bank for otherwise-unmapped percussion only. | The softer rattle fits substantially better; this became the preferred experimental listening setup across the pieces inspected. |
| `--roland-gm-bank=/path/to/MTGM.MID` | Load the whole bank into the main device, then apply Darker's custom upload on top. | Large changes to the arrangement's sound; listening did not support treating this as the intended configuration. |

The two percussion options retain the original events on the main device, so
its unmapped-key diagnostics remain audible-event references in the console.
Already-mapped percussion is not doubled. The options are alternatives, not
switches to stack together. Omitting them restores original factory-map playback.

| MIDI key | General MIDI meaning | Roland bank's replacement (zero-based internal timbre) |
| --- | --- | --- |
| 52 | Chinese cymbal | Writable timbre 63 |
| 55 | Splash cymbal | Writable timbre 61 |
| 57 | Crash cymbal 2 | Writable timbre 60 |
| 58 | Vibraslap | Rhythm timbre 92 |

The full bank replaces all 64 writable timbres, changes patch assignments,
partial reserves and receive channels. In particular, melodic receive channels
become 1–8 instead of the factory 2–9: this can change which parts sound, not
just their instruments. Applying Darker's six timbres afterwards does not undo
those other changes. Some bank writes lie outside Munt's recognised memory
regions and are reported and ignored. None of these experiments proves that
Darker expected this bank; the separate-device option is a reconstruction of
missing percussion, not a claim that the original used two devices.

## What plays on the drifting opening part?

For discussion and export, **track1** means the eleven parts sharing the common
loop; **track2** means original sequencer part 10. These are research stem names,
not original titles, MIDI channel numbers or a long/short classification.

Track2 uses MIDI channel 8 (zero-based 7). It selects zero-based program 24,
**Syn Brass 1**, at tick 1585, then program 32, **Fantasy**, at tick 6576.
Its first notes after that second selection occur at tick 6578. These are
factory melodic patches, not Darker's six uploaded patches, and not the missing
rhythm notes. The out-of-sync part therefore exists without either percussion
repair. Adding percussion did not create it.

The common loop lasts 9168 ticks; track2 lasts 8784 ticks. Their first loop
jumps coincide, but later jumps drift. Their loop boundaries realign after
1,677,744 ticks: 183 common loops and 191 track2 loops, approximately 2 hours
58 minutes 25 seconds after the first common jump. This is a sequencer boundary,
not a guarantee of identical synthesiser oscillator or reverb state.

An audit of all thirty arrangements found no equivalent drifting opening loop
outside LAPC-I. The FM version of group 2 does contain a shorter loop: one part
repeats every 768 ticks against 4608 ticks for the others, an exact six-to-one
relationship. That is different from the LAPC-I opening's gradual displacement.
The remaining arrangements have matching per-part loop lengths.

Listening under DOSBox did not clearly reveal track2. That observation does
not contradict the native event trace: MIDI routing and synthesiser state still
need identifying for that listening configuration. It is not evidence of an
extra pause or a different loop handler in the original driver.

## Corrected listening references and interpretation

The team prepared two hand-corrected opening mixes for future research:

- [Group 1 — corrected intro](../analysis/audio/roland-gm-percussion-bank/group-1-corrected-intro.flac)
- [Group 1 — corrected loop](../analysis/audio/roland-gm-percussion-bank/group-1-corrected-loop.flac)

Both are 139.359-second, 48 kHz stereo, 16-bit FLAC files. They are edited
listening references, not native timing exports; their names identify their
intended roles, not the native intro/loop boundaries. They were supplied as
finished mixes and have been retained unchanged. The exact edit operations,
gains and joins have not been independently reconstructed.

During comparison, moving track2's introductory melody earlier to align its end
with track1, and aligning its loop to the end of track1's loop, produced a much
more convincing musical fit. The corrected mixes preserve the team's proposed
interpretation for listening. They do not replace the unmodified stems, source
sequences or native execution trace. See the
[recording catalogue and provenance](../analysis/audio/roland-gm-percussion-bank/README.md)
for both sets; the manifest records the corrected files separately.

Our working hypothesis is that the LAPC-I version was an adaptation of material
primarily developed or checked on another setup, leaving unmapped percussion
and an unintended loop mismatch. Supporting evidence includes the isolated
loop anomaly and shared percussion material: in group 1's source streams,
SCC-1, GUS and AWE32 each contain six key-52, three key-55, three key-57 and
twelve key-58 note commands; LAPC-I retains two key-52, three key-57 and twelve
key-58 commands. These are source-command counts, not the repeated native
scheduler counts above, and do not establish identical event timings.

This is an inference, not confirmed authorship history. Another Roland device,
such as a Sound Canvas, remains a candidate for the primary setup. Musical
plausibility alone cannot identify a canonical mix or the composer's hardware.

## Remaining hardware comparison work

The runtime event streams have been verified. Native AWE32 and Gravis synthesis
are now implemented as described below; physical-hardware recordings can help
check the emulator cores' remaining timbral differences. The original SCC-1 revision still awaits its internal processor ROM;
the later SCC-1A v1.30 now has a verified complete set and native playback. The SC-55 is an independently
identified and working period General MIDI alternative.

[Nuked-SC55](https://github.com/nukeykt/Nuked-SC55) supports CM-300/SCC-1 hardware
when supplied with a complete matching ROM set. Further comparisons should help
separate arrangement choices from device timbres, but cannot by themselves prove
which hardware was used during composition.

### SC-55 playback implementation

`--music=roland-sc55` now provides SC-55 v1.21 hardware emulation for the
original SCC-1/General MIDI arrangement, through the Nuked-SC55 backend.
The existing `midi` option remains a SoundFont rendition.
`roland-lapc` selects LAPC-I/MT-32-family emulation; the ambiguous former
`roland` name now produces guidance to choose `roland-lapc`, `roland-sc55` or `roland-scc1a`. This is a faithful
SC-55 playback configuration, not a claim of SCC-1 hardware identity.
The five v1.21 firmware/sample ROMs are fetched separately, identified by
SHA-256 at runtime, and never embedded in the executable. The tested source is
[this ROM collection](https://archive.org/details/nuked-sc-55-clap-rom-files).
The original SCC-1 v1.10/v1.20 set is still unavailable locally: its internal processor ROM
R15199774 is the outstanding file. Its absence does not prevent running the
same MIDI arrangement on a correctly emulated SC-55.


### SCC-1A playback and comparison with SC-55

`--music=roland-scc1a` now runs the same original SCC-1/General MIDI event
stream on Nuked-SC55's CM-300 hardware path with SCC-1A v1.30 firmware.
The complete set in `8vvq0a.zip` (`roms/scc1a/`) matches all five upstream
SHA-256 definitions. Its paired program ROMs are R00128523 and R00128567;
its three wave ROMs are R15279806, R15279807 and R15279808. This resolves
emulation for the SCC-1A revision, not the missing original SCC-1 MCU.

Place `cm300_rom1.bin`, `cm300_rom2.bin` and `cm300_waverom1.bin` through
`cm300_waverom3.bin` beside the packs, or supply `--scc1a-rom-dir`.
ROMs remain external runtime assets; the existing SC-55 choice remains available.

We compared the first 30 seconds of each of the six music groups, starting a
fresh device for each rendition. Both received the same native event sequence,
with three seconds of firmware boot before playback. Measurements use 48 kHz
stereo float output at unity gain, without clipping or normalisation.
[Full measurement results](../analysis/audio/scc1a-comparison/results.json)
include RMS levels, peaks, waveform correlation, timing search and band power.

| Music group | SCC-1A level relative to SC-55 | Largest absolute band difference below 12 kHz | Stereo waveform correlation |
|---|---:|---:|---:|
| 1 | -0.09 dB | 0.27 dB | 0.372 |
| 2 | -0.28 dB | 0.38 dB | 0.155 |
| 3 | -0.04 dB | 0.22 dB | 0.334 |
| 4 | +0.09 dB | 0.44 dB | 0.469 |
| 5 | -0.30 dB | 0.29 dB | 0.440 |
| 6 | +0.02 dB | 0.35 dB | 0.149 |

Broad band powers use mono downmixes, 4096-sample Hann windows, and bands
0–200, 200–1000, 1000–4000 and 4000–12000 Hz. Above 12 kHz, group 6 differs
by +2.77 dB; the other groups differ by less than 0.20 dB in that band.
Searching ±50 ms for a constant offset raises mono waveform correlation to
0.20–0.74 depending on the group, so a single fixed delay does not explain all
the differences. Ten-millisecond RMS envelope correlations range from 0.53
to 0.97.

The renders are not sample-identical, but their average levels and broad
spectral balance are very similar. These measurements do not establish a
large perceptual change, identify which firmware behaviour causes each
difference, or determine the composer's original hardware. Phase, modulation,
voice timing and effects can all change waveform correlation without changing
the overall instrument character. A listening comparison remains useful.

Both devices passed note playback, reset and exact output equality across
512- and 257-frame host buffers. SCC-1A also started successfully in the normal
Debug game executable using ROMs installed beside the game packs.

## Native AWE32 and Gravis playback

The reconstruction now offers native synthesis for the remaining two sampled
arrangements. `--music=soundblaster_awe32` uses the AWE32 sample ROM and an
EMU8000 emulator; `--music=gravis` uses the original UltraMID resident driver
and Gravis patches with a GF1 emulator. Explicit `--soundfont` overrides retain
the previous comparison renditions. Sound effects remain on their separate
original OPL path.

### AWE32

Resource `00/37` contains both the Sound Images sequencer and Creative-style
synthesis library. Its initialiser at `1002` installs the preset tables at
`4818`, `4A20`, `4B8C`, `5100`, `5266`, `5830` and `82AE`. Note-on enters at
`3EEA`, note-off at `3E0A`, controller changes at `4314`, programs at `4454`
and pitch bend at `45FE`. The existing verified C++ sequencer now invokes those
original library functions in an isolated x86 instance; their I/O drives the
EMU8000 instead of being intercepted and redirected to a generic SoundFont.

An important compatibility detail occurs at `2B8E`: this old library compares
the device identification against exactly `000C`. The upstream EMU8000 core
reports `001C`, causing the library to return success without most hardware
initialisation. Reporting the earlier `000C` revision enables the original
initialisation sequence. Native sample-counter polling must also advance the
emulated chip, including shutdown/release operations.

The sample ROM is the 1 MiB `awe32.raw` from the
[86Box ROM collection](https://github.com/86Box/roms/tree/master/sound/creative).
The synthesis core comes from [DOSBox-X's EMU8000 implementation](https://github.com/joncampbell123/dosbox-x/blob/b60936a716c72e0978e940f813bab2cd40d43868/src/hardware/emu8k.cpp),
derived from 86Box. The ROM stays a runtime asset.

### Gravis UltraSound

Resource `00/36` locates UltraMID using its `ULTRAMID` signature at offset
`0103` in a segment referenced by interrupt vectors `78`–`7F`. MIDI output at
`0E5D` passes a byte in `CL` to resident service `AX=0010`. Patch loading,
program interpretation, voice allocation and envelopes belong to that resident
driver, not Darker's sequencer.

The reconstruction runs UltraMID 1.12 with the documented `-c` preload option,
a 1 MiB GF1, port 240, DMA 3 and IRQ 5. Its original `ULTRAMID.INI` is important:
the 1024K column maps GM programs to a reduced set of patches that fits card
memory. This uses 85 distinct patches, rather than loading every individually
named GM instrument. For example, program 0 maps to the bright-piano patch.
These substitutions are original driver behaviour, not missing extraction.

The [preserved Gravis installation in Boxer](https://github.com/alinebee/Boxer/tree/master/Resources/DOS%20Toolkit/ULTRASND)
supplies the executable, INI and patch data. The
[UltraMID programming manual](https://github.com/RobertSundling/GUSDK222/blob/main/ULTRAMID/ULTRAMID.DOC)
describes preload mode and resident services. The GF1 core is isolated from the
pinned DOSBox source already used for FM effects. A small private DOS-service
adapter supports startup, read-only patch loading, memory and DMA; it does not
run the game or a full DOS operating system. Hardware interrupts execute
UltraMID's original envelope handling, and hardware continues advancing while
the library waits for voice ramps to finish.

Both hardware paths pass note/release, consecutive-group and output-block-size
checks. Gravis additionally renders twenty seconds of all six groups on a
separate audio thread. Original timed sequence comparisons are unchanged.
These are working original-driver hardware emulations; analogue-output identity
and the composer's preferred hardware still require independent evidence.

### Register-polling audio continuity correction

Listening and waveform inspection exposed periodic clicks in the first native
Gravis and AWE32 implementations. Both advanced their chip emulation during
native register reads but discarded the resulting PCM. These missing waveform
segments caused discontinuities even in offline exports; the problem was not
host audio underruns. Both adapters now retain runtime polling samples in
playback order. Gravis also counts those samples towards its BIOS clock.

The three-minute opening captures use the fixed playback path:

- [Gravis](../analysis/audio/gravis-native/group-1-opening.flac).
- [AWE32](../analysis/audio/awe32-native/group-1-opening.flac).

These are uninterrupted diagnostic captures of the opening arrangement, not
intro/loop stems. The Gravis correction removes the 57 sample-to-sample steps
larger than 0.2 in the first ten seconds of the previous stereo float export.
Instrument balance and hardware fidelity remain separate listening comparisons.

### Gravis RAM selection

`--music=gravis --gus-ram=256` selects 256 KiB of card RAM. The other supported
sizes are `512`, `768` and `1024`; 1024 remains the default. This changes the
DRAM detected by the original UltraMID executable, which selects the matching
preload column in `ULTRAMID.INI`. It does not replace the patches with a modern
bank or change Darker's sequence. All four sizes use `ULTRAMID -c`.

Darker forwards MIDI to the resident driver rather than loading instruments
per song. Per-song loading is an UltraMID capability, but is not offered here:
it would change the game's original approach. The fetch script supplies the
union of patches required by the four original preload maps. All six groups
are checked at every RAM size.

## Complete native music FLAC sections

The [lossless music collection](../analysis/audio/native-loops/index.html) provides
complete intros and loops for Sound Blaster FM (DBOPL), General MIDI (FluidR3),
Roland LAPC-I/CM-32L, Roland SC-55, Gravis UltraSound with 1 MiB, and AWE32.
All are 48 kHz stereo, 24-bit FLAC, rendered through the current engine without
fades, per-track normalisation, filtering or extra tails. SC-55 exports alone
use a fixed gain of 0.5 (−6.0206 dB), because their floating-point peaks exceed
full scale; this avoids clipping while preserving relative levels between its
pieces. Other modes use unity gain. Smaller Gravis RAM settings
are not exported. Existing Roland GM percussion-bank exports are linked rather
than duplicated, and the hand-corrected Roland research mixes remain unchanged.

The LAPC opening and FM group 2 have separately repeating parts, so those
pieces are supplied as two parallel stems. Start both intros together; each
then proceeds immediately into its own repeating loop. Leading silence is
included. Group 6 starts directly with its loop. See the collection's timing
notes and manifest for original part numbers, sample boundaries and hashes.

## Scene and briefing music mapping

The [scene and music catalogue](../analysis/presentations/music.html) lists the fresh entry path for all 124 script records, following explicit page chains and exposing music changes. Each of the six groups links to complete intro/loop FLACs for the exported hardware modes. The [presentation browser](../analysis/presentations/index.html) groups animation clips by scene and links their active music directly.

Group numbers are one-based, whereas opcode `40` takes a zero-based selector. Level 1 starts with group 6 for the quotations, then changes to group 2 for the welcome and briefing. Startup and menu music use group 1; death/committal and the final presentation select group 6. Flight itself has no background music. Records without a selection inherit caller state; seamless continuation can bypass a briefing, so this catalogue must not be read as a compulsory playlist for every entry route.