Previous Thread
Next Thread
Print Thread
Page 1 of 4 1 2 3 4
Fairlight CMI #111274
11/14/17 06:41 PM
11/14/17 06:41 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
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!

[Linked Image]

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.

[Linked Image]

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

[Linked Image]

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.

[Linked Image]

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

[Linked Image]

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.

[Linked Image]

All the Interrupts are listed as active:

[Linked Image]

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:

[Linked Image]

We're getting close!

Re: Fairlight CMI [Re: SynaMax] #111282
11/16/17 06:28 AM
11/16/17 06:28 AM
Joined: May 2005
Posts: 24
L
Luigi30 Offline
Member
Luigi30  Offline
Member
L
Joined: May 2005
Posts: 24
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.

Re: Fairlight CMI [Re: Luigi30] #111313
11/22/17 08:45 AM
11/22/17 08:45 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
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:

Quote
"With the pitch register held at maximum, octave register is cycled from 0 to 8. At each setting, a timer is used to time a waveform by presetting a segment count appropriate to that octave and selecting the RUN mode. If timeout occurs before the End of Sound is reached or if the timer value is greater than a certain tolerance when the end is reached, an error is generated. The timer is clocked by the internal clock."


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?

Last edited by SynaMax; 11/22/17 08:46 AM.
Re: Fairlight CMI [Re: SynaMax] #111314
11/22/17 09:32 AM
11/22/17 09:32 AM
Joined: Feb 2004
Posts: 1,968
Sydney, Australia
Vas Crabb Offline
Very Senior Member
Vas Crabb  Offline
Very Senior Member
Joined: Feb 2004
Posts: 1,968
Sydney, Australia
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.

Re: Fairlight CMI [Re: SynaMax] #111315
11/22/17 10:19 AM
11/22/17 10:19 AM
Joined: Mar 2006
Posts: 1,014
PA, USA
L
Lord Nightmare Offline
Very Senior Member
Lord Nightmare  Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,014
PA, USA
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.


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Re: Fairlight CMI [Re: Lord Nightmare] #111473
12/01/17 02:07 AM
12/01/17 02:07 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Originally Posted by Lord Nightmare
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.

Re: Fairlight CMI [Re: SynaMax] #111474
12/01/17 06:53 AM
12/01/17 06:53 AM
Joined: Jan 2012
Posts: 899
Bavaria
rfka01 Offline
Senior Member
rfka01  Offline
Senior Member
Joined: Jan 2012
Posts: 899
Bavaria
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


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Re: Fairlight CMI [Re: SynaMax] #111485
12/02/17 06:21 AM
12/02/17 06:21 AM
Joined: Jul 2011
Posts: 94
T
TSCHAK Offline
Member
TSCHAK  Offline
Member
T
Joined: Jul 2011
Posts: 94
@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

Re: Fairlight CMI [Re: TSCHAK] #111489
12/02/17 04:06 PM
12/02/17 04:06 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Originally Posted by TSCHAK
@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.

Re: Fairlight CMI [Re: SynaMax] #111503
12/04/17 06:18 PM
12/04/17 06:18 PM
Joined: Dec 2004
Posts: 111
San Jose, CA
P
Phil Bennett Offline
Senior Member
Phil Bennett  Offline
Senior Member
P
Joined: Dec 2004
Posts: 111
San Jose, CA
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.

Re: Fairlight CMI [Re: Phil Bennett] #111506
12/05/17 05:35 AM
12/05/17 05:35 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Those screenshots are absolutely awesome! Do you recall if Page R, the sequencer software, worked in that driver?

I'm definitely interested in taking a look at this older driver. smile

Re: Fairlight CMI [Re: SynaMax] #111515
12/06/17 07:30 AM
12/06/17 07:30 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
In other news, I started working on reverse engineering the *.RS file format today. This is the music sequence files that PAGE R uses. Even without debugging directly on the machine, I can already see several patterns going on in the binary data.

First off, the file is split up into 0x80-byte sized chunks. The header has some magic bytes (0x0102) in the beginning and then the speed value of the song. The speed value is different from tempo (since we're dealing with PIT timers and stuff instead of a MIDI clock) so in order to figure out the speed value of your song, you need to divide 314160 by the song's BPM. So, if your song's BPM is 120, then the speed value will be 2618 (314160/120 = 2618).

I'm not 100% sure, but I'm pretty confident the next two bytes are the time signature of the song. The two values I've seen so far are 0x0404 and 0x0804, both of which are valid time signature that are used by the sequencer (4/4 and 8/4).

The last thing that I found out is that the chunk at offset 0x680 is either always full of 0xE5 bytes or zeroed out. I don't know why that's the case.

I'll post more updates on the format as soon as I discover them!

Re: Fairlight CMI [Re: TSCHAK] #111518
12/06/17 06:22 PM
12/06/17 06:22 PM
Joined: May 2012
Posts: 466
S
shattered Offline
Senior Member
shattered  Offline
Senior Member
S
Joined: May 2012
Posts: 466
Originally Posted by TSCHAK
@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


btw, Synergy HCS disk is in softlist -- http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=110725#Post110725

Re: Fairlight CMI [Re: SynaMax] #112502
02/06/18 02:32 AM
02/06/18 02:32 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
I made several new discoveries with the Fairlight emulation. First off, MESS does actually generate sound from the Fairlight. When I load notes into a song in the Page R sequencer and if there's a sample loaded into the channel's RAM, it will play the sound and actually change pitch. The catch is that the emulator plays the sound forever, so it creates annoying cluster chords whenever I change the pitch, but, nevertheless, I thought it was really cool to actually hear audio playback inside of MESS.



The second thing I discovered, is a secret debugging page that's not listed in the main index. Page T doesn't have any documentation unfortunately, but it looks like it's a hex editor and has some special debugging features.

[Linked Image]
[Linked Image]
[Linked Image]

Changing the screen inversion to FF inverts the colors of the screen, which is really cool looking!

[Linked Image]

More importantly, if you look closely at Page T's first screenshot, you can see that each channel's state (aka "C. STAT") is FF. I think this is the byte that constantly spams the command line whenever the current version of MAME is trying to initialize the channel cards. The emulator wants to change it to an FF but something is preventing it from happening.

Re: Fairlight CMI [Re: SynaMax] #112505
02/06/18 04:16 AM
02/06/18 04:16 AM
Joined: Dec 2012
Posts: 242
Dunedin, NZ
L
LoganB Offline
Senior Member
LoganB  Offline
Senior Member
L
Joined: Dec 2012
Posts: 242
Dunedin, NZ
Originally Posted by SynaMax
The second thing I discovered, is a secret debugging page that's not listed in the main index. Page T doesn't have any documentation unfortunately, but it looks like it's a hex editor and has some special debugging features.


http://www.mixound.com/Produits/Hardware/Fairlight/CMI-II/fairlight.htm
Quote
Page T is called TEST! I found this undocumented page by accident when trying to troubleshoot my own faulty instrument. It can display the status of most of the system in real time, allowing the user to see where problems may be, and it's fun to watch even when all is well - marvel at the sight of keys being captured in a buffer, and watch as each voice card is assigned a channel, plays through its voice, and is then released for the next note!

Re: Fairlight CMI [Re: LoganB] #112510
02/06/18 07:07 AM
02/06/18 07:07 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Did a bit more research and I found this rare screenshot of Page T so we know what it is supposed to look like.

[Linked Image]

Looks like the Channel state switches from either 01 or FF. 01 means a sample is playing and FF denotes if the channel is not playing anything.

Channel Mode refers if the sample is a Mode 1 or Mode 4 sample (Mode 1 = 00; Mode 4 = 80). If a sample is playing, then the channel mode's lower byte changes to 8. If a different sample is loaded and the previous sample stops playing the lower byte still stays at 8 for whatever reason.

The pitch of the sample is denoted in the "Stroke" table, under "S. Key". 07 = C1, 13 = C2, 1F = C3, 2B = C4, etc.

Re: Fairlight CMI [Re: SynaMax] #112826
03/10/18 02:56 AM
03/10/18 02:56 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Made a lot of progress today and found some interesting things in the debugger as to what's happening with the CMI emulation.

Since the CMI runs on two 6809s, I was a little confused on where to start debugging. Considering that I was experiencing write errors to the floppy image in MESS and the fact that the CMI System Disk won't load in MAME but the QDOS diagnostic disk will, I figured there's something weird going on with the floppy drive. I did some reading up about the Fairlight's CPU arrangement and I found out that CPU 1 handles all the I/O, realtime processes such as music and sample playback, where as CPU 2 handles monitor drawing and floppy disk control. So I figured I start with CPU 2. Initially, everything seems to work fine, both emulators pop up the same registers and have no discrepancies whatsoever, until near the very end of the bootup. At offset 8199, the Fairlight does this:

8199 TST $824B
819C BNE $8199

In MESS, the byte at $824B changes to a 01 and the CMI proceeds with booting up. In MAME, the byte also changes in CPU2's RAM, but the CPU gets stuck in this loop forever. I set up some breakpoints and watchpoints and found this.

I set up a breakpoint in MESS at 819E (the next immediate instruction after 819C). MESS ran right to it and stopped the emulation. In MAME, no dice. The loop just stayed forever, even though memory does show that 824B does have a 01 in place.

In MESS, I set up a watchpoint at 824B. Here's the PC register values it grabbed:

PC=F668 (data=0)
PC=F693 (data=0)
PC=F693 (data=0)
PC=808D (data=1)

The same watchpoint in MAME:


PC=F666 (data=0)
PC=F691 (data=0)
PC=F691 (data=0)
PC=808A (data=1)

Why the differences in PC registers? Is CPU2 executing instructions too early? Or did something change between the old MESS debugger and the new MAME one?

Another thing that I found interesting is the contents of the memory itself.

[Linked Image] [Linked Image]

Ignore FC90, that's the timer so the values are always different. FC80 is of interest though. That's suppose to be the ACIA registers. Also, FD00 is different as well, that the Shared 512 byte RAM for both processors. FF00 also looks like a glitch, as if MESS pasted the name of 6840 PTM in memory, which is weird.

So, ultimately, I don't have an answer as to what's going on, but I feel I'm definitely on to something.

Re: Fairlight CMI [Re: SynaMax] #112827
03/10/18 04:18 AM
03/10/18 04:18 AM
Joined: May 2015
Posts: 37
M
mixmaster Offline
Member
mixmaster  Offline
Member
M
Joined: May 2015
Posts: 37
Originally Posted by SynaMax
FF00 also looks like a glitch, as if MESS pasted the name of 6840 PTM in memory, which is weird.

It's not weird. It's old versions of programs having bugs because one, they are out of date; two, out of date versions will likely have bugs; three, it's out of date and you shouldn't be seriously using any old version of MAME nor any version of MESS. Period.

Unless it's to point out long standing bugs or regressions. If something used to work in MESS, but not in new versions of MAME, then you can happily tell your problem here or file a report on MAMETesters.

Re: Fairlight CMI [Re: SynaMax] #112845
03/11/18 06:20 PM
03/11/18 06:20 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Originally Posted by mixmaster
Originally Posted by SynaMax
FF00 also looks like a glitch, as if MESS pasted the name of 6840 PTM in memory, which is weird.

It's not weird. It's old versions of programs having bugs because one, they are out of date; two, out of date versions will likely have bugs; three, it's out of date and you shouldn't be seriously using any old version of MAME nor any version of MESS. Period.

Unless it's to point out long standing bugs or regressions. If something used to work in MESS, but not in new versions of MAME, then you can happily tell your problem here or file a report on MAMETesters.


What I'm trying to do is figuring out why the Fairlight CMI driver in the latest version of MAME doesn't load the Fairlight System Disk. This disk successfully loads in a 2009 build of MESS that Phil Bennett worked on, hence why I'm comparing the two drivers. I'll gladly file a report on MAMETesters if that will help get this bug fixed.

Re: Fairlight CMI [Re: SynaMax] #112892
03/17/18 01:24 AM
03/17/18 01:24 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
So I realized I can't post on MAMETesters because the CMI is listed as a machine that's not working, so I'm going to continue posting my findings here.

This time I focused my debugging only on CPU 1 and immediately I noticed a difference between the two emulators. I had the debuggers focus only on CPU 1 and let them run to the next interrupt.

In MESS, CPU 1 ran until it stopped at address $FBEA. The 6809 instruction there was RTI (return from interrupt), so that made sense. The next interrupt stopped at address $0F6E, where there was another RTI instruction. After two two interrupts, the system continues to boot.

In MAME, CPU 1 completely skipped the interrupts at those addresses and continues to run. The first interrupt we encounter is at address $4FE2, where the subroutine here looks like it's trying to write the channel cards. Sure enough, every time I hit F7 to go to the next interrupt, it stops at that same address and adds another "Unknown channel card 6 write to E001 = 00" to the command line.

I then went to the source code of Phil Bennett's MESS driver and the new MAME driver, where I made an interesting discovery. Remember the missing memory-mapped ACIA registers? Well, I noticed that the Phil's code uses the 6850 driver to emulate the ACIA, whereas the new MAME driver uses the MOS6551 instead (I'm assuming because the 6850 is similar to the 6551). Maybe something is off with how the 6551 is implemented, hence why those registers don't show up.

Last edited by SynaMax; 03/17/18 01:26 AM.
Re: Fairlight CMI [Re: SynaMax] #112893
03/17/18 02:06 AM
03/17/18 02:06 AM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
No, the 6850 and 6551 are very different and definitely not compatible. That's probably your regression right there.

Last edited by R. Belmont; 03/17/18 02:07 AM.
Re: Fairlight CMI [Re: SynaMax] #112895
03/17/18 05:24 AM
03/17/18 05:24 AM
Joined: May 2009
Posts: 1,671
J
Just Desserts Offline
Very Senior Member
Just Desserts  Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,671
No offense, but SynaMax and RB, I'm not a grotesque moron. That's probably not the regression.

SynaMax, I would ask that you look at CMI2xServiceManual.pdf, particularly page 205 of 378 in the PDF. It should be the schematic page for "Q133-02, Sheet 3 of 5".

If you look closely at it, you'll note a gang of four chips, all of which are marked on the schematic, surprise surprise, as "6551". They should be mapped in the correct place and hooked up correctly in the memory map. There may be lurking bugs, but I assure you, I'm not so colossally stupid that I would arbitrarily utilize the MOS 6551 ACIA in place of the Motorola 6850 ACIA.

Re: Fairlight CMI [Re: Just Desserts] #112897
03/17/18 09:48 AM
03/17/18 09:48 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Sorry, I apologize if I came off as rude or implied that you were stupid in my previous post; I assure you that was not my intent.

Thanks for the heads up on the 6551, I can't believe I missed that. I had my service manual open the whole time and I checked to see if the 6551 was on there or not. My bad.

Re: Fairlight CMI [Re: SynaMax] #112898
03/17/18 11:16 AM
03/17/18 11:16 AM
Joined: Apr 2012
Posts: 208
UK
Pernod Online content
Senior Member
Pernod  Online Content
Senior Member
Joined: Apr 2012
Posts: 208
UK
I have been following this thread out of curiosity, and have also compared Phil's original code with the current but not noticed any obvious regressions. Have you tried enabling trace on each CPU? This should allow you to compare both old and new traces to see where they diverge.


BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
Re: Fairlight CMI [Re: Pernod] #112910
03/19/18 07:53 PM
03/19/18 07:53 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Thanks a lot for the suggestion, Pernod! As a beginner when it comes to debugging, I really appreciate it. smile

I did a trace and compared the first CPU between the two emulations. I'll post my findings, once I figure out what's the subroutines are doing.

Re: Fairlight CMI [Re: SynaMax] #112929
03/21/18 07:47 AM
03/21/18 07:47 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
So I found something wrong with the register for the Floppy Disk Controller on CPU2.

The instruction at $DDD9 loads into register A the byte from $FCE1 (which is the status and address register for the FDC). In MESS, this byte switches to C8 and the next instruction checks this with a BITA instruction (BITA #$40). If the result equals to 40, it proceeds with the subroutine and continues loading data from the floppy. Looking at the memory window in MAME, I don't see $FCE1 change at all; it's always 00. The debugger does say the byte is being read and written to, but it hits a point where instead of register A having the value C8, it just stays at 88 and since it fails the BITA instruction, it stays in a loop and constantly goes back to $DDD9. Eventually it gets out of the loop but nevertheless, I don't believe this to be the expected behavior.

As for CPU1, things start going wrong at instruction $FB36. The opcode there is LDB $1,X. X's value at this point is FC84, which means it's an ACIA register. In MESS, it seems that the value at $FC85 is always 00. That's what shows in both the memory window as well as the B register. In MAME, the ACIA registers are all FF (however, the value that's loaded into the B register is 60; could someone explain why that is?). This instruction gets called quite frequently and since the register values are different, instructions $FB3C and $FBE3 get skipped a lot in MAME.

Instruction $F8EE (TST $FE00) is very important for loading the system disk. It tests the byte at $FE00 to see if it's a 1 or 0. If it's a 1, it proceeds to instruction $F8FD, where it uses jump offsets located at $FE01 to boot the system.

Setting up a watchpoint at $FE01 reveals these jump addresses:

F815
0EEA
8CBF
8C7F
8C9B
8CFD
1C31

Everytime a new address is written to memory, $FE00 changes to a 1 so that the program can go fetch the new address. In MAME, $1C31 is never reached because after $8CFD, the $FE00 byte stays on.

I'm still double checking to make sure I'm not missing anything else, but I'm pretty confident the problem lies in the ACIA (or at least it's a good place to start).

Re: Fairlight CMI [Re: SynaMax] #112930
03/21/18 12:59 PM
03/21/18 12:59 PM
Joined: Jan 2012
Posts: 782
C
crazyc Offline
Senior Member
crazyc  Offline
Senior Member
C
Joined: Jan 2012
Posts: 782
Originally Posted by SynaMax
In MESS, this byte switches to C8 and the next instruction checks this with a BITA instruction (BITA #$40). If the result equals to 40, it proceeds with the subroutine and continues loading data from the floppy. Looking at the memory window in MAME, I don't see $FCE1 change at all; it's always 00.

The fdc_r function has an (apparently unneeded?) machine().side_effects_disabled() at the start so the debugger won't show you the real value. Bit 6 is the interrupt line so it's not getting a expected irq from the fdc. Also the motor control seems to be missing which would cause problems (or does the 1791 have a builtin motor control?). Edit: It's an 8" drive so the motor is always on.

Last edited by crazyc; 03/21/18 01:59 PM.
Re: Fairlight CMI [Re: SynaMax] #112967
03/27/18 06:58 AM
03/27/18 06:58 AM
Joined: May 2012
Posts: 466
S
shattered Offline
Senior Member
shattered  Offline
Senior Member
S
Joined: May 2012
Posts: 466
I think that i8214 emulation should call check_interrupt() in etlg_w() and inte_w() -- this solves most of screen corruption in ms6102 (8275 sometimes happens to set IRQ while INTE=0 in 8214, so interrupt is ignored and never handled.)

Doesn't help CMI, though.

Re: Fairlight CMI [Re: SynaMax] #112968
03/27/18 01:20 PM
03/27/18 01:20 PM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
shattered: that makes sense, go ahead and submit it.

Re: Fairlight CMI [Re: SynaMax] #112970
03/27/18 10:17 PM
03/27/18 10:17 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Something weird happens on CPU 1 at instruction $8D22.

In MESS, this is what happens:

Code
PC = 8D22 S = 0F00 CC = D8 DP = 00 A = FF B = 80 D = FF80 X = 7DF0 Y = 9110 U = C800

8D22: ANDCC #$EF          // logical AND EF with D8 in CC register 
8D24: LDX   #$1C31        // load 1C31 into X, CC = C8
8D27: STX   $FE01         // store 1C31 at FE01
...


As you can see this writes the important jump address 1C31 at offset FE01.

In MAME, this happens:

Code
8D22: ANDCC #$EF          // logical AND EF with D8 in CC register 
4FE2: LDA   #$40          // why did it jump to 4FE2?  CC register is still D8.
4FE4: LDX   #$7B8C
4FE7: JMP   $4FF2
4FF2: CLRB  
4FF3: TFR   B,DP
4FF5: JSR   $4DCC
4DCC: CLR   $FCFC
4DCF: INC   $1CE2
4DD2: RTS   
...


I double checked the CPU flags at $8D22 in both MESS and MAME and they're the same: EF.IN...

The only thing that changes when 8D22 jumps to 4FE2 is the PC pointer (obviously) and the stack, which goes from 0F00 to 0EF4; CC doesn't change at all. From there on MAME just continues running the wrong instructions (looks like it loops from 4FE2 to 5025), writing to channel card 6 and spamming the command prompt.

Last edited by SynaMax; 03/27/18 10:29 PM.
Re: Fairlight CMI [Re: SynaMax] #112971
03/28/18 12:57 AM
03/28/18 12:57 AM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
You sure it's not switching CPUs at that point?

Re: Fairlight CMI [Re: SynaMax] #112973
03/28/18 01:37 AM
03/28/18 01:37 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
I just double checked and made sure I wasn't focused on CPU 1. When I hit either F10 or F11 to go to the next instruction, it stays on CPU1.

The only reference to 4FE2 I can find is here:

Code
8DB1: LDX   #$4FE2
8DB4: STX   $FFDE


EDIT: It's triggering an interrupt, I think. According to this site, FFDE-FFDF is IRQ15 (low priority PICU). $5025 is an RTI opcode and jumps back to $4FE2.

Last edited by SynaMax; 03/28/18 01:53 AM.
Re: Fairlight CMI [Re: SynaMax] #112977
03/28/18 12:48 PM
03/28/18 12:48 PM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
Ahh, yeah, IRQ is the other reason the PC will go flying.

Re: Fairlight CMI [Re: Lord Nightmare] #113292
04/29/18 01:48 PM
04/29/18 01:48 PM
Joined: Mar 2006
Posts: 1,014
PA, USA
L
Lord Nightmare Offline
Very Senior Member
Lord Nightmare  Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,014
PA, USA
Originally Posted by Lord Nightmare
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.


These links are now dead, did someone save those two PDFs? archive.org did not grab them.

EDIT: Nevermind, archive.org did grab them, I just missed them (thanks, balrog!):
http://web.archive.org/web/20170801113735/http://www.fairlightus.com/cmi/fairlight_docs/CMI-01.pdf
http://web.archive.org/web/20170801113535/http://www.fairlightus.com/cmi/fairlight_docs/CMI-01A.pdf

More docs can be found at https://web.archive.org/web/*/http://www.fairlightus.com/cmi/fairlight_docs/*


LN

Last edited by Lord Nightmare; 04/29/18 03:08 PM. Reason: Add links

"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Re: Fairlight CMI [Re: Lord Nightmare] #113294
04/29/18 08:43 PM
04/29/18 08:43 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Steve Rance also made a mirror of that site here:

http://steverance.com/CMI/

And here's the links to those PDFs as well, just in case.
http://steverance.com/CMI/fairlight_docs/CMI-01.pdf
http://steverance.com/CMI/fairlight_docs/CMI-01A.pdf

Last edited by SynaMax; 04/29/18 08:58 PM.
Re: Fairlight CMI [Re: SynaMax] #113299
04/30/18 11:13 AM
04/30/18 11:13 AM
Joined: Mar 2006
Posts: 1,014
PA, USA
L
Lord Nightmare Offline
Very Senior Member
Lord Nightmare  Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,014
PA, USA
The major differences between the CMI-01 and CMI-01A are mostly in the entirely different analog section.

The memory map is also slightly different:
Code
CMI-01:
00 - /PORT (read/write to RAM address at ram pointer location, may auto-increment?)
01 - /LVD write (VCA DAC)
02 - /LAT2 write (low 4 bits; to FILT filter circuit PWM (chopper? or pulse width?) generator)
03 - /FRD write
04 - /FRU write
05 - N/C
06 - N/C
07 - N/C

CMI-01A:
00 - /PORT (read/write to RAM address at ram pointer location, may auto-increment?)
01 - N/C
02 - N/C
03 - /FRD write
04 - /FRU write
05 - /LVOL write (VCA DAC)
06 - /LFILT write (8 bits, expanded to 10 bit DAC input and to FILTER input of SSM2045 VCF/VCA)
07 - N/C


The remainder of the PTM/PIA and RAM memory map is the same on both.
The O bus of the second PIA's port A affects the filter in a different way on the CMI-01A (it adds to the top 4 bits of the FILTER input to the SSM2045) vs affecting the PWM counter on the CMI-01.

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Re: Fairlight CMI [Re: Lord Nightmare] #113303
05/01/18 01:06 AM
05/01/18 01:06 AM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Awesome find on the memory map differences, LN! I'm pretty sure CMI-01-A is the one we want to follow since that was the channel card used in the CMI IIx. I'm not sure if the CMI-01 is compatible with the Series IIx, since it originally was for the Series I.

I found out how the Fairlight writes to the channel cards. The subroutine starts at $5557 by loading the sample audio data into A by grabbing it from X and then increments X. In this case, the sample data was temporarily located at $8000 so X's value started at 8000. At $5559, it stores A at $E000, the channel card port and then the next instruction increments register B. It does this for 80 bytes and breaks the loop once B hits 80. Then the machine executes several other instructions before going back to load the next 80 bytes of the sample data.

Code
5557:    LDA   ,X+
5559:    STA   $E000
555C:    INCB
555D:    BPL   $5557

Last edited by SynaMax; 05/01/18 01:06 AM.
Re: Fairlight CMI [Re: SynaMax] #113415
05/12/18 07:02 PM
05/12/18 07:02 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Just saw this on the Fairlight Facebook Group:

[Linked Image]

This photo was taken by Robbie Puricelli, a Fairlight restorer and I asked him a few questions. First off, as you can see in the photo above, it's possible to boot into the Fairlight's OS without channel cards installed; just boot off of the system disk like you normally would. Second, he told me Series I cards (aka the CMI-01) are compatible with the Series IIx.

Re: Fairlight CMI [Re: SynaMax] #113436
05/15/18 10:44 PM
05/15/18 10:44 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Nothing technical, just a really cool video on why this machine is amazing (and further proof as to why it needs to be preserved).


Re: Fairlight CMI [Re: SynaMax] #113635
06/29/18 09:04 PM
06/29/18 09:04 PM
Joined: Nov 2017
Posts: 23
S
SynaMax Offline OP
Member
SynaMax  Offline OP
Member
S
Joined: Nov 2017
Posts: 23
Anyone want to buy a Fairlight?

It's currently broken but with the right parts and restoration efforts, it would be nice to have a unit on hand to debug with.

Page 1 of 4 1 2 3 4

Who's Online Now
2 registered members (robcfg, Tafoid), 34 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,553
Posts111,744
Members4,800
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.055s Queries: 14 (0.012s) Memory: 6.0337 MB (Peak: 6.4653 MB) Zlib enabled. Server Time: 2018-07-17 13:41:46 UTC