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

[LambdaMikel]

Also, Zeit-Daten werden bei "1" gelesen, richtig?

Richtig. Allerdings weisst Du nicht, ob Du nicht evtl. "32" für hours oder minutes liest, BIS du auch 255 gesehen hast. Die 255 sagt Dir - hoppla, der Wert VORHER war der richtig Wert. 255 kann ja bei den Uhrzeit-Funktionen nie als Wert zurückkommen für hours, minutes, ... Das hat hier also Synchronisationsbyte-Funktion. Und hast zudem den Vorteil, dass wenn Du die obige Schleife "read until 255" implementierst, es auch egal ist, für wie lange der Wert hours / minutes / ...  auf dem Bus erscheint. Du musst nur sicherstellen, dass Du den Bus oft genaug samplest, damit Du in jedem Fall die Übergänge <wert> -> 255 -> 0 -> READY mitkriegst. Falls Du natürlcih 255 "verpasst", ist es leider schlecht, und wir müssten evtl. die Zeit, für die <wert> auf dem Bus erscheint, verlängern. Dann evtl. slow getters verwenden statt fast getters, damit bleibt <wert> ja 10 ms auf dem Bus, und das sollte wirklich genug Zeit sein, um <wert> zu lesen.

Wenn ich also 32 lese, dann ist der LS3 noch nicht bei "1" angekommen. Die Firmware ist zu langsam. Wäre keine Problem, könnte man länger warten, aber es ist unterschiedlich. Problem: Die Wartezeiten unterscheiden sich.

Fast richtig. Wie gesagt, Du kannst Dir nur sicher sein dass Du den Wert für hours, minutes, ... WIRKLICH gelesen hast, wenn Du 255 siehst. Dann ist es der Wert, den Du VOR 255 gelesen hast. Wenn Du nur 32 siehst, und nicht auf 255 testest, kann es eben auch sein, dass Du den Wert bereits verpasst hast... oder dass 32 der Wert selbst ist. Genau dafür haben wir eben 255 im Datenstrom. 

Nur auf 32 zu testen ist also nicht ausreichend - es muss wirklich der Übergang <wert> -> 255 erkannt werden.

Und bei Punkt "5": Müsste da nicht &20 oder &80 auf dem Bus sein?

Nein, vorher kommt noch mal 0, dann kommt erst das Ready-Signal. Du kannst Die 0 bei 5. allerdings ignorieren, und nachdem Du 255 gelesen hast, einfach wieder Warten bis Du wieder READY (= 128 oder 32) siehst. Es schien mir nur praktisch, auch 0 zu senden, da ja je nach Mode das READY verschieden ist.

[LambdaMikel]

PS Stefan, mach Dir keinen Stress... ich lade heute Abend mal ein Stück Z80 hoch dass das Uhrzeit lesen nach dieser Methode demonstriert. Dann werde ich ja sehen, ob es Problem gibt, und ob wir evtl. die Zeiten für fast getters verlängern müssen.

Das Problem, dass die Zeiten für die Firmware Calls (selbst für die gleiche FunktioN!) u.U. immer unterschiedlich lang brauchen ist leider kaum zu beheben für mich: das Uhr-Modul hat seinen eigenen Takt und u.U. nicht-deterministitische Verzögerungen, dann ist LS 3 nicht synchron mit dem CPC getaket, dann können noch Interrupts ne Rolle spielen im ATMega, etc.

[LambdaMikel]

Wow, was ist hier denn passiert... der Server hat alles Beitraege der letzten 3 Tage geloescht??
Technisches oder Backup Problem oder sonstiges Admin Problem?

@Rennert, melde Dich mal wenn Du rausgefunden hast, ob EEPROM2, 3, 4 bei Dir laufen, und drumld2.bas.

[TFM]

Ja, irgendwie fehlt hier einiges. Hauptsache die Firmware ist verfügbar. 

EDIT: Am Server gibt's auch Probleme, hier das neueste ROM...

[LambdaMikel]

Ja, irgendwie fehlt hier einiges. Hauptsache die Firmware ist verfügbar. 

EDIT: Am Server gibt's auch Probleme, hier das neueste ROM...

Danke dafür, gucke mir gerade mal |RESUME an.
Einige Beobachtungen:
- der Lese-Code für RESUME ist unterschiedlich zu EEGET.
- der Code von EEGET gefällt mir besser, da Du hier nach 512 gelesenen Bytes mittels CALL LS_WALP eine Warteschleife hast (CALL LS_WALP). Bei RESUME zählst Du nicht in 512er Seiten, sondern mittels DE global die Anzahl der Bytes, und machst keine Pause nach 512. Das könnte das Synchronisationsproblem erklären. OK, Du machst in jedem Schritt Test auf READY, allerdings brauchen wir nach 512 Bytes wie gesagt eine zusätzliche Pause... nach READY müssen wir noch etwas warten.
- noch besser wäre, nach 512 Bytes pro Seite nach dem CALL LS_WALP *zusätzlich* noch einige us zu Warten. Vielleicht 20?
- ich verstehe nicht, wie mittels RESUME die Register wieder hergestellt werden. Warum tauscht Du den Registersatz aus mit EXX? Ich sehe auch nicht, wie in HIBERNATE die Register gesichert werden. 

Screenshots anbei.

[Rennert]

ja meine Beiträge sind auch weg.

erstmal musste ich die Rom aufs X-Mem machen, da ja das M4 Rom nicht unterstützt wird beim drumld2. bei eeprom auch?

also eeprom2 fängt an, kommt auch ne kurze Spracheinlage zwischendurch, dann passiert nix mehr
eeprom3 macht auch nix
eeprom4 bringt nen * dann 23 und ne kurze Spracheinlage und nix mehr dann.
in allen Fällen kann ich noch Reset mit Tastenkombi machen, also kein voller Hänger.
drumld2 lädt den ersten Track, dann passiert nix mehr.

habe auch mal alle Module außer X-Mem und LS3 entfernt, das LS3 an den ersten Steckplatz unbuffered gesteckt, das ist nicht das Problem.

[LambdaMikel]

ja meine Beiträge sind auch weg.

erstmal musste ich die Rom aufs X-Mem machen, da ja das M4 Rom nicht unterstützt wird beim drumld2. bei eeprom auch?

also eeprom2 fängt an, kommt auch ne kurze Spracheinlage zwischendurch, dann passiert nix mehr
eeprom3 macht auch nix
eeprom4 bringt nen * dann 23 und ne kurze Spracheinlage und nix mehr dann.
in allen Fällen kann ich noch Reset mit Tastenkombi machen, also kein voller Hänger.
drumld2 lädt den ersten Track, dann passiert nix mehr.

habe auch mal alle Module außer X-Mem und LS3 entfernt, das LS3 an den ersten Steckplatz unbuffered gesteckt, das ist nicht das Problem.

@rennert, eeprom3 kann eigentlich nicht haengen. die einzigen stellen wo es haengen koennte sind die wait statements. der rest ist ja einfach nur basic. kannst du bitte einmal rausfinden, wo es haengt, in welcher zeile. zum debugging kannst du sonst ja auch print statements einfuegen, z.b. in die 2. schleife. waere sehr wertvoll rauszukriegen woran es liegt.

und ja, es laeuft ewig, ohne output unter umstaende. wo haengt es denn.

und drumload.bas ist ebenfalls nur basic. das sollte auch nicht haengen. wie gesagt, es dauert ewig bis ein sample von basic aus hochgeladen ist. auch hier koennen print statements helfen um zu sehen, ob es noch laeuft.

ausserdem - wenn basic auf escape key reagiert, haengt es nicht in wait statements, sondern macht was.

[Rennert]

 Bei eeprom4 hatte ich es ja geschrieben wo es nicht mehr weitergeht. Du hattest ja gesagt, das pro Prog 5-10minuten durchlaufen. Hab auch schon ne halbe Stunde gewartet.
Bei eeprom3 habe ich nie nen wait gesehen.
Die LEDs am Mäusekino verändern sich auch nicht mehr.
Werde mal paar Prints einbauen

[Rennert]

So:

Eeprom2: hängt bei Zeile50 EEUP
Eeorom3: bei Zeile 70 erstes WAIT
Eeprom4: bei Zeile100 EEUP

Abbruch per Escape geht nicht mehr. Also nur noch Softreset

[LambdaMikel]

Eeorom3: bei Zeile 70 erstes WAIT

wow... bitte mal print inp(&fbee) einbauen. vor dem wait:

65 print inp(&fbee):goto 65

das heisst ja, dass er nicht mal das ready signal auf dem bus sieht!
da scheint ja etwas fundamental im argen zu sein.

ls3 firmware ist die letzte version, v39?

und wie geht denn drumload.bas

[Rennert]

ja V39 ist geflasht.
drumld2 fängt an den ersten Track zu laden, dann hängts. Mein alter Beitrag ist ja weg, da hatte ich das auch schon geschrieben.

teste gleich mit der Ergänzung.
Erst paar 0, dann immer 128

[LambdaMikel]

OK, 128... na das ist gut.
Was ich nicht verstehe ist dann - warum haengt er dann bei WAIT &FBEE,128 ?
Geht das WAIT beim KC Kompakt u.U. nicht? Macht keinen Sinn...

ich hatte gesagt "drumload.bas' nicht "drumld2.bas". ersteres verwendet NUR BASIC, kein TFM RSX.

[Rennert]

Nachdem ich zweimal mit Zeile 65 gestartet habe, habe ich mit Esc gebrakt. Dann Zeile 65 in Print"1" geändert und nochmal run. Das eeprom3 lief durch mit paarmal Wait.
Ich denke es hängt, weil am Anfang 0 ist. Print inp bringt am Anfang ca. 12 Nullen bis 128 kommt.

[LambdaMikel]

nein, das ist voellig egal was auf dem bus ist.
wait sollte solange warten, bis 128 auf dem bus ist, sonst waere das kommand ja voellig ueberfluessig.
ich denke, das ist ein bug im kc compact...

hast du nicht auch einen cpc? damit mal probieren.

und dann koenntest du ja auch mal probieren, was passiert, wenn du wait &fbee,x
gegen
10 if inp(&fbee)<>x then 10

ersetzt.

[Rennert]

das Problem hatte ich bei RTC.bas damals schon.

hatte dann ne Zeile geändert. da war wd=inp(&fbee) drin und ich habe dann ne Schleife gemacht, wenn der Wert abweicht. Teste gleich mal deine Zeile.

in welcher Datei waren denn die EEPROM.BAS Dateien? Finde die aufm PC nicht mehr. Habs nur noch aufm Stick am KCC