LambdaSpeak CPC Sprach-Synthesizer, Sample Player, RTC, MP3, UART Erweiterung

[TFM]

Hola! Ja, sorry hab den Post mit dem Deal verpasst. Im Prinzip könnten wir das schon machen, aber ich muss gleich schon mal sagen, dass ich nicht all zu viel Zeit habe. Die RSX Erweiterung könnte also etwas Zeit in Anspruch nehmen (also wohl eher 1-2 Monate anstatt Wochen - ja, ich bin jetzt lieber mal pessimistisch, dann kann's nur besser werden).
Falls der DEAL noch gilt, dann können wir ja den "Rest" per PM besprechen. 

So eine RSX Erweiterung kann man dann auch in ein ROM integrieren. Gibt es eines für das SSA1? Dann können wir das u.U. auch da mit einbauen. 

EDIT: Da ist ein SSA-1 ROM, und in dem sind 12 KB frei! Super! 

[TFM]

@Michael: Ok, die RSX machst Du jetzt selber hast ja gesagt, aber es wäre trotzdem interessant welche Control Bytes der Lambda-Speak nun verwendet. Könntest Du bitte die folgende Liste mal ergänzen? Das wäre super :-)

|lambdaspeak,@a$

|setvolume,<nibble>
|setvoice,<nibble>
|setspeed,<nibble>

|speakmode
|speakvolume
|speakvoice
|speakspeed 

|ssa1
-----
out &fbee,255      ;-> ssa1 mode


|lambda
-------
out &fbee,254      ;-> native mode


|iotest
|reset
|speakinfo

|hal9000
|testleds

|getversion -> int

|getvolume -> int
-----------------
out &fbee,249      ;Read volume control byte
in  a,(&fbee)      ;A = Volume


|getvoice -> int
|getspeed -> int
|getmode -> int

[LambdaMikel]

@Michael: Ok, die RSX machst Du jetzt selber hast ja gesagt, aber es wäre trotzdem interessant welche Control Bytes der Lambda-Speak nun verwendet. Könntest Du bitte die folgende Liste mal ergänzen? Das wäre super :-)

Hi TFM,
werde ich machen, aber momentan kann die LambdaSpeak Firmware das noch gar nicht. Ich arbeite erst noch an den zusaetzlichen Control Bytes. Ich werde erst die Firmware von LambdaSpeak erweitern, und dann an den RSX-Befehlen arbeiten. Momentan gibt es nur die SSA-Software, die BASIC-Elizas die ich mit Sprache erweitert habe (Native und SSA1 Modus), und den kleinen BASIC-Treiber im SCreenshot.

Ich update diesen Thread, sobald wir mehr haben 

Bis dahin,
Viele Gruesse
Michael

[LambdaMikel]

Hallo zusammen, und frohes neues Jahr!
Nun hat es doch etwas laenger gedauert, bis ich die Control-Bytes / Firmware am Laufen hatte... tatsaechlich haben sich die Control-Bytes mehrfach geandert, insofern war es gut, dass ich mit dem Update gewartet habe. Aller Voraussicht nach wird die Firmware also wie folgt aussehen:

Code Select Expand



switch ( control_byte ) {

  case 0xFF : process_reset(); break;

  case 0xEF : native_mode_epson(); break;
  case 0xEE : native_mode_dectalk(); break;
  case 0xED : ssa1_mode(); break;
  case 0xEC : non_blocking(); break;
  case 0xEB : blocking(); break;
  case 0xEA : confirmations_on(); break; 
  case 0xE9 : confirmations_off(); break;   
  case 0xE8 : english(); break;
  case 0xE7 : spanish(); break;

  case 0xDF : stop_command(); break;  // will never be reached, because of blocking - only for documentation!!
  case 0xDE : flush_command(); break;

  case 0xCF : get_mode(); break;
  case 0xCE : get_volume(); break;
  case 0xCD : get_voice(); break;
  case 0xCC : get_rate(); break;
  case 0xCB : get_language(); break;
  case 0xCA : get_delay(); break;
  case 0xC9 : get_version(); break;
  case 0xC8 : speak_copyright_note(); break;
  case 0xC7 : speak_hal9000_quote(); break;
  case 0xC6 : sing_daisy(); break;
  case 0xC5 : echo_test_program(); break;
  case 0xC4 : test_message(); break;

  case 0xB0 : set_voice_default(); break;
  case 0xB1 : set_voice(1); break; // default
  case 0xB2 : set_voice(2); break;
  case 0xB3 : set_voice(3); break;
  case 0xB4 : set_voice(4); break;
  case 0xB5 : set_voice(5); break;
  case 0xB6 : set_voice(6); break;
  case 0xB7 : set_voice(7); break;
  case 0xB8 : set_voice(8); break;
  case 0xB9 : set_voice(9); break;
  case 0xBA : set_voice(10); break;
  case 0xBB : set_voice(11); break;
  case 0xBC : set_voice(12); break;
  case 0xBD : set_voice(13); break;
  case 0xBE : set_voice(14); break;
  case 0xBF : set_voice(15); break;

  case 0xA0 : set_volume_default(); break;
  case 0xA1 : set_volume(1); break;
  case 0xA2 : set_volume(2); break;
  case 0xA3 : set_volume(3); break;
  case 0xA4 : set_volume(4); break;
  case 0xA5 : set_volume(5); break;
  case 0xA6 : set_volume(6); break;
  case 0xA7 : set_volume(7); break;
  case 0xA8 : set_volume(8); break;
  case 0xA9 : set_volume(9); break;
  case 0xAA : set_volume(10); break;
  case 0xAB : set_volume(11); break;
  case 0xAC : set_volume(12); break;
  case 0xAD : set_volume(13); break;
  case 0xAE : set_volume(14); break; // default
  case 0xAF : set_volume(15); break;

  case 0x90 : set_rate_default(); break;
  case 0x91 : set_rate(1); break;
  case 0x92 : set_rate(2); break;
  case 0x93 : set_rate(3); break;
  case 0x94 : set_rate(4); break;
  case 0x95 : set_rate(5); break;
  case 0x96 : set_rate(6); break;
  case 0x97 : set_rate(7); break;
  case 0x98 : set_rate(8); break;
  case 0x99 : set_rate(9); break;
  case 0x9A : set_rate(10); break;
  case 0x9B : set_rate(11); break;
  case 0x9C : set_rate(12); break; // default
  case 0x9D : set_rate(13); break;
  case 0x9E : set_rate(14); break;
  case 0x9F : set_rate(15); break;

  case 0x80 : set_buffer_delay_default(); break;
  case 0x81 : set_buffer_delay(1); break;
  case 0x82 : set_buffer_delay(2); break;
  case 0x83 : set_buffer_delay(3); break;
  case 0x84 : set_buffer_delay(4); break;
  case 0x85 : set_buffer_delay(5); break;
  case 0x86 : set_buffer_delay(6); break;
  case 0x87 : set_buffer_delay(7); break;
  case 0x88 : set_buffer_delay(8); break;
  case 0x89 : set_buffer_delay(9); break;
  case 0x8A : set_buffer_delay(10); break; // default !!
  case 0x8B : set_buffer_delay(11); break;
  case 0x8C : set_buffer_delay(12); break;
  case 0x8D : set_buffer_delay(13); break;
  case 0x8E : set_buffer_delay(14); break;
  case 0x8F : set_buffer_delay(15); break;

  }



Die get_xxxx Reader legen den entsp. xxx Wert fuer ~ 200 ms auf den &FBEE Port; der Wert ist > 0 und nach 200 ms geht der Port wieder auf 0. Man muss also eine busy polling loop schreiben, um zu lesen: warte bis &FBEE <> 0, lese &FBEE, warte bis &FBEE = 0, raus aus der Schleife.  Zudem ist das ein 4 Bit-Wert > 0, oberes Nibble, also bitte durch 16 teilen.

Die Firmware unterstuetzt nun auch den DecTalk-Mode, mit der Epson IC singen kann etc. Die EMic2-basierte Variante konnte diese Sachen auch schon, da der Emic2 einen eigenen Mikrocontroller und Command-Parser implementiert hatte. Da wir nun aber den Raw Epson IC verwenden, haben wir diese EMic2-Command Shell nicht mehr, und muessen alles selbst machen.

Ich habe das mit dem LambdaSpeak 2 Breadboard getestet, und werde es demnaechst in LambdaSpeak 1.5 einbauen. Die Hardware von LambdaSpeak 1.5 ist ja etwas anders, daher wird es ein bisschen dauern, bis LambdaSpeak 1.5 auch die neue Firmware hat.

Und dann kommt die RSX-Erweiterung fuer den CPC an die Reihe.

[TFM]

Hallo!!!  Das sind ja gute Neuigkeiten!



Nur eine Frage, wenn man den Wert einliest, liegt der dann immer noch die vollen 200 ms auf dem Port? Oder ist es so, dass wenn man den Wert liest, der Port wieder 0 wird und dann für das nächste Kommando verwendet werden kann?

200 ms ist ja eine 1/5 Sekunde, eine Unendlichkeit. Oder meintest Du 200 us?

Wie ist das wenn ich Kommandos gebe um zwei Parameter zu lesen? Muss ich dann die 200 ms warten bis ich den 2. Wert lesen kann? Oder "überschreibt" das zweite Kommando das erste Kommando und ich kann dann sofort den 2. Wert lesen?

So, der Tag ist gerettet, das sind ja mal super Neuigkeiten!!! 



EDIT: So hab mal ein bisschen an dem BASIC Proggy und der Doku gearbeitet. Das ist mehr didaktisch als sinnvoll, aber es sollte veranschaulichen was so passiert. Bitte drübergucken und kommentieren wer will. Schließlich ist ja alles noch in der Entwicklung.
Wie man sieht stimmt die RSX Liste nicht genau mit den Befehlen überein, es entwickelt sich ja alles weiter. Kommentare willkommen :-)

[LambdaMikel]

Hi TFM,

momentan ist es tatsaechlich eine fuenftel Sekunde. Ich wollte halt den Wert mit BASIC lesen. Wahrscheinlich kann ich diese Zeit, fuer die der Wert auf dem Port liegt, reduzieren. Also den kleinsten Wert finden, fuer den das noch klappt:

Code Select Expand


10 a = inp(&fbee)
20 if a = 0 then goto 10
25 print a
30 b = inp(&fbee) : if b = a  then goto 30


... hmm.. ich erinnere mich gerade, mach das nicht ohnehin der BASIC WAIT Befehl so? Werde ich mal probieren. Den hatte ich ganz vergessen!

Ja, es muss ein Wert nach dem anderen gelesen werden, sequentiell. Uebrigens ist es so, dass die Command Bytes mit Ausnahme der get-xxx Reader den CPC auf RD_WAIT ziehen... also anhalten. Diese Anhalten des CPCs ist auch der Default fuer die Sprachausgabe - solange LambdaSpeakspricht, wird der CPC angehalten. Allerdings nur im native mode - der SSA1 mode ist immer non blocking. Es gibt ja das SSA1-Protokoll dafuer. Fuer den native mode habe ich allerdings auch etwas aehnliches eingebaut, der dann non-blocking funktioniert. Hier wird dann, statt den CPC anzuhalten bis Ende der Sprachausgabe, der CPC nicht angehalten. Der CPC laeuft also weiter waehrend der Lambda spricht, und man kann dann genau 2 Dinge tun: entweder das stop control byte senden (was die Sprachausgabe sofort stoppt), oder aber mittels inp(&fbee) lesen, ob der CPC noch spricht oder nicht. Bei gesetztem 7. Bit spricht er noch. Sobald er fertig ist, geht inp(&fbee) auf 0. Damit ist also Flusskontrolle moeglich.

[LambdaMikel]

Der CPC laeuft also weiter waehrend der Lambda spricht, und man kann dann genau 2 Dinge tun: entweder das stop control byte senden (was die Sprachausgabe sofort stoppt), oder aber mittels inp(&fbee) lesen, ob der CPC noch spricht oder nicht. Bei gesetztem 7. Bit spricht er noch. Sobald er fertig ist, geht inp(&fbee) auf 0. Damit ist also Flusskontrolle moeglich.

Sobald er fertig ist mit Sprechen, kann man natuerlich wieder alles machen. 

[TFM]

Hab mal kurz einen Test gemacht: In BASIC kann man (innerhalb einer Schleife mit Zähler) einen Port 117 mal einlesen. Also... 1.000.000/100 = 10.000 us. Also mit 10 Millisekunden ist man auf der sicheren Seite. Solange man in BASIC sofort einliest und nicht wartet sollte das gut funktionieren. 

Idee: Wäre es mögich per Kontroll-Byte die Warezeit zum setzen, z.B. zwischen 10 us und 10 ms? Das wäre beim MC coden ein super Vorteil. :-)

Ah mit den beiden:
&EC - non_blocking
&EB - blocking
kann man also entscheiden ob im native Mode der CPC angehalten wird. Super! Das ist klasse für Z80 code. Gerade wenn z.B. ein Spiel z.B. weiterlaufen soll.

[LambdaMikel]

Idee: Wäre es mögich per Kontroll-Byte die Warezeit zum setzen, z.B. zwischen 10 us und 10 ms? Das wäre beim MC coden ein super Vorteil. :-)

Gute Idee, habe ich eingebaut - 2 neue Control-Bytes also:

fast_getters = &E6 (10 micro seconds)
slow_getters (fuer BASIC) = &E5 (10 milli seconds)

Zudem habe ich das Protkoll nun doch noch mal überdacht, nun, wo ich den WAIT-Befehl widergefunden habe... im native mode wird READY auf dem Port mittels 32 angezeigt. Kommt ein Control-Byte, geht der Port sofort auf 0. Dann kann ein Wert gelesen werden, und nach 10 ms bzw. 10 us (s. oben) geht der Port wieder auf 0. Danach kann man mittels WAIT wieder darauf warten, dass LambdaSpeak wieder empfangsbereits ist (auf 32 warten). Das funktioniert sowohl im Blocking als auch im Non-Blocking-Mode. Anbei 2 Screenshots mit einem Testprogramm.

Zunächst ein Reset (&FF) Danach warten, bis sich der SSA1-Mode meldet (Default nach Reset / Einschalten). Dieser Mode meldet sich mittels 128 als "READY" (SSA1-Standard). Dann in den Epson-Mode schalten (&EF). Der Epson / Native Mode melde READY mittels 32, wie gesagt. Bestätigungen ausschalten (&E9), non-blocking mode (&EC), und dann 3 Werte lesen: Volume, Speak Rate, und Voice. S. Screenshots.

10 milli seconds funktionieren prima für BASIC, danke für den Test / Hinweis!

[LambdaMikel]

PS Man sieht doch - ausdenken kann man sich viel, wenn man es nicht selbst benutzt / programmieren tut, taugt es alles nichts. Jetzt scheint mir das Protokoll allerdings brauchbar; wenn ich mir den BASIC-Code anschaue, sieht das jetzt sauber aus (keine Warte-Schleifen mehr etc).

Übrigens - es scheint nicht möglich zu sein, mittels WAIT of ein 0-Byte zu warten?! Ist das richtig? Ich dachte an sowas wie WAIT &FBEE,255,255, aber das funktioniert nicht. Sollte doch eigentlich?!

[TFM]

PS Man sieht doch - ausdenken kann man sich viel, wenn man es nicht selbst benutzt / programmieren tut, taugt es alles nichts. Jetzt scheint mir das Protokoll allerdings brauchbar; wenn ich mir den BASIC-Code anschaue, sieht das jetzt sauber aus (keine Warte-Schleifen mehr etc).

Übrigens - es scheint nicht möglich zu sein, mittels WAIT of ein 0-Byte zu warten?! Ist das richtig? Ich dachte an sowas wie WAIT &FBEE,255,255, aber das funktioniert nicht. Sollte doch eigentlich?!

Der WAIT Befehl in BASIC. Da musste ich jetzt im Handbuch nachschlagen. Aber da ist ein Fehler. Mit einem Parameter wartet der WAIT Befehl bis die Antwort nicht 0 ist, allerdings wird bei einem Parameter die AND Verknüpfung verwendet. Stimmt also, 0-Bytes kann man nicht abfragen.

Aber um auf die Eingabe von 0 zu warten geht folgendes:
WHILE inp(&FBEE)<>0:WEND

[TFM]

Was ich noch nicht verstehe sind folgende Kommandos:

&EE - native_mode_dectalk - Ist das ein Dritter Modus neben Epson und SSA-1??

&EA - confirmations_on
&E9 - confirmations_off 

&DE - flush_command

&C6 - sing_daisy
&C5 - echo_test_program
&C4 - test_message

Vielleicht kannst Du die ja kurz erklären? 

[LambdaMikel]

Was ich noch nicht verstehe sind folgende Kommandos:

&EE - native_mode_dectalk - Ist das ein Dritter Modus neben Epson und SSA-1??
&EA - confirmations_on
&E9 - confirmations_off 
&DE - flush_command
&C6 - sing_daisy
&C5 - echo_test_program
&C4 - test_message

Vielleicht kannst Du die ja kurz erklären? 

Sehr gerne. Also:

• FE - der Epson-IC hat 2 Modi / Parser. Einen DecTalk-Parser, mit dem kann man sehr detailliert phonetisch modellieren. So kann er z.B. singen. Der Epson-Mode klingt etwas besser, und hat nur rudimentaere Modellierungs-Moeglichkeiten. Google mal nach DecTalk songs.
• FA, F9 - fuer die Setter/Getter-Funktionen, wenn Confirmations an sind, wird immer auch per Sprache ausgegeben. Also "Set Voice to 2", "Current Voice is 2". And so on.
• DE - das ganze funktioniert intern ja asynchron, es werden also Characters gepuffert bis entweder CR (13) kommt, oder aber - im SSA1-Modus - eine Zeit lang nichts mehr ankam. Dann wird der Puffer gesprochen. Der Puffer kann auch mittels dieses Kommandos geleert werden und wird dann gesprochen. Der Buffer hat 512 bytes. Ein echtes "synchrones Sprechen" - phoneme fuer phoneme in Echtzeit - ist mit dem Epson nicht moeglich. Der SSA1 kann das, aber diese Emulation eben nicht.
  Fuer Spiele etc. bedeutet das halt, dass immer mit einer kleinen Verzoegerung gesprochen wird, und dass ab und zu eine Sprechpause einbaut werden muss, damit der Buffer nicht ueberlaueft (ansonstent wird er allerdings automatisch geleert).
• C6 - eine demo, DecTalk singt. "Daisy Bell (Bicycle Built for Two)" is a popular song, written in 1892 by British songwriter Harry Dacre.
• C5 - ein ECho-Porttestprogramm. In diesem mode kann man Port IO auf &FBEE testen. Hardwaretest sozusagen. Alles, was auf out &fbee,x ausgegeben wird, wird mittels y=inp(&fbee) zurueckgeechoed. Also x=y. Der MOde kann nur durch Reset-Taste am LambdaSpeak verlassen werden.
• C4 - eine Test-SPrachausgabe, die den aktuellen Modus miteilt. NIcht wirklich essentiell. Funktioniert allerdings auch, wenn Confirmation Off sind. ALso doch nuetzlich.

[LambdaMikel]

... habe einmal ein Demo-Video der 2.0-Firmware hochgeladen:

https://youtu.be/9lcQwHY9uwA

Demonstriert einige der oben diskutierten Control Bytes, und zeigt auch den DecTalk-Modus, mit dem LambdaSpeak "singen" kann. Das geht ganz einfach von BASIC aus.

Anbei das Programm aus dem Video; Happy Birthday DecTalk Song (teilweise) ab Zeile 190:

Code Select Expand


10 OUT &FBEE,&FF
20 a=INP(&FBEE):IF a<>128 GOTO 20
30 PRINT "hit space bar for quiet"
40 OUT &FBEE,&EF
50 WAIT &FBEE,32
60 OUT &FBEE,&EC
70 WAIT &FBEE,32
80 a$="hello how are you i am lambdaspeak 123456789"
90 FOR i=1 TO LEN(a$)
100 c$=MID$(a$,i,1)
110 OUT &FBEE,ASC(c$)
120 NEXT
130 OUT &FBEE,13
140 a=INP(&FBEE)
150 IF INKEY$=" " THEN OUT &FBEE,&DF:PRINT "quiet!"
160 IF a<>32 GOTO 140   
170 REM
180 OUT &FBEE,&EE
190 a$="[:phone arpa speak on][:rate 200][:n1][hxae<300,10>piy<300,10> brr<600,22>th<100>dey<600,19>dih<600,15>rdeh<600,14>ktao<600,12>k_<120>_<120>][:n1]"
200 a$=a$+"[:phone arpa speak on][:rate 200][:n3][hxae<300,10>piy<300,10> brr<600,22>th<100>dey_<120>_<120>][:n3]"
210 FOR i=1 TO LEN(a$)   
220 c$=MID$(a$,i,1)
230 OUT &FBEE,ASC(c$)   
240 NEXT
250 OUT &FBEE,13   
260 a=INP(&FBEE)
270 IF INKEY$=" " THEN OUT &FBEE,&DF:PRINT "quiet!"
280 IF a<>32 GOTO 260
290 REM
300 OUT &FBEE,&CE
310 WAIT &FBEE,255
320 PRINT INP(&FBEE)/16
330 a=INP(&FBEE):IF a<>0 THEN GOTO 330
340 WAIT &FBEE,32
350 OUT &FBEE,&CC
360 WAIT &FBEE,255
370 PRINT INP(&FBEE)/16
380 a=INP(&FBEE):IF a<>0 THEN GOTO 380
390 WAIT &FBEE,32
400 OUT &FBEE,&B2
410 WAIT &FBEE,32
420 OUT &FBEE,&CD   
430 WAIT &FBEE,255
440 PRINT INP(&FBEE)/16   
450 a=INP(&FBEE):IF a<>0 THEN GOTO 450
460 WAIT &FBEE,32
470 OUT &FBEE,&CD


Das Video verwendet LambdaSpeak 1.8-Hardware - eine weitere Zwischenversion auf dem Weg zu LambdaSpeak 2.0. Die Firmware von 1.8 ist identisch zu 2.0. Der Atmega644 wird die gleiche pin-Belegung etc. verwendet. In 2.0 wird das GAL 22V10, 74LS374 und 74LS244 gegen einen Xilinx XC9572xl TQ100 CPLD ersetzt. Alles in SMD, 3-Chip-Design (ATmega, Epson Speech IC, und Xilinx CPLD also). Leider gibt es noch ein Problem mit dem CPLD, sodass es noch etwas dauert, bis LS 2.0 fertig ist.

Anbei ein paar Bilder vom aktuellen Breadboard, dass noch etwas debugging braucht - bis auf den SSA1-Treiber funktioniert es (|say scheint Allophone-Bytes zu verschlucken, was sehr rästelhaft ist, dass Spiele wie Roland in Space diesen Defekt bei der Sprachausgabe nicht zeigen).

[LambdaMikel]

Anbei ein paar Bilder vom aktuellen Breadboard, dass noch etwas debugging braucht - bis auf den SSA1-Treiber funktioniert es (|say scheint Allophone-Bytes zu verschlucken, was sehr rästelhaft ist, dass Spiele wie Roland in Space diesen Defekt bei der Sprachausgabe nicht zeigen).

Good news - das Problem wurde behoben. Das LambdaSpeak 2.0 Breadboard funktioniert jetzt. Ich hatte die VCCIO-Stromversorgung für den Xilinx CPLD nicht richtig gemacht. Hat jetzt seinen eigenen Spannungsregler, und damit ist das Problem behoben

Also nur noch eine Frage der Zeit, bis LambdaSpeak 2.0 in SMD als 3-Chip-Version erscheint. Bryce macht das.