K.M.I. - the site
 Please note that this webpage is archived for historical purposes and is no longer being maintained or updated.  
[ Fairlight CMI ]  
General info

Greg Holmes' page
Jean-Bernard Emond's page: Manuals + Schematics + EPROM


click here


click here

Fairlight CMI Series III/MFX software revisions (OS-9) overview:

click here

CMI Series I, II, IIx:

Operating system:
QASAR variant QDOS of Motorola's MDOS, running on CPU P2. Series I/II machines have a dual-6800 system with 64KB shared system RAM, whereas the Series IIx has a dual-6809 with 256KB shared system RAM (up to 2MB) running a special QDOS-6809 version. (Note that the Series IIx is also capable of running OS-9, see Series III below.) By default, CPU P1 runs a service request loop in ROM. During cmi-software operation, CPU P1 is running a real-time control executive for sampling, channel-card control, sequencers and handles the music+Alpha-keyboard input data. CPU P2 runs the operating system (CMIDOS.SY + CMI.SY) which is resonsible for non-realtime tasks as file I/O and the graphical user-interface. Note that P1 and P2 share the QASAR RAM and MMU.
Cmi software consists of two parts: a system-resident part (operating system and shared cmi code) and dynamically loaded overlay parts (display pages plus associated code).
For convenience and archiving purposes, the file LBFILE.SY contains a user-maintainable database ("disk library") for up to 80 disks and the files contained on each disk (80 disk IDs and 80x128 encoded file-names).
(See Greg Holmes' page for more infos.)
Note: The QASAR QDOS has nothing to do with 86-DOS, which is often referred to as "QDOS" (or "Quick and Dirty Operating System"), written by Tim Paterson for Intel 8086-based computers. Furthermore, QASAR QDOS has also nothing to do with QDOS for the Sinclair QL (68008-based) computer system.
(click here for more infos about MDOS and other operating systems)

By default, the optional SMIDI processor (68000, "MP", CMI-28) runs a service request loop in ROM ("MON"). During cmi software opertation, the SMIDI processor is running the mdmain68 (in MIDI.LO) SMPTE+MIDI real-time executive.

During cmi software operation, the optional AIC processor (6809, CMI-07) is running the AIC09.LO executive.

Device drivers/low-level driver ROMs:
click here to go to the Series III chapter

click here to go to the Series III chapter

File extensions:
click here to go to the Series III chapter

User Software/Sequencers:
Keyboard Sequencer ("Page 9", .SQ timed MIDI-frame file format)
Music Composition Language ("MCL", "Page C", compiler with .SQ output)
Real-Time Composer ("Page R", 1980, 8-voice sequencer, by Michael Carlos and Tom Stewart, infos: Greg Holmes)
Film Music Processor ("FMP", timecode sequencer, for Series IIx, see also Series III below)
STAVEWRITER (music printing system, for Series IIx with HP 7475A plotter)
(See Greg Holmes' page for more infos.)

QDOS filesystem:
derived from Motorola's MDOS filesystem, 512512 Bytes total per drive or partition, fixed 128-Byte sector size, fixed 512-Byte cluster size, 8-Byte file size granularity, flat filesystem (no sub-directories), place for up to 160 files in root directory
(see also OS-9 backup/conversion commands for QDOS below)

QDOS file extensions:
2-letter file extensions, upper-case file names (8 letters max.)
click here to go to the Series III chapter

QDOS 8" floppy format (Series I/II/IIx)
Drive: Mitsubishi M2896-63, Qume Q242, YE Data YD180
360rpm, single density (FM), soft sectored (1 index hole), 77 tracks/side, 26 sectors/track, 128 Bytes/sector, 500KBit/sec raw
single-sided -> total: 2002 sectors = 250.25KB formatted
double-sided -> total: 4004 sectors = 500.5KB formatted
There are two variants of the double-sided QDOS format: QDOS-6809 and QDOS-6800 ("old QDOS"), differing in the low-level sector-numbering scheme for side 1 (which is handled by the low-level driver and is transparent to the user as long as the device parameters are set appropriately).
For compatibility, Series IIx machines (running QDOS-6809) still employ the (old) QDOS-6800 format for CMI sound-disks (with the system-disk however having the new QDOS-6809 format).

QDOS Winchester drive format (Q077):
Drive: ???
QDOS parameters:
OS9 parameters:
7 heads, 219 tracks/head, 32 sectors/track, 256 Bytes/sector
total: 49056 sectors = 12264KB formatted
(OS9 devices: /wdv0, /wdv1)

QDOS-only system:
bootstrap in sector 0017, loads kernel via RIB in sector 0018
QDOS.SY (QDOS kernel, RIB at sector 0018)
QDOSOV0.SY (QDOS overlay: disk allocation)
QDOSOV1.SY (QDOS overlay: I/O and memory functions)
QDOSOV2.SY (QDOS overlay: I/O functions)
QDOSOV3.SY (QDOS overlay: file functions)
QDOSOV4.SY (QDOS overlay: file functions)
QDOSOV5.SY (QDOS overlay: chain file execution)
QDOSOV6.SY (QDOS overlay: shell (command interpreter))
QDOSER.SY (error messages)

typ. address space layout (CPU P2):
0000-007F: system variables
0080-00FF: bootstrap
0100-1FFF: QDOS system (kernel, overlays)
2000-3FFF: 8KB user program space
4000-7FFF: 16KB user program space
8000-BFFF: 16KB user program space or VRAM

CMI-6809 system:
bootstrap in sector 0017, loads kernel via RIB in sector 0018
CMIDOS.SY (customized QDOS kernel, RIB in sector 0018)
CMI.SY (CMI system code, loaded by kernel)
CMIERR.SY (error messages)
PROVER0.SY (page R system overlay)
PROVER1.SY (page R system overlay)
PRGROM.SY (page R graphics bitmaps + code)
LBFILE.SY (disk library)
Note: CMIDOS.SY is a customized QDOS kernel, containing only the necessary QDOS system services. CMI.SY is the cmi system software, containing a proprietary multi-tasking system for CPU P2 with a graphics/light pen user interface and real-time code for CPU P1. (Although QDOS-6809 supports Q256 and Q096 systems, CMI.SY for the CMI Series IIx runs only on Q256 hardware.)

typ. address space layout (CPU P2):
0000-BFFF: variable mapping (CMI system)
. 4000-7FFF: optionally mapped to CMI-07 RAM (AIC09)

. 8000-BFFF: optionally mapped to VRAM
C000-C7FF: RAM
C800-CFFF: RAM, for communication with CMI-28 (MIDI)
E000-E7FF: channel hardware
F000-FFFF: peripherals

typ. address space layout (CPU P1):
0000-BFFF: variable mapping (CMI system)
. 4000-7FFF: optionally mapped to CMI-07 RAM (AIC09)

. 8000-BFFF: optionally mapped to VRAM
C000-C7FF: RAM
C800-CFFF: RAM, for communication with CMI-28 (MIDI)
E000-E7FF: channel hardware
F000-FFFF: peripherals

CMI Series III, MFX1, MFX2:

Operating system(s):
The dual-6809 QASAR has the overall control of the CMI system. CPU P2 runs the OS-9/6809 Level 2 operating system with the graphical user interface and the sequencers (RS, CAPS, TT, CL, PFTASK) as real-time tasks. CPU P1 is used as a co-processor with its own operating system and tasks.
The general interface processor (SMIDI, CMI-28) is responsible for the system timing and real-time events, directly triggering the CMI-31 channel cards. (The QASAR sequencers transmit/receive timed MIDI events to/from the CMI-28's play/record queues (contained within QASAR RAM). Here, the time-critical part is done by the CMI-28.)
Each CMI-31 channel card has an on-board 68B09 CPU for control of the address/clock generators and the analog post-processing VCF/VCAs of its two channels.
The waveform processor (CMI-33) (or waveform supervisor (CMI-41) in later revisions) is responsible for waveform manipulation/loading/saving and sampling. Furthermore, large parts of the MDR harddisk-recorder software (including the GFX graphics library) are executed on the CMI-41.
Inter-processor communication is based upon interrupts (IPIs) and mailboxes (shared memory areas), whereas intra-processor inter-task communication employs semaphores and shared memory techniques (offered by the processors' operating systems).

1) QASAR version of Microware's OS-9/6809 Level 2 multitasking realtime operating system ("Fairlight OS9 Level 2"), running on CPU P2 (6809, Q209), using the virtual memory paging hardware (MMU) on the system RAM boards (Q256/Q356). CPU P2 runs the graphical user interface (cmi part) and the sequencers (RS, CAPS, CL, TT, PFTASK) as tasks. (OS9 requests=SWI2, system tick=1/16sec.) P2 ROM code bootstraps the system from disk. The OS9 kernel is able to offer "clock tick" interrupts to other processors (P1, MP, WP, WS) if required (normally, only the JKERNEL on the WS has this feature enabled).

2) By default, CPU P1 (6809, Q209) runs a service request loop in ROM (Q133). During OS9-only operation, P1 is running the executive iop (providing ROM services and improved text console I/O "IOPACK"). During cmi/mdr software operation, P1 is running the P1Exec multi-tasking non-preemptive kernel (contained within the p1task module) with various P1 tasks, especially the IOPACK P1 task iopcmi (replacing iop). Communication P2<->P1 is accomplished via the OS9 task p1task (i.e. running on P2) and the communication P1 task P2Serve, which are responsible for the p1exec startup/termination and creating/killing of P1 tasks. (P1Exec requests=SWI2.) CPU P1 is used for the execution of IOPACK commands (text console I/O) and especially for big parts (non-realtime) of the sequencer software (RS/CAPS/CL/TT). Note that P1 and P2 share the QASAR RAM and MMU. In Rev<=8, P1Exec services channel card requests (CHINT, IRQ2 P1 interrupt), especially setting the output router (ESP-RT1, in Rev8) and forwarding an IPI to the WS/WP under dtm operation. In Rev>=9, P1Exec simply forwards the channel card interrupt to WS CCINT (see below).

3a) By default, the waveform processor ("WP", CMI-33) runs a service request loop in ROM ("KMON"). During cmi/dtm software opertation, the waveform processor runs the wpexec68 waveform service request executive for non-realtime waveform manipulation, loading, saving, sampling and general administration of waveform-memory. Communication with wpexec68 is accomplished by the OS9 task wptask.

3b) By default, the the waveform supervisor ("WS", CMI-41) runs a service request loop in ROM ("KMON20"). During cmi/mdr software opertation, the waveform supervisor (CMI-41) executes a multi-tasking system called JKERNEL (jker module in jsys). J-modules (for J-tasks) are identical to OSK-modules, but differ in the CRC since Rev8 (J: $000000 and OSK: $800fe3). The JKERNEL was developed by Chris Johnston Walker in 1986. (JKERNEL is not to be confused with the Java-based J-Kernel.)
The CMI-41 J-task wsexec plays the same role as the CMI-33 executive wpexec68 (non-realtime waveform manipulation, loading, saving, sampling and general administration of waveform-memory). Communication with wsexec is accomplished by the OS9 task wstask. JKERNEL access to OS9 resources (esp. the OS9 filesystem) is accomplished by wsst ("WS server task", OS9 task) and Server020 (J-task). On the other hand, OS9 requests are serviced by Server09 (J-task). The WS SCSI/TSCSI driver is implemented in KMON20 (no cmi/mdr running) or via the jscsi module (in jsys, plus SCSI Deblock J-task in Rev>=9). The J-task SCSI Driver (cmi/mdr running) acts on behalf of the QASAR low-level driver for WS devices. For fast page changing, OS9 modules can be kept in WS memory space, served by the wsm/wsm-file J-tasks. Large parts of the MDR disk-recorder software (and the GFX graphics library) run under the JKERNEL system. (JLIB library, jker requests=trap 9, jscsi requests=trap 6/7/8/a, system tick=1/16sec.) In Rev>=9, the CCINT WS interrupt (forwarded channel card CHINT, see CPU P1 P1Exec above) and CC-Driver J-task (cctask68 in older revisions) are used to service channel card requests, esp. setting the output router (ESP-RT1) and metronome click.

3c) As a software development system, there is also a CMI version of OSK Level 1 ("OS-9/68K Level 1", no MMU) available for the waveform processor/waveform supervisor (CMI-33: 68000, CMI-41: 68020+68881), using the QASAR as an I/O processor and the waveform RAM as additional main memory. (Note: OSK uses WRAM in "16-Bit mode", i.e. sets the "not-8-Bit" line to 1 for compatibility reasons with old WRAM cards. For the CMI-33 this gives 14MB. In the CMI-41 case, where the "not-8-Bit" line is address line 24, this reduces OSK memory to the upper 16MB. Nevertheless, an OSK program can access the unused lower 16MB directly via pointers.) (OSK requests=trap 0.)

4) By default, the SMIDI processor (68000, "MP", CMI-28) runs a service request loop in ROM ("KMON"). During cmi/MDR software opertation, the SMIDI processor is running the midi68 SMPTE+MIDI real-time executive. Communication with midi68 is accomplished by the OS9 task mptask. The midi68 executive is the main real-time component of the CMI/MDR system (MIDI, SMPTE, channel card events, sequencers, MDR time), directly controlling/triggering the channel cards. Startup and communication with OS9 via mptask. Sequencer communication (RS, CAPS, TT, CL, PFTASK) is accomplished via separate play/record queue buffers for each sequencer (2KB, in QASAR RAM). Events are in form of timed MIDI frames (8 Bytes). Time measurement is based upon "time-unit" values (1/48000 sec, for sub-frame timing resolution, independent of frame-rate).

5) The channel cards processors (68B09, "CC", CMI-31) run the real-time control executive ccprog / mdrccprog / dtmcc(rev2) / dtmwscc with the cmi / mdr / dtm / wsdtm software, respectively. Startup and communication with OS9 via mptask, mdrtask and drtask, respectively. Directly controlled from MP midi68, WS J-task CC-Driver and WS CCINT handler. With MDR/DTM: Sample-clock locked to MDR time (provided by midi68). Real-time clock ("tick") from CMI-32 timer, triggering FIRQ (typ. 1msec) for envelope-timing.

6) The XDR sample card DSP (56001, ESP-348) runs proprietary sampling/rate-conversion/scaling/routing code from ESP-348 ROM called DSP348. Communication with WS via bi-directional serial interface. (With Rev6 firmware, real-time digital sample-input scaling and automatic 44.1k/48k conversion possible.)

7) The DSP96K (96002, ESP-96K) runs proprietary time-dilation/contraction code: dsp96k.obj* modules. Communication with WS via shared WRAM on ESP-96K by use of the mdrwsmain J-task, which acts as a loader (transferring dsp96k.obj* modules to ESP-96K RAM) and as a server for 96K-requests during waveform manipulation.

(click here for more infos about OS-9 and other operating systems)

Fairlight CMI Series III/MFX software revisions (OS-9):

Rev 3.?:
Rev 4.?:
Fairlight OS9 Level 2 - Version 4.23 - 7th July 1986
IOPACK v2.06
(Note: Stereo voice capability)
Rev 5.4:
(Note: Flanger, Mix, CL, DTM, optionally: CAPS)
Rev 6.03:
Fairlight OS9 Level2 - Version 5.14-fk - 26th October 1988
IOPACK v3.22
(Note: last release for Waveform Processor CMI-33, CAPS)
Rev 7.30:
(Note: first release for Waveform Supervisor CMI-41)
Rev 8.30R:
FAIRLIGHT CMI/OS9 LEVEL 2 - VERSION 6.13:fkw 21st June 1989
IOPACK v5.00
MFX Version 1.10 28 Oct 1988
(Note: XDR release, requires "software security boot floppy")
Rev 9.34:
FAIRLIGHT OS9 VERSION 6.39:fkw 29th April 1992
(Note: final MFX1 release)
Rev 10.19:
(Note: first MFX2 release)
Rev 11.39:
FAIRLIGHT OS9 VERSION 6.46:fkw 23rd March 1993
(Note: final MFX2 release)
Rev 12.?:
(Note: first MFX3 release, last release with CMI functionality)
Rev 13.?:
(Note: final MFX3 release, last release for Waveform Supervisor+QASAR)
Rev 14.?:
(Note: MFX3plus release, first release for Wave Executive)
Rev 15.?:
(Note: MFX3.48 release)

Fairlight OS-9/6809

Main directories
Note: File names are case-insensitive (saved case-sensitive), but normally directory names are all in upper-case letters by convention.

Partition table (if hard disk):
(see special entries in LSN0 of /sc00)

Secondary bootstrap
(if hard disk):
(see special entries in LSN0 of /sc00)
= go2_9 for partition 9 (/d0=/k0)
= go2_1 for partition 1 (/d0=/c0)
contains module "GO"

Main modules
(see special entries in LSN0 of /d0)
contains bootstrap module ("GO"), additional low-level device drivers (loaded by GO, e.g. for CMI-41 SCSI), main modules ("kernel", "init", "sysgo", "clock", "ioman", "ersw", "adsw"), file managers ("pipeman", "scf", "rbf"), device drivers, device descriptors
(Note: in older revisions, the Q219's light-pen and the Q077 were also supported as /lpen and /wdv..., respectively)
Kernel versions and boot partitions: "fk"=/f0 or /k000 Q777 SCSI, "fkw"=like "fk" but CMI-41 SCSI, "c"=/c000

contains modules "Shell", "goback", "goto", "ifyes", "ifno", ...

Startup shell script

Additional modules ("Utilities"):
/d0/CMDS/utils_x (x=1,...,4)
(loaded by startup)

Session file

OS-9/6809 development system (Rev=x):

OS-9/68K (OSK) development system:
/k0/CMDS/osk (6809 OS9 task)
/c001/OSK/oskboot_c1 (CMI-33 OS-9/68000 kernel)
/c001/OSK/oskbt20_c1 (CMI-41 OS-9/68020 kernel)


/d0/CMDS/wsst (WS server task, running on 6809)
/d0/CMDS/jsys (jkernel + jscsi, see CMI-41 below)

device aliases (see also OS9 command "adevice"):
Rev. 11.39:
/c0 -> /c000
/c1 -> /c001
/cmif -> /c0
/k0 -> /k000
/k1 -> /k001
/k2 -> /k002
/k3 -> /k003
/d0 -> /k0 (or /c0, or /f0 if booted from floppy)
/d1 -> /k1
/d2 -> /k2
/d3 -> /k3
/tape -> /sc10 (first tape drive)
/xtape -> /sc50 (second tape drive)
/w0 -> /sc30 (WORM drive)
/p1 -> /p1_19k2 (first printer)
/wsp1 -> /p1_19k2ws (wsacia driver (uses WS) instead of sacia)
/p2 -> /p2_9k6 (second printer, not available for printing with MFX)
/mfx -> /p2_19k2 (MFX keyboard)
/term -> /term_9k6
/comms -> /comms_9k6
Rev. 9.34:
/c0 -> /c000
/c1 -> /c001
/cmif -> /c0
/k0 -> /k000
/k1 -> /k001
/k2 -> /k002
/k3 -> /k003
/d0 -> /k0 (or /c0, or /f0 if booted from floppy)
/d1 -> /k1
/d2 -> /k2
/tape -> /sc10 (first tape drive)
/xtape -> /sc50 (second tape drive)
/w0 -> /sc30 (WORM drive)
/p1 -> /p1_9k6 (first printer)
/p2 -> /p2_9k6 (second printer)
/mfx -> /p2_19k2 (MFX keyboard)
/term -> /term_9k6
/comms -> /comms_9k6
/lazer -> /p1_9k6 (first printer)
Rev. 6.03:
/u0 -> /c000
/u1 -> /c200
/u2 -> /c300
/u3 -> /c400
/u4 -> /c500
/u5 -> /c600
/w0 -> /sc30
/w1 -> /sc40
/w2 -> /sc50
/w3 -> /sc60
/w4 -> /sc70

QASAR Device drivers:

The device drivers for hard disks and floppy drives are splitted into two parts: OS-9 driver module or QDOS driver (containing the controller address and device parameters) and the low-level device driver (with OS-independent standard call table interface). With Series IIx/III, the low-level driver is contained within ROMs on the controller cards, loaded by the Q133 (typically via loader code contained in the same ROM, loader magic Byte=0x2112) at boot time before OS-9 (or QDOS) is started. The OS-9 secondary bootstrap ("GO") can load additional low-level drivers before the kernel module is started. All low-level drivers are linked into a list (head pointer in $FE69).
Note on Q133 firmware:
* MRK17 loads/supports the QFC9 and the WS SCSI+TurboSCSI, command input for the KMON20 Rev8.05 diagnostics mode and color graphics cards.
* MRK10 loads/supports the Q077, Q777, QFC9 and WS SCSI+TurboSCSI.

Low-level device drivers:

QFC2 (Floppy):
The 6800 driver code is contained in Q032 ROM.

Q077 (winchester DMA), Q777 (SCSI), QFC9 (Floppy and "Mini-Floppy"):
The 6809 driver code is contained in ROM on controller card, loaded via DMA into RAM intiated by F8L ROM (Q133) at boot time, then boot via F8L ROM with help of this driver.

CMI-41 (WS SCSI on-board, TurboSCSI with extra card):
low-level driver in two parts: The 68020 driver (which listens to the $FDE0 mailbox) is contained in CMI-41 KMON20 ROM, the 6809 driver (which uses the $FDE0 mailbox) is contained in CMI-41 KMON20 ROM. The 6809 driver is loaded via KMON20 (LDRV or BOOT command) into QASAR RAM, initiated by F8L ROM (Q133), then boot via F8L ROM with help of this driver. After JKERNEL startup, the 68020 driver part from the KMON20 is replaced by a J-task "SCSI driver". (KMON20 Rev8.05 and JKERNEL Rev>=9 support SCSI drives with 256-8192 Byte sector size via translation to 256 Byte blocks for OS9.)

Device types:
01: QFC9 Floppy
03: QFC9 "Mini-Floppy" revision
81: Q077 Winchester DMA
82: Q777 SCSI
88: WS: WS-SCSI, TurboSCSI, RAM-disk, /wsmem


The CMI-41 JKERNEL system and its J-tasks access WS SCSI and TurboSCSI drives directly, independent of the QASAR OS9 system. Access to SCSI drives from multiple J-tasks running within the JKERNEL system is coordinated via JKERNEL traps and semaphores ("jscsi" module, plus "SCSI-Deblock" J-task for Rev>=9). From this point of view, the J-task "SCSI driver" acts on behalf of the QASAR OS9 system. Further communication mechanisms between OS9 and JKERNEL ensure the integrity of the drives' filesystems for shared file access (Server020 J-task and wsst OS9-task).
Large parts of the JKERNEL SCSI driver were written by Chris Alfred.


IOPACK is an AMPEX DIALOGUE 80 series Video Display Terminal emulator on the video graphics console (OS9 device /video) for enhanced text display functions (see also OS9 INFO/iopack). The "multi-mode" versions of IOPACK also support the color graphics cards (type C/D).
The QASAR provides three terminal outputs: video graphics console, TVT, and TVT2. The QASAR ROM (e.g. Q9F0 + F8L) contains default console I/O functions (e.g. OUTCH) and character bitmaps (for the video graphics console), which are used under firmware operation (e.g., monitor and booting) and QDOS. OS9 tasks (running on CPU P2) can write to the video,TVT,TVT2 screens via the OS9-devices /video,/tvt,/tvt2 respectively.
Once IOPACK is running, the CPU P2 ROM functions + bitmaps and the CPU P1 service handler are bypassed/replaced by more sophisticated IOPACK routines.

TVT/TVT2 output:
CPU P1 handles the output to the TVT/TVT2 for the QASAR subsystem (note that CPU P2 cannot access the TVT/TVT2). In addition, any DMA on a P1 timeslot can access the TVT/TVT2 directly, as done for debugging purposes from midi68 (CMI-28), wpexec68 (CMI-33), and JKERNEL (CMI-41). Under IOPACK operation (QDOS and OS9), the IOPACK P1 functions for TVT/TVT2 simply branch to the default QASAR ROM P1 functions.
Case 1: QDOS:
QDOS (running on CPU P2) calls OUTCH (with TOFLAG!=0), which in turn contacts CPU P1 running IOPACK. (For a Q256 system, IOPACK runs in the "temp.task" hardware map.)
Case 2: OS9:
An OS9 task (running on CPU P2) uses the OS9 devices /tvt,/tvt2, which in turn are serviced by CPU P1 running IOPACK.

Video graphics output:
With the CMI QASAR systems (ROMID C and K), CPU P1 does not access the graphics card VRAM under QASAR ROM operation. (Note that on non-CMI QASAR systems (with ROMID Q,L,V), in contrast, CPU P1 handles the VRAM.) In Q096 systems, this is even inhibited by hardware. In Q256 systems, however, CPU P1 may optionally access the VRAM. In any case, only CPU P2 makes use of the video graphics console under QASAR ROM operation without IOPACK.
Case 1: QDOS:
The video graphics console part of QDOS IOPACK runs on CPU P2, which can access the VRAM via map switching (Q096: map A=QDOS/map B=IOPACK, Q256: "P2 sys.task"=QDOS/"temp.task"=IOPACK).
For this case, the QASAR ROM function OUTCH contains a bypass location (fe05) which branches to an P2 IOPACK routine such that QDOS (also runing on CPU P2) still can use OUTCH (with TOFLAG==0) transparently. (For a Q256 system, P2 OUTCH and IOPACK run in the "temp.task" hardware map.)
Case 2: OS9:
The OS9 IOPACK completely runs on CPU P1, which may temporarily access the VRAM for this purpose (note that OS9 requires a Q256 system where P1 may access the VRAM). An OS9 task (running on CPU P2) uses the OS9 device /video, which in turn is serviced by CPU P1 running IOPACK.
Note: Under cmi software operation (QDOS and OS9), the graphical user interface always runs on CPU P2, independent of IOPACK. As a special case, the OS9 IOPACK for CMI (iopcmi P1 task) is responsible for the shell mode only (reachable via "$") and emulates the OS9-only IOPACK (iop).

Keyboard input:
Case 0: QASAR ROM:
The default CPU P1 service handler, which is provided by the QASAR ROM, is also responsible for processing the SACIA keyboard input (multiplexed alpha-keyboard, music-keyboard, and graphics pad/mouse).
Case 1: QDOS:
Under QDOS, with or without IOPACK, CPU P1 is responsible for processing the keyboard input. (In particular with CMI software, CPU P1 handles real-time music events from the music-keyboard and also real-time sequencer operation plus channel card control. Optionally with CMI Series IIx machines, additional music event I/O is implemented via MIDI on the CMI-28.)
Case 2: OS9:
Under OS9, keyboard input is processed by the sacia OS9 device driver, which is running on CPU P2. That is, the CPU P1 keyboard input routines are deactivated once OS9 is running. (In particular with CMI software, the iprehd OS9 device driver handles graphics pad/mouse code on the keyboard input. An OS9 system on a CMI Series III machine does not have a music-keyboard attached to the SACIA input. Here, music real-time event I/O and sequencer operation is implemented via MIDI on the CMI-28. Then, CPU P1 no longer has these real-time responsibilities.)

QDOS files:
QIOPACK.CM (contains the P1 service executive and P2 bypass code)

OS9 Files:
/d0/SYS/iop (P1 executive, especially new character bitmaps)
/d0/CMDS/iopack (iop loader, called by startup)
/k2/CMDS/CMISYSx/iopcmi (P1 task, replacing iop under CMI operation)

OS-9 filesystem: (also look for general OS-9 infos here)
Also called RBF ("Random Block File") filesystem. Fixed 256-Byte sector size. Due to the 24-Bit implementation of sector numbers and the fixed 256-Byte sector size in OS-9 Level 2: max. 4GB disk size ($FFFFFF sectors). With larger disks, only the lower 4GB are accessible.
KMON20 Rev8.05 and JKERNEL Rev>=9 support WS-SCSI and TurboSCSI drives with 256-8192 Byte disk-sector size, which are translated to 256 Byte blocks for QASAR OS-9 requests (see low-level device driver chapter above).

MDR-DOS filesystem:
Software Rev10+11+12 (MFX2 and MFX3) use the MDR-DOS filesystem for MDR-related files (.MT and .MK) in parallel to the OS9 filesystem for the system-software and cmi-related files. Note that MFX1 (software Rev9) uses the OS9 filesystem for MDR files, though. MDR-DOS can reside in any partition (compatible to OS9 partitioning scheme) with a maximum partition size of 4GB. Fixed 256-Byte block size for disk allocation (WS-SCSI and TurboSCSI drives with 256-8192 Byte sector size). It has a flat filesystem (no directories except root). By default, the root directory has a size of 1MByte, containing place for 102 files (with each file-entry using $2800 Bytes). The default cluster size is 4096 sectors (i.e. 1MByte). This filesystem is intended for large files with high transfer-rate requirements. An MDR-DOS partition can be recognized by an entry of 0000 in the OS9 dd_map field of LSN0 (Bitmap size).
Note that MDR-DOS is implemented only within the JKERNEL and unknown to OS9. (On the other hand, access from the JKERNEL system to the OS9 filesystem and devices is accomplished with help of the OS9-task wsst and J-task Server-020.)
MDR-DOS was written by Chris Alfred.
See MDR below for more. (See also OS-9 commands "mdrinit" and "diskpart".)

FLFS (Fairlight Filesystem):
Used in software Rev.14 (MFX3plus) and upwards to handle disk drives with up to 200GB. However, the maximum file size is limited to 4GB. The boot device of the system must be in the OS-9 RBF format.

SCSI device and partition naming:
Devices attached to the boot SCSI controller are called /scxy, /cxyz, /kxyz (with x=SCSI ID, y=SCSI LUN, z=partition).
In principle, the CMI Series III can boot from the following devices (apart from a floppy):
* Q777 SCSI drive
* WS-SCSI (CMI-41) SCSI drive
* TurboSCSI SCSI drive
* WS (CMI-41) RAM disk (loaded via KMON20 from tape e.g.)
If booted from WS-SCSI or TurboSCSI, the Q777 devices appear as /qscxy, /qcxyz, /qkxyz and the RAM disk as /ram, /rcxyz, /rxyz, respectively. If booted from WS-SCSI, the TurboSCSI drives are /sbxy, /bxyz, /jxyz. If booted from TurboSCSI, the WS-SCSI drives are /sbxy, /bxyz, /jxyz. Under MDR (see below), /scxy (i.e. boot controller) drives have SCSI IDs 0,...,7 and /sbxy have "artificial" SCSI IDs 8,...,15.
On a Rev<=6 system with WS installed (untypical): If booted from Q777, the WS-SCSI devices appear as /wscxy, /wcxyz, /wkxyz.

SCSI disk partition naming (/q..., /sb..., /r... analogous):
/scxy: x = SCSI ID, y = LUN
/cxyz: x = SCSI ID, y = LUN, z = partition number - 1 (0,...,7)
/kxyz: x = SCSI ID, y = LUN, z = partition number - 9 (0,...,7)

partition table file (/sc00/SYS/parttab) format:
partition x has entry of 16 Bytes starting at offset 0x10*(x-1):
xx ss ss ss nn nn nn 00 ... 00
xx = partition number (1,...)
ssssss = partition start sector
nnnnnn = partition size in sectors
unused partitions correspond to 16 Bytes of 0

OS9 LSN0 (sector 0) layout of disk/partition
bootstrap entry in LSN0:
at 0x0015: ss ss ss nn nn
ssssss = (DD_BT) start sector of SYS/bootfile (must be contigous)
nnnn = (DD_BSZ) size of bootfile in sectors
partition table entry in LSN0 (if hard disk):
at 0x0070: ss ss ss nn 00 00 qq qq qq mm mm
ssssss = start sector of SYS/parttab (must be contigous)
nn = number of entries in parttab
qqqqqq = start sector of QDOS partitions
mmmm = number of QDOS partitions
Note: /k-partitions (>=9) have 4300x256Bytes, QDOS partitions have 4004x128Bytes, exactly the size of the corresponding floppies.

SCSI hard disks:
With older revisions (esp. Q777), 256-Byte sector (=block) size required for the SCSI disk (see SCSI "mode select" command and low-level formatting, see OS9: "scsiformat -b=256 /sc00", normally a lot of older full height 5.25" SCSI disks allow such re-formatting, see also ESDI to SCSI Emulex MD21 board for two ESDI disks as two SCSI LUNs: info). KMON20 Rev8.05 and JKERNEL Rev>=9 support WS-SCSI and TurboSCSI drives with 256-8192 Byte sector size via translation to 256 Byte blocks.
(With standard CMI/MDR software, IOMEGA ZIP drives and CD-ROM drives are not supported. However, certain streamer-tape drives (see below) and certain MO-type drives are supported.)

typ. CMI SCSI devices:
/sc00: hard disk 0 (boot disk, internal)
/sc10: tape 0 (=/TAPE, internal)
/sc20: hard disk 1
/sc30: WORM 0 (=/w0)
/sc40: hard disk 2
/sc50: tape 1 (=/XTAPE)
/sc60: hard disk 3

typ. disk partitioning (some OS9 tools: "diskinit", "mdrinit", "diskpart", "cmipart", "partgen", "bootgen", "pback", "wscat", "dd"):
(actually, this is the whole disk and the LSN0 size entry must contain the full disk size, but first sectors contain small filesystem "master"): 256 sectors, 1 sector/cluster, contains partition table ("SYS/parttab"), secondary bootstrap "SYS/bootfile" to partition 9 or 1
(partition 9, filesystem "OS9"): 4300 sectors, 1 sector/cluster, contains floppy CMI_OS9_K0
(partition 10, filesystem "cmiuser"): 4300 sectors, 1 sector/cluster, contains floppy CMI_USER_K1
(partition 11, filesystem "cmisys"): 4300 sectors, 1 sector/cluster, contains floppy CMI_SYSTEM_K2
(partition 12, filesystem "mdr"): 4300 sectors, 1 sector/cluster, contains floppy CMI_MDR_K3
(partition 1, filesystem "cmi"): rest, typ. 16 sectors/cluster, contains CMIFILES/FAIRLIGHT (and fast page change file "cmixfast" for Revx)

How to install the CMI system software from scratch
Warning: This procedure erases all data on the disk!!! Use low-level formatting with care!!! Use at your own risk!!!

Notes: SCSI disk must be low-level formattable to 256-Byte sector size for use with older firmware. Max. $FFFFFF blocks (=4GB) accessible, even on disks >4GB. Boot from floppy labeled CMI_OS9_K0 and exit to OS9 shell. Load diskinit and pback. go2_9 is the bootsector (bootstrap to partiton 9=/k0), contained on floppy CMI_OS9_K0. After creation of filesystems, normal update procedure also possible. (diskinit v2.00 seems to have a "sign-bug", allowing only for partitions <2GB.) In Rev11, the all-in-one utility "diskpart" can be used instead (Note: diskpart should not be used to format /sbxy drives i.e. on the secondary SCSI controller!).
Format + Bootblock:
scsiformat -b=256 /sc00 (for SCSI disk 0, 256B only necessary for Rev<9)
diskinit /sc00 -xqs "-n=master" -a=256 -c=1 d (where d=total disk size in sectors)
bootgen /sc00 /f0/cmds/go2_9
Partitions + Filesystems:
cmipart /sc00 -k=4 -q=4 -w=5 ! partgen /sc00 -qw
diskinit /k0 -rqs 4300 "-n=CMIOS9" -c=1
diskinit /k1 -rqs 4300 "-n=CMIUSER" -c=1
diskinit /k2 -rqs 4300 "-n=CMISYS" -c=1
diskinit /k3 -rqs 4300 "-n=CMIMDR" -c=1 (for Rev11)
diskinit /c0 -rzqs "-n=USER_DISK" -c=16 (cluster size here typically 16, 32, 64)
Software: (alternative: reboot floppy CMI_OS9_K0 and run update)
makdir /c0/CMIFILES
pback /f0 /k0 (with floppy CMI_OS9_K0)
pback /f0 /k1 (with floppy CMI_USER_K1)
pback /f0 /k2 (with floppy CMI_SYS_K2)
pback /f0 /k3 (with floppy CMI_MDR_K3, for Rev11)
wscat /k1 >= /c0/cmixfast (where x=CMI version)
(wscat /k1 /k3/CMDS/CMIUSER9 >= /c0/cmi11fast (for Rev11))
copy /k0/sys/mdr_devices /sc00/sys/mdr_devices

OS9 8" floppy format:
Drive: Mitsubishi M2896-63, Qume Q242, YE Data YD180
360rpm, double sided, double density (MFM), soft sectored (1 index hole),
77 tracks/side, 28(16) sectors/track, 256 Bytes/sector, 500KBit/sec raw
track 0, side 0: 16 sectors/track, FM (SD)
track 0, side 1: 28 sectors/track, MFM (DD)
track 1, side 0 ... track 76, side1: 28 sectors/track, MFM (DD)
total: 4300 sectors = 1075KB formatted
QFC9 EPROM revisions:
DQFC910: for 8" drives (access selection via "HEAD LOAD")

adapter for 3-mode 3.5" floppy drive to QFC9 controller:
Older 3.5" floppy drives allow for a 360rpm mode via the DENSITY select line.
(Note that the standard PC 360rpm format provides 1.2MB formatted DS/HD with 78 tracks/side, 16 sectors/track, 512 Bytes/sector MFM. But since the raw data rate of 500kBit/sec, the 360rpm and 77<78 tracks are suitable, it is possible to use such a 3.5" floppy drive with the QFC9.)
The only problem is the correct handling of the QFC9's HEAD LOAD(out), DS1,...,DS4(out), READY(in) lines and the 3.5" floppy's MOT0,MOT1(in), DS0,DS1(in) lines. (See also QFC9 description above.)
Note: Floppy drives with 300rpm (1.44MB mode) also seem to work (but not recommended).

OS9 "Mini-Floppy" format (MFX1, MFX2):
Drive: TEAC FD-235HG (3.5")
OS9 devices /m0, /m1:
77 tracks/side
total: 4300 sectors = 1075KB formatted
OS9 devices /mh0, /mh1:
80 tracks/side
total: 4468 sectors = 1117KB formatted
(Other parameters see 8" floppy above.)
QFC9 EPROM revisions:
DQFC911: for 3.5"/5.25" "Mini-Floppy" drives (access selection via "DS")

SCSI QIC tape drives:
Tape media:
9-track QIC-24 tape media format, 60MB on DC600A tape
SCSI tape drives:
Archive Corporation 5945S-1 (tape drive with QIC-36 interface + extra QIC-36-to-SCSI Emulex MT02 formatter board, 5.25" FH, info, MT02 info, MT02 error codes, Note: 5945C is the pure HH tape drive with QIC-36 interface but w/o formatter board, 5945L-x is the same tape drive but with QIC-36-to-QIC-02 formatter board)
Archive Corporation 2060S (tape drive with SCSI interface, 5.25" HH, Note: 2060L is same tape drive but with QIC-02 interface)
QIC standards:
standards, info, info
Interface standards:
QIC-36 basic interface
QIC-02 intelligent interface
Tape media standards: (Verbatim QIC tapes)
QIC-11 (4/9-track, 27/60MB DC600A)
QIC-24 (9-track, 60MB DC600A)
QIC-120 (15-track, 125MB DC6150)
QIC-150 (18-track, 150MB DC6150, 250MB DC6250)
QIC-525 (26-track, 525MB DC6525)
QIC-1000 (30-track, 1010MB DC9100)

OS9 Backup/Conversion utilities:

copy020 (uses CMI-41 PRAM, approx. 6 times faster than copy)

backup, restore (harddisk partition backup utilities)
dirtape, totape, fromtape (file backup utility,.tp description files)
tp_dir, tp_put, tp_get (ancestor of dirtape/totape/fromtape)
devices: Archive Corporation 5945S-1 or 2060S (QIC-24 Media, SCSI, 60MB on DC600A tape)

fromworm, toworm
cache directory: /c000/WCACHE
devices: Matsushita LF-5010, Maxtor RXT-800

QDOS floppy
qdosdir, toq, fromq
bs128, bs256 (select floppy sector size, requires attach/detach)
K.M.I. floppy-image utilities: qget, qput, qformat

Multi-floppy file backup
vsave, vrec

Conversion utilities (Series IIx -> III):

Screen dumps:

This saves/restores the contents of the 16KB video RAM, typically "_px" file name extension (e.g. the startup logo /k2/CMDS/CMISYSx/logo_px):
scrdump <file> (with "cmirun" or from within cmi via "run")
vfork scrfill <file>; sleep
(Note: vfork creates a process with video RAM access, sleep can be terminated by <ctrl-q>)
In turn, "_px"-files can be printed by use of the "sd" OS9-utility.

CMI Series III software (for x=Rev):

main directories
/c000/CMIFILES (for libraries)
/c000/CMIFILES/FAIRLIGHT (Fairlight library)
/c000/WCACHE (for WORM)

general configuration files:
/k0/SYS/cmix_cfg (system configuration, read by cmix)
/k0/SYS/jsys_cfg (jkernel configuration, read by jsys)
/k1/CMDS/CMIUSERx/DIR/defaults.dir (last directory settings, read by dir_pg)
/k2/CMDS/CMISYSx/cmi_pages (display pages, read by in_init)
/k2/CMDS/CMISYSx/defaults.mp (default patch, read by midi68)
/k2/CMDS/CMISYSx/logo_px (startup logo)
/k0/SYS/picture (startup logo Rev11, read by picfill/picfill68)
/k0/SYS/system.pal (color settings (PALRAM image) Rev11, read by picfill68)

Track Split
("TS", track sheet utility for multi-track tape recording)

Timecode Trigger
("TT", timecode sequencer, in Rev <=5.2, successor: Cue List):

Cue List
see Cue List-section below!

Film Music Processor
Stand-alone system for Series IIx and III:
/d0/FMP (root directory)
/d0/FMP/SYS/startup (starts "filmusic /d0/FMP /f0")
/d0/FMP/FILMUSIC (user directory)

see DTM-section below!

see MDR-section below!

see MDR/MFX-section below!

see MDR/GFX-section below!

see RS-section below!

see CAPS-section below!

MCL ("Music Composition Language")
/k0/CMDS/CMISYS/com ?? (OS9 compiler: .MC -> .SQ)

PFTASK ("Frame Playing Task", playback 8-Byte "timed frames" to MP, e.g. used for .SQ files?):

ATP ("Audio Trigger Page", audio sample input triggers sounds, Rev8):

Sorted by CPU:

main CPU P2 (Q209) modules:
/k0/CMDS/cmix (system startup)
/k0/CMDS/cmi (system startup w/o sequencers)
/k2/CMDS/CMISYSx/grres (resident initialization module, graphics task)
/k2/CMDS/CMISYSx/inres (resident initialization module, input task)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrres (resident initialization module, MDR)
/k1/CMDS/CMIUSERx/textwin_dp (support module)
/k1/CMDS/CMIUSERx/fkmenu_dp (support module)
/k2/CMDS/CMISYSx/p1task (CPU P1 communication task)
/k2/CMDS/CMISYSx/ertask (error logging task)
/k2/CMDS/CMISYSx/grtask (graphics task)
/k2/CMDS/CMISYSx/lptask (light pen (graphics pad) task: switching windows + calling window event handler functions)
/k2/CMDS/CMISYSx/gfxtask (GFX graphics task)
/k2/CMDS/CMISYSx/lbtask (library (file load/save) task)
/k2/CMDS/CMISYSx/copy020 (fast copy for lbtask, uses CMI-41 PRAM)
/k0/CMDS/(CMISYSx/)wsst (JKERNEL communication server task)
/k0/CMDS/(CMISYSx/)wsmod (handle WFM modules)
/k2/CMDS/CMISYSx/wstask (WS communication task)
/k2/CMDS/CMISYSx/wptask (WP communication task)
/k2/CMDS/CMISYSx/mptask (MP communication task)
/k2/CMDS/CMISYSx/input (command input task)
/k2/CMDS/CMISYSx/pftask (Frame playing task, see above)
/k2/CMDS/CMISYSx/DTM/dtmtask (DTM)
/k2/CMDS/CMISYSx/drtask (WSDTM Rev7)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrtask (MDR)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrmaptask (started by mdrtask)
/k2/CMDS/CMISYSx/CAPS/captask (CAPS)
/k2/CMDS/CMISYSx/RS/rstask (Realtime Sequencer)
/k2/CMDS/CMISYSx/CL/cltask1 (Cue List)
/k2/CMDS/CMISYSx/TT/tttask (Timecode Trigger)
/k1/CMDS/CMIUSERx/ATP/atptask (ATP, started by atp_ov)

main CPU P1 (Q209) modules
/k0/SYS/iop (IOPACK, see OS9)
/k2/CMDS/CMISYSx/iopcmi (CMI IOPACK, see OS9)
/k2/CMDS/CMISYSx/p1task (P1Exec in p1task: CPU P1 kernel)
/k2/CMDS/CMISYSx/p1task (CPU P1 communication task, executed by CPU P2)
/k2/CMDS/CMISYSx/RS/rsp1task (RS)
/k2/CMDS/CMISYSx/CAPS/test_p1 (CAPS)
/k2/CMDS/CMISYSx/CL/clp1ptask (Cue List)
/k2/CMDS/CMISYSx/CL/clp1dtask (debugging)
/k2/CMDS/CMISYSx/DTM/dtmp1tsk3 (DTM)
/k1/CMDS/CMIUSERx/WSDTM/dtmp1tsk1 (WSDTM Rev7)
/k1/CMDS/CMIUSERx/WSDTM/dtmp1tsk2 (WSDTM Rev7)
/k1/CMDS/CMIUSERx/WSDTM/dtmp1tsk3 (WSDTM Rev7)
/k1/CMDS/CMIUSERx/WSDTM/dtmp1tsk5 (WSDTM Rev7)
{/k2|/D3}/CMDS/CMISYSx/MDR/mdrp1task (MDR Rev9)

channel card ("CC", CMI-31) modules:
/k2/CMDS/CMISYSx/ccprog (CMI-31 CMI executive, started by mptask)
/k2/CMDS/CMISYSx/DTM/dtmccrev2 (CMI-31 DTM executive, started by dtm_pg Rev6)
/k2/CMDS/CMISYSx/dtmwscc (CMI-31 WSDTM executive, started by drtask Rev7)
{/k2|/D3}/CMDS/CMISYSx/MDR/mdrccprog (CMI-31 MDR executive, started by mdrtask)

SMIDI processor ("MP", CMI-28):
/k2/CMDS/CMISYSx/mptask (6809 OS9 task)
/k2/CMDS/CMISYSx/errfile.mp (Error text file)
/k0/CMDS/kstart (for CMI-28/33/41, executed by 6809 CPU)
/k0/CMDS/com68 (for CMI-28/33/41, executed by 6809 CPU)
/k2/CMDS/CMISYSx/(MIDI/)midi68 (CMI-28 executive, started by mptask)

waveform processor ("WP", CMI-33) modules:
/k2/CMDS/CMISYSx/wptask (6809 OS9 task)
/k2/CMDS/CMISYSx/errfile.wp (Error text file)
/k0/CMDS/kstart (for CMI-28/33/41, executed by 6809 CPU)
/k0/CMDS/com68 (for CMI-28/33/41, executed by 6809 CPU)
/k2/CMDS/CMISYSx/wpexec68 (CMI-33 executive, started by wptask)

waveform supervisor ("WS", CMI-41) modules:
/k2/CMDS/CMISYSx/wstask (6809 OS9 task)
/k2/CMDS/CMISYSx/errfile.wp (Error text file)
/k2/CMDS/CMISYSx/errfile.jker (Error text file)
/c000/cmixfast (fast page change WFM modules file, created by wscat)
/k2/CMDS/wscat (create cmixfast WFM modules file, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)wsmod (handle WFM modules, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)kstart (for CMI-28/33/41, executed by 6809 CPU)
/k0/CMDS/com68 (for CMI-28/33/41, executed by 6809 CPU)
{/k0|/D3}/CMDS/(CMISYSx/)jprocs (utility, executed by 6809 CPU)
{/k0|/D3}/CMDS/(CMISYSx/)jsetpr (utility, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)jrun (utility, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)jkill (utility, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)jsend (utility, executed by 6809 CPU)
/k0/CMDS/(CMISYSx/)jsys (JKERNEL: jker + jscsi (+ keytest), started by cmix)
/k0/SYS/jsys_cfg (configuration file)
/k0/CMDS/(CMISYSx/)wsst (JKERNEL communication server task on 6809 OS9)
/k0/CMDS/(CMISYSx/)wsm (WFM modules J-task, started by cmix)
/k2/CMDS/CMISYSx/jprocs68 (started by cmix)
/k2/CMDS/CMISYSx/jfman68 (started by cmix)
/k2/CMDS/CMISYSx/JPROGS/wscom68 (started by cmix, Rev <=9)
/k2/CMDS/CMISYSx/JPROGS/tvtmon68 (started by cmix or wscom68, Rev <=9)
/k2/CMDS/CMISYSx/JPROGS/ertask68 (started by ertask)
/k2/CMDS/CMISYSx/JPROGS/gfxtask68 (GFX, started by gfxtask)
/k2/CMDS/CMISYSx/wsexec (J-task, started by wstask)
/k2/CMDS/CMISYSx/MIDI/cctask68 (started by mptask, Rev <=9)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrwsmain (MDR >=Rev9, started by mdrtask, see also DSP96K)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrwsgrass (GFX Rev9, started by mdrwsmain)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdrwsplay (started by mdrwsmain)
/k2/CMDS/CMISYS9/MDR/mdr68020main (MDR Rev8, started by mdrtask)
/k2/CMDS/CMISYS9/MDR/mdr68020play (started by mdr68020main)
/k2/CMDS/CMISYS9/MDR/mdr68020tvt (started by mdr68020main)
/k2/CMDS/CMISYSx/ATP/atp68 (started by atptask)
/k2/CMDS/CMISYSx/dtmwstsk (WSDTM Rev7, started by drtask)
/k2/CMDS/CMISYSx/wsdtmplay (WSDTM Rev7, started by drtask)

XDR sample card (ESP-348) modules:
runs from ROM!

waveform accelerator ("DSP96K") modules:
see DSP96K-section below!

CMI operation:


contains max. 80 instruments (however, limited by @in in cmi_cfg to 40), data saved in .SY file

contains max. 8 buddied voices plus max. 16 buddied external voices (buddied = played in parallel), uniquely mapped from MIDI input channel and ACIA number (A-D) and MIDI key (if from master keyboard), optional MIDI input key transposition per instrument, optional MIDI input controller mapping per ACIA, data saved in .IN/.SY file

plays CMI channels, unique allowed channel mask, contains max. 63 subvoices, buddied voices in instrument obviously cannot share channel, mono+stereo voices cannot share channel, multiple voices may share channel (if Rev>=8), max. 16 voices total in system, data saved in .VC file

"external voice":
plays MIDI output, unique MIDI output channel and ACIA number (A-D), max. 32 external voices total in system, data saved with instrument

sample data, uniquely mapped from MIDI key for each voice, unique router output for each voice+subvoice (if Rev>=8, map saved in .RT file), data saved with voice


"CL", timecode sequencer, successor of Timecode Trigger ("TT").

CL files are called event modules (or event data modules, "EDM"), which have a fixed size of 12KB with a maximum of 255 events per file (older revisions used 4KB size by default, allowed 2/4/6/8/10/12KB). Event modules can call other event modules as a special type of event, which is referred to as a library module event. In CL, all time-informations are based upon "time-unit" values (1/48000 sec, for sub-frame timing resolution, independent of frame-rate).
CL is also capable of recording MIDI events in real-time into a so-called take file (.TK, 8-Byte timed-frame format, similar to .SQ), which in turn can be converted into an event module. Furthermore, TT files can be converted to CL files.

QASAR CPU P2 (cltask1, cltask2) handles the user interface, CPU P1 (clp1ptask, clp1rtask) coordinates real-time events, and the SMIDI CPU (midi68) finally is responsible for the time-critical part to play/record real-time events (as timed MIDI-frames).



"Realtime Sequencer" or "Rhythm Sequencer", 16-track pattern-oriented MIDI sequencer, successor of the Series II "Page R" sequencer.

RS uses statically allocated memory, i.e. for a given number of used patterns (=measures), the file-size does not change dynamically. Furthermore, within each pattern, fixed time-slots are used for key-events, in 16 separate monophonic tracks with fixed instrument assignment (corresponding to the 16 channels of the CMI Series III). Each time-slot corresponds to one microbeat. Each event is saved as a key-number, velocity and release value, and a duration (max. 255 microbeats) in an event-slot corresponding to the time of its occurance. The number of time-slots per pattern depends on the chosen time signature, however, it cannot exceed the max. value of 96 (per track). (For a 4/4 time e.g., we have 96 microbeats, i.e. a resolution of 24PPQ. The playback accuracy, however, is much higher.) A shared maximum of 16 continous controllers plus 16 switches are recorded with one value per microbeat. Tempo and time signature can vary from pattern to pattern (however remains constant within a pattern).
An RS-file ("sequence-file") can contain a maximum of 255 patterns. Patterns are played back/recorded according to 27 so-called sections (SONG, A, B, ..., Z), which define play-sequences of patterns. (A section-step contains a pattern reference number and a repetition count, but can also contain a reference to another section.)
The RS resembles a totally-static sequencer design, which stems from the Series I/II/IIx machines' page-R sequencer. Typically, such a sequencer concept is also used in drum-machines. In contrast, modern MIDI-sequencers normally have a dynamical event-oriented design. (Compare also with CAPS, which is partially dynamic within each quarter, leading to a significantly higher resolution of 384PPQ.)
Series I/II/IIx page-R sequence files can be converted into a Series III RS file (via r2r3 tool). On the other hand, RS can export take-files (.TK, see Cue-List) with help of the "capsgen" command (misleading).

QASAR CPU P2 (rstask) handles the user interface, CPU P1 (rsp1task) coordinates real-time events, and the SMIDI CPU (midi68) finally is responsible for the time-critical part to play/record real-time events (as timed MIDI-frames).



"Composer, Arranger, Performer, Sequencer", 80-track MIDI sequencer.

CAPS is based upon statically allocated memory, i.e. for a given number of measures, the file-size does not change dynamically. Each pre-allocated quarter contains a fixed number of available event- and controller-slots: 220 key-event slots shared amoung 80 polyphonic tracks(="parts") and 24 values for each of the possible 80 shared controllers. Each track corresponds to one fixed CMI instrument with arbitrary polyphony. Times are measured in "microbeats" (1/384 quarter, giving 384 PPQ resolution). A key-event consists of a time-stamp (relative to the quarter begin in microbeats), the MIDI key number, velocity and release value, and also the total duration (max. 65536 microbeats). (Note: Such a concept does not correspond to MIDI events, which encode note-on and note-off separately.) All events within a quarter are organized as separate linked lists for each track (part) and are dynamically allocated. In contrast, controllers are statically recorded every MIDI-clock (1/24 quarter) (unusual for MIDI sequencers). Each track can be assigned max. 8 out of 80 controllers (exclusively shared amoung all tracks). A CAPS-file (.OP "Opus-file") also contains a fixed number of 480 measure-information slots, where quarters (events + controllers, allocated only for the Opus length) are assigned to measures. Tempo-values are stored every 1/32 note within a measure.
The built-in undo-function is based upon a doubling of quarter-memory, with a switchable assignment to measures (alternating recording, keeping one level of history). A "packed" Opus does not contain this doubled quarter-memory. For example, an "unpacked" Opus in 4/4 time of 5min duration approximately consumes 3MB of disk space.
CAPS reads and writes quarters and measures from/to disk on demand (keeping only a small number of measures in RAM for caching). CAPS can handle arbitrary sequences of measures with varying time signatures (with beat 1/2, 1/4, 1/8, 1/16, or 1/32, and a maximum number of 8 quarters per measure) and varying tempo (1/32 resolution of changes). The mainly static concept (with dynamically managed events in each quarters for a higher time-resolution) enables CAPS to correctly chase SMPTE (offering also SMPTE cue-lists).
With CAPS, tracks (i.e. parts) refer to instruments (with a dynamical assignment to channel cards, if supported by the CMI software Rev.).

QASAR CPU P2 (captask) handles the user interface, CPU P1 (cap_p1task, cap_p1rtask) coordinates real-time events, and the SMIDI CPU (midi68) finally is responsible for the time-critical part to play/record real-time events (as timed MIDI-frames).



DTM ("Digital Tape Machine") is the hard disk recording system for CMI software Rev5+6. DTM runs on a WP (CMI-33) system with Q777 SCSI contoller, providing a maximum of 1 track (2 channels if stereo) playback simultaneously. DTM has a fixed sample-rate of 48kHz. (Rev7 also had an experimental DTM version called "WSDTM", which ran on WS (CMI-41) systems with the JKERNEL.) The successor of DTM is MDR (see below).

DTM is implemented as special functions within wpexec68 (running on the WP), OS9-tasks (dtmtask, dtmedplay), P1-tasks (dtmp1tsk*), various CMI display pages (with _dt suffix typically), a special CC executive (dtmcc*), and special functions within midi68 (running on the MP).

A DTM-file (.DR-file) occupies disk space in a granularity of contiguous 4MB blocks. It contains multiple segments of waveform data and an edit-list of "events", which specify which waveform is supposed to be played at which time offset. Waveform data is never altered during editing. Optional crossfades between adjacent events are implemented by use of extra file space, located within the first 2MB of the DTM-file.

DTM software:

WSDTM (DTM Rev7, with CMI-41):
/k1/CMDS/CMIUSERx/WSDTM/dtmp1tsk* (P1-tasks)
/k2/CMDS/CMISYSx/drtask (OS9-task)
/k2/CMDS/CMISYSx/dtmwstsk (J-task, started by drtask)
/k2/CMDS/CMISYSx/wsdtmplay (J-task, started by drtask)
/k2/CMDS/CMISYSx/dtmwscc (CMI-31 executive, started by drtask Rev7)

MDR, GFX, MFX, and sync possibilities

The harddisk recording system "MDR" ("Multitrack Disk Recorder", Rev>=7) is the successor of DTM ("Digital Tape Machine", Rev5,6). While DTM runs on a WP (CMI-33) system with the Q777 SCSI contoller, providing a maximum of 2 channels playback simultaneously, MDR requires a WS (CMI-41) system with WS-SCSI (on CMI-41) or additional TurboSCSI (ESP-TS1), providing up to 16 channels simultaneous playback. Rev11 software recognizes the presence of a TurboSCSI controller by means of the "hardware protection level" (see ESP-TS1) and accordingly switches to Rev10 (level=A) or Rev11 (level=B) mode. Large parts of MDR were written by Steve Rance, Chris Alfred, and Michael Carlos.

MDR is implemented as separate J-tasks (running on the WS) and OS9-tasks (running on the QASAR) with a special CC executive (mdrccprog) and special functions within midi68 (running on the MP). (Rev9 software also uses a P1-task called mdrp1task.) MDR runs independently in parallel to the old CMI software system (esp. CAPS/RS/CL) and has its own control and sync paths, controlled and synchronized from the MFX (via the CMI's MIDI D) or CMI SMPTE inputs (LTC or MTC). MDR Rev11 requires 4MB of WS PRAM and at least 12MB of WRAM. Starting with Rev10, the MDR-DOS filesystem (see above) is employed for MDR-related files (.MT, .MK). (Setup parameters are contained within the mdr_data file.) The official MDR time is measured in "time-units" (1/48000 sec, independent of the selected frame-rate) and provided by midi68 (MP). The playback sample-clock of each channel is locked to this MDR time, with nominal values of 44100Hz or 48000Hz (same for all channels, depending on the MDR project file, independent of the selected frame-rate, even if dropframe). During record (with the ESP-348), sample-rate conversion is always activated to ensure a correct sample count, synchronous with MDR time (channel card 1 acting as the clock source, see ESP-348 above). As a special option, the record sample-rate (same as playback by default) can be run-up by 0.1% (for use with a 29.97fps (i.e. dropframe) project, where old 30fps video material is played back at 29.97fps later on). Note that Rev6 ESP-348 firmware can convert 44.1kHz/48kHz AES/EBU source rates automatically into the project's rate and can amplify the signal in the digital domain. Digital AES/EBU output of one MDR track is also possible, however, with a sample-rate not in exact sync to the official MDR time (freely running sample clock, see ESP-348 above).

The so-called "GFX" graphics system is used for the graphical user interface during MDR operation. It is implemented as the gfxtask68 (mdrwsgrass in Rev9) J-task (with the GFX library) for the WS, the gfxtask OS9-task (in Rev11) for the QASAR, and individual modules for each display page (J-modules: _gfx, OS9-modules: _pa and _pb files). Here, graphics processing and generation is primarily accomplished by the WS, providing an improved and faster GUI in addition to the old CMI QASAR-based system (OS9-tasks: grtask, lptask, input).

The MFX keyboard acts as a control console, sync source and router for the MDR and other external machines. It sends proprietary SysEx-encoded timecode and control commands and forwarded music-keyboard MIDI packets to the CMI MIDI D input (handled by the MP). (Note that MTC is not employed here, except for the "MIDI 1.0" machine, see below.) MFX runs the "mfx.runtime" executive (contained within the MFX's NVRAM, downloadable from the CMI, see "mfxload" OS9 utility) during operation with MDR. (Note: mfx.runtime re-routes MIDI data from the music-keyboard input, but supports only 3-Byte MIDI command packets, as sent by the CMI music-keyboard. Neither Real-time, Active-Sensing, SysEx, nor omitted start-bytes are allowed.)

For MFX/MDR, the following sync sources are possible:
1) MFX's internal timecode generator. (MFX sync mode "MFX" with no master)
2) External timecode (Sony protocol) via MFX's RS422 input, forwarded by the MFX to the slaves. (MFX sync mode "MFX" with one master machine "SONY 2.0")
3) External frame-click signal via MFX's RS422 input, forwarded by the MFX to the slaves. (MFX sync mode "EXTERNAL") (Not to be confused with the CMI's CLICK input!)
4) External SMPTE (LTC) at the CMI's SMPTE input or MIDI-timecode (MTC) at one of the CMI's MIDI inputs.
Note that MDR time is internally measured in "time-units" (1/48000 sec), independent of the selected frame-rate.

In cases 1-3, the MFX sends timecode to the MP (SysEx-encoded via MIDI D) as the official MDR time. Only in case 4 under normal-speed playback/record, the MP's SMPTE input (LTC or MTC) is used as MDR time (in which case the MFX is synchronized via the /mfx port by the J-task mdrwsplay).
The midi68 executive directly synchronizes the channel cards (those which are used for MDR) and the MDR system (running on QASAR and WS, special MDR entries in C_TCODE).
Note that the MFX's MIDI input (normally from the Music-keyboard) cannot be used as a sync/control input (at least with MFX1/MFX2 software).

Note that the MDR is always a sync-slave, although the MP can forward the timecode it receives to the CMI SMPTE output (the MDR time appears under "SMPTE GENERATION=FREE-RUN"). Apart from the MDR disk-recorder, other slave machines are possible for the MFX. For example, a "SONY 2.0" machine, which is an external recorder attached to the MFX's RS422 (control output only, no timecode output however). A special case is the "MIDI 1.0" machine, which is nothing but the MFX's MIDI output to the CMI's MIDI D input using MIDI-SMPTE (MTC) (Note that the CMI's MIDI D input is also used for control/sync of the MDR by the MFX. However, this uses a different protocol, based upon SysEx). This "MIDI 1.0" machine can be used to synchronize MIDI sequencers on the CMI (i.e. CAPS/RS/CL) to the same master which is also used for the MDR and other sync slaves ("SyncGroup") attached to the MFX. Here, the system sync of the old CMI software part (i.e. CAPS/RS/CL) must be set to "SMPTE MTC-D" (note that the CMI system in turn can be used to forward sync to other MIDI outputs, CLICK out, CLOCK out, SMPTE out). (A more accurate way would be the usage of a common external SMPTE input for the MDR and CMI sequencers.) The MFX can switch each slave individually on/off-line ("Sync" switches for machines, "Disk" switch for MDR), additionally to the global "SyncGroup" switch.

An MDR-file (.MT-file, "project") contains 24 Tracks, each containing multiple "clips" (dynamically allocated). Each clip contains information about head/sync/tail/fade times and references to "waves" (1 for Mono, 2 for Stereo). Waves contain the original sample data (dynamically allocated, not necessarily contiguous). Note that the sample data within the waves is not altered during editing (unless "space"-functions are used), only the clips (telling which part of which wave is to be used) are changed. Clips can also refer to waves with sample data contained within different files (in which case such a file is called a "library"). "Fades" are realized during playback in real-time with help of the VCAs on the channel cards (CMI-331). An MDR-file is uniquely identified by a 32-Bit ID (hidden in the file header), which is especially employed to reference a library file. This ensures that a library file can be found even if it has been renamed or moved to a different storage device (MDR always scans for MDR-files on all available MDR-devices). (Note that "backup"-functions do not change this ID. In contrast, "copy" creates a new project with a new unique ID.)
(Note: Early MDR versions under software Rev7 and Rev8 might be considered as preliminary. These systems employed a different file-architecture with one .DR-file, containing information for all tracks, and multiple .TR-files, containing waveform data for individual tracks.)

MDR software (moved to /D3 since Rev11):
{/k2|/D3}/CMDS/CMIUSER9/MDR/mdr_pagesx (x=9,10,11)
/d0/SYS/mdr_devices (template)
{/k2|/D3}/CMDS/CMISYS9/MDR/mdr_data (setup values)

MFX software:
* "MFX III sound design console" (<=Rev8):
/k0/mfx (OS9 shell-script, sends mfx.l and mfxslave)
/k0/CMDS/mfxsend (OS9 up-load program)
/k0/CMDS/MFX/mfx.l (master-CPU)
/k0/CMDS/MFX/mfxslave (slave-CPU)
/k0/CMDS/MFX/mfxrom.s (master-CPU firmware)
/k0/CMDS/MFX/mfxrom09.s (slave-CPU firmware)
/k0/mfxdiag (OS9 shell-script, sends mfxdiag.l and mfxslave)
/k0/CMDS/MFX/mfxdiag.l (master-CPU diagnostics)
/k3/MFX (development system)
* "MFX1", "MFX2" (>=Rev9):
/k0/CMDS/mfxload (OS9 up-load program)
{/k2|/D3}/CMDS/CMISYS9/MDR/mfx.runtime (master-CPU)
/D3/CMDS/mfx.diagled (master-CPU diagnostics)

GFX (graphics system under JKERNEL/MDR):
/k2/CMDS/CMISYSx/gfxtask (OS9 task, Rev11)
/k2/CMDS/CMISYSx/JPROGS/gfxtask68 (J-task, Rev11, started by gfxtask)
/k2/CMDS/CMISYSx/MDR/mdrwsgrass (J-task, Rev9, started by mdrwsmain)
{/k2|/D3}/CMDS/CMISYS9/GFX (general _gfx modules)
{/k2|/D3}/CMDS/CMISYS9/MDR[/GFX] (MDR-specific _gfx modules)

(see above for
MDR-DOS filesystem, and MFX hardware)

DSP sampler (ESP-348) functions:

The XDR sample card DSP (56001, ESP-348) runs proprietary sampling/rate-conversion/scaling/routing code from ESP-348 ROM called "DSP348". Communication with WS via bi-directional serial interface. (With Rev6 firmware, real-time digital sample-input scaling and MDR-assisted semi-automatic 44.1k/48k conversion is possible.)

Upon DSP (56001) RESET, the DSP on-chip bootstrap loads the secondary bootstrap from the ESP-348 ROM (bootmode 1). The secondary bootstrap then copies data/code from the ROM to program, X-data and Y-data space (according to a load-table within the ROM). Finally, the secondary bootstrap jumps to the entry address of the loaded application program code. Sample-rate conversion is based upon sin(x)/x interpolation with phase-detection via ESP-348 built-in hardware.

(See hardware chapter for more information about the ESP-348.)

Waveform accelerator (DSP96K) functions:

MDR software uses the optional DSP96K card for time-dilation/contraction (in "CONST" mode only, "VARI" mode is implemented by the WS J-task mdrwsmain). Here, the card with the lowest ID is used (default installation: ID3). Communication with the WS is accomplished via shared WRAM on the DSP96K by use of the mdrwsmain J-task, which acts as a loader (transferring dsp96k.obj* code modules to DSP96K RAM) and as a server for 96K-requests during waveform manipulation (esp. load/save waveform segments from/to MDR-files to/from DSP96K WRAM). (See "setdsp" command on MDR tracks page and TVT-debug output during DSP96K operation, esp. with MDR U-flag set. Time-dilation/contraction parameters are contained within the mdr_data file.) Note that the DSP96K has neither access to the waveform bus nor to the QASAR bus, only to its on-board WRAM and SRAM. The on-board WRAM, however, is also accessible by the WS, providing a means of communication.
The DSP96K code was written by Andrew Cannon.

Upon DSP96K RESET release (triggered by WS), the DSP96K on-chip bootstrap loads the secondary bootstrap from the DSPINIT PROM (96002 boot mode 5). This secondary bootstrap then jumps to the ternary bootstrap at 82000100 (DSP address, in DSP96K WRAM), which has been loaded to this location by mdrwsmain. In turn, the ternary bootstrap jumps to the entry point of the dsp96k.obj* code, which also has been loaded by mdrwsmain. Typically, this entry point is 82001000 (in DSP96K WRAM). For example, if ID=3, DSP addresses 82000100 and 82001000 correspond to WS Byte-addresses 04800400 and 04804000, respectively. dsp96k.obj* initializes the DSP96K hardware and enters a service request loop, waiting for commands from mdrwsmain via DSP96K WRAM mailboxes. For the execution of time-consuming tasks, so-called overlays are used, which are code and data segments in dsp96k.obj* which are copied to the DSP96K on-chip RAM areas and SRAM in order to speed-up execution (compared to execution from on-board WRAM). During overlay execution, mdrwsmain acts as a server for DSP96K requests (via DSP96K WRAM mailboxes), such as waveform block load/save.

DSP96K software (MDR time-dilation/contraction, DSP96K used for "CONST" mode only, WS is used for "VARI" mode):
/D3/CMDS/CMISYS9/DSP96K/dsp96k.obj* (code modules, varying quality 1-4)
/D3/CMDS/CMISYS9/MDR/mdrwsmain (J-task, esp. used as DSP96K loader/server)
/D3/CMDS/CMISYS9/MDR/mdr_data (bandsplitter default values, varying quality 1-4)
Note: In Rev11, the code modules are actually the same for all qualities (1-4), variation is accomplished via different parameter sets (in mdr_data, see also the "setdsp" command) for different quality numbers.

File extensions:

res: resident subroutine module
task: 6809 OS9 task
68: 68k module
dsp96k.obj*: DSP96K object file

_pg: primary display page (Usr6 P Prog module)
_dp: display page (Usr6 P Prog module)
_ov: small display page (Usr6 P Prog module)
_xm: ext. module (Usr6 P Prog module)
_cm: command module (Usr6 P Prog module)
_pa: MDR/GFX large display page (Usr6 P Prog module), associated _gfx file
_pb: MDR/GFX small display page (Usr6 P Prog module), associated _gfx file
_gfx: MDR/GFX display page (J-module), associated _pa/_pb file
_dt: DTM (Usr6 P Prog module)
_ed: CAPS (Usr6 P Prog module)
_db: Usr6 P Prog module
_p1: CPU P1 Subroutine module
_cp: CAPS Subroutine module
_bgnd: Subroutine/Program module
_ovl: WP Subroutine module
_init: Subroutine module
_sr: Subroutine module
_fl: FLANGER page file
_ts: Track Split page file
_icon: icon (Data module)
_sy: character Bitmap
_cfg: configuration
_px: screendump Bitmap

.jker: JKERNEL data file
.mdr: MDR config/data file
.wp: waveform processor data file
.os9: OS9 file
.cmi: CMI software file
.fft: FFT page file
.ps: PostScript file (see psdump)
.doc: text file
.txt, .TXT: text file
.cm: shell command file
.pal: PALRAM image (for type D graphics cards)

.a: assembler source (rma)
.ma: assembler source (c.mac, rma)
.ca: C source (c.comp, rma)
.mca: C source (c.prep, c.comp, rma)
.o: assembler source (c.opt, rma)
.mo: assembler source (c.mac, c.opt, rma)
.c: C source (c.comp, c.opt, rma)
.mc: C source (c.prep, c.comp, c.opt, rma)
.h: C include file

.ha: assembler include file
.d: assembler include file
.r: relocatable object file (rlink)
.l: library (rlink)
.s: binary image in Motorola hex format
.m: macro definition file
.mh: macro definition file
.u: macro definition file
.i: command include file
.p: shell script?, PASCAL souce?
.asm: assembler source (asm, OS-9 Level 1)
.b, .bas: BASIC09 file (see basic09, runb)

.SY: CMI system file, QDOS system binary file
.RT: router file
.IN: instrument file, Series I/II/IIx instrument file (page 3)
.OP: CAPS opus file
.RS: Series I/II/IIx Real-time Composer file (page R), Series III Rhythm Sequencer file
.TK: Cue List Take file (8-Bytes "timed-frames" format similar to .SQ)
.CL: Cue List file (event module)
.VC: voice file, Series I/II/IIx voice file (page 3)
.SV: subvoice file
.SX: MIDI System Exclusive file
.TS: Track Split file
.SL: Series I/II/IIx scale file
.FN: function curve file
.TP: tape directory file
.PX: screendump Bitmap
.DR: Disk Recorder "tape" file (<=Rev8)
.TR: Disk Recorder track file (<=Rev8)
.MT: MDR Disk Recorder Multi-Track file (>=Rev9)
.MK: MFX macro file
.DL: Dubber Language file (MFX3 Rev>=13: for D.A.D. via MDL-command)
.EL: ???
.MX: ???
.TT: Timecode Trigger file
.CO: Series I/II/IIx control file (voice effect patches + function curves, page 7)
.SQ: MIDI frame sequence file (8-Byte "timed-frames" format), MCL compiler output format, Series I/II/IIx keyboard sequence file (page 9), Series III sequence file (see pftask)
.PC: Series I/II/IIx MCL Piece source file
.PT: Series I/II/IIx MCL Part source file
.SS: Series I/II/IIx MCL Sequence source file
.MC: Series I/II/IIx MIDI configuration file (page I), Series III MCL Piece source file
.AI: Series I/II/IIx analog interface file (page A)
.HL: Series I/II/IIx help file
.DP: Series I/II/IIx display page file
.OV: Series I/II/IIx display overlay file, QDOS overlay file

.CF: QDOS chain procedural file
.CM: QDOS command file
.ED: QDOS EDOS-converted file
.SA: QDOS ASCII source file (optionally compressed spaces)
.AL: QDOS assembler listing file
.LX: QDOS loadable object in Motorola EXORciser (S-record) format
.LO: QDOS loadable object in binary format (e.g. MIDI.LO, AIC09.LO)
.RO: QDOS relocatable object file

(Note: The upper-case 2-letter suffixes are mandatory only under QDOS. More infos about CMI Series IIx files on Greg Holmes' page.)

Back to Top


Designed by K.M. Indlekofer. See disclaimer. Send comments about this site to Klaus Michael Indlekofer. Last updated 07/24/2005.