Who can dump/send me the Amstrad SSA-1 Speech Synthesizer rom? I really need it...
Do you mean the internal ROM on the SPO256AL2?
I am not sure. I need the rom like the existing DK'Tronics speech rom, which contains the RSX commands and port output routines
Here's how I emulate the DK'Tronics speech:
package jemu.system.cpc;
import jemu.ui.Talker;
/**
*
* @author Markus
*/
public class Speech {
static Talker talk;
static Thread Speech ;
protected static String[] Phoneme;
protected static int[] bytes;
public static String speechthis = "";
public static String Translate(String input){
String out="";
for(int i = 0; i < input.length(); i=i+6*3){
out+=input.charAt(i);
out+=input.charAt(i+1);
out+=input.charAt(i+2);
}
input = out;
String result="";
System.out.println("input:"+input);
int len = input.length()/3;
Phoneme = new String[len];
bytes = new int[len];
for (int i = 0; i < len; i++) {
String got = input;
Phoneme[i] = got.substring(0,2);
input = input.substring(3);
}
for (int i = 0; i < len; i++){
if (Phoneme[i].equals("00"))
Phoneme[i]="ignore";
else
if (Phoneme[i].equals("01"))
Phoneme[i]="10ms";
else
if (Phoneme[i].equals("02"))
Phoneme[i]="ignore";
else
if (Phoneme[i].equals("03"))
Phoneme[i]=" ";
else
if (Phoneme[i].equals("04"))
Phoneme[i]="50ms";
else
if (Phoneme[i].equals("18"))
Phoneme[i]="a";
else
if (Phoneme[i].equals("1C"))
Phoneme[i]="b";
else
if (Phoneme[i].equals("08"))
Phoneme[i]="c";
else
if (Phoneme[i].equals("15"))
Phoneme[i]="d";
else
if (Phoneme[i].equals("07"))
Phoneme[i]="e";
else
if (Phoneme[i].equals("28"))
Phoneme[i]="f";
else
if (Phoneme[i].equals("24"))
Phoneme[i]="g";
else
if (Phoneme[i].equals("1B"))
Phoneme[i]="h";
else
if (Phoneme[i].equals("0C"))
Phoneme[i]="i";
else
if (Phoneme[i].equals("0A"))
Phoneme[i]="j";
else
if (Phoneme[i].equals("2A"))
Phoneme[i]="k";
else
if (Phoneme[i].equals("2D"))
Phoneme[i]="l";
else
if (Phoneme[i].equals("10"))
Phoneme[i]="m";
else
if (Phoneme[i].equals("0B"))
Phoneme[i]="n";
else
if (Phoneme[i].equals("17"))
Phoneme[i]="o";
else
if (Phoneme[i].equals("09"))
Phoneme[i]="p";
else
if (Phoneme[i].equals("27"))
Phoneme[i]="r";
else
if (Phoneme[i].equals("37"))
Phoneme[i]="s";
else
if (Phoneme[i].equals("11"))
Phoneme[i]="t";
else
if (Phoneme[i].equals("0F"))
Phoneme[i]="u";
else
if (Phoneme[i].equals("23"))
Phoneme[i]="v";
else
if (Phoneme[i].equals("10"))
Phoneme[i]="m";
else
if (Phoneme[i].equals("2E"))
Phoneme[i]="w";
else
if (Phoneme[i].equals("31"))
Phoneme[i]="y";
else
if (Phoneme[i].equals("2B"))
Phoneme[i]="z";
else
if (Phoneme[i].equals("14"))
Phoneme[i]="aa";
else
if (Phoneme[i].equals("13"))
Phoneme[i]="ee";
else
if (Phoneme[i].equals("06"))
Phoneme[i]="ii";
else
if (Phoneme[i].equals("35"))
Phoneme[i]="oo";
else
if (Phoneme[i].equals("3F"))
Phoneme[i]="bb";
else
if (Phoneme[i].equals("21"))
Phoneme[i]="dd";
else
if (Phoneme[i].equals("3D"))
Phoneme[i]="gg";
else
if (Phoneme[i].equals("22"))
Phoneme[i]="ggg";
else
if (Phoneme[i].equals("39"))
Phoneme[i]="hh";
else
if (Phoneme[i].equals("3E"))
Phoneme[i]="ii";
else
if (Phoneme[i].equals("38"))
Phoneme[i]="nn";
else
if (Phoneme[i].equals("0E"))
Phoneme[i]="rr";
else
if (Phoneme[i].equals("0D"))
Phoneme[i]="tt";
else
if (Phoneme[i].equals("19"))
Phoneme[i]="yy";
else
if (Phoneme[i].equals("3B"))
Phoneme[i]="ar";
else
if (Phoneme[i].equals("2F"))
Phoneme[i]="aer";
else
if (Phoneme[i].equals("32"))
Phoneme[i]="ch";
else
if (Phoneme[i].equals("29"))
Phoneme[i]="ck";
else
if (Phoneme[i].equals("3C"))
Phoneme[i]="ear";
else
if (Phoneme[i].equals("1A"))
Phoneme[i]="eh";
else
if (Phoneme[i].equals("33"))
Phoneme[i]="er";
else
if (Phoneme[i].equals("34"))
Phoneme[i]="err";
else
if (Phoneme[i].equals("2C"))
Phoneme[i]="ng";
else
if (Phoneme[i].equals("3A"))
Phoneme[i]="or";
else
if (Phoneme[i].equals("16"))
Phoneme[i]="ou";
else
if (Phoneme[i].equals("1F"))
Phoneme[i]="ouu";
else
if (Phoneme[i].equals("20"))
Phoneme[i]="ow";
else
if (Phoneme[i].equals("05"))
Phoneme[i]="oy";
else
if (Phoneme[i].equals("25"))
Phoneme[i]="sh";
else
if (Phoneme[i].equals("1D"))
Phoneme[i]="th";
else
if (Phoneme[i].equals("12"))
Phoneme[i]="dth";
else
if (Phoneme[i].equals("1E"))
Phoneme[i]="uh";
else
if (Phoneme[i].equals("30"))
Phoneme[i]="wh";
else
if (Phoneme[i].equals("21"))
Phoneme[i]="zh";
else{
System.err.println("Unknown speech command " + Phoneme[i]);
Phoneme[i]="ignore";}
}
speechthis = "";
out="";
for (int i = 0; i < len; i++)
if (!Phoneme[i].equals("ignore"))
out+=Phoneme[i]+"|";
say (out);
return result;
}
/*ALLOPHONE DECIMAL HEX ALLOPHONE DECIMAL HEX
a 24 18 (aa) or (ay) 20 14
b 28 1c (ee) 19 13
c 8 08 (ii) 6 06
d 21 15 (oo) or (eau) 53 35
e 7 07 (bb) 63 3f
f 40 28 (dd) 33 21
g 36 24 (gg) 61 3d
h 27 1b (ggg) 34 22
i 12 0c (hh) 57 39
j 10 0a (ii) 62 3e
k 42 2a (nn) 56 38
l 45 2d (rr) 14 0e
m 16 10 (tt) 13 0d
n 11 0b (yy) 25 19
o 23 17 (ar) 59 3b
p 9 9 (aer) 47 2f
r 39 27 (ch) 50 32
s 55 37 (ck) 41 29
t 17 11 (ear) 60 3c
u 15 0f (eh) 26 1a
v 35 23 (er) 51 33
w 46 2e (err) 52 34
y 49 31 (ng) 44 2c
z 43 2b (or) 58 3a
(space) 1 01 (ou) 22 16
(space) 3 03 (ouu) 31 1f
(space) 4 04 (ow) 32 20
(oy) 5 05
(sh) 37 25
(th) 29 1d
(dth) 18 12
(uh) 30 1e
(wh) 48 30
(zh) 33 21
*/
public static void say(final String out){
System.out.println("Saying:" + out);
Speech = new Thread() {
public void run() {
talk=new Talker();
talk.sayPhoneWord(out);
}};
Speech.start();
}
}
Example:
|SAY,"hello world"
sends:
input:1B 07 2D 35 01 2E 3A 2D 15 00
to port &fbfe
I translate it to:
Saying:h|e|l|oo|10ms|w|or|l|d|
For this I use a simple java speech synthesizer, which is sample based. (1 .AU audiofile for each phoneme)
The Amstrad SSA-1 Synthesizer should work in a similar way only that the port is &fbee here.
Of course, PITCH settings or other speech manipulating commands are not possible here, but it produces a simple speech output.
http://cpc-live.com/speechtest
Quote from: Devilmarkus on 01:41, 05 January 10
I am not sure. I need the rom like the existing DK'Tronics speech rom, which contains the RSX commands and port output routines
Oh, I don't have that, didn't even know it existed. I'm pretty sure my SSA-1 didn't have a ROM in it.
Quote from: Devilmarkus on 01:41, 05 January 10
Here's how I emulate the DK'Tronics speech:
I thought you might be emulating the SPO256 using sound snips, but that doesn't allow for changes in pitch etc either. The only way to do it properly is to emulate the chip which is quite difficult and processor intensive.
It should NOT be much more processor intensive than emulating the 3-channel PSG. It's a bit difficult though. Btw. I've just added some fairly complete SP0256 specs to the SSA-1 and Dk'tronics speech cpcwiki pages.
Properly emulating it is still impossible because the clock frequency used in the CPC interfaces is still unknown. Does somebody know more on that subject?
The SSA-1 seems to use a fixed clock frequency. Maybe the recommended 3.12MHz.
The Dk'tronics speech interface seems to allow to adjust the clock frequency (with the |SPED command), allowing to change the intonation. So this one is much more difficult, there must be an additional some I/O port (or additional bits in the known I/O port), and there seems to be no info on the selectable frequency range.
Judging from SSA-1 cpcwiki page, the RSX commands were included on cassette, not on ROM. No idea where to get the cassette from. Anyways, the games that do support it don't need the RSX commands and access the I/O port directly.
Btw. does somebody have RSX driver disk for the Dk'tronics speech interface? For this one, a ROM does actually exist (at ftp://ftp.nvg.ntnu.no/pub/cpc/emulator/rom/), but there should be also a RSX driver disk for the ROM-less version of that interface.
The disk version would be a bit easier to use, to figure out how the |SPED command works. The only known Dk'tronic speech game (Jumpjet) doesn't seem to use the SPED feature, so one could only rev-engineer the RSX driver.
Here it is: http://share.cpcwiki.eu/931240
Well, it's not the ROM version. I've uploaded the *.cdt image including the manual.
According to the wiki the device was available on tape only!
Quote from: nocash on 05:06, 05 January 10Btw. does somebody have RSX driver disk for the Dk'tronics speech interface? For this one, a ROM does actually exist (at ftp://ftp.nvg.ntnu.no/pub/cpc/emulator/rom/), but there should be also a RSX driver disk for the ROM-less version of that interface.
Here we go: http://share.cpcwiki.eu/317082
Excellent work Markus, I compared it to my real DKTronics Speech Synthesiser with the same sentences and it was spot on. I have the ROM based CPC464 version here and the original documentation, so let me know if there's any hardware or other info you need and I can pass it on to you.
Bryce.
Thanks... The CDT files for the Amstrad SSA-1 I know and already have.
I suggested that there would also exist a ROM file...
@ Bryce:
I am wondering that JavaCPC sounds so real.
It's a very basic Speech synthesizer which I found in web.
I only read out the port &FBFE and convert the bytes to phonemes.
These phonemes are set together to a phoneme string, which is send over the Speech synth.
No chip is emulated!
I know, that Kevin is working on this, too, and maybe he can emulate the chip, too...
To the users from DK'Tronics AND!!! Amstrad SSA-1:
Please do this from BASIC:
PRINT INP(&FBFE) -> DK'Tronics
PRINT INP(&FBEE) -> Amstrad SSA-1
I need booth return values (defaut is &FF when no speech device is connected, DK'Tronics should return &00 I think)
Well, if need be, I can send my SSA set. I can't dump it myself, but I'd be glad to lend it or even donate it (if it should be vandalized) for the good of science!
Please do this from BASIC when SSA-1 is connected:
PRINT INP(&FBEE)
Also do this while speaking...
I need the returned port value
Thank you.
> PRINT INP(&FBEE)
The I/O Ports are described in Appendix B and C of the SSA-1 manual.
The only thing that is unknown about the SSA-1 is the clock frequency.
Can somebody open it and check if it has a 3.12MHz oscillator, or something else?
Btw. does somebody know anything about the "MHT Speech Synthesizer"?
Does it exist? Does it use a SP0256, too? At what I/O ports? Is there any software for it? Etc.
Quote from: nocash on 15:23, 05 January 10
Can somebody open it and check if it has a 3.12MHz oscillator, or something else?
I found this (not that good) picture of the SSA-1 board if it can help somehow:
(http://cpcrulez.fr/im3/Amstrad_SSA1_4.jpg)
The question is: Do we really need a ROM?
When I have speech feature enabled, I can also enter this small listing in BASIC:
10 CLS
20 READ a$
30 IF a$="xx" THEN END
40 OUT &FBFE,VAL("&"+a$)
50 GOTO 20
60 DATA 00,00,01,21,13,01,01,02,2A,14,01
70 DATA 01,02,0D,27,18,0B,0C,08,37,01,01
80 DATA 37,09,13,32,01,01,37,31,0B,1D,07
90 DATA 37,06,2B,34,00,xx
This proggy says "DK'Tronics speech synthesizer" also when I have no Speech-rom set.
(For Amstrad SSA-1 you should change port number &FBFE in line 40 to &FBEE)
I don't know, if this would work with real hardware, too...
Maybe someone can test this?
I looked at appendix B but I don't understand these things :(
For that more emulation is needed, but I want to keep it simple.
I need to know the real value which is returned from port &FBEE...
SSA-1 reads booth ports:
FBFE and FFEE!
So I need booth values.
Hi Markus,
just pulled my DKTronics speech Synthesiser out from under the pile of CPC stuff, dusted it off and tried the Print INP(&FBFE) command... It returns the value 127. Hope this helps you further.
Bryce.
Yeah... This is the same than Amstrad SSI-1 does.
But:
SSI-1 changes port value to 0 in most cases when speech is spoken.
I don't know exactly yet how this works...
Please check the DK'Tronics, too, if it returns 0, while talking...
Here's a first SSA-1 test: http://cpc.devilmarkus.de/ssa1test
The Soccer game works well... also 3d Stuntrider.
I can also init speech,
but I cannot use |SAY command and also "Roland in space" still denies speech... :(
Funny to hear the good adaption...
http://www.youtube.com/watch?v=v8WKbKK3Apg captured from original SSA-1
> I found this (not that good) picture of the SSA-1 board
Yeah, I know that image. The orange thing in the middle looks like an oscillator. But the resolution of the picture is too bad to read the part number printed on it.
Can somebody make a better photo?
> just pulled my DKTronics speech Synthesiser out from
> under the pile of CPC stuff, dusted it off
Photo of it's mainboard would be nice, too! Do you have a camera?
> dusted it off and tried the Print INP(&FBFE) command...
> It returns the value 127
No surprise so far. It would be interesting to see what happens when it is busy. Can you enter this line:
OUT &FBFE,&04:PRINT INP (&FBFE)
that should a long output "OY" sound, and bit7 should get set... and maybe other bits change, too. So it may return 255... or something else.
> The question is: Do we really need a ROM?
No.
> 20 READ a$
> 30 IF a$="xx" THEN END
> 40 OUT &FBFE,VAL("&"+a$)
> 50 GOTO 20
You need to add a wait for stat bit7=0 in line 35:
35 IF ((INP &FBFE) AND &80)>0 THEN 35
That bit is probably the /LRQ signal... or maybe the inverted SBY signal.
Not sure if the Dk'tronics outputs both /LRQ and SBY signals?
> I looked at appendix B but I don't understand these things
How is that possible? Where's the problem? Bit7 means 128, Bit6 means 64 - in case you haven't read your binary numbers tutorial recently.
As explained in Appendix C, with "/LOAD" they mean the /LRQ pin (Load Request), and with "/BUSY" they mean the SBY pin (Standby).
/LRQ=0 means it is ready to receive data (and may - or may not - be speeking)
SBY=1 means it is ready to receive data (and that is NOT speeking)
> SSA-1 reads booth ports:
> FBFE and FFEE!
Huh? What are you talking about here? I thought the SSA-1 is the hardware? If you are still talking of the status registers: The SSA-1 output status info on Port FBEE. I am sure it doesn't READ status info. And as far as I know it doesn't use Ports FBFE nor FFEE, only FBEE.
> SSI-1 changes port value to 0 in most cases when speech is spoken.
Really? Since bit0-5 are unused, I'd think that they are always high-z. And only bit7 and bit6 can go zero.
Hi all,
I can tell you what happens on a real DKTronics....
While it's speaking &FBFE is toggling between 255 and 127 (127 seems to be each time a pause is between letters)
And according to the SPO256 datasheet, the chip won't run with anything other than a 3.12MHz crystal, it's osc1 and osc2 inputs aren't configurable that you could control them any other way. Unless they used some old Gem such as Stateks PXO Series (a crystal in a chip which as far as I can remember could be varied to 64 different frequencies using a 6bit parallel input port and even be switched on and off) there will have to be a crystal in the box.
Bryce.
Quote from: Bryce on 19:55, 05 January 10
Hi Markus,
just pulled my DKTronics speech Synthesiser out from under the pile of CPC stuff, dusted it off and tried the Print INP(&FBFE) command... It returns the value 127. Hope this helps you further.
Bryce.
Well, just dug up a old DKTronics cart too (alas no speakers or software so i got it nearly for free). According to the manual its a Edition 2. Opening up the cart it also says v2 on the mobo. I dont think there is any "rom-software" on the mobo as there is pretty much only the SPO256A-AL2 chip. Manual also confirms that all commands need to be loaded from tape to be able to use them. The cart casing says "dk´tronics" on top.
Using the Print INP(&FBFE) i get 127 just like Bryce :)
Using the OUT &FBFE,&04:PRINT INP (&FBFE) i get 127 again (didnt hear a "OY" sound tho?).
A bit off track: i recall seeing a different dktronics speech cart that said "dk'tronics speech rom" on top. So perhaps there are several versions, with and without rom software?
Even more off track: I recall the free speech software on with AA issue 103 (tape 37) uses the |say command but cant find this in the Dk´tronics manual.
OUT &FBFE,&04 causes a pause... So you can't hear it.
try OUT &FBFE,&05 instead ("OY")
> Using the OUT &FBFE,&04:PRINT INP (&FBFE) i get 127 again
> (didnt hear a "OY" sound tho?).
Maybe... didn't you mention you had no speakers? :-)
The status should toggle though, or did I make a mistake in the example?
> i recall seeing a different dktronics speech cart that said
> "dk'tronics speech rom" on top. So perhaps there are several
> versions, with and without rom software?
Yes, yes, that's already described in the article,
http://cpcwiki.eu/index.php/Dk'tronics_Speech_Synthesizer
> While it's speaking &FBFE is toggling between 255 and 127
Good to know, then the Dk'tronics version seems to have only one status bit. Probably /LRQ, since the other one, SBY is less useful.
> according to the SPO256 datasheet, the chip won't run with anything
> other than a 3.12MHz crystal
Yeah, that's the "official" recommended value. But I guess one could overclock or underclock it a little.
Some of the SP0256 interfaces for the ZX Spectrum have an "intonation" feature. I think nobody actually knows yet how that feature works. The SP0256 chip itself doesn't seem to have that feature built-in; at least neither the datasheet nor the people who rev-engineered the sp0265 opcodes do mention such a feature.
So, I could imagine only two ways how to change the intonation: Externally modify the clock input, or pass the sound output through an external low-pass/high-pass filter. And since the Dk'tronics has the "|SPED" command to change the "speed", I thought that it supports variable clock input?
To know that things, it'd be great if somebody could add a picture of the Dk'tronics mainboard here,
http://cpcwiki.eu/index.php/Dk'tronics_Speech_Synthesizer
And a better resolution picture of the SSA-1 mainboard here,
http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer
The DK'Tronics speech works fine now...
Also games like "Jump Jet" from Anirog Software give out speech now.
The SSA-1 Seems to be a bit harder!
I added 3 different Port states but it still denies it's work sometimes...
(The 4th port state 0xC0 is useless: It denies writing and is not playing, this makes no sense)
You can hear SSA-1 in games like "3d Stuntrider" or "Glen Hoddle Soccer".
You can also hear the SSA-1 software starting up...
But basic interpreter input it still denies :( (Or is there a trick?)
Also the game "Roland in Space" (Which also checks DK'Tronics port) still denies it's speech output :(
Please don't forget: it's a VERY simple emulation
Here you can see the available options:
> The DK'Tronics speech works fine now...
> Also games like "Jump Jet" from Anirog Software give out speech now.
Oops, that means that there are more than one game supporting the Dk'tronics hardware?
I've disassembled the |SPED command, I should probably have done that yesterday. It doesn't seem to use any hardware I/O (so apparently there's no variable clock, and it probably really uses a 3.12MHz oscillator?).
Instead, the |SPED,n command causes a simple software delay (of n/50 seconds) between each allophone. So the speech chip should repeat the end of the last allophone, ie. "OY" would be become "OYYYYYYY" when using a large delay value.
Not to sure what that feature is good for.
Anyways, as far as I understand, the software seems to be intended to add that delay at the END of the last allophone. Which means that, in order to determine to END of it, it would need to read SBY.
If that's true, and if there's really only one status bit supported by the Dk'tronics, then it seems as if it doesn't support the /LRQ signal.
Strange, the /LRQ seems to be the more important bit to me, as it allows to send new data while the chip still processes the old allophone, and so, to avoid unwanted delays between the separate allophones. But, now it seems as if Dk'tronics WANTED to have delays between them.
Here's a quote of the french cpcrulez.forum:
Quotebon alors la liste des jeux utilisant le SSA-1 et son port &FBEE (01 ee fb ed 78)
3D BOXING
3D STUNT RIDER
ALEX HIGGIN'S WORLD POOL
ALEX HIGGIN'S WORLD SNOOKER
DRAGON GOLD
ROLAND IN SPACE
GLEN HODDLE SOCCER
TUBARUBA
GREMLINS
SEABLOOD
ROBIN OF SHERWOOD
DARKWURLDE
Original thread: http://cpcrulez.fr/forum/viewtopic.php?f=5&t=3810
Sad: The adventure games like "Gremlins" do not react to port &FBEE - Is it for sure, this game provides SSA-1 speech output? If yes, do I need to enable it with a command?
No port reaction in JavaCPC here....
Maybe also some memory addresses are different when the SSA-1 rom is connected? Or maybe it has a ROM inside?
>> are more than one game supporting the Dk'tronics hardware?
> Here's a quote of the french cpcrulez.forum:
> bon alors la liste des jeux utilisant le SSA-1 et son port &FBEE
Even with my VERY limited french skills, I can tell that that is NOT about Dk'tronics.
And aside, the list is incorrect.
Dragon Gold doesn't seem to use an speech at all. Unless there are different versions of that game, one with, another without speech.
Gremlins, Seablood, Robon of Sherwood are using Port FBEC,FBEE,FBEF for network transmission or so, not for speech.
The correct list of (known) SSA-1 games is here,
http://cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer
And for Dk'tronics, it seems that only the Jumpjet game exists?
Example for "Tubaruba":
When you start or loose a live, it sends these phonemes:
input:0C,
Saying:|IH|
input:0B,
Saying:|NN1|
input:0D,
Saying:|TT2|
input:27,
Saying:|RR2|
input:1F,
Saying:|UW2|
input:21,
Saying:|DD2|
input:33,
Saying:|ER1|
input:18,
Saying:|AA|
input:2D,
Saying:|LL|
input:34,
Saying:|ER2|
input:11,
Saying:|TT1|
input:02,
Saying:|50ms|
(I don't understand this :D But should mean "Intruder alert" )
When you have died, it plays this sequence:
input:09,
Saying:|PP|
input:0E,
Saying:|RR1|
input:07,
Saying:|EH|
input:09,
Saying:|PP|
input:2F,
Saying:|XR|
input:03,
Saying:|100ms|
input:0D,
Saying:|TT2|
input:16,
Saying:|UW1|
input:03,
Saying:|100ms|
input:21,
Saying:|DD2|
input:06,
Saying:|AY|
input:02,
Saying:|50ms|
This means "Prepare to die"
Watch a little video here: http://cpc.devilmarkus.de/tubaruba
Morning,
my interface is the DKTronics ROM version, I'll open it up an take a few hi-res photos of it tonight for the wiki page. If I have time, I might even scribble down the circuit diagram (if it's not too much work).
Bryce.
Now I put some photos I make this morning of the 2 models I have :
http://cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer
Well that's saved me the bother, the ROM version seems to be more or less identical to mine. And by the way, you don't need to cover the EPROM when taking a picture with the flash, the light produced by the flash definitely hasn't enough UV to have any effect on its content. Or was it just reflecting the light too much?
Bryce.
Does somebody also have the user's guide or a service manual for the DK'Tronics?
Would be cool to scan it and to upload it, too...
Here I played around with the RSX command from DK'Tronics rom:
http://cpc.devilmarkus.de/dktronics/
Yeah, I have. I'll see if I can upload it later.
Bryce.
> Now I put some photos I make this morning of the 2 models I have
Great, thanks!
Confirms that it has the -AL2 version of the SP0256 chip.
And, look, it doesn't have a 3.12MHz oscillator. In fact, there's no oscillator at all.
Very important to know that detail. So I'd guess it's driven by the 4MHz signal on the expansion port (?) The picture resolution is too low (and the romless-board too dirty) to say that for sure.
> take a few hi-res photos of it tonight for the wiki page.
> If I have time, I might even scribble down the circuit diagram
Would be cool!
On the SP0256 chip, it'd be interesting where the two OSC pins are connected to.
The other two important pins on that chip would be SBY and /LRQ. Looking at the rom-less photos, I'd say it's safe to say that SBY (Pin8) is not connected, so only /LRQ seems to be supported.
On the expansion port side, it would be interesting which address lines are decoded, ie. to figure out if Port FBFE is mirrored to other addresses, just for curiosity, not soo important.
http://cpc-live.com/webcpc/speech.html
Feel free to play around with it :D
(DK'Tronics emulation)
2 games online which support speech:
- Jump Jet: (DK'Tronics)
http://cpc-power.com/index.php?page=detail&onglet=jeuenligne&num=1224
- Tubaruba (Amstrad SSA-1)
http://cpc-power.com/index.php?page=detail&onglet=jeuenligne&num=2308
You must login to be able to play...
Another small test program:
10 synth=0:IF INP(&FBFE)<>127 THEN synth=1
20 RESTORE 160:GOSUB 50
30 IF dk=1 THEN PRINT"Spoken with DK'Tronics speech":END ELSE PRINT"Spoken with Amstrad SSA-1 speech":END
40 '
50 READ a:WHILE a<>999
60 IF synth<>1 THEN 90
70 IF INP(&FBEE)<64 THEN 70:'ssa1 speech
80 GOTO 100
90 :'dktronic speech
100 IF synth<>1 THEN 130
110 OUT &FBEE,a:dk=0:'ssa1 speech
120 GOTO 140
130 OUT &FBFE,a:dk=1:'dktronic speech
140 READ a:WEND:RETURN
150 '
160 DATA 6,3,26,16,3,26,11,3,26,16,55,17,39,26,21,3,42,23,16,9,49,31,17,51,0,999
200 DATA 55,55,3,17,24,24,3,9,0,999
Taken from amstradeus.com and modified slightly to detect speech
Maybe it would help me when I knew, what is done in this piece of disassembly from "Roland in Space":
ld A,(HL) ;1038: ~ 7E
ld BC,&FBEE ;1039: ... 01 EE FB
out (C),A ;103C: .y ED 79
or A ;103E: . B7
ret Z ;103F: . C8
in A,(C) ;1040: .x ED 78
bit 6,A ;1042: .w CB 77
jr NZ,&1040 ;1044: . 20 FA
inc HL ;1046: # 23
jr &1038 ;1047: .. 18 EF
ld HL,&004A ;1049: !J. 21 4A 00
ld (&1C79),HL ;104C: "y. 22 79 1C
ld (&1C75),HL ;104F: "u. 22 75 1C
ex DE,HL ;1052: . EB
ld HL,&0067 ;1053: !g. 21 67 00
ld (&1C7B),HL ;1056: "{. 22 7B 1C
ld (&1C77),HL ;1059: "w. 22 77 1C
call &BC1D ;105C: ... CD 1D BC
ld (&1C7F),HL ;105F: ".. 22 7F 1C
ld HL,&1DBB ;1062: !.. 21 BB 1D
ld (&1C7D),HL ;1065: "}. 22 7D 1C
ld A,&4C ;1068: >L 3E 4C
ld (&1C73),A ;106A: 2s. 32 73 1C
ld (&1C74),A ;106D: 2t. 32 74 1C
xor A ;1070: . AF
ld (&1CD2),A ;1071: 2.. 32 D2 1C
jp &1808 ;1074: ... C3 08 18
ld DE,(&1C75) ;1077: .[u. ED 5B 75 1C
ld HL,(&1C77) ;107B: *w. 2A 77 1C
call &BC1D ;107E: ... CD 1D BC
ld (&1C81),HL ;1081: ".. 22 81 1C
ld DE,(&1C79) ;1084: .[y. ED 5B 79 1C
ld HL,(&1C7B) ;1088: *{. 2A 7B 1C
call &BC1D ;108B: ... CD 1D BC
ld (&1C7F),HL ;108E: ".. 22 7F 1C
ld HL,(&1C79) ;1091: *y. 2A 79 1C
ld BC,(&1C75) ;1094: .Ku. ED 4B 75 1C
xor A ;1098: . AF
sbc HL,BC ;1099: .B ED 42
jr NZ,&10A8 ;109B: . 20 0B
ld A,(&1CD2) ;109D: :.. 3A D2 1C
or A ;10A0: . B7
jr NZ,&10A8 ;10A1: . 20 05
ld A,&53 ;10A3: >S 3E 53
ld (&1C74),A ;10A5: 2t. 32 74 1C
ld HL,(&1C81) ;10A8: *.. 2A 81 1C
ld DE,&1C83 ;10AB: ... 11 83 1C
ld B,&10 ;10AE: .. 06 10
call &18A8 ;10B0: ... CD A8 18
push BC ;10B3: . C5
push HL ;10B4: . E5
ld B,&04 ;10B5: .. 06 04
ld A,(DE) ;10B7: . 1A
ld (HL),A ;10B8: w 77
inc HL ;10B9: # 23
inc DE ;10BA: . 13
call &189C ;10BB: ... CD 9C 18
djnz &10B7 ;10BE: .. 10 F7
pop HL ;10C0: . E1
ld A,&08 ;10C1: >. 3E 08
add H ;10C3: . 84
ld H,A ;10C4: g 67
jr NC,&10CF ;10C5: 0. 30 08
ld BC,&C050 ;10C7: .P. 01 50 C0
add HL,BC ;10CA: . 09
ld A,&C7 ;10CB: >. 3E C7
and H ;10CD: . A4
ld H,A ;10CE: g 67
pop BC ;10CF: . C1
djnz &10B3 ;10D0: .. 10 E1
ld A,(&1C61) ;10D2: :a. 3A 61 1C
or A ;10D5: . B7
jr Z,&10E8 ;10D6: (. 28 10
ld DE,(&1C62) ;10D8: .[b. ED 5B 62 1C
ld HL,(&1C60) ;10DC: *`. 2A 60 1C
call &06E6 ;10DF: ... CD E6 06
ld HL,&0000 ;10E2: !.. 21 00 00
ld (&1C60),HL ;10E5: "`. 22 60 1C
ld HL,(&1C7F) ;10E8: *.. 2A 7F 1C
ld DE,(&1C7D) ;10EB: .[}. ED 5B 7D 1C
ld IX,&1C83 ;10EF: .!.. DD 21 83 1C
ld B,&10 ;10F3: .. 06 10
push BC ;10F5: . C5
push HL ;10F6: . E5
ld B,&04 ;10F7: .. 06 04
ld A,(HL) ;10F9: ~ 7E
ld (IX+&00),A ;10FA: .w. DD 77 00
and &AA ;10FD: .. E6 AA
ld C,A ;10FF: O 4F
cp &80 ;1100: .. FE 80
jr Z,&110E ;1102: (. 28 0A
cp &A0 ;1104: .. FE A0
jr Z,&110E ;1106: (. 28 06
ld A,(DE) ;1108: . 1A
and &AA ;1109: .. E6 AA
jr Z,&110E ;110B: (. 28 01
ld C,A ;110D: O 4F
ld A,(HL) ;110E: ~ 7E
and &55 ;110F: .U E6 55
cp &40 ;1111: .@ FE 40
jr Z,&1121 ;1113: (. 28 0C
cp &50 ;1115: .P FE 50
jr Z,&1121 ;1117: (. 28 08
ld A,(DE) ;1119: . 1A
and &55 ;111A: .U E6 55
jr NZ,&1121 ;111C: . 20 03
ld A,(HL) ;111E: ~ 7E
and &55 ;111F: .U E6 55
or C ;1121: . B1
ld (HL),A ;1122: w 77
inc DE ;1123: . 13
inc HL ;1124: # 23
inc IX ;1125: .# DD 23
call &189C ;1127: ... CD 9C 18
djnz &10F9 ;112A: .. 10 CD
pop HL ;112C: . E1
ld A,&08 ;112D: >. 3E 08
add H ;112F: . 84
ld H,A ;1130: g 67
jr NC,&113B ;1131: 0. 30 08
ld BC,&C050 ;1133: .P. 01 50 C0
add HL,BC ;1136: . 09
ld A,&C7 ;1137: >. 3E C7
and H ;1139: . A4
ld H,A ;113A: g 67
pop BC ;113B: . C1
djnz &10F5 ;113C: .. 10 B7
ld HL,(&1C79) ;113E: *y. 2A 79 1C
ld (&1C75),HL ;1141: "u. 22 75 1C
ld HL,(&1C7B) ;1144: *{. 2A 7B 1C
ld (&1C77),HL ;1147: "w. 22 77 1C
ret ;114A: . C9
ld DE,&8DB1 ;114B: ... 11 B1 8D
ld BC,&0009 ;114E: ... 01 09 00
ldir ;1151: .. ED B0
ld HL,&8DB1 ;1153: !.. 21 B1 8D
jp &BCAA ;1156: ... C3 AA BC
ld A,&12 ;1159: >. 3E 12
call &BB1E ;115B: ... CD 1E BB
jr NZ,&1165 ;115E: . 20 05
xor A ;1160: . AF
ld (&1FBC),A ;1161: 2.. 32 BC 1F
ret ;1164: . C9
ld A,(&1FBC) ;1165: :.. 3A BC 1F
or A ;1168: . B7
ret NZ ;1169: . C0
inc A ;116A: < 3C
ld (&1FBC),A ;116B: 2.. 32 BC 1F
ld A,(&1FBD) ;116E: :.. 3A BD 1F
xor &01 ;1171: .. EE 01
ld (&1FBD),A ;1173: 2.. 32 BD 1F
jp Z,&BCA7 ;1176: ... CA A7 BC
jp &1699 ;1179: ... C3 99 16
ld A,L ;117C: } 7D
or A ;117D: . B7
ret NZ ;117E: . C0
ld A,H ;117F: | 7C
and &07 ;1180: .. E6 07
ret NZ ;1182: . C0
ld A,H ;1183: | 7C
sub &08 ;1184: .. D6 08
ld H,A ;1186: g 67
ret ;1187: . C9
push AF ;1188: . F5
push DE ;1189: . D5
push HL ;118A: . E5
call &BD0D ;118B: ... CD 0D BD
ld A,&04 ;118E: >. 3E 04
cp L ;1190: . BD
jr NZ,&118B ;1191: . 20 F8
call &BD0D ;1193: ... CD 0D BD
ld A,&05 ;1196: >. 3E 05
cp L ;1198: . BD
jr NZ,&1193 ;1199: . 20 F8
pop HL ;119B: . E1
pop DE ;119C: . D1
pop AF ;119D: . F1
ret ;119E: . C9
push AF ;119F: . F5
push BC ;11A0: . C5
push DE ;11A1: . D5
push HL ;11A2: . E5
ld DE,&0000 ;11A3: ... 11 00 00
ld HL,&0000 ;11A6: !.. 21 00 00
call &BD10 ;11A9: ... CD 10 BD
ld HL,(&1DAF) ;11AC: *.. 2A AF 1D
ld A,H ;11AF: | 7C
or A ;11B0: . B7
jr Z,&11C7 ;11B1: (. 28 14
ld BC,&FBEE ;11B3: ... 01 EE FB
in A,(C) ;11B6: .x ED 78
bit 6,A ;11B8: .w CB 77
jr NZ,&11C7 ;11BA: . 20 0B
ld A,(HL) ;11BC: ~ 7E
out (C),A ;11BD: .y ED 79
or A ;11BF: . B7
inc HL ;11C0: # 23
jr NZ,&11C4 ;11C1: . 20 01
ld H,A ;11C3: g 67
ld (&1DAF),HL ;11C4: ".. 22 AF 1D
pop HL ;11C7: . E1
pop DE ;11C8: . D1
pop BC ;11C9: . C1
pop AF ;11CA: . F1
ret ;11CB: . C9
nop ;11CC: . 00
dec C ;11CD: . 0D
dec C ;11CE: . 0D
nop ;11CF: . 00
nop ;11D0: . 00
ld B,&06 ;11D1: .. 06 06
ex AF,AF' ;11D3: . 08
ex AF,AF' ;11D4: . 08
inc D ;11D5: . 14
inc D ;11D6: . 14
jr &11F1 ;11D7: .. 18 18
ld A,(DE) ;11D9: . 1A
ld A,(DE) ;11DA: . 1A
ld (DE),A ;11DB: . 12
ld (DE),A ;11DC: . 12
nop ;11DD: . 00
ld (DE),A ;11DE: . 12
ld (DE),A ;11DF: . 12
nop ;11E0: . 00
inc D ;11E1: . 14
ld (BC),A ;11E2: . 02
ld (BC),A ;11E3: . 02
inc D ;11E4: . 14
rlca ;11E5: . 07
rlca ;11E6: . 07
ld A,(BC) ;11E7: . 0A
ld A,(BC) ;11E8: . 0A
rrca ;11E9: . 0F
rrca ;11EA: . 0F
ld A,(DE) ;11EB: . 1A
ld A,(DE) ;11EC: . 1A
ld B,&06 ;11ED: .. 06 06
ld BC,&0403 ;11EF: ... 01 03 04
ld (BC),A ;11F2: . 02
rrca ;11F3: . 0F
ld D,D ;11F4: R 52
ld C,A ;11F5: O 4F
ld C,H ;11F6: L 4C
ld B,C ;11F7: A 41
ld C,(HL) ;11F8: N 4E
ld B,H ;11F9: D 44
jr NZ,&1245 ;11FA: I 20 49
ld C,(HL) ;11FC: N 4E
jr NZ,&1252 ;11FD: S 20 53
ld D,B ;11FF: P 50
ld B,C ;1200: A 41
ld B,E ;1201: C 43
ld B,L ;1202: E 45
ld BC,&1601 ;1203: ... 01 01 16
ld (BC),A ;1206: . 02
inc B ;1207: . 04
and H ;1208: . A4
jr NZ,&123C ;1209: 1 20 31
add HL,SP ;120B: 9 39
jr C,&1243 ;120C: 85 38 35
jr NZ,&1257 ;120E: G 20 47
ld B,L ;1210: E 45
ld C,L ;1211: M 4D
jr NZ,&1267 ;1212: S 20 53
ld C,A ;1214: O 4F
ld B,(HL) ;1215: F 46
ld D,H ;1216: T 54
ld D,A ;1217: W 57
ld B,C ;1218: A 41
ld D,D ;1219: R 52
ld B,L ;121A: E 45
ld BC,&1801 ;121B: ... 01 01 18
ld (BC),A ;121E: . 02
dec B ;121F: . 05
ld D,B ;1220: P 50
ld (HL),D ;1221: r 72
ld H,L ;1222: e 65
ld (HL),E ;1223: s 73
ld (HL),E ;1224: s 73
jr NZ,&127A ;1225: S 20 53
ld D,B ;1227: P 50
ld B,C ;1228: A 41
ld B,E ;1229: C 43
ld B,L ;122A: E 45
I need to know what happens on port &FBEE here (Sorry, I'm an absolute Assembler-noob)
Hi All,
just opened up my DKTronics unit. It looks slightly different to the pictures submitted by CPCManiaco, but it's probably just a slightly different revision (I don't have the two Electrolytic capacitors seen above the TTL chips in the picture, the rest seems to be the same. Pin 27 of the SPO256 is indeed going to pin 50 of the expansion port (Clock Signal). SBY doesn't seem to be connected to anything. LRQ is connected to Pin 9 of the 74LS32, the lower of the two chips on the right hand side in picture 30-08.2009 001.jpg (Pin 9 of a 74LS32 is one of the two inputs on a dual OR gate) I then lost interest and didn't follow the track further :) Due to it being a double-sided overcrowded board, doing the entire circuit diagram seems like way too much work to me.
Also - a word of warning to anyone else who decides to dis-assemble their unit. In mine, the chip socket of the SPO256 is soldered in the wrong direction, I doubt this is the case on all units, but be careful of the orientation of the chip (and ROM) if you remove them, because the socket orientation can't be trusted. I assume (and they look like) they were hand soldered.
Bryce.
Quote from: nocash on 23:56, 05 January 10
> Using the OUT &FBFE,&04:PRINT INP (&FBFE) i get 127 again
> (didnt hear a "OY" sound tho?).
Maybe... didn't you mention you had no speakers? :-)
Indeed no speakers at all, but i was messing around with the normal "sound" command (that the manual refers to for adjusting the left/right speakers) and i also got sound from the internal speaker like normal. So i kinda assumed that i should hear a noise when using the cart even without the external speakers. Of cause i dont really know :)
Looks like there is a rom version of DK'tronics speech for sale here:
http://www.retrogames.co.uk/more/on/details/015737
Feels a bit expensive for an unboxed and untested set tho.
Without the external speakers you definitely won't hear any speech. The cable which goes from the interface to Audio Output socket is to route the normal sound through it's internal amplifier so that the stereo sound the CPC offers can actually be heard in stereo for a change (internally there's only one speaker as I am sure you all know), but there is no possible way for it to send it's output back into the CPC and through the AY-8912, so the internal speaker could never possibly speak.
Bryce.
This SSA-1 let's me go mad!!!
http://cpc.devilmarkus.de/roinspace/
It's a really hard nut to find the correct timings... But it works better now...
I thought that sounded quite good.
I've scanned in the DK'Tronics user manual and uploaded it as a pdf to the page. It's actually just a section of the DK'Tronics "all in one" Manual which covers every interface DK'Tronics produced (with the exception of the RTC) and was supplied no matter which one you had actually bought.
http://www.cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer#Downloads
And apologies for the quality, it's not great, but neither is the original. They went for the 8 Pin Dot Matrix look.
Bryce.
Hi Bryce! Supercool, fantastic. Thanks! Great to know about the Dk'tronics OSC, SBY, LRQ pins. The LRQ goes to an OR-gate? How strange is that? I would have assumed it'd go to something with tristate output and /OE. Anyways, doesn't seem to be an important feature. And, yeah, drawing an entire schematic would be a pain.
I've also had a closer look at the photos of the TMPI thing,
http://cpcwiki.eu/index.php/TMPI_speech_synthesizer
which uses a MEA8000 speech synthesizer chip, which contains an internal 3.84MHz oscillator. But it doesn't use that oscillator, instead, its CLK IN pin connects to Pin50 of the expansion port. So, like the Dk'tronics, it's driven at 4MHz.
Hey, only for the Amstrad SSA-1 it's still unknown if it's using 3.12MHz, 4MHz, or something different. Can't somebody open it and make a hires-picture? Or just write down the part-number printed on the oscillator (the big orange rectangular thing, close to the middle of the mainboard).
> I've scanned in the DK'Tronics user manual and uploaded it
Cool. I like this sentence best,
"Also the program must find out when the speech chip has finished
saying each allophone by reading from I/O locations &FBFE and
waiting until its value is less than 128."
Sounds as if Dk'tronics guys didn't realize the difference between LRQ and SBY at all :-) Or they just didn't wanted to confuse the users about too many details :-)
Is here really nobody who owns an Amstrad SSA-1 speech?
I need the read port values before, during and after talking.
I do. Tomorrow morning I'll go to my mother's and try to locate it...
> 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...?
Quote from: nocash on 16:10, 08 January 10
> 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?
> 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).
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...
Come on guys!!! Helpppppppp.... ;)
You surely all remember this nice car:
(http://cpc.devilmarkus.de/kitt_front1.png) (http://cpc.devilmarkus.de/kitt_truth.png)
(Click on it to see the truth!!!)
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 :)
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
Cool! Thank you, Gerald!
Quote from: Gerald on 22:53, 11 January 10
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?
> 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.
Quote from: nocash on 16:39, 12 January 10
> 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 ???
Quote from: nocash on 16:39, 12 January 10
> 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
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
> 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? ;-)
Quote from: nocash on 20:54, 12 January 10
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:
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:
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)
/*
* 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.
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
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 (http://cgi.ebay.co.uk/SSA-1-Speech-Synthesizer-for-AMSTRAD_W0QQitemZ220537902735QQcmdZViewItemQQptZUK_VintageComputing_RL?hash=item335915568f)
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 (http://www.cpcwiki.eu/index.php/Amstrad_SSA-1_Speech_Synthesizer).
> 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.
Quote from: nocash on 20:54, 12 January 10
> 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.
Quote from: Ygdrazil on 22:23, 12 January 10
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/ ???
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...
http://www.youtube.com/watch?v=0z-jGDOzwGQ
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.
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.
> 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.
Quote from: nocash on 23:22, 13 January 10
Is yours really doing LoadDeQuest, not LoadReQuest? ;-)
As long as it is not LoadHollyQuest ;)
Quote from: nocash on 23:22, 13 January 10
> 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)?
I do not that any sw relies on a delay, but if you set it to none, sw may run differently on emulator than on reald HW.
Remember that LRQ :P high indicates that you should not load a new allophone. If you test your code to program the SPO on an emulator that do not deal with that delay, you may conclude that you can send 2 allophones in sequence before having to check for that LRQ bit, which is wrong !
Quote from: nocash on 23:22, 13 January 10
> 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...
With a real SSA1 you will hear it ;). If you do not send a pause at the end of a word, you have a endless and constant sound getting out. The pause is specified in the SPO256 datasheet.
That effect may be a bit tricky to emulate as you have to loop the end of your sample.
Quote from: nocash on 23:22, 13 January 10
> 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).
The test was done on purpose : get the minimum LRQ high time. The next serie of test will do the same sequence of allophone with a pause pushed on the FIFO. I expect the second LRQ time to be as long as the allophone SBY time minus the pause LRQ time.
Quote from: nocash on 23:22, 13 January 10
> 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.
That the plan, but using some pause instead of sound.
Really some detailled infos. I will try if I can use them in my emulation.
Big thanks for testing!!!
BTW.: I also improved the digiblaster emulation (Sounds a bit smoother now)
http://www.youtube.com/watch?v=sMNmr-oVE54
Yeah really great with all the new stuff emulated
BTW.. The white lines in the border (Of the video that shows in the digiblaster playing stuff) is this showing how much 'frametime' it takes to play the samples?
/Ygdrazil
Quote from: Devilmarkus on 11:31, 14 January 10
Really some detailled infos. I will try if I can use them in my emulation.
Big thanks for testing!!!
BTW.: I also improved the digiblaster emulation (Sounds a bit smoother now)
http://www.youtube.com/watch?v=sMNmr-oVE54
Hi Gerald, you've also measured some allophone times, didn't you? The timings I've currently described in
http://cpcwiki.eu/index.php/SP0256_Voice_Generator
are "guessed" (there was no info on them anywhere, so I just tried to make sense of various info fragments) (the main guess is "256" which looks nice, but it might be also an odd number like "217" or so).
For allophones 00h..04h, the repeat counts are 1,4,7,15,31 (with pause 64x timing). And for 05h its repeat = 3+3+1+3+1+4+2+4+2+9 = 32 (with 91x pitch timing). So if my guess was correct, the timings should be:
00h PA1 --> 1*5.251ms = 5.251ms
01h PA2 --> 4*5.251ms = 21.004ms
02h PA3 --> 7*5.251ms = 36.757ms
03h PA4 --> 15*5.251ms = 78.765ms
04h PA5 --> 31*5.251ms = 162.781ms
05h OY --> 32*7.466ms = 238.912ms
is that close to what happens on real hardware? The datasheet gives other values, 10ms, 30ms, 50ms, 100ms, 200ms, and 420ms.
> If you test your code to program the SPO on an emulator that
> do not deal with that delay, you may conclude that you can
> send 2 allophones in sequence before having to check for that LRQ
Yeah, right, but I'll ignore that case in my emu. If somebody is stupid enough not to check LRQ isn't my fault :-) and if somebody is really trying to do that: it won't work anyways (as soon as sending more than 2 in sequence).
> With a real SSA1 you will hear it . If you do not send a pause
> at the end of a word, you have a endless and constant sound
> getting out.
Yup, I know. At the moment, on cpcwiki it's only described as part of the RET opcode description (the first place where emulator programmers would look for it). For cpc/z80/basic programmers it should be probably also mentioned in section where describing the CPC I/O ports. Or best, at the bottom of the allophone list.
> That effect may be a bit tricky to emulate as you have to loop
> the end of your sample.
What sample? :-) I am emulating the opcodes, so it works automatically without problems.
Well, I am using an array for each allophone length:
public static int lengths[] = {10 ,30 ,40 ,100,200,420,260,70 ,120,210,
140,140,70 ,140,170,70 ,180,100,290,250,
280,70 ,100,100,100,180,120,130,80 ,180,
100,260,370,160,140,190,80 ,160,190,120,
150,190,160,210,220,110,180,360,200,130,
190,160,300,240,240,90 ,190,180,330,290,
350,40 ,190,50 ,0,0,0,0,0,0,0,0,0,0,0,0};
Taken from SPO256 documentation... All times are milliseconds.
But I don't know actually how to use them in a good way...
BTW.: I uploaded all SPO256 allophones as WAV files here!!! (http://cpcwiki.eu/index.php/SP0256_Allophones#Downloads)
(For JavaCPC I am using the same files but 16bit)
Who is interested:
SPO256-AL2 emulator (http://www.speechchips.com/shop/item.aspx?itemid=13)
> Well, I am using an array for each allophone length:
> Taken from SPO256 documentation... All times are milliseconds.
Hello? You said that you don't emulate the real microprocessor and its repeat counts at all - so, how can you even THINK of using real timings for unreal sounds?
Or did you use corrupt wav files? And need to clip them to real length? I remember seeing such files a year ago, where the recorded files had random length (being longer than the normal allophones).
The WAV files I am using are not corrupt.
I need these times to add to a counter to manipulate LRQ/SBY values.
Oh god. The purpose of the LRQ/SBY stuff is to allow to synchronize the software with the duration of the allophones. If you emulate your allophones by using WAV files, then the duration is - precisely - the length of the WAV file.
Just tested the RSX driver cassette for the SSA-1. The funny part is that it accidently used port FAEE instead FBEE :-) It's loading BC=FBEE, and does then execute OUTI
nice try, but OUTI pre-decements B, so writes to FAEE. of course both works since A8 isn't decoded. It may just increase clashes with other hardware, and won't work on emulators that fully decode FBEE.
Quote from: nocash on 16:37, 14 January 10
Oh god. The purpose of the LRQ/SBY stuff is to allow to synchronize the software with the duration of the allophones. If you emulate your allophones by using WAV files, then the duration is - precisely - the length of the WAV file.
And also allows playing with different sets of wav files, just for fun or to emulate the external rom capability of the SP0256.
Quote from: nocash on 16:37, 14 January 10
Oh god
Thanks, Buddha, but you can call me Markus
I need exact timings, because if i don't have them the port write cannot feed the voice data.
I am building a longgggg bytearray by adding all WAV coming from write port.
So that's why I need to improve timings.
DK'Tronics is much easier to handle here.
After the 7th day god decided to sleep...
Quote from: Devilmarkus on 17:12, 14 January 10
I need exact timings, because if i don't have them the port write cannot feed the voice data.
I am building a longgggg bytearray by adding all WAV coming from write port.
So that's why I need to improve timings.
DK'Tronics is much easier to handle here.
After the 7th day god decided to sleep...
I think everyone is free to implement the dk'tronics speech and ssa-1 speech hardware as they wish. If they want to use samples.. fine. if they want to use bullshit samples... fine. if they want to emulate spo exactly then fine.
For the first version of my emulation I too will use samples.
I think the javacpc emulation has helped us to look into the details of this hardware furthur and to experience the speech in games that maybe we didn't know had them.
Quote from: nocash on 13:02, 14 January 10
Hi Gerald, you've also measured some allophone times, didn't you?
Yes, you will find them in the attached file. Note this file contains min/avg/max value observed for 10 samples of each allophone
Quote from: Devilmarkus on 17:12, 14 January 10
I need exact timings, because if i don't have them the port write cannot feed the voice data.
I am building a longgggg bytearray by adding all WAV coming from write port.
So that's why I need to improve timings.
Have you measured how long your wav are for each allophone? I think this should be the better way to get the SBY timing in your case.
You may also want to compare them with the table I've posted and check how close they are with the 'real' value. If your wav are too long they may contain some garbage.
Quote from: gerald on 21:07, 13 January 10
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?
And the winner is ...
... the last allophone written in the buffer is played when the current one is finished.
> Yes, you will find them in the attached file. Note this file contains
> min/avg/max value observed for 10 samples of each allophone
> SPO256_AllophoneLenght.txt
Cool. Thanks!
Hmmmmmm, the timings seem to be almost exactly 1.25 times longer than my calculated timings. So my calculation formula seems to have been correct, except for needing to multiply the result by 1.25.
Any idea where that 1.25 value comes from?
Your 3.12MHz resonator IS running at 3.12MHz, isn't it? I guess that components have some tolerance higher than quartz oscillators, though if it runs only at (3.12/1.25)MHz then it'd be a really high tolerance :-/
And otherwise, if it is 3.12MHz... as far as I know, it uses 7bit PWM output, so the sample rate should be 3.12MHz/128, or half of it, 3.12MHz/256... btw. did you check that, too? With a oscilloscope the PWM pulses should be well visible.
Quote from: nocash on 20:46, 14 January 10
Hmmmmmm, the timings seem to be almost exactly 1.25 times longer than my calculated timings. So my calculation formula seems to have been correct, except for needing to multiply the result by 1.25.
Any idea where that 1.25 value comes from?
A division by 8 somewhere ? 1/8 = 0.125 ;D
Quote from: nocash on 20:46, 14 January 10
Your 3.12MHz resonator IS running at 3.12MHz, isn't it? I guess that components have some tolerance higher than quartz oscillators, though if it runs only at (3.12/1.25)MHz then it'd be a really high tolerance :-/
My simple multimeter tells me it's running at 3.12MHz. While it is not highly precise, I do not think the multimeter and the oscillator are 25% off :o
Quote from: nocash on 20:46, 14 January 10
And otherwise, if it is 3.12MHz... as far as I know, it uses 7bit PWM output, so the sample rate should be 3.12MHz/128, or half of it, 3.12MHz/256... btw. did you check that, too? With a oscilloscope the PWM pulses should be well visible.
Using the logic analyser, I measured a 40.25KHz frequency at the DIGITAL OUT pin while no speech (constant square signal). But during speech, the frequency seem to slightly change. I'll try to get a scope to check that waveform.
How to get the 40.25KHz from 3.12MHz is an other mystery, but not important for emulation.
>> Any idea where that 1.25 value comes from?
> A division by 8 somewhere ? 1/8 = 0.125
I'd be glad if it'd be a 2^n thing. But to be 1.25 times slower that expected... it'd mean to be 5/4 times slower (or 4/5 times faster, if you turn it around).
> My simple multimeter tells me it's running at 3.12MHz.
Okay, then that wasn't the reason. :-/ Would have to good to be true.
> Using the logic analyser, I measured a 40.25KHz frequency at the DIGITAL
> OUT pin while no speech (constant square signal).
Square wave makes sense. If it's silent, PWM should be 50% high, 50% low.
> But during speech, the frequency seem to slightly change.
Maybe the analyser just missed "pulses" at times when PWM is 100% high, 0% low for max amplitude (and vice versa for min). Or there's something more strange going on.
> How to get the 40.25KHz from 3.12MHz is an other mystery, but not
> important for emulation.
Yeah. The how/why part is maybe not so important. Would be nice to know though... getting back to the "divide by five" in the above 4/5 times faster idea...
3.12MHz/5/16 = 39kHz
Well.... that'be almost, but not really 40.25kHz :-/
Uh, and if they output 7bit PWM samples at 40.25kHz, then the PWM stuff must be running 128 times higher, at 5.152MHz. How strange...
Anyways, knowing about the 40.25KHz frequency is important and helpful (many thanks finding that value) for low level emulation of the voice generator.
Tried to make some sense of the frequencies...
The older SP0250 application manual describes DAC OUTPUT as 10KHz 7bit PWM. And the newer SP0256 datasheet BLOCK DIAGRAM says 7bit PWM, too. As well as 5KHz max pitch, which means 10KHz sample rate, too.
Let's assume that the datasheet values are correct. Then it'd need the PWM driven at 128x10KHz = 1.28MHz. That would be 3.12MHz/13/3*16. Which is more or less reasonably possible. The divider/multiplier isn't making it a simple "straight" timing design. The reason for doing that was maybe that they needed the 3.12MHz for clocking the filter multipliers internally.
And the 40.25KHz. Let's say there was some inaccuracy caused by the resonator or so, and it should be 40KHz, which would 4x higher than the 10KHz sample rate.
The reason there would be producing the 10KHz sample rate's "silence" as two 50% HIGH/LOW pulses would result in a nasty 10KHz noise. Now, rearranging it to eight 12.5% HIGH/LOW pulses would give much better silence with in-audible 40KHz noise, and which'd be the frequency you've measured.
I think that could/should be how it really works. For emulating it, 10KHz would be the important value, the one at which the pitch/noise/filter stuff is running.
PS: For curiosity, I've uploaded all known sp025x related datasheets at,
http://cpcwiki.eu/index.php/SP0256
PPS: The differences between the specified & measured allophone times are funny. I had calculated only a few by hand, and figured out that there would be some values wrong in the datasheet. But I didn't expect that almost all values were totally wrong :-)
Quote from: gerald on 19:40, 14 January 10
And the winner is ...
... the last allophone written in the buffer is played when the current one is finished.
Gerald thankyou for your testing.
Would you be able to show a chronogram or oscilloscope output of the LRQ and SBY signals.. especially the sequence:
inactive -> load allophone -> speaking allophone -> stopped speaking.
I think it would be interesting to see that.
Here you are :
The first capture show the whole sequence for the shortest pause.
(http://img8.hostingpics.net/pics/548789SOP256_ALDLRQSBY_P0.png)
The second capture detail the beginning of the sequence.
(http://img8.hostingpics.net/pics/799322SPO256_ALDLRQSBY_P0_detaill.png)
For the 'precise' timing please refer to the previous post ;)
Hi nocash
Thanks for uploading the datasheets.
Here is a capture of the digital output (pin 24). With persistence over all allophones we can see resolution of the PWM output.
(http://img8.hostingpics.net/pics/237831SPO256_DigitalOutput.png.png)
- each small step is about 635ns -> this is 2 period of 3.12MHz
- one period is about 24.8us -> this is 40 steps -> 80 period of 3.12MHz
- The duty cycle is not 50%, the falling edge in 'idle' position is at 17 step
- signal variation is +/- 16 step around idle position
The PWM seems to have 5bit resolution, but can have 33 different values (-16 to +16) :o
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.
As a side note, the rom clock (pin 26) is 1.56Mhz
> Here is a capture of the digital output (pin 24). With persistence over
> all allophones we can see resolution of the PWM output.
Cool! Looks a bit other than expected at first glance...
So they have inserted some dummy bits with constant LOW level between the PWM packets. Getting them the desired 10kHz sample rate, by simply using 3.12MHz/2 (instead of my 3.12MHz/39*16 idea, of which the *16 looked a bit overcomplicated anyways).
> 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).
> 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.
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.
Oh, and here is a -AL2 disassembly that I've found somewhere in the net,
http://cpcwiki.eu/imgs/2/28/SP0256-AL2-Disassembly.txt
Quote from: nocash on 16:37, 16 January 10
> 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 ;D
Quote from: nocash on 16:37, 16 January 10
> 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.
Quote from: nocash on 16:37, 16 January 10
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.
> 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.
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...
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
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! :D ), 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!
Quote from: gerald on 20:05, 15 January 10
Here you are :
The first capture show the whole sequence for the shortest pause.
(http://img8.hostingpics.net/pics/548789SOP256_ALDLRQSBY_P0.png)
The second capture detail the beginning of the sequence.
(http://img8.hostingpics.net/pics/799322SPO256_ALDLRQSBY_P0_detaill.png)
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?
Quote from: arnoldemu on 17:10, 18 January 10
Are these taken from the pins on the SPO itself?
Yes
Quote from: arnoldemu on 17:10, 18 January 10
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)
Quote from: arnoldemu on 17:10, 18 January 10
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 :-[)
(http://img8.hostingpics.net/pics/792342SSA1Digital.png)
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).
> 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
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 :P
- I''ve finally found a working version, but I cannot remember where ;D
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.
Quote from: nocash on 16:00, 23 January 10
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.
Quote from: nocash on 16:00, 23 January 10
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.
Quote from: nocash on 16:00, 23 January 10
> 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)
Quote from: gerald on 19:26, 23 January 10
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 :P
- I''ve finally found a working version, but I cannot remember where ;D
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 ::)
Hi Markus
Your spetest returns to basic prompt after the speak.
This is because you are mainly testing the SBY bit in line 80 :
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)
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.
(http://img10.hostingpics.net/pics/58862SPO256_spetest.png)
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.
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 :P). 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
Quote from: gerald on 20:29, 29 January 10
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 :P). 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 ;)
SSA1 - Speech test:
[cpc=http://cpcwiki.eu/forum/index.php?action=dlattach;topic=503.0;attach=404,DISC,1]SSA1[/cpc]
Here's a small BASIC program I found in a german CPC magazine (CPC International)
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)
Can it sit in the background and do its stuff while you do something else?
Quote from: Gryzor on 13:03, 29 July 10
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.
Quote from: Gryzor on 13:03, 29 July 10
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)
Quote from: arnoldemu on 17:10, 18 January 10Roland 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/ (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/new-%27next-generation-speech-synthesizer%27-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]
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.
Hi gerald,
no I haven't, thanks!
So it seems that
Quote
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...
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?
Thanks guys,
SSA-1 emulation is working now:
Cheers
Michael
With regard to DK'tronics and supported games, the list
http://www.cpcwiki.eu/index.php/Dk%27tronics_Speech_Synthesizer (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?