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

[LambdaMikel]

Gut, und ich habe inzwischen gesehen, dass READY im EPSON modus sofort angezeigt wird. Auch wenn er noch spricht. Das ist natuerlich ein Problem. Wird behoben in der naechsten Firmware.

NEIN! Wir verstehen uns da falsch! Es ist ja RICHTIG, dass er &20 anzeigt, denn er darf ja ruhig sprechen und den CPC weiter machen lassen. Wir reden ja vom NON-blocking Modus. Oder hab ich den Faden verloren... ich guck's mir noch mal an.

Beides richtig... wie gesagt, m.E. sollty READY &20 NUR angezeigt werden, wenn er wieder bereit ist, das naechste Kommando anzunehmen. Solange er noch spricht, ist das nicht der Fall,  auch im Non BLocking Mode! Das einzige Kommando das funktioniert waehrend er spricht ist STOP.

Ich denke, wir moechten gerne einen READY Indikator, der anzeigt, dass JEDES Kommando wieder empfangen werden kann, und OHNE VERZOEGERUNG verarbeitet werden kann.  Und da gibt &20 momentan den falschen Eindruck. STOP kann also jederzeit gesendet werden, OHNE dass man nach &20 testen muss, und ansonstent sollten im EPSON Modus erst wieder Kommandos gesendet werden, wenn &20 auf dem Bus ist. Was erst der Fall sein darf, wenn er mit Sprechen durch ist. Egal, ob Blocking oder nicht (na bei Blocking hat der CPC ja ohnehin keine Chance, VORHER was zu senden). Momentan wird &20 "zu frueh" auf den Bus gelegt.

[TFM]

Ja, glaube wir verstehen uns jetzt.  Jedenfalls kann er ja schon z.B. die Uhr auslesen, während er spricht. Wenn das anders wäre, dann würde ja trotzdem das OS einfrieren. 
Lassen wir es erst mal so, ich muss da noch testen...

Nebenbei: Wegen dem !STOP Problem, da wäre auch ein Firmware Uptdate für den 1.95 etc gut. (Falls !STOP nach dem 1. Einschalten auch alles einfriert). 

[LambdaMikel]

Ja, glaube wir verstehen uns jetzt.  Jedenfalls kann er ja schon z.B. die Uhr auslesen, während er spricht. Wenn das anders wäre, dann würde ja trotzdem das OS einfrieren. 
Lassen wir es erst mal so, ich muss da noch testen...

Gute Beobachtung... das war mir gar nicht klar - aber jetzt, wo ich darueber nachdenke.

Ja, der Epson-Chip spricht prinzipiell alleine, und der ATMega kann machen. Wenn das Kommando das gesendet wird waehrend er spricht nichts mit dem Epson-Chip zu tun hat (z.B. Uhr), geht es prinzipiell. Nur alles was den Epson Chip involviert muss halt warten, bis er mit Sprechen durch ist, daher blockiert er dann.

[TFM]

Ok wunderbar.

Neues Problem: Sendet man einen Text (ohne &0D am Ende) und schickt dann &DE, dann spricht der LS zwar sofort, aber das letzte Zeichen wird unterschlagen. Man kann das in BASIC mit OUT Befehlen simulieren (im EPSON Modus getestet). Bitte beheben. Derweil arbeite ich drum herum, werde einfach &0D anstatt &DE senden, das sollte auch funktionieren.

[LambdaMikel]

Neues Problem: Sendet man einen Text (ohne &0D am Ende) und schickt dann &DE, dann spricht der LS zwar sofort, aber das letzte Zeichen wird unterschlagen. Man kann das in BASIC mit OUT Befehlen simulieren (im EPSON Modus getestet). Bitte beheben. Derweil arbeite ich drum herum, werde einfach &0D anstatt &DE senden, das sollte auch funktionieren.

Fixed.

Anbei auch für L195... bitte mal testen. Ist ebenfalls v41, aber natürlich ohne EEPROM und I2C etc. support.

[TFM]

Hab's beide gebrannt, und scheinen beide gut zu funktionieren. Die Fehler sind behoben, erstklassige Arbeit wie immer! 

[LambdaMikel]

Hab's beide gebrannt, und scheinen beide gut zu funktionieren. Die Fehler sind behoben, erstklassige Arbeit wie immer! 

Danke und freut mich!
Soll ich jetzt noch die Sache mit dem &20 Ready aendern?

[TFM]

Soll ich jetzt noch die Sache mit dem &20 Ready aendern?

Lass uns das erst mal gedanklich durchspielen, wir wollen ja auch kompatibel bleiben. Bitte um Ideen ;-)

Nebenbei, das hier können wir dank LS ja jetzt besser...

[LambdaMikel]

Top! Aber schwierig zu verstehen...ja LS würde etwas verständlicher klingen 

OK, dann lassen wir's erstmal so. Du kannst ja sonst zur Sicherheit immer STOP senden um nicht in die Warte-Situation zu kommen.

[TFM]

Momentan bin ich Dank der Hitze meist recht lätscherd (= faul, träge, unlustig). Bin froh, wenn die Dinge laufen. Mir ist's lieber mal ein paar kleine sichere Schritte vorwärts zu machen, als nochmal etwas "größeres" zu ändern. Das können wir aber immer noch machen. 

Wegen dem KCc (siehe viele Mitteilungen hier zuvor), da weiß ich nicht wo ich ansetzen soll. Es geht ja auch nicht, dass ich dem Rennert mal schnell 21 DSKs schicke und sage "Guck mal, ob eines davon funktioniert". Mal sehen, ob da noch jemand von Euch eine zündende Idee hat. 

[LambdaMikel]

Momentan bin ich Dank der Hitze meist recht lätscherd (= faul, träge, unlustig). Bin froh, wenn die Dinge laufen. Mir ist's lieber mal ein paar kleine sichere Schritte vorwärts zu machen, als nochmal etwas "größeres" zu ändern. Das können wir aber immer noch machen. 

Wegen dem KCc (siehe viele Mitteilungen hier zuvor), da weiß ich nicht wo ich ansetzen soll. Es geht ja auch nicht, dass ich dem Rennert mal schnell 21 DSKs schicke und sage "Guck mal, ob eines davon funktioniert". Mal sehen, ob da noch jemand von Euch eine zündende Idee hat. 

Die einzige Idee die ich noch hätte wäre ihm eine Version der |eeup etc. Kommandos bereitzustellen, die es ermöglicht, Verzögerungszeiten einzustellen. Könnte ja gerne einfach eine Reihe von 16 Bit Wert irgendwo im Speicher sein den man von BASIC aus POKEn kann und der dann zu Verzögerungen in ms o.ä. an kritischen Programmstellen z.B. bei EEUP und EEGET führt (Verzögerung nach 256 bzw. 512  gelesenen / gesendeten Bytes etc.) Dann könnte er ausprobieren mit welchen Werten es funktioniert und wir hätten ne Idee.

Programmmäßig wäre das ja einfach nur ein Unterprogramm CALL an bestimmten Stellen, sollte also nicht zu schwierig sein das einzubauen. Und falls Unterprogrammaufrufe den Stack durcheinanderbringen, hat der MAXAM eigentlich Macros?

Wie viel muss man denn zählen beim CPC damit 1 ms Verzögerung kriegt in Z80?

Muss mal wieder in die Sourcen gucken am WE - machst Du inzwischen die Verzögerung nach 512 gesendeten Bytes bei EEGET und RESUME (und natürlich auch bei EEUP und HIBERNATE nach 256 Bytes? )

Ich weiß, Du kanst kein C lesen, aber hier ist nocheinmal die Schleife für EEGET und RESUME funktioniert genauso, siehe C-Kommentare; Details sind nicht so wichtig, einfach nur den groben Ablauf angucken und die Kommentare sind das wichtigste:

Code Select Expand


  // bis all bytes gesendet:
  while (pcm1_address < pcm1_endAddress) {

   // 0 auf den Bus -> busy
    speech_native_busy; 

   // CPC anhalten, Puffer mit EEPROM DAten füllen
    z80_halt;

    EEPROM_PCM_PLAY_ON;

    SLAVE_SELECT;
    SPI_tradeByte(EEPROM_READ);
    EEPROM_send24BitAddress(pcm1_address);

    for (uint16_t i = 0; i < ((uint16_t) EEPROM_BYTES_PER_PAGE * 2); i++)  {
      SPI_tradeByte(0);
      byte = SPDR;
      if (i < SEND_BUFFER_SIZE) {
send_msg[i] = byte;
      } else {
buffer[i - SEND_BUFFER_SIZE] = byte;
      }
      pcm1_address++;
    }

    SLAVE_DESELECT;
    LAMBDA_EPSON_ON;
 
    // Puffer ist gefüllt, Z80 weiterlaufen lassen
    z80_run;
   
    // &20 auf den Bus -> bereit, nächste Seite zu lesen
    speech_native_ready; 

   // für 512 Bytes:
    for(uint16_t i = 0; i < ((uint16_t) EEPROM_BYTES_PER_PAGE * 2); i++)  {

      // LEDS_ON;

     // warte bis nächstes Byte angefordert wird mittels out &fbee,<beliebig>
      loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
      loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);

      // z80_halt;

      // LEDS_OFF;
   
      if (i < SEND_BUFFER_SIZE) {
byte = send_msg[i];
      } else {
byte = buffer[i - SEND_BUFFER_SIZE];
      }
   
     // lege das nächsste Byte aus dem Puffer auf den Bus
      DATA_TO_CPC(byte);   

      // z80_run;
   
    }

    // Seite komplett gesendet, mach weiter in WHILE Schleife oben
    // bis alle Bytes gesendet worden sind -
   // kuze Verzögerung hier (fast / slow / medim getters!!) da oben
   // gleich wieder 0 für Busy und dann &20 für READY auf dem Bus
   // erscehint, und wir dürfen das 512. Byte der Seite ja nicht verpassen
   
   // HIER muss der CPC nun etwas warten, obwohl ich ihn ja sogar anhalte...

    // needed, otherwise the last byte will not appear long enough on the databus!
    CPC_READ_DELAY;

  }




Und hier ist nocheinmal die UPLOAD EEUP  / HIBERNATE Prozedur - bitte beachten, hier sind es 256 Bytes, nicht 512 nach denen eine kleine Verzoegerung erfolgen sollte:

Code Select Expand


  uint8_t byte = 0;

  // bis noch nicht alle Bytes gesendet wurden:
  // EVTL. SOLLTE ICH HIER BUSY (0) auf den Bus legen, damit Du nicht zu früh sendest!
  // Werde ich noch einmal ändern...

  while (pcm1_address < pcm1_endAddress) {

    EEPROM_writeEnable();
    SLAVE_SELECT;
    SPI_tradeByte(EEPROM_WRITE);
    EEPROM_send24BitAddress(pcm1_address);
 
   // Bereit für 256 Bytes -> &20 auf den Bus
    speech_native_ready; 

    // Empfange 256 Bytes:
    for (int i = 0; i < EEPROM_BYTES_PER_PAGE; i++) {
      z80_run;
      // warte auf Byte mittels out &fbee,<byte>
      loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);
      loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
     // z80 anhalten
      z80_halt;
      // _delay_us(3);
     // byte einlesen, liegt ja auf dem Datenbus
      DATA_FROM_CPC(byte);             
     // byte ins EEPROM schreiben
      SPI_tradeByte(byte);

      pcm1_address++;
    }
    // EEPROM seite vollends gesendet (256 bytes), jetzt 0 auf den Bus -> BUSY
    speech_native_busy; 

    // WARTEN bis EEPROM Puffer weggeschrieben wurde
    SLAVE_DESELECT;
    while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};

  // bis alle Seiten geschrieben worden sind (s. WHILE oben)
  }

   // alle Bytes wurden gesented -> Busy
  speech_native_busy; 
   // anhalten, dann Bestätgung sprechen etc., zurück
  z80_halt;


Ganz klar, SENDE der Daten ist einfacher, da Du nicht zwischen READY/ BUSY und Nutzbyte auf dem Datenbus unterscheiden musst.

Ich moechte die Firmware ungerne noch aendern. Sonst koennten wir auch probieren, ob wir aus BUSY und READY komplett verzichten, oder ob ich nicht Z80 RUN und HALT konsistent und brutal verwende. Oder aber HALT und RUN komplett raus. Momentan wird beides verwendet, was etwas inkonsistent ist.

Na, kann ja auch verstehen, wenn Du erstmal keinen Bock mehr hast auf das Problem - ich kann mich ja auch noch mal ransetzten irgendwann, aber momentan arbeite ich an einem MIDI IN fuer den CPC, sodass man AY mittels Keyboard spielen kann. Das geht auch nur in Z80, gar nicht so einfach fuer einen wie mich!

[TFM]

Das könnte helfen...

[LambdaMikel]

Würde also 4 16 Bit Werte v1, v2, v3, v4 vorschlagen:

- EEGET, RESUME: Leseverzögerung in v1 us nach jedem Byte. Default 5 us.
- EEGET, RESUME: Leseverzögerung in v2 ms nach 512 Bytes. Default 50 ms.
- EEUP, HIBERNATE: Schreibverzögerung in v3 us nach jedem Byte. Default 5 us.
- EEUP, HIBERNATE: Schreibverzögerung in v4 ms nach 512 256 (!) Bytes. Default mit 50 ms. 

[Rennert]

Wenn ich ausm Urlaub wieder da bin, kann ich auch wieder testen.

[LambdaMikel]

Genau, aber zuerst sollte es einmal bei mir funktionieren. Wenn es auf einem normalen CPC nicht richtig funktioniert, brauchst gar nicht est testen am KC Compact...