SC2MUSIC - Super Cars II (Atari ST) chip music, extracted for conversion work

Source: CARS.REL from the original disk (loads at $10000). The music driver
and the tune data are inside CARS.REL; there are no separate music files.

Tunes
  0  title / attract music     (started by the game with d0=0 at $16EF8)
  1  menu / post-race music    (d0=1 at $1754C and $1776A)
  The tune table at $1EBA0 holds 2 tunes: tune 0 header $1EE40, channel
  data A/B/C at $1F73E, $1F82A, $1F916; tune 1 header $1EE4C, channel data
  at $1EE58, $1EF9C, $1F0E0. Entries after the second one are not tunes.

Driver entry points (runtime addresses)
  $1C996  init: d0 = tune number (game does: move.w d0,$1B7EA then jsr)
  $1CAB6  tick 1, called from the VBL
  $1CBC4  tick 2, called from the Timer B interrupt at the bottom of the
          screen. So the driver runs twice per 50Hz frame.
  The driver writes YM registers 0-10 only. The hardware envelope (regs
  11-13) is never used; volumes never set the envelope bit.

Files
  SC2MDRV.BIN    CARS.REL from $1C996 to the end ($20310): the driver code
                 and all music data, loaded at $1C996.
  SC2TUNEn.R100  register log, 100 records per second (one after each
                 driver tick), 14 bytes each = YM regs 0-13 read back from
                 the chip. 3 minutes = 18000 records. This is the exact
                 data the driver produced in Hatari.
  SC2TUNEn.YM    the same at 50Hz (the record after the second tick of each
                 frame) in plain YM3 format (interleaved, reg 13 = $FF), for
                 YM players. Loses the half-frame updates; use R100 for
                 accurate conversion.
  SC2TUNEn.WAV   reference render of the R100 log by YMRENDER.PY (my simple
                 YM2149 model, not an emulator recording), 44.1kHz mono.
  YMRENDER.PY    the renderer.
  MUSREC.S       the Hatari ROM used to record the logs: it runs the game's
                 own driver from CARS.REL and reads the YM registers back.

Not done: the song loop points. Neither tune repeats exactly within the
3 minutes recorded, so the loop length is not known yet (repeating
6.4 second phrases exist inside tune 0). Decoding the driver's sequence
format would settle it.
