Previous Thread
Next Thread
Print Thread
Page 2 of 4 1 2 3 4
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: 467
S
shattered Offline
Senior Member
shattered  Offline
Senior Member
S
Joined: May 2012
Posts: 467
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.
Page 2 of 4 1 2 3 4

Who's Online Now
2 registered members (Praxis, Justin), 73 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,566
Posts111,891
Members4,805
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.043s Queries: 14 (0.017s) Memory: 5.7303 MB (Peak: 5.9515 MB) Zlib enabled. Server Time: 2018-08-19 19:29:54 UTC