|
|
|||||||||||||||
| Sections | |||||||||||||||
|
|||||||||||||||
|
|
|||||||||||||||
| Software | |||||||||||||||
| Links: Greg Holmes' page Jean-Bernard Emond's page: Manuals + Schematics + EPROM Downloads: click here Screendumps: click here Fairlight CMI Series III/MFX software revisions (OS-9) overview: click here QDOS
filesystem: 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 Note: 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:
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 CMI IOPACK v3.20 (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 JKERNEL V2.09, JSCSI V2.02, DEBUGGER V2.01 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 MULTI-MODE IOPACK v1.03 JKERNEL V9.34, JSCSI V6.01 MFX SOFTWARE VERSION 0.24 (Note: final MFX1 release) ... Rev 10.19: (Note: first MFX2 release) ... Rev 11.39: FAIRLIGHT OS9 VERSION 6.46:fkw 23rd March 1993 MULTI-MODE IOPACK v1.05 JKERNEL V11.32, JSCSI V7.00 MFX SOFTWARE VERSION 0.62 (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) ...
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 JKERNEL SCSI driver: 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: 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: Case 0: QASAR ROM, no IOPACK: 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) /d0/CMDS/killio /d0/CMDS/display /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"): /sc00 (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 /k000 (partition 9, filesystem "OS9"): 4300 sectors, 1 sector/cluster, contains floppy CMI_OS9_K0 /k001 (partition 10, filesystem "cmiuser"): 4300 sectors, 1 sector/cluster, contains floppy CMI_USER_K1 /k002 (partition 11, filesystem "cmisys"): 4300 sectors, 1 sector/cluster, contains floppy CMI_SYSTEM_K2 /k003 (partition 12, filesystem "mdr"): 4300 sectors, 1 sector/cluster, contains floppy CMI_MDR_K3 /c000 (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 makdir /c0/CMIFILES/FAIRLIGHT 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: Disk: copy copy020 (uses CMI-41 PRAM, approx. 6 times faster than copy) tcopy trecpy tredel pback TAPE: 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) WORM: wdir wfree winit wput wget warc 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): r23 r2r3 r923 s3m v23 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): CMI operation: "system": contains max. 80 instruments (however, limited by @in in cmi_cfg to 40), data saved in .SY file "instrument": 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 "voice": 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 "subvoice": 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 Cue-List: "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). Directories: /k1/CMDS/CMIUSERx/CL /k2/CMDS/CMISYSx/CL RS: "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). Directories: /k1/CMDS/CMIUSERx/RS /k2/CMDS/CMIYSYSx/RS CAPS: "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). Directories: /k1/CMDS/CMIUSERx/CAPS /k2/CMDS/CMISYSx/CAPS Configuration: /k1/CMDS/CMIUSERx/CAPS/cap_cfg /k1/CMDS/CMIUSERx/CAPS/ed_sizes DTM: 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: /k1/CMDS/CMIUSERx/DTM /k2/CMDS/CMISYSx/DTM WSDTM (DTM Rev7, with CMI-41): /k1/CMDS/CMIUSERx/WSDTM /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): {/k1|/D3}/CMDS/CMIUSER9/MDR {/k2|/D3}/CMDS/CMIUSER9/MDR/mdr_cfg {/k2|/D3}/CMDS/CMIUSER9/MDR/mdr_pagesx (x=9,10,11) /sc00/SYS/mdr_devices /d0/SYS/mdr_devices (template) {/k2|/D3}/CMDS/CMISYS9/MDR {/k2|/D3}/CMDS/CMISYS9/MDR/errfile.mdr {/k2|/D3}/CMDS/CMISYS9/MDR/helpfile.mdr {/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. |
