Fairlight-CMI

Dear group

I've got the above error message in MDR, or after return from MDR to CMI screens. Apparently, graphics output is not correctly updated as well. I also have lost my MFX controller memory due to empty battery; and mfxload works after power on. The controller also works, I can even open a project and jump around, with correct sound output. CMI mode is apparently fine, including screen updates.

I see Karel has had a similar thing on an MFX3 but has not got any answers so far.
(I've opened a new topic because I only found his "additional problem" when I left out most words from the actual message from the search field.)

I'm going to look through the MFX3 and Merlin service manuals, but if anyone has an idea or a hint on how to get this error away, I'd be very happy! (SEM does probably mean Semaphore, and it may indicate that some graphics drawing portion is busy when a new request comes, but why does that happen?) - I also noted that when I use the CMI key/menu on the MFX controller to change system volume level, rplay stops playing while I turn the knob. But I guess that's not really related and might even be normal.

I use the system only very rarely, so sorry, I'm far from perfectly knowledgeable with it, and I wouldn't always know what's normal and what not...

Thankd for your reading and for any reply in advance!

Kind regards, Joerg

P.S.: That error message appears in the status line (second line from top) of the VGA display, and nnn is a number that keeps counting up. I've had one experience where every "tick" I turned the jog wheel would do something correctly visible or audible on the mfx console, but at the same time, nnn would be counted up by one. Still, the display on the VGA screen would not update (the machine has a CG-3 card).

I've also tried ! in the MDR display - this makes some text content with available commands appear, but text ouptut is written right into the existing MDR graphics content. So again, clearing the screen (maybe hardware page swapping, something related to this) does not happen as it should.

Technical functionality - apart from (-) correct display updates and (+) this error message - is so good that I can even use the Jog/Shuttle functionality to scrub through audio at arbitrary speeds. I can also change between MDR projects etc. (relatively long, though I experienced a complete stall after quite some time) - But - just no proper display updates for the MDR page.

I can also use "quit" to leave it all, and cmi11 (or reboot) to start the CMI software again. Either will give a clean screen update. So I would guess that most of the hardware should be ok and hope for a software problem or missing cable or ... ???

I've also entered the "SETUP" pages on the MFX controller and cannot set anything that I think might help here. Everything else can be configured as expected.

Both the MFX3plus and QDC service manuals didn't have the error message listed. Google doesn't help either. :-(

Once again, thanks for any replies & kind regards, Joerg

P.P.S.: (Much later)

Solved it (sort of)

I'm not quite sure what the mechanics are in detail, but either the CMI does not load some stuff needed to support MFX on bootup, or some wrong stuff - might be when it asks for the MFX controller boot rom revision during bootup or whatever.

--

In detail: What I did to get a NON-WORKING system:

Boot CMI w/ MFX controller switched on, which would have no software in non volatile RAM or maybe the wrong software. (After first or second round of upload as described in this section.)

In CMI software: type quit or $ or # (any way to go to the shell)

On the MFX controller: type [-][+][Blue] buttons alltogether -> waiting for software...

Type mfxload [Enter] (the MFX kbd can act as keyboard even w/o special software)

Now, the software is loaded into the MFX Controller, and a growing *solid* bargraph is displayed on the controller.

When the upload is complete, the controller resets itself and complains with some message like:

"Check sum. Synchonised RAM ... "

(Have not remembered it and won't look it up now).

A second upload with the same keys/command on CMI would then also proceed,

and display a non-solid growing bargraph - where only the last vertical line of each char would grow,

then the next character would begin. Giving something like a zebra with a 1:6 or so duty cycle.

Then, the MFX controller would reset again, and NOT complain any more.

Pressing ESC for the CMI, or cmi11 - depending on how you entered the shell - would return to the CMI software. Pressing ESC F12 to enter the MDR screen would produce an almost working screen as described above plus many error messages, plus more funny graphics and functionality problems you would not want.

-

OK. From there on I looked around in the system.

Found the default path that mfxload would use. Meditated about "cmisys9" vs. "cmi11" vs. "Revision 11.39", but most probably, one referst to OS9, the other to the CMI software revision - so let that be. After all, I didn't find anything like cmisys11... :-)

Listed mfxload and found hints on included help. Tried mfxload -h

Tried mfxload -l

Very nice, esp. if you hit space etc.

(found more diagnostics before but will not write them up here now)

Looked around on other partitions... In boot configuration files. etc. pp. - all not really successful.

--

So. Now, how I got a working machine (if you don't have docs, use inspiration...):

Switch MFX controller off.

Boot CMI completely (I've booted with the controller off before, and switched it on later on, vaguely remembered - so there can't be anything wrong, and nothing should go wrong at this early boot stage if the CMI cannot see the controller: Better none at all, than a ROM signature which doesn't fit the RAM image we're going to load later?? Hm. But even when the upload looked as if it had finally succeeded, simply booting CMI again would not end in a perfect system, so I don't know whether controller visibility at boot time has any significance at all).

From CMI software: use # to go to shell

On MFX controller:

Press [1][2][3] together -> Clears non volatile RAM :-)

Press [-][+][Blue] together -> waiting for upload

For CMI: type mfxload [Return]

Now, the upload proceeds - with a *solid* bargraph

Controller resets

This time: NO complaint from the controller. Maybe for the first time of those I tried mfxload.

For CMI: type [ESC]

You're back in the CMI environment.

Funnily, the status line reads: "MFX & CMI Software revisions do not match" or something similar.

(I'm not sure whether it had already shown that immediately after MFX power up,

or just upon returning.)

Type [ESC][F12] for MDR screen.

Open a project.

More than funnily, everything works now: Scrolling audio track content, no error messages any more etc.

--

So conclusion:

(1) Good: It's a software problem. All the needed software is still here.

(2) Bad: We still don't know the mechanics perfecly. But we have hope that this will help:

-> Either clearing controller memory before uploading is necessary,

OR

Keeping the controller powered off during CMI boot is necessary,

OR

I'll be a little bit frustrated when I try to switch on this beastie the next time again.

Because I've still not added a new battery.

(I had dismanteled the whole thing a few days ago, recapped the PSU because (probably)

a bad cap smelled very bad, noted the bat voltage of 2.0 instead of 3.0 V and let it be

because I just couldn't remember that the bat had failed before. Had been months since I used it last.)

(3) I'll put in a new battery. Living without one is much too troublesome.

(No battery may have the advantage of protecting the board against battery leakage etc.)

--

Thought I'd write this up for anybody else who has this problem now (Karel?) or in the future, given that I'd searched around and asked before. And finding that (& *might* be how) a problem can be fixed with what you have is often already helpful, even if you don't understand it completely.

Kind regards, Joerg

P.P.P.S: Sorry for the full quotes in the follow up messages.

That's not normally my style (except when I'm very tired).

Didn't pay too much attention to the three dots at the bottom of the text box - didn't know it was too expensive nowadays to show *all* that would be sent, given they also have the bandwidth for tons of graphics and javascript frameworks at the same time...

Kind regards (& good night if that suits your location) - j.