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

[LambdaMikel]

|pcmup hat einen Fehler - das letzte Byte wird nicht richtig gesendet! Bitte einmal nachsehen. S. Testprogramm EEPROM.BAS, das |pcmup verwendet, und das den Fehler zeigt - das letzte gelesene Byte der Seite (Adr. 511 = 512. Byte) ist nicht 255, sollte es aber sein. Bitte einmal nachschauen, wo der Fehler in |pcmup ist (bei PCM Samples ist das natürlich egal da man das eine Byte eh nicht hört, aber bei Daten kann es natürlich fatal sein).

Das scheint mein Fehler zu sein... stay tuned :-)

[LambdaMikel]

OK, neuste Version anbei.

Änderungen:
- neues Command: speak temperature &D1. S. BASIC-Testprogram "SAYTEMP.BAS" auf LS300.DSK anbei.
- F7 (eeprom get data) nimmt jetzt 2 Argument: Start-Seite und Anzahl Seiten.
  Danach werden alle Daten der Seiten nach und nach rausgeschrieben; nächstes
  Byte wird per "Handshake" angefordert (out &fbee,<beliebig>)
  Wichtig, bitte beachten: nach 512 Bytes (also nach dem das letzte Byte einer Seite
  gelesen wurde), MUSS etwas gewartet werden, bevor das nächste Byte mittels
  out &fbee,<beliebig> angefordert werden kann. Das liegt daran, dass der ATMega
  etwas Zeit braucht, um die nächste Seite zu puffern. Bitten einmal in eeprom3.bas
  und eeprom.bas nachschaeuen; die funktionieren jetzt beide, aber nur, wenn man etwas
  wartet. Im BASIC-Progamm reicht es, wenn man ein print "wait wait wait" einbaut.
  Ohne dieses print  zur Verzögerung ist das erste Byte der nächsten Seite falsch.
  Bitte beachten - hier "READY" und "BUSY" einzufügen bringt nichts, da ich dann ja
  das aktuell gelesen Byte aus dem EEPROM welches als letztes auf den Datenbus gebracht
  wurde, überschreibe. Also lieber so.
- Bugfixes im Serial Buffer
- Neu: PCMPLAYMODE kann nun verlassen werden, indem man channel 255 sendet!
  Das ist ein RESET.
  S. DRUMMER3.BAS auf MIDEFSEQ2.DSK (angehängt).

Also, für mich wär es das erst einmal. Bitte Bescheid sagen, ob alles funktioniert.

Zusätlich gilt: getfullmode wie oben beschrieben 8bittig, und PCMUP und EEPROMUP
sollten verschieden sein ( eeprom_pcm_upload_mode(1) vs. eprom_pcm_upload_mode(0) für PCM-Test des hochgeladenen Samples).

[TFM]

|pcmup hat einen Fehler - das letzte Byte wird nicht richtig gesendet! Bitte einmal nachsehen. S. Testprogramm EEPROM.BAS, das |pcmup verwendet, und das den Fehler zeigt - das letzte gelesene Byte der Seite (Adr. 511 = 512. Byte) ist nicht 255, sollte es aber sein. Bitte einmal nachschauen, wo der Fehler in |pcmup ist (bei PCM Samples ist das natürlich egal da man das eine Byte eh nicht hört, aber bei Daten kann es natürlich fatal sein).

Nein, !PCMUP funktioniert super, genau so wie !EEUP. Das habe ich gerade mit !EEGET getestet. Der Fehler liegt im BASIC Programm.

Anbei das neue RSX ROM...

Achtung: Stand von gestern! Heutige neue Firmware habe ich noch nicht geladen (mach ich gleich).

[TFM]

  Wichtig, bitte beachten: nach 512 Bytes (also nach dem das letzte Byte einer Seite
  gelesen wurde), MUSS etwas gewartet werden, bevor das nächste Byte mittels
  out &fbee,<beliebig> angefordert werden kann. Das liegt daran, dass der ATMega
  etwas Zeit braucht, um die nächste Seite zu puffern. Bitten einmal in eeprom3.bas
  und eeprom.bas nachschaeuen; die funktionieren jetzt beide, aber nur, wenn man etwas
  wartet. Im BASIC-Progamm reicht es, wenn man ein print "wait wait wait" einbaut.
  Ohne dieses print  zur Verzögerung ist das erste Byte der nächsten Seite falsch.
  Bitte beachten - hier "READY" und "BUSY" einzufügen bringt nichts, da ich dann ja
  das aktuell gelesen Byte aus dem EEPROM welches als letztes auf den Datenbus gebracht
  wurde, überschreibe. Also lieber so.

Ok, wie lange muß man denn da warten? Bitte sag mit mal wie viele Mikrosekunden das minimal sein müssen. Ich hab jetzt keine Lust schon wieder eine Stunde damit zu verbringen zum testen wo und wann ich wie lange warten muss. Was dem LambdaSpeak III wirklich fehlt sind klare Kommunikations-Protokolle. Nix für ungut. 

EDIT: Wiso machst es denn nicht einfach so:
Sobald die nächste Seite zum lesen angefordert wird, setzt der LS3 den Status auf &00 (beschäftigt), und zwar so lange bis die neue Seite zur Verfügung steht. Nur so eine Idee. 

EDIT 2: NOCH BESSER! Nach dem lesen des letzten Bytes sendet man &00 an den LS3, dann weiß er, dann man das letzte Byte gelesen hat. Und er kann auf "beschäftigt" springen. Und dann wartet man einfach bis der LS3 mit z.B. &20 wieder Bereitschaft meldet, anschließend wird weiter gelesen. Na? 

EDIT 3: u.U ist EDIT besser als EDIT2 Bei 36 Grad kann man schlecht denken. 

[TFM]

PCMUP und EEPROMUP sollten verschieden sein ( eeprom_pcm_upload_mode(1) vs. eprom_pcm_upload_mode(0) für PCM-Test des hochgeladenen Samples).

??

[LambdaMikel]

  Wichtig, bitte beachten: nach 512 Bytes (also nach dem das letzte Byte einer Seite
  gelesen wurde), MUSS etwas gewartet werden, bevor das nächste Byte mittels
  out &fbee,<beliebig> angefordert werden kann. Das liegt daran, dass der ATMega
  etwas Zeit braucht, um die nächste Seite zu puffern. Bitten einmal in eeprom3.bas
  und eeprom.bas nachschaeuen; die funktionieren jetzt beide, aber nur, wenn man etwas
  wartet. Im BASIC-Progamm reicht es, wenn man ein print "wait wait wait" einbaut.
  Ohne dieses print  zur Verzögerung ist das erste Byte der nächsten Seite falsch.
  Bitte beachten - hier "READY" und "BUSY" einzufügen bringt nichts, da ich dann ja
  das aktuell gelesen Byte aus dem EEPROM welches als letztes auf den Datenbus gebracht
  wurde, überschreibe. Also lieber so.

Ok, wie lange muß man denn da warten? Bitte sag mit mal wie viele Mikrosekunden das minimal sein müssen. Ich hab jetzt keine Lust schon wieder eine Stunde damit zu verbringen zum testen wo und wann ich wie lange warten muss. Was dem LambdaSpeak III wirklich fehlt sind klare Kommunikations-Protokolle. Nix für ungut. 

Das weiss ich leider auch nicht. Sollte nicht so lange dauern, das rauszukriegen... vielleicht 10 ms ?
Die Zeit die das print "wait wait wait" im EEPROM[3].BAS benötigt ist ausreichend.

Wie gesagt, aufgrund von Hardware-Beschränkungen geht es leider nicht anders.

[LambdaMikel]

PCMUP und EEPROMUP sollten verschieden sein ( eeprom_pcm_upload_mode(1) vs. eprom_pcm_upload_mode(0) für PCM-Test des hochgeladenen Samples).

??

Wie gesagt, einziger Unterschied zwichen PCMUP und EEPROMUP ist FE vs. F9.


    case 0xFE : eeprom_pcm_upload_mode(1); break;
    ....
    case 0xF9 : eeprom_pcm_upload_mode(0); break;

FE kennst Du ja schon, un nach dem Uploaden eines PCM-Samples wird das Sample 5mal zum Testen ausgeben auf dem Lautsprecher.
F9 macht genau das gleiche, ABER macht keinen Sample Test. Das ist alles. Protokoll und alles identitisch.  Du kannst also einfach den gleichen RSX code verwenden für EEPROMUP wie für PCMUP verwenden, aber statt me FE halt mit F9 aufrufen.

[LambdaMikel]

|pcmup hat einen Fehler - das letzte Byte wird nicht richtig gesendet! Bitte einmal nachsehen. S. Testprogramm EEPROM.BAS, das |pcmup verwendet, und das den Fehler zeigt - das letzte gelesene Byte der Seite (Adr. 511 = 512. Byte) ist nicht 255, sollte es aber sein. Bitte einmal nachschauen, wo der Fehler in |pcmup ist (bei PCM Samples ist das natürlich egal da man das eine Byte eh nicht hört, aber bei Daten kann es natürlich fatal sein).

Nein, !PCMUP funktioniert super, genau so wie !EEUP. Das habe ich gerade mit !EEGET getestet. Der Fehler liegt im BASIC Programm.

Anbei das neue RSX ROM...

Achtung: Stand von gestern! Heutige neue Firmware habe ich noch nicht geladen (mach ich gleich).

Genau, habe ich ja oben auch geschrieben und rausgefunden beim Testen... es war die Verzögerung für letztes Byte der Seite... Nix für Ungut 

[LambdaMikel]

EDIT: Wiso machst es denn nicht einfach so:
Sobald die nächste Seite zum lesen angefordert wird, setzt der LS3 den Status auf &00 (beschäftigt), und zwar so lange bis die neue Seite zur Verfügung steht. Nur so eine Idee. 

Das können wir machen... wenn das für Dich einfacher ist nach Byte 512 wieder auf READY zu warten. Damit BASIC das letzte Byte mitkriegt, muss ich hier dennoch 10 ms (slow getters) bzw. Zeit für fast getters warten nach dem letzten Byte, sonst würde ich ja sofort nach dem letzten Byte of BUSY schalten und das Byte wäre verloren. Also würdest Du lieber auf READY warten statt Warteschleife. OK.

[TFM]

Wie gesagt, aufgrund von Hardware-Beschränkungen geht es leider nicht anders.

Doch, bitte siehe editierter Post von mir oben :-)

[LambdaMikel]

Wie gesagt, aufgrund von Hardware-Beschränkungen geht es leider nicht anders.

Doch, bitte siehe editierter Post von mir oben :-)

OK, hast Recht  Anbei.
Nach dem letzten gelesen Byte einer Seite kommt also BUSY (=0). Und dann also mit dem lesen des ersten Bytes der nächsten Seite warten, bis wieder READY erscheint (32).

Problematisch "letzte Bytes" könnten also 32 oder 0 sein... bei 32 sicherstellen, dass Du es nicht für READY hälst (erst musst Du die 0 kurz sehen), und bei 0 als letztem Byte ist es eigentlich kein Problem. In jedem Fall warten bis 32 wieder da ist.

[TFM]

Welche von den beiden Ideen hast denn jetzt genommen? 

[LambdaMikel]

EDIT 2 und EDIT 3 lese ich jetzt erst. Also diese Version ist EDIT.
Was immer für Dich besser ist!  EDIT sollte doch gehen hoffe ich.

An EDIT3 hatte ich gesten auch gedacht, aber dann hat man einen Handshake für "nächste Seite starten" der "nix sendet" statt einen Handshake für "nächstes Byte". Handshake für "nächstes Byste" find ich einfacher. Aber wie Du willst!

[LambdaMikel]

Hier ist mal der Code für EDIT:

Code Select Expand


  //
  // read pages
  //

  pcm1_address      =  ( ( (uint32_t) EEPROM_BYTES_PER_PAGE * (uint32_t) startPage ) << 1 );
  pcm1_endAddress   =  ( ( (uint32_t) EEPROM_BYTES_PER_PAGE * (uint32_t) (startPage + pages)) << 1 );

  while (pcm1_address < pcm1_endAddress) {

    // phase 1 - read next page from EEPROM into BUFFER

    speech_native_busy; 

    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;

    // phase 2 - CPC requests one page from buffer, using handshaking

    LAMBDA_EPSON_ON;
 
    usart_input_buffer_index = 0;

    z80_run;

    speech_native_ready; 


    for(uint16_t i = 0; i < ((uint16_t) EEPROM_BYTES_PER_PAGE * 2); i++)  {

      LEDS_ON;

      loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
      loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);

      z80_halt;

      LEDS_OFF;
   
      if (usart_input_buffer_index < SEND_BUFFER_SIZE) {
byte = send_msg[usart_input_buffer_index];
      } else {
byte = buffer[usart_input_buffer_index - SEND_BUFFER_SIZE];
      }
      usart_input_buffer_index++;
   
      DATA_TO_CPC(byte);   
      z80_run;
   
    }

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

  }


  //
  //
  //
 
  command_confirm("EEPROM data sent.");

  return;
[code]



[TFM]

Sorry, aber C kann ich nicht lesen. Irgendwann sollten wir da ja (so 2021 oder so) man in ATmega Assembler umwandeln, den krieg ich noch so hin. Aber Zukunftsmusik beiseite... C sagt mir hald gar nichts. Also... wie macht das EEGET das denn jetzt?