Amstrad SSA-1 Speech Synthesizer ROM needed

[gerald]

> one period is about 24.8us -> this is 40 steps -> 80 period of 3.12MHz
I think its 39 steps (+/-1 step, depending on when the next PWM packet starts). Uploaded an edited copy of your image here,
  http://cpcwiki.eu/index.php/SP0256_Measured_Timings
the additional blue digits (1..39) may be helpful to count the steps.
I've also added some notes any my interpretation (which is hopefully correct).

My brain was thinking 39, but my finger typed 40 

> The position of the next rising edge is also interesting : it can be on
> step earlier or one step after the one in 'idle' state.
Strange :-) really don't want to know why.

I've captured the begining of the "hello" of the SSAI software with the logic analyser (only about 10ms).
The PWM is indeed 7 bit when grouped by 4 consecutive pulses, which all last for 156 pulses of 1.56MHz.
So one 100us period is made of 4 part that can last 38 to 40 'step', one 38 will be compensated by a 40 within the same period.

Another new thing is that I let my sp0256 emu write the number of 10kHz samples per allophone to a log file (based on the pitch/repeat values in the ROM). Those "calculated" timings are also here:
  http://cpcwiki.eu/index.php/SP0256_Measured_Timings
they do match up perfectly with your measured values, except yours are slightly longer, probably caused by the chip executing "NOPs" in standby mode.

On the same capture, i can see that the sound only start after 4.5ms. On an other capture of the same 'hello', it start only after 6ms. The time is measured from the falling edge of LRQn (when allophone in process) to the 1st PWM sample that is not 17/39 (idle value).

I'll try to find a way of capturing the whole played allophone at digital out level.

[nocash]

> On the same capture, i can see that the sound only start after 4.5ms.
> On an other capture of the same 'hello', it start only after 6ms.
> The time is measured from the falling edge of LRQn (when allophone
> in process) to the 1st PWM sample that is not 17/39 (idle value).
Uh, when? Do you mean the delay occurs before the "H"? Or between "H-E-LL-O"?
I guess in standby mode (ie. before "H") the delay should range from 0 .. 6.4ms (if the most recently allophone was noise or pause; which have timing equal to pitch=64), or 0 .. 9.1ms (if recent allophone was a voiced sound with pitch=91). If data is send continously, without entering standby, then there are probably no delays between the allophones (ie. between H-E-LL-O).

> I'll try to find a way of capturing the whole played allophone at digital out level.
Yeah, could be useful. Though I am happy with what we already know.

NB. just noticed that somebody uploaded the old faulty recordings of AL2 allophones as WAV files to cpcwiki,
  http://cpcwiki.eu/index.php/File:Allophones.zip
Fortunately, markus said that he doesn't use such corrupted WAV files :-)

I've looked for some info on the TMPI (Techni-Musique) speech synthesizer with MEA8000 chip, and found two schematics for it, see:
  http://cpcwiki.eu/index.php/TMPI_speech_synthetizer
there seem to be two versions, one clocked at 4MHz, and the other clocked at... whatever frequency. I guess nobody here has the thing for real, and could check the text on the oscillator?

A funny detail is that both versions don't seem to decode A8..A15, so it conflicts with everything including the CPC's built-in I/O ports :-)

For the MEA8000 speech chip, I've found some useful figures with details on the filters and parameter translation, see the Datasheets section at,
  http://cpcwiki.eu/index.php/MEA8000
haven't yet extracted the important bits from that info. But it seems to cover most important details.

[Gryzor]

Hey guys,

Sorry for my disappearance... I see this is getting on fabulously! Still, I managed to unearth my unit yesterday (complete with speakers), and I'd be willing to sacrifice it if anyone wants to perform any voodoo on it...

[nocash]

Hi Gryzor,
> be glad to lend it or even donate it (if it should be vandalized) for the good of science!
can't promise that I'd do the vandalizing part :-) but if you want to get rid of it so much that you'd donate it without vandalizing then I'd take it gladly.

The thing that I'd like to look into would be making some hardware that emulates an external speech ROM, so one could execute custom program code on the speech chip, to see how the opcodes work (there are still 1-2 question marks in the opcode specs).

The only problem is that I am not sure if/how I can do it. Easiest would be to emulate the serial ROM on a PC, and output the data via printer port... but the I/O waitstates on PCs are so long that it'd be much too slow, so I'd probably need some other hardware.

---

For the MEA8000 thing... I've tried to compare the new jpg-figures with the mess emulators source code. And now I am totally confused :-) as on the SP0256, filters use latched old/older values, but, mess uses them somewhat like so:
  OLD*b_cos*c_exp,   OLDER*-2*c_exp
and the jpg/figure says something like so,
  OLD*-b_cos*c_exp,   OLDER*-b_cos*b_cos

[Gryzor]

Well, it's like this: I don't exactly want to throw it away or destroy it (I paid good money after all for it! ), BUT if there's something good to come out of it, then I'd give it up. If you do something with it in the end, you can keep it as a reward. If you don't manage, please let me have it back

But let's see if it's needed for the current project!

[arnoldemu]

Here you are :
The first capture show the whole sequence for the shortest pause.

The second capture detail the beginning of the sequence.


For the 'precise' timing please refer to the previous post

Interesting. thanks

Are these taken from the pins on the SPO itself?

Roland in Time expects the following sequence:
- LRQ = 0, SBY = 1
- write: LRQ = 1, SBY = 0
- waits 18microseconds and then reads port: LRQ = 1, SBY = 1
After this it has identified an ssa-1 and probably allows the allophone to complete and the final state:
is back to LRQ = 0, SBY = 1.

It sends allophone 0.

This seems to indicate that the allophone has been played before LRQ returns back to allowing a write?
Could there be a delay between the SPO and the actual values the CPC reads from the SSA I/O port (FBEE) to cause this?

[gerald]

Are these taken from the pins on the SPO itself?

Yes

Roland in Time expects the following sequence:
- LRQ = 0, SBY = 1
- write: LRQ = 1, SBY = 0
- waits 18microseconds and then reads port: LRQ = 1, SBY = 1

Are you sure of the last one (LRQ=1, SBY=1) ?
I would expect (LRQ=0, SBY=0)

After this it has identified an ssa-1 and probably allows the allophone to complete and the final state:
is back to LRQ = 0, SBY = 1.

It sends allophone 0.

This seems to indicate that the allophone has been played before LRQ returns back to allowing a write?
Could there be a delay between the SPO and the actual values the CPC reads from the SSA I/O port (FBEE) to cause this?

There is only a tristate buffer between the SPO output and the Z80 bus.
Here is the digital part of the SSA1 (I've been lasy finishing the analogue part )

[nocash]

Hi, I've finally figured out how the MEA speech chip works,
  http://cpcwiki.eu/index.php/MEA8000_I/O_Ports_and_Pinouts
  http://cpcwiki.eu/index.php/MEA8000_Voice_Generator
the nastiest part was that the "so-helpful-filter-figure" was total nonsense (the mess emulators source code was correct) the new corrected version of that figure with red ink is here:
  http://cpcwiki.eu/index.php/File:Mea8000_06.jpg
another nasty part is that the MEA timings are quite fragile. If data doesn't arrive continously, then it automatically enters standby/stop mode - and expects the next packet to be 5-bytes instead of 4-bytes.

Aside from that, the chip is pretty cool. The ability to program the voice generator directly by software makes it much more flexible than the SP0256, so it can produce different languages & intonations.

There are still dozens of unknown details,
  http://cpcwiki.eu/index.php/MEA8000_Unknown_Details
which would be nice to know. Anyways, the existing info is more or less enough to use or emulate it (the TMPI speech demonstration program works okay in my emu).

[nocash]

> Roland in Time expects the following sequence:
> LRQ = 0, SBY = 1
> write: LRQ = 1, SBY = 0
Good point. That games speech detection really relies on the presence of the short LRQ=1 pulse.

> waits 18microseconds and then reads port: LRQ = 1, SBY = 1
I'd say LRQ=0, SBY=0, too. Delay (after the OUT) seems to be circa 90 cycles / 22us, more or less what you said. But doesn't match up too good with gerald's measured timings :-) which were 15..41us or so.
Ie. 41us would be much too long and the detection would fail. Probably the HW does respond with short delays in this special situation - well, that's one of the things that I don't really want too understand :-)

> Here is the digital part of the SSA1
Nice schematic! The 7474 looks a bit useless in that place, but I guess they had a reason to place it there.
Just added a copy of the schematic on the SSA-1 page, I guess that's okay?
  http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer

[gerald]

I had a look at Roland in space and what I've found so far is :
- Version with infinite life I had does not have speech support 
- Version on tagrc, when written to a 3 1/2 disk does not work (read fail). DSK is OK on winape. I did not check further 
- I''ve finally found a working version, but I cannot remember where 

From the loader assembly code and my z80 datasheet, there is about 118 T cycles between the 1st OUT to the 2nd IN. That is 29.5 us, not counting the wait state inserted by the gate array.
With the logic analyser, I've measured 32.9us from the beginning of the OUT to the end of the IN, which is what the Z80 should see. The SP0256 datasheet specifies that LRQn timing to be from 16.67us to 33.3us.

I'd say LRQ=0, SBY=0, too. Delay (after the OUT) seems to be circa 90 cycles / 22us, more or less what you said. But doesn't match up too good with gerald's measured timings :-) which were 15..41us or so.
Ie. 41us would be much too long and the detection would fail.

I had a closer look at the data set I used for the table, and 41us is appearing only once in 715 samples. Next comes 32.2us. And 90% of the data are below 30.5.
So it is unlikely that the SSA1 is not detected.

Probably the HW does respond with short delays in this special situation - well, that's one of the things that I don't really want too understand :-)

With the datasheet information (16.67 to 33.3us) it likely that it the buffer transfer is done/checked every 26 1.56Mhz clock cycle.

> Here is the digital part of the SSA1
Nice schematic! The 7474 looks a bit useless in that place, but I guess they had a reason to place it there.
Just added a copy of the schematic on the SSA-1 page, I guess that's okay?
  http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer

Fine, I was just expecting that . I am just too shy/lazy to edit the wiki myself 
The 7474 is there to get a ALDn timing within specification (200ns to 960ns). The OUT access last 1.37us, wich is too long. The 7474 fix it to 500ns (2 clock cycles)

[Devilmarkus]

I had a look at Roland in space and what I've found so far is :
- Version with infinite life I had does not have speech support 
- Version on tagrc, when written to a 3 1/2 disk does not work (read fail). DSK is OK on winape. I did not check further 
- I''ve finally found a working version, but I cannot remember where 

Here it is...

I also add "sptest.dsk" it also contains Roland. (run"disc")
+ SSA1 Software (run"ssa1")
+ a test which speech is selected (dktronics/ssa1) (run"spetest")
   interesting for me is here: what does your oscilloscope tell you about LRQ and SBY while "spetest" speaks? Does it first speak and then return to basic or does it return to basic immideately and keeps speaking?

+ some bullshit 

[gerald]

Hi Markus

Your spetest returns to basic prompt after the speak.
This is because you are mainly testing the SBY bit  in line 80 :

Code Select Expand

80 if INP(&FBEE) < 64 then 80

It will still speak after return to basic prompt if you replace this test with a bit 6 low test (LRQn)

Code Select Expand

80 if (INP(&FBEE) and 64) = 64 then 80
However, you will gain only 145ms : the return to basic will happen 145ms before.

With the version that test the SBY bit,  the speak will be a slightly longer as the new allophone are send only when the previous one if fully finished. This is not a problem with a real SPO as the allophone trailing part plays in loop, but I am not sure that you emulate that feature.

This is visible in the trace below : the 1st is with LRQn test, the second with SBY test.


In the 1st test, you see that the SPO is never in standby, and the last allophone (P0) is written earlier relatively to the end of the speech.

[gerald]

Hi all SPO fan

Here are SPO0256-AL2 allophones in binary form. Each file contains one allophone, as sampled at the output of the chip (and some processing ). These samples are to be played at 10KHz to emulate a 3.12MHz clocked SPO256 like the SSA1.
The archive also contain a table which list the duration of each allophone as well as a 'blocking' time that have to be used to emulate the LRQn behaviour (see Readme.txt)

Enjoy

[Devilmarkus]

Hi all SPO fan

Here are SPO0256-AL2 allophones in binary form. Each file contains one allophone, as sampled at the output of the chip (and some processing ). These samples are to be played at 10KHz to emulate a 3.12MHz clocked SPO256 like the SSA1.
The archive also contain a table which list the duration of each allophone as well as a 'blocking' time that have to be used to emulate the LRQn behaviour (see Readme.txt)

Enjoy

Thanks a lot... I will have a look @ them and will try to code a playback routine. Maybe i can send them through digiblaster emulation

[Devilmarkus]

SSA1 - Speech test:
[cpc=http://cpcwiki.eu/forum/index.php?action=dlattach;topic=503.0;attach=404,DISC,1]SSA1[/cpc]

[Devilmarkus]

Here's a small BASIC program I found in a german CPC magazine (CPC International)

Code Select Expand

10 REM ****** The Speaking Clock *******
20 REM
30 REM ****** Assumes the SSA1 code has been loaded
40 REM
50 REM ****** Twelve hour cycle. Time spoken every
60 REM        five seconds
70 REM
75 ON ERROR GOTO 500
80 O$="o clock":P$="precisely":SEC$="second":SECS$=SEC$+"s"
90 A$="and"
100 MODE 1:|ECHO,1
110 HOURS=12
120 PRINT"`12 Hour Speaking Clock`":PRINT
130 INPUT"`Enter the time in HOURS,MINS`";HH,MM
140 IF HH>12 OR MM >60 THEN 130
150 S=0
160 MODE 0
170 PEN 3:PRINT"`The Speaking Clock`":PEN 1
180 |ECHO,0:GOSUB 270
190 EVERY 250 GOSUB 210
200 WHILE -1: WEND
210 REM ***** Update the time ************
220 SS=(SS+5) MOD 60
230 IF SS<>0 THEN 270
240 MM=(MM+1) MOD 60
250 IF MM<>0 THEN 270
260 HH=(HH+1) MOD HOURS
270 LOCATE 7,11
280 IF HH=0 THEN HH=HOURS
290 PRINT USING "##:##:##";HH;MM;SS
300 H$=STR$(HH):|SAY,@H$
310 IF MM = 0 THEN |SAY,O$:GOTO 330
320 m$=STR$(MM):|SAY,@M$
330 IF SS=0 THEN |SAY,@P$:RETURN
340 |SAY,@A$
350 S$=STR$(SS):|SAY,@S$
360 IF SS>1 THEN |SAY,@SECS$ ELSE |SAY,@SEC$
370 RETURN
500 PRINT:PRINT "The SSA1 software has not been loaded"
510 PRINT:END

It is a simple talking clock for the Amstrad SSA-1 speech synthesizer.
(Works well with my emulated SSA-1 and the speech software loaded)

[Gryzor]

Can it sit in the background and do its stuff while you do something else?

[arnoldemu]

Can it sit in the background and do its stuff while you do something else?

not with this program no. It requires you to enter the time.

A different one is needed.

[Devilmarkus]

Can it sit in the background and do its stuff while you do something else?

Well... as Kevin already mentioned: You would need a diferent program with interrupts to do that.
(binaries)

The speech itself buffers the output so it doesnt slow down your CPC.
(As Software speech does: Nothing other is possible while it speaks)

[LambdaMikel]

Roland in Time expects the following sequence: - LRQ = 0, SBY = 1 - write: LRQ = 1, SBY = 0 - waits 18microseconds and then reads port: LRQ = 1, SBY = 1 After this it has identified an ssa-1 and probably allows the allophone to complete and the final state: is back to LRQ = 0, SBY = 1.

This is kind of an old thread by now, not sure how much sense it makes to reply. I am working on a related problem,

http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/new-'next-generation-speech-synthesizer'-for-the-cpc-464/

and got to the point where SSA-1 driver software as well as Roland in Space "in game" speech is working ("Time for tea" etc.), but the title screen speech "Amsoft and ... produly presents" and "9 generations left" is not heard.

So I took my logic analyzer and measured Roland in Space. To me it seems that when title screen starts to speak, ~LRQ goes high for ~ 25 us, then goes low for ~1 ms, then stays high for allophones whith very short "dips" for loading allophones. SBY stays low after the first allophone, for all the time (constantly speaking).  I am attaching two screnshots.

Here, 1 = ~LRQ, 2 = SBY, 3 = ~ALD 

The timing for the first LRQ lengths are 25us, 1ms, 2.6 ms (the first pause?), 6.4 ms (another pause??), 82 ms (the A in "Amstrad" ? )


[attachimg=1][attachimg=2][attachimg=3][attachimg=4]

[gerald]

Did you had a look at the file attached to http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-ssa-1-speech-synthesizer-rom-needed/msg5056/#msg5056 ?
There is a small explanation on how SBY and LDQn works.

[LambdaMikel]

Hi gerald,
no I haven't, thanks!
So it seems that

Example 1: single allophone write t=0       : write /OY/ to SPO -> SBY goes low, LRQn goes high t=0+tLRQn : -> /OY/ get processed by SPO, input buffer is free, LRQn goes low t=2945+tLRQn : End of allophone -> SBY goes high

The tLRQn seems to be the 25 us then?
And I wasn't aware of the blocking delays... that might explain some of the discrepancies I am seeing w.r.t. to the allophone time table...

[LambdaMikel]

So, my hypothesis for Roland in Space title screen is:

It checks that ~LRQ = 0, SBY = 1, then writes a pause allophone, checks that ~LRQ = 1, SBY = 0, then waits for ~25 us, checks that ~LRQ = 0, SBY = 0.

At this point it knows that SSA-1 is present.

Then Roland in Space It waits for ~1 ms and writes out allophone bytes, starting with another pause (or even two pauses).

Do others agree / disagree with that?

[LambdaMikel]

Thanks guys,
SSA-1 emulation is working now:

Cheers
Michael

[LambdaMikel]

With regard to DK'tronics and supported games, the list
http://www.cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer
seems to be incomplete (I remember that also Amstrad Pool / Snooker had some speech),
but I can't really find any info on the Web. Does someone know of more games?

Would people consider DK'tronics mode useful (in addition to SSA-1 moe3 and native Emic 2 mode) for LambdaSpeak?