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

[TFM]

ok, jetzt musst du nur noch tfm triggern, dass er das timing fuer den kc compact anpasst (laenger macht?) damit eeup, eeget, pcmup, hibernate, resume gehen. 

Welche der RSX Befehle gehen denn beim KCc nicht?

[LambdaMikel]

- 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.

Und wie lange (in us) soll die Pause sein?

Klar ist der Code anders, würde man bei !RESUM einen CALL verwenden so würde ein Wert auf den Stack geschrieben. Das wäre in den Fall eine Crash-Garantie.

Habe ich doch geschrieben... so 10 ms sollten reichen. Wenn nicht, 10 ms 



Ja aber Du koenntest ja trozdem die Pause machen nach 512 Bytes, das ist mein Hauptkritikpunkt 

EDIT: ZUmindest dacht ich das. Ich wuerde erst einmal mit 10 ms probieren, dann 20 ms, ... die Pause wird benoetigt, da der ATMega Daten vom EEPROM puffern muss, und das Lesen dauert ein bisschen. Ich weiss leider nicht, wie lange.  Selbst wenn es 10 ms sind nach 512 bytes, addiert sich das ja nur zur ne zusaetzlichen Sekunde oder zweien. 

In BASIC reicht die Zeit, die das print "wait wait wait" benoetigt, ich denke also, es ist im zweistellinge millisekunden bereichl

[Rennert]

PCMMode, eeget, eeput hängen den KCC auf. Hibernate und resume gehen daher auch nicht.

Du meinst PCMUP? PCMPLAY / PCMMODE sollte den KC nicht aufhaengen...

[TFM]

Nun, es geht ja auch ohne Pause wie man sieht, wenn Pause, dann einmal am Ende, aber auch das hab ich getestet und es ist einfach nur ominös. Also Du sagst 10 ms. Na gut ich teste das dann nochmals.

- 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.

Und wie lange (in us) soll die Pause sein?

Klar ist der Code anders, würde man bei !RESUM einen CALL verwenden so würde ein Wert auf den Stack geschrieben. Das wäre in den Fall eine Crash-Garantie.

Habe ich doch geschrieben... so 10 ms sollten reichen. Wenn nicht, 10 ms 



Ja aber Du koenntest ja trozdem die Pause machen nach 512 Bytes, das ist mein Hauptkritikpunkt 

EDIT: ZUmindest dacht ich das. Ich wuerde erst einmal mit 10 ms probieren, dann 20 ms, ... die Pause wird benoetigt, da der ATMega Daten vom EEPROM puffern muss, und das Lesen dauert ein bisschen. Ich weiss leider nicht, wie lange.  Selbst wenn es 10 ms sind nach 512 bytes, addiert sich das ja nur zur ne zusaetzlichen Sekunde oder zweien. 

In BASIC reicht die Zeit, die das print "wait wait wait" benoetigt, ich denke also, es ist im zweistellinge millisekunden bereichl

[TFM]

ok, jetzt musst du nur noch tfm triggern, dass er das timing fuer den kc compact anpasst (laenger macht?) damit eeup, eeget, pcmup, hibernate, resume gehen. 

Welche der RSX Befehle gehen denn beim KCc nicht?

PCMMode, eeget, eeput hängen den KCC auf. Hibernate und resume gehen daher auch nicht.

Nur um sicher zu sein, hast es mal so ausprobiert: !LSINIT zuvor eingegeben?

[TFM]

Kann es sein, dass man die RTC nicht lesen kann wenn Kommando &F4 zuvor gesendet wurde?
(Nicht, dass das jetzt wichtig wäre). 

[LambdaMikel]

In BASIC reicht die Zeit, die das print "wait wait wait" benoetigt, ich denke also, es ist im zweistellinge millisekunden bereichl

Der Effekt kann ganz gut beobachtet werden - nimm aus EEPROM3.BAS mal das print wait wait wait raus, und dann siehst Du, dass es zu Lesefehlern kommt beim ersten Byte der naechsten Seite oder so.

Wohlgemerkt, wenn sogar das lahme BASIC Lesefehler feststellt, dann treten diese erst recht in MC auf denke ich.

[LambdaMikel]

Kann es sein, dass man die RTC nicht lesen kann wenn Kommando &F4 zuvor gesendet wurde?
(Nicht, dass das jetzt wichtig wäre). 

Koennte sein, habe ich nicht getestet.

[LambdaMikel]

PCMMode, eeget, eeput hängen den KCC auf. Hibernate und resume gehen daher auch nicht.

Du meinst PCMUP? PCMPLAY / PCMMODE sollte den KC nicht aufhaengen...

[LambdaMikel]

Klar ist der Code anders, würde man bei !RESUM einen CALL verwenden so würde ein Wert auf den Stack geschrieben. Das wäre in den Fall eine Crash-Garantie.

Warum das denn... der CALL kehrt doch mit RET wieder zurueck und dann ist auch der Stack wiederhergestellt.... und im letzten SChritt wenn alles eingelesen ist holst Du Dir den SP doch aus dem RAM...  Du meinst weil der Stackbereich im RAM evtl. "seitenueberlappend" (also ueber 2 Seiten verteilt) wieder hergestellt wird? Sollte ein CALL / RET zwischen Seiten/RAM-Veraenderungen nicht trotzdem problemlos gehen?  Ach so... der RAM Stackbereich passt nicht mehr zum Stackpointer, und der Stackpointer wird erst am Ende wieder hergestellt.

Verstehe! Gute Beobachtung, pfiffig!! 

[Rennert]

ok, jetzt musst du nur noch tfm triggern, dass er das timing fuer den kc compact anpasst (laenger macht?) damit eeup, eeget, pcmup, hibernate, resume gehen. 

Welche der RSX Befehle gehen denn beim KCc nicht?

PCMMode, eeget, eeput hängen den KCC auf. Hibernate und resume gehen daher auch nicht.

Nur um sicher zu sein, hast es mal so ausprobiert: !LSINIT zuvor eingegeben?

Ich teste zuhause nochmal alles, ja Lsinit mache ich immer vorher.
Nach Z.B. PCMMODE, 4 kam kein Cursor mehr.

Andere Frage: Was hört man bei Pcmtest? Ich verstehe den Satz nicht als Deutscher

[LambdaMikel]

S. Video YOuTUbe oben - Dillinger talks to the MCP - "End of line"

Ich kann Dir ja mal ein PCMTEST EEPROM passend zum KC Kompakt machen - wuerde Dir das besser gefallen?

[CPCEmulator]https://youtu.be/VphPebctAsM[/CPCEmulator]

Nix fuer ungut  - Spass muss sein!

[Rennert]

Ahhh, habe immer End the line verstanden. Also funzt der PCMTest.

[Rennert]

habe mal im X-Mem alles auser FOS, LS3 Rom und Parados deaktiviert.
beim drumload hat er mal die Files geladen, aber alle 1110 bytes und hat sie beim Laden richtig abgespielt.dann bei drummer gingen nur die ersten 3 Files, die restlichen waren leer.
habe mal den Rechner ausgemacht und neu an. jetzt lädt er wieder nur mit 0 bytes und nix geht mehr.
eeprom3 läuft immer ohne Probs durch

[LambdaMikel]

habe mal im X-Mem alles auser FOS, LS3 Rom und Parados deaktiviert.
beim drumload hat er mal die Files geladen, aber alle 1110 bytes und hat sie beim Laden richtig abgespielt.dann bei drummer gingen nur die ersten 3 Files, die restlichen waren leer.
habe mal den Rechner ausgemacht und neu an. jetzt lädt er wieder nur mit 0 bytes und nix geht mehr.
eeprom3 läuft immer ohne Probs durch

alle 1110 bytes is nicht richtig, dann spielt er beim testen eben nur die 1110 bytes ab.
du musst im basic programm drumload.bas rausfinden, wie zeile 310 length=.... beim kc compact berechnet werden kann. zur not musst du die laenge fuer jede datei von hand eingeben: 310 input length.


und eetest sagt am ende "done testing" ?