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

[LambdaMikel]

Habe ich oben geschrieben:

EDIT 2 und EDIT 3 lese ich jetzt erst. Also diese Version ist EDIT.
"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.  "



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]

Wie gesagt, nur bei letztem Seiten-Byte 0 oder 32 müsstest Du etwas vorsichtig sein...

[LambdaMikel]

S. Antworten oben. Bin jetzt erstmal arbeiten.

[TFM]

Na klar, Danke deweil  Mal sehen ob ich das hinbekomme. 

[LambdaMikel]

Na klar, Danke deweil  Mal sehen ob ich das hinbekomme. 

... habe da groesste Zuversicht - Du schaffst das schon   

[LambdaMikel]

Gebe Dir uebrigens recht, dass die verschiedenen Protokolle im LS3 alles etwas Kraut und Rueben sind bzw. uneinheitlich.

Einige Gedanken fuer das naechste Projekt:

- fuer SSA und DKtronics kann ich nix machen
- fuer die Kommandos die Werte liefern auf dem Datenbus (getversion, getvolume, ...) haette ich vielleicht von Anfang an Handshakeing "out &fbee,<beliebig>" machen sollen als Bestaetigung, wann der Wert vom CPC angekommen wurde.
ALLERDINGS fuehrt das dazu, dass die LS3 Firmware dann wartet bzw. blockiert bis das Argument abgenommen wurde. Und falls es nicht abgenommen wird, blockiert er fuer immer (wenn man denn kein Timeout einbaut).
- fuer Parameter-Uebergabe ist das blockierende Verhalten natuerlich prinzipiell ok, mit der Ausnahme vom PCM Play mode, da der ATMega hier auch waehrend der Parameter-Uebergabe weiterhin PCM Samples abspielen muss. Das ginge natuerlich prinzipiell ebenfalls wenn man entweder INterrupts oder einen 2. Thread verwenden wuerde - aber 1. ist zu lahm fuer diese Anwendung, und 2. gibt es im ATMega nicht.

Also alles nicht so einfach, ist eben auch learning by doing bei mir. Vielen Dank fuer Deine Flexibilitaet, TFM!!

[TFM]

Vielen Dank für deine Updates in Lichtgeschwindigkeit.  Ich mache mir eher sorgen ob die 255 möglichen Versionsnummern ausreichen.  Möglicherweise ist es besser nur für "offizielle" Firmware Updates eine neue Versionsnummer zu nehmen.
Will jetzt noch eine Funktion umschreiben, und dann sollte ich mit viel Glück heute noch das ROM zur aktuellen Firmware fertig haben.

Ansonsten... find ich Kraut und Rüben ganz gut, denn es funktioniert. Wir beide haben da diametrale Sichtpunkte (Hardware - Software). Also zusammen kriegen wir das sowas von hin. Ich hab da auch noch ein paar Ideen was ins ROM gehört, andere Sachen muss man mal sehen wie das unter Amsdos geht. Bzw. wie man um Limitationen herumkommt. Melde mich dann wieder... 

[LambdaMikel]

... bin schon sehr gespannt, was Du wieder geniales ausheckst 

[TFM]

Hier ein Update... das aber leider bei EEGET nicht geht, ich dann zwar Daten einlesen, aber trozdem alles richtig gelesen wird bleibt es hängen. LS3 scheint nicht &80 bzw. &20 am Ende zu melden.
Beim BASIC Programm EEPROM ist das ähnlich, da zeigt LS3 Port &FBEE dann den Wert 191 = &BF.

Bitte Firmware anpassen, dass die wieder auf 32 bzw. 128 zurückspringt. Einfach mal EEPROM laufen lassen und dann ? inp(&FBEE) tippen, dann sieht man worum es geht.

Wenn die Firmware angepasst ist, dann sollten auch die RSXe laufen.

cu. & bis morgen! 

[LambdaMikel]

Bitte Firmware anpassen, dass die wieder auf 32 bzw. 128 zurückspringt. Einfach mal EEPROM laufen lassen und dann ? inp(&FBEE) tippen, dann sieht man worum es geht.

OK, komisch. Aber zwischendrin kommt 32, oder? Ist nur das letzte Byte?

Wo finde ich denn EEPROM? Ist nicht auf der DSK.

Gucke ich mir in ein paar Stunden an.

[LambdaMikel]

Hier ein Update... das aber leider bei EEGET nicht geht, ich dann zwar Daten einlesen, aber trozdem alles richtig gelesen wird bleibt es hängen. LS3 scheint nicht &80 bzw. &20 am Ende zu melden.
Beim BASIC Programm EEPROM ist das ähnlich, da zeigt LS3 Port &FBEE dann den Wert 191 = &BF.

Bitte Firmware anpassen, dass die wieder auf 32 bzw. 128 zurückspringt. Einfach mal EEPROM laufen lassen und dann ? inp(&FBEE) tippen, dann sieht man worum es geht.

Wenn die Firmware angepasst ist, dann sollten auch die RSXe laufen.

cu. & bis morgen! 

Hallo Stefan, das kann ich nicht bestätigen. Nachdem das letzte Byte gelesen wurde, sehe ich erst kurz 0, und dann 128 wenn er vorher im SSA1 modus war. Wenn ich bei EEPROM3.BAS nach dem next "230 print inp(&fbee): goto 230" schreibe, sehe ich erst 0 für kurze Zeit, und dann 128. Und dort bleibt es, weil er in den SSA1-Modus zurückgekehrt ist.

Evtl. hast Du nicht die letzte Firmware genommen? 

Oder ich habe Dich nicht richtig verstanden. 

Bis morgen

EDIT: Oh, jetzt habe ich EEPROM.BAS und nicht EEPROM3.BAS verwendet, und tatsächlich, da ist 191 am Ende!! Wow... wie kommt das denn. OK, ich gucke mal.

[LambdaMikel]

.. da hast Du natürlich wieder voll und ganz recht gehabt, und es war ein mehr als unerwarter Effekt bzw. Bug im Code.
Neue Firmware anbei.

[TFM]

Cool! Danke! 
Wird gleich mal verwendet, gähn, und dann ab in die Kiste 

[LambdaMikel]

Sehr geil, TFM!
Ich kann doch tatsächlich mittels |eeup,0,0,2*48 einen memory dump hochladen in 4 Sekunden, CPC aus, und mittels |eeget,0,0,2*48 habe ich mein BASIC Programm in 4 Sekunden wieder im Speicher  Yeah!!

HOWEVER, es kann den Bildschirmspeicher nicht restaurieren.
|eeup,&c000,0,2*16 -> |eeget,&c000,0,2*16 gibt farbenfrohes buntes Allerlei.
RAM bzw. ROM eingeblendet?

Anbei EEPROM2.BAS auf DSK. Ein Test-Program - das zeigt, dass es prinzipiell sehr gut funktioniert!

EDIT: Hmm, mit |eeup,0,0,2*48 und |eeget,0,0,2*48 war wohl Glück... normalerweise scheint er zu crashen nach dem RESUME. Wahrscheinlich muss noch etwas mehr korrekt hergestellt werden als nur der Speicher damit das Resume reibungslos funktioniert? Register und so weiter? Na ja, Bildschrimspeicher wäre der erste Schritt dass das richtig funktioniert.

[LambdaMikel]

Hier noch ein kleiner Bug:
|getvolume, |getvoice etc. liefern alle "4". |getver funktioniert richtig.