Amstrad SSA-1 Speech Synthesizer ROM needed

[nocash]

> Tomorrow morning I'll go to my mother's and try to locate it...
Juhu. Would be great if you can decipher the text on the oscillator!

> I need the read port values before, during and after talking.
Oh my... the port values are fully described here,
  http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer
and binary numbers are described here,
  http://www.google.de/search?hl=en&q=binary+numbers+tutorial&btnG=Search&aq=f&oq=

Btw. I've added an article about the MHT Speech thing,
  http://cpcwiki.eu/index.php/MHT_Speech_Synthesizer
the pictures seem to come from cpcrulez.fr, the upper four pictures do show the MHT Speech. The other two pictures seem to show something else (I guess their filenames are just wrong, and they don't show a speech interface at all) (though with the 3.5mm socket, it MAY really be some kind of audio output, or audio input device?).

The MHT hardware seems to be very similar to the SSA-1 and Dk'tronincs speech interfaces, but all important details are still unknown. Any info about its I/O Ports, oscillator, chipset, manual, supported games, included RSX driver...?

[arnoldemu]

> I need the read port values before, during and after talking.
Oh my... the port values are fully described here,
  http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer
and binary numbers are described here,
  http://www.google.de/search?hl=en&q=binary+numbers+tutorial&btnG=Search&aq=f&oq=

True, but it doesn't say about the timings. How long is it before the signals change for example?

[nocash]

> True, but it doesn't say about the timings. How long is it before the signals change for example?

Didn't you see the links to the SP0256 chapters? The allophone list includes (rounded) timing values. And the instruction set and voice generator chapters give really excessive information about the real timings. All you need is to disassemble or emulate the SP0256-AL2 ROM - dumps of that ROM are in the internet (though, caution: usually in bit-reversed form, ie. within the bytes, only the Target values have correct bit-order, and all other opcode and parameter bits are reversed).

The only thing about the timings that is really-really unknown is the clock source (that's why I'd be so happy if somebody who owns a SSA-1 would take a screwdriver and check it).

[Devilmarkus]

Indeed, the timings are still a hard nut to heck out for me...
But all SSA-1 featured games work now...
Only the speech software itself still denies it's work (|SAY,"....")

Here you can hear "Roland in space" -> full speech output:
http://cpc.devilmarkus.de/roinspace/

I extra turned the music down to keep a better ear on speech output...

[Devilmarkus]

Come on guys!!! Helpppppppp....

You surely all remember this nice car:


(Click on it to see the truth!!!)

[Bryce]

I knew it! Kit could only have been that intelligent with some serious hardware hidden inside. But that still doesn't explain how he managed to see people inside buildings or always know that his curly-headed, Berlin Wall defeating, Folk-singing side-kick needed help. Maybe they had Skippy hidden in the trunk.

Bryce.

Markus, you have waaaaay too much free time on your hands

[Gerald]

Hi Markus

I've done some reverse engineering my old good SSA1.
Most interesting point are:
   The SPO256-AL2 uses a 3.12Mhz resonator.
   IO port FBEE is decoded using A10 A4 A0 only. So any port with these bit low could access the SSA1
   IORead returns LRQ on bit D6 and SBY on bit D7. Other bits are not driven by the interface.

I'll try to get some timing info on SBY and LRQ later this week (I need to setup my 464 for that)

Gerald

[Devilmarkus]

Cool! Thank you, Gerald!

[arnoldemu]

Hi Markus

I've done some reverse engineering my old good SSA1.
Most interesting point are:
   The SPO256-AL2 uses a 3.12Mhz resonator.
   IO port FBEE is decoded using A10 A4 A0 only. So any port with these bit low could access the SSA1
   IORead returns LRQ on bit D6 and SBY on bit D7. Other bits are not driven by the interface.

I'll try to get some timing info on SBY and LRQ later this week (I need to setup my 464 for that)

Gerald

Talking of port decoding. I thought I remembered reading about the port decoding for dk'tronics speech. But I can't find it here. Can anybody help?

[nocash]

> I've done some reverse engineering my old good SSA1.
> The SPO256-AL2 uses a 3.12Mhz resonator.
Great! That was the missing detail. Ah, you have really checked it, haven't you? Ie. not just looked at the datasheet, which recommends 3.12MHz, but hardware doesn't necessarily use that frequency (eg. dktronics used the 4MHz clock from expansion port).

> IO port FBEE is decoded using A10 A4 A0 only. So any port
> with these bit low could access the SSA1 IORead returns
> LRQ on bit D6 and SBY on bit D7.
Fine, confirms what they said in the manual.

> I'll try to get some timing info on SBY and LRQ later this week
Okay. I'd still recommend reading (and understanding) the data sheet being the better approach on that part ;-)

Btw. I've added a new NO PICTURE EXISTS YET symbol,
  http://cpcwiki.eu/index.php/File:NoPicture.gif
for situations where technically relevant photos are missing. If the 3.12MHz is confirmed, then I guess it can be removed from the SSA-1 page. NB. other pages where photos would be still needed are: Dk'tronics Mouse Interface, AMX Mouse, Amstrad Serial Interface, Amstrad Magnum Phaser, Dk'tronics Silicon Disc, Dk'tronics memory expansion, CPC-Mousepack 2.0.

[gerald]

> I've done some reverse engineering my old good SSA1.
> The SPO256-AL2 uses a 3.12Mhz resonator.
Great! That was the missing detail. Ah, you have really checked it, haven't you? Ie. not just looked at the datasheet, which recommends 3.12MHz, but hardware doesn't necessarily use that frequency (eg. dktronics used the 4MHz clock from expansion port).

I have a nice picture of that 3.12MHz resonator 
I can provide component / solder side picture of the PCB to put in the wiki ... if someone volunteer to do it or show me how to do it 

> I'll try to get some timing info on SBY and LRQ later this week
Okay. I'd still recommend reading (and understanding) the data sheet being the better approach on that part ;-)

The datasheet is clear on the behaviour of SBY and LRQ signal.
- SBY is high when no allophone is processed. SBY = stand by. A table specify the length of each allophone.
- LRQ is low to indicate that the SPO can accept a new allophone. It will go high when a new allophone is loaded (with ALD), and will go low again after a while (presumably when on the last instruction of the microcode). You can load a new allophone before the last finished playing. The datasheet does not specify that timing.

Gerald

[Devilmarkus]

The main problem is that we have no exact timings for this.
But some good news:
I got the SSA-1 emulation work, too now. Also the Software reacts now and you are able to |SAY,"blabla" things.

Still needs better timings here... But it's already working nice...

Watch it here:
http://cpc.devilmarkus.de/ssa1

Cheers,
Markus

[nocash]

> I have a nice picture of that 3.12MHz resonator. I can provide
> component / solder side picture of the PCB to put in the wiki ...
> if someone volunteer to do it or show me how to do it

To upload a new picture, click "Upload file" (in the frame menu on left side of screen in http://cpcwiki.eu), then add a link to that file in the article.

Or, in this case you may want to replace the older low-res photos (if yours are showing the same board in better quality). To do that, click the old picture, this should gice you a "Upload new version of this file" option.

> The datasheet is clear on the behaviour of SBY and LRQ signal.
Yes!

> You can load a new allophone before the last finished playing.
> The datasheet does not specify that timing.

I thinks that's quite clear, too. The chip can hold max two allophones (one currently played, and one queued in a 1-byte fifo). The duration how long it takes to play an allophone depends on the repeat counts of the opcodes for that allophones - this would give the exact timings. Aside from that the rounded millisecond ARE in the sp0256 datasheet.

But, markus doesn't emulate the real allophones anyways, so he doesn't need the exact timings for the real allophones anyways. I think his only problem is that he can't do the binary to decimal conversion, isn't it? As we all now all 8bits set gives 255 decimal. The "big" question is: What happens to the decimal value if bit6 is not set? Any binary number experts here ready to help? ;-)

[Devilmarkus]

But, markus doesn't emulate the real allophones anyways, so he doesn't need the exact timings for the real allophones anyways. I think his only problem is that he can't do the binary to decimal conversion, isn't it? As we all now all 8bits set gives 255 decimal. The "big" question is: What happens to the decimal value if bit6 is not set? Any binary number experts here ready to help? ;-)

This is not exact what is missing.
I need to set SBY and LRQ bits manually.
This is also no problem.
The problem here is more "When must I change SBY to low/high and when LRQ?"

To have a better understanding you need to know how an emulator works and it's internal functions.
I am creating 2 devices first:

Code Select Expand

  protected SSA1               ssa1              = (SSA1) addDevice(new SSA1());
  protected DKTronics          dktronics         = (DKTronics) addDevice(new DKTronics());

These 2 devices I connect to the emulated z80 as read and write device:

Code Select Expand

    DeviceMapping amstradSpeech = new DeviceMapping(ssa1, 0x0411, 0x0);
    DeviceMapping dktronicsSpeech = new DeviceMapping(dktronics, 0xFFFF, 0xFBFE);    // needs more realistic values here
......
        z80.addOutputDeviceMapping(amstradSpeech);
        z80.addInputDeviceMapping(amstradSpeech);
        z80.addOutputDeviceMapping(dktronicsSpeech);
        z80.addInputDeviceMapping(dktronicsSpeech);

Now I built 2 new classes: DKTronics and SSA1.
Booth have their own "read and write port" function and also use a cycle routine.
Example for SSA1: (DKTronics is almost the same)

Code Select Expand

/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package jemu.core.device.speech;

import jemu.core.Util;
/**
*
* @author Markus
*/
public class SSA1 extends SpeechDevice{

    public static   int     LRQ;
    protected       int     SBY;
    protected       boolean DEBUG           = false;
    protected       int     speechCount     = 0;
    protected       int     speechlength    = 0;
    protected       int     length          = 0;
    protected       int     phonemelength   = 0;
    public          boolean doCycle         = false;
    protected       Speech  speech          = new Speech();

    public SSA1() {
        super("Amstrad SSA-1 Speech Synthesizer");
        LRQ = 0x80;
        SBY = 0x00;
    }

    public int readPort(int port) {
        if (Speech.enabled && Speech.SSA){
            if (DEBUG)
                System.out.println("Port read on " +
                        Util.hex((short)port) + " - " + Util.hex((short)(LRQ|SBY)));
            return (LRQ|SBY);
        }
        return 0xFF;
    }

    public void writePort(int port, int value){
        if (Speech.enabled && Speech.SSA){
            speechCount = 0;
            doCycle = true;
            phonemelength = Speech.lengths[value];
            speechlength += phonemelength*320;
            length = speechlength;
            speech.SpeechByte +=Util.hex(value).substring(6)+",";
            if (DEBUG)
                System.out.println("Port write to " + Util.hex((short)port)
                        + " - Value:" + Util.hex((short)value));
        }
    }

    public void reset(){
        LRQ = 0x80;
        SBY = 0x00;
        speech.SpeechByte="";
    }

    public void cycle(){
          int counter = 320000;
          speechCount++;
          if (speechCount < phonemelength){
              SBY = 0x40;
          } else {
              SBY = 0;
          }
          if (speechlength > 0){
              speechlength--;
              LRQ = 0x00;
              if (speechlength == 0){
              LRQ = 0x80;
              speechCount = counter-length;}
          }
          if (speechCount == counter){
              speechlength = 0;
              speechCount = 0;
              speech.Translate(speech.SpeechByte);
              doCycle = false;
              SBY = 0x00;
          }
    }
}


The values need better adjustment here but I think it's a good start to emulate this.

[Ygdrazil]

Great stuff emulating both the Speech Synths!!!

Another device worth (and probably even more simple than the SPO256) emulating could be the Amdrum(Simple) and the Music Machine (not so simple)!!

Great stuff!!!!!!

/Ygdrazil

[Cholo]

Probably a bit to late now, but to anyone interested i noticed there is a SSA-1 for sale on Ebay (without speakers but with tape software):
http://cgi.ebay.co.uk/SSA-1-Speech-Synthesizer-for-AMSTRAD_W0QQitemZ220537902735QQcmdZViewItemQQptZUK_VintageComputing_RL?hash=item335915568f

[robcfg]

Maybe I'm a bit late too, but I just uploaded 300dpi scans of the SSA1 and its circuit board to the SSA1 page here.

[nocash]

> just uploaded 300dpi scans of the SSA1 and its circuit board to the SSA1 page

Nice pictures, thanks! The solder side shows that the full 8bit data bus is connected, not sooo important detail, but the MHT and dk'tronics devices use only 6bit, and upper 2bit are GNDed.

[arnoldemu]

> I have a nice picture of that 3.12MHz resonator. I can provide
> component / solder side picture of the PCB to put in the wiki ...
> if someone volunteer to do it or show me how to do it

To upload a new picture, click "Upload file" (in the frame menu on left side of screen in http://cpcwiki.eu), then add a link to that file in the article.

Or, in this case you may want to replace the older low-res photos (if yours are showing the same board in better quality). To do that, click the old picture, this should gice you a "Upload new version of this file" option.

> The datasheet is clear on the behaviour of SBY and LRQ signal.
Yes!

> You can load a new allophone before the last finished playing.
> The datasheet does not specify that timing.

I thinks that's quite clear, too. The chip can hold max two allophones (one currently played, and one queued in a 1-byte fifo). The duration how long it takes to play an allophone depends on the repeat counts of the opcodes for that allophones - this would give the exact timings. Aside from that the rounded millisecond ARE in the sp0256 datasheet.

But, markus doesn't emulate the real allophones anyways, so he doesn't need the exact timings for the real allophones anyways. I think his only problem is that he can't do the binary to decimal conversion, isn't it? As we all now all 8bits set gives 255 decimal. The "big" question is: What happens to the decimal value if bit6 is not set? Any binary number experts here ready to help? ;-)

So with the 1 byte fifo:


ssa-1 is idle, no allophone loaded:

SBY is high, LRQ is low.

Load a allophone:

LRQ is high now. SBY is high for how long before ssa-1 takes byte?

Now ssa-1 starts to talk.

LRQ goes low? so that another allophone can be loaded into fifo...?
SBY is high now until current allophone is played?

Now ssa-1 finishes current allophone.

LRQ stays low if no allophone is loaded, otherwise it remains high for a bit while spo fetches it from fifo?
SBY remains high, or does it go low then high? and if it does how long ?

This is the timing we are thinking about.

With a 1-byte fifo, the LRQ and SBY can have indepedant timing. And the timing of how long it takes to switch state also depends on the internal timing in the SPO and not necessarily directly related to the length of the allophone being spoken.

[Devilmarkus]

Great stuff emulating both the Speech Synths!!!

Another device worth (and probably even more simple than the SPO256) emulating could be the Amdrum(Simple) and the Music Machine (not so simple)!!

Great stuff!!!!!!

/Ygdrazil

AmDrum sounds like this: http://cpc.devilmarkus.de/amdrum/

[Devilmarkus]

Had a bug in sound output... So it sounded bad.
Please check again now:
http://cpc.devilmarkus.de/amdrum/

I think this is close to the original...

[Devilmarkus]

[gerald]

Hi All

I've done some timing measurement with the following setup :
ALDn, LDQn, SBY are connected to a logic analyser which will trigg on falling edge of ALDn. Sampling rate is 100MHz, giving a 10ns resolution on timing.
The CPC will play all allophone in sequence, waiting for SBY to be high between each of them. The fifo is not used.

10 captures of 64 allophone have been used.

Some quick results :

Timing (ns)	min	avg	max
ALDn falling to LDQn rising	180	187	190
ALDn falling to SBY falling	200	204	210
LDQn high duration	15940	24203	41600

As you can see, LDQn and SBY change at the same time (from a Z80 perspective), delay is constant and is independant of the allophone.

LDQn duration is not constant, but does not seems to be allophone dependant.

SBY duration is, as expected, function of the allophone (not in the table). But the duration of the same allophone is not constant, variation is +/- 33% for the shortest (P0) to less that 1% for the longest.


From an emulation point of view :
LDQn timing can be limited to a constant delay from the write to FBEE.
SBY timing could be based on the duration of the sample used for the allophone.

What also need to be checked is what the SPO256 does when allophone are written when LDQn is high. Is the new one ignored or does it replace the one in the buffer?

I will do some more measurements, changing the sequence of allophone to check the variablility of the LDQn and SBY.

[nocash]

Whew it's going technical :-) NB I have emulated a sp0256 a while ago, but never seen one for real, so some details are 100% clear to me.

> So with the 1 byte fifo:
> ssa-1 is idle, no allophone loaded:
> SBY is high, LRQ is low.
Yup.

> Load a allophone:
> LRQ is high now. SBY is high for how long before ssa-1 takes byte?
Not sure, but I'd assume instantly. Ie. that LRQ doesn't go high at all, and SBY goes low immediately.
At least that'd be the concept how it SHOULD work. If the chip is too slow to react immediately, then it might happen as you described, would be interesting to know if it does happen! Anyways, it happens like so, then it'd be rather a dirt-effect, and I doubt that any software relies on the 'glitch', so it could be ignored in emulation.

> Now ssa-1 starts to talk.
> LRQ goes low? so that another allophone can be loaded into fifo...?
Yup (or LRQ stays low, if it reacted immediately).

> SBY is high now until current allophone is played?
No high means standby, so it's low until allophone is played (=finished).

> Now ssa-1 finishes current allophone.
> LRQ stays low if no allophone is loaded,
Yup.

> otherwise it remains high for a bit while spo fetches it from fifo?
Should fetch immediately when the allophone finished, it so LRQ should go low immediately, too. Even if it takes 1-2 clock cycles, it's probably unimportant to emulate that.

> SBY remains high, or does it go low then high? and if it does how long ?
No it should remain low forever, until the chip runs out of incoming data. Ie. until the last allophone finishes, and the fifo is empty at the same time.

> With a 1-byte fifo, the LRQ and SBY can have indepedant timing.
Well, that's why there are 2 status bits, not just one.

> And the timing of how long it takes to switch state also depends
> on the internal timing in the SPO and not necessarily directly
> related to the length of the allophone being spoken.
Again, I guess'd that'd be less than some microsecond and can be ignored.

[nocash]

> I've done some timing measurement with the following setup :
> The CPC will play all allophone in sequence, waiting for SBY to be high
Good job.
Is yours really doing LoadDeQuest, not LoadReQuest? ;-)

> LDQn high duration   15940   24203   41600
Okay, wouldn't have expected that. I'd have thought it's 0.0000000 seconds.

> From an emulation point of view :
> LDQn timing can be limited to a constant delay from the write to FBEE.
Not sure that's required at all... is there any software that relies on the presence of that delay (when detecting the speech chip or so)?


> SBY duration is, as expected, function of the allophone (not in the table).
> But the duration of the same allophone is not constant, variation is +/-
> 33% for the shortest (P0) to less that 1% for the longest.
Interesting. Maybe the sp0256 executes delays (with repeat count=1) when it's in standby mode...

> From an emulation point of view :
> LDQn timing can be limited to a constant delay from the write to FBEE.
> SBY timing could be based on the duration of ... the allophone.
Yup, of course applies only in your test case (where you didn't load extra data into fifo during speech output). In reality, that case won't happen unless the speech software is crappy and causes buffer underruns (some SSA-1 programs actually do that since they check only SBY, others are better, and do check LRQ instead).

> What also need to be checked is what the SPO256 does when allophone
> are written when LDQn is high. Is the new one ignored or does it replace
> the one in the buffer?
Would be interesting to know. And should be easy to test, just write OY-OY-SH shortly after another, and hear what it says.