Hi!

I recently found out that MAME has a driver in early development for the famous Fairlight CMI, the world's first digital sampler. Huge thanks to Just Desserts and Phil Bennett for their phenomenal work on the driver so far!

Currently, the driver will only allow the machine to boot into diagnostic disks. Regular Fairlight System Disks don't boot as of yet.

As a big fan of MAME and this historical machine, I decided to look into the diagnostic disks for the machine and see if I can figure out what is causing the machine to not boot those System Disks. Using "QDOSDIAG.IMD" from Fairlight US's website, we have several tests we can run from this disk image.

The first one is CMITST. You can use LIST to list all the avaliable tests functions that are inside CMITST. We're going to do a couple here. Some don't work because they deal with the analog filters and other components that aren't implemented yet (to my knowledge).

The memory test (MEM) on the channel cards pass!



You maybe wondering what "Segment Random Access" means. Fairlight liked to use several unique terms for digital audio that we don't use today. Instead of letting the user have the ability to edit every single PCM audio data sample inside a Fairlight sound file (file extention *.VC), the user edits "segments" of a sound, which basically a chunk of the PCM audio data, 128 samples in length. Every VC file has 128 segments in it. If we were to look at the raw PCM audio data from a VC file, you would see that there are exactly 16384 samples in it. 128 (samples) * 128 (segments) = 16384 samples. So, in that "Segment Random Access" test, it is randomly selecting one of the 128 segments that comprise the PCM data in the channel card RAM.

The DUMP command allows us to look at one of these segments in the Channel Card RAM.



The TIM command tests the Timer on the 6840. The CMI IIx Service manual explains what the test do in detail on page 86.



The RAMP command deals with Envelope Control and actually produces sound (albeit glitchy). The VOL command also produces sound as well. This command requires you to hit the spacebar to continue with the next RAMP test.



The PIT command doesn't pass, which deals with the master pitch rate multipliers on the Channel Cards.



So with the exception of a couple of the tests, everything else seems to pass.

Then we run CMIINT, which tests all the Interrupts in the CMI. Immediately, we see something is not right.



All the Interrupts are listed as active:



Hopefully, with further testing and debugging, we can soon boot into the CMI system disks. Speaking of system disks, I loaded an earlier revision of the system disks (V12, instead of V19) and got this screen without any crashes from MAME:



We're getting close!

I was just looking at this driver today after going on a Peter Gabriel kick. It looks like the current problem is that the channel cards are undocumented beyond the schematics that are available. The service manual (which goes into great detail about every other part of the machine) just has a basic overview and says they’re proprietary technology that must be returned to the factory for service. The PIT tests send some data to an unimplemented register and promptly fail, for example. I’m not sure how you’d get around that without having a CMI IIx to compare with.

Considering the fact that the channel cards do pass memory tests and retain data in their own RAM, it tells me that the channel cards are at least somewhat responsive. According to the service notes of the CMI, the PIT (Pitch and Octave Control) tests deal with the 6821 PIA that handles octave and pitch control:



And sure enough, looking at the error logs in the debugger, there are tons of "No port CA2 write handler" errors for the channel card PIAs when trying to boot into the CMI system disk. Just Desserts told me that it's possible that the MAME drivers for Intel i8214 PIC, Motorola 6850 ACIA, Motorola 6820 PIA, or Motorola 6840 PTM chip emulation could be causing a problem as to why the system disk isn't booting. From looking at the diagnostic tests and error logs, the 6821 PIA is definitely looking fishy.

I'm probably bringing this up a bit early, since this is something that doesn't effect the developement of the driver currently, but there's something that concerns me. There's some analog components in the Fairlight, mainly the infamous CEM3320 and SSM2045 VCF chips on the channel cards. The CEM3320 was used in revisions 1 and 2 of the channel cards and the SSM2045 were in revisions 3 and 4. These chips were used as cutoff filters to help reduce the "harshness" of the lo-fi 8-bit samples since there was quite a bit of aliasing in the samples. Often times, a high pitch frequency at around 15khz will occur in a recorded sample, so when playing the sample at a lower pitch, this results making this digitizing artifact really noticeable, so the filter chips were used to filter out that noise as much as possible. Since they're analog components, is it possible for them to be implemented into MAME or no?

I doubt the PIA emulation itself is bad, there's probably just nothing hooked up to its I/O ports.

MAME supports discrete netlist emulation, although it's fairly expensive. Look at a driver like kidniki, monymony, or cheekyms for an example of its use.

There exist schematics for rev 8 of the voice cards at http://www.fairlightus.com/cmi/fairlight_docs/CMI-01.pdf and http://www.fairlightus.com/cmi/fairlight_docs/CMI-01A.pdf which, while they are later cards, may have enough of the PIA CAx and CBx connections to the 6840PTM chip the same to allow the driver to start to pass those tests.

Thanks for sharing those, Lord Nightmare!

IMO, the CMI-01-A looks like the card we should stick with for several reasons, as the dates on the schematics for the CMI-01-A are consistent with when the Series IIx came out, whereas the CMI-01 schematics are dated 1980, which is Series I era. That being said, the connections on the 6821 and the 6840 chips seem to the be set up the same way between revisions. I could be wrong, but it looks like just some optimization and tidying up of the circuitry was done to simplify things. Also, the CMI-01-A schematics have a lot more info on the filters and envelope generators.

I hope you get this running ... guitar guy myself but I find those beasts utterly fascinating.
When I was researching the Kaypro stuff, I came across the DK Synergy that uses a Kaypro II as its user interface and storage.

http://www.dragonslair.ca/synergy.htm

@rfka01: if you think the Synergy/Kaypro II combo was awesome, the Crumar GDS (its parent), was built on an off the shelf CP/M microcomputer, with the same voice card as found in the Synergy, with a massive keyboard connected to an I/O card, which provided DIRECT control of all 64 oscillators and their parameters via individual sliders on the keyboard controller. The GDS was the development system that was used to create the sounds on the original Synergy sound carts.

-Thom

Ah, the Crumar GDS! That was the digital synth Wendy Carlos used for the soundtrack to "Tron" and apparently some of her patches that she created ended up on the Synergy. It's amazing how obscure the GDS is, I can barely find any pics or video on it.

The CMI IIX driver did at one point boot into the music software (many years ago, before it was publicly submitted):

http://philwip.mameworld.info/cmi_iix.html

Peripheral device emulation has improved massively since the original driver was written and unfortunately something broke along the way (or perhaps only worked by sheer chance).

Getting the driver back into a more functioning state shouldn't be too tricky, once the issue is narrowed down. I still have my MESS source tree and driver from 2009 if anybody wants to build the older version and use it to help debug the newer driver.