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

[LambdaMikel]

FOS zeigt die Uhrzeit an, anscheinend nach Deutscher Zeitzone. Kommt die Zeit nicht vom M4?

Ja, genau... Zeit ist vom M4. Habe endlich auch mal rausgekriegt, wie man Zeitzone und NTP Server einstellt. Momentan braucht mein M4 3 Minuten, um sich an meinen Wifi AP zu verbinden, und zwischenzeitlich sagt er immer "AP Does not Exist". Dachte schon, es wäre hinüber, oder ich zu blöd für die |netset Parameter, aber dann ging es auf einmal doch!

Also, M4 ist frisch installiertes FOS von vorgestern aus diesem Thread, und altes LS ROM ist raus. Allerdings weiss ich nicht, wie ich damit die LS Uhrzeit auslesen kann. Vielleicht habe ich TFM falsch verstanden.

[LambdaMikel]

Achtung, habe gerade festgestellt, dass "DRUMLOAD.BAS" von den LambdaDrum DSKs nicht funktioniert, wenn M4 drin ist!
Er kriegt dann die Datei-Header nicht richtig, die er braucht, um die Datei-Länge in BASIC zu bestimmen. M4 scheint da arg rumzupatchen. Funktioniert also nur mit Amsdos oder Parados.

EDIT: habe die DSK images im Github mal upgedated, mit Warn-Meldung für Drumload.bas / M4, und RTC.BAS mit der "if x = 128" Variante.

[Rennert]

Man kann ja fix mit lM4ROMOFF das Teil deaktivieren und so Drumload laden

[Rennert]

So beim heutigen Durchlauf kam WD-Error wieder mit Wert 128, zum Montag mal erst nach knapp 2 Stunden

habe die Zeile 790 trotzdem mal anders angepasst.

790 wd= inp(&fbee):if wd <1 or wd>7 then 790

so wie ich dem Listing entnehme, kann man das GOTO weglassen. Ist beim Uhr stellen und Datum setzen zumindest so. Ist das immer so nach einem THEN?

[Rennert]

als das mit dem IF Befehl haut auch nicht ganz hin, da er nach dieser gewissen Zeit, nur noch falsche Werte ausliest(wahrscheinlich 128) und dann in dieser Schleife gefangen ist. Die Uhrzeit läuft dann auch nicht mehr. die Schleife lief dann über eine Stunde ohne Änderung.
habe jetzt mal das IF wieder gelöscht und:

845 if wd<1 or wd>7 then print"error":wd:goto 860

jetzt sollte er durchlaufen und mal schauen ob sich die Error Anzeige ändert oder irgendwann der Wochentag wieder richtig ausgelesen wird.

[LambdaMikel]

ok, wenn er also in der schleife hängt, dann sieht es so aus, dass er den wert gar nicht erwischt bzw. zu spät gelesen hat. dann kommt der wert natürlcih auch nicht mehr. 128 signalisiert, dass LS 3 wieder bereit ist, einen befehl zu akzeptieren. in diesem falle hilft also tatsächlich nur, wie tfm schon meinte, dass kommando noch einmal senden. 

es ist eigenartig, dass er den wert verpasst. ich muss also die slow getters noch slower machen... von 10 ms wieder auf 50 ms oder so, dann sollte das problem nicht mehr auftreten.  der wert muss also länger bereitgestellt werden.

ich tippe darauf dass basic eine GC oder ähnlich nach einer gewissen zeit macht, und das führt dazu, dass inp verzögert wird sodass der wert verpasst wird. die GC wird wahrscheinlich durch die ganzen Strings, die mittels PRINT USING zusammengebaut werden, ausgelöst.

ein maschinenprogram hat dieses problem natürlich nicht. ist also m.E. ein reines basic-problem. hoffe, @TFM sieht das auch so und seine MC Lese-Uhr wird funktionieren 

edit: anderseits, 50 ms helfen dann auch nicht, wenn es die GC ist, wissen wir ja, dass das beim 464 sogar 40 minuten und mehr dauern kann... hilft also nur MC und ich kann die Firmware so lassen. 10 ms sind lang genug.

TFM was meinst du.

[LambdaMikel]

Man kann ja fix mit lM4ROMOFF das Teil deaktivieren und so Drumload laden

Oh gut, dass wusste ich noch gar nicht...

[Rennert]

welches Kommando müsste neu gesendet werden? könnte man nicht einfach wenn der Wert verschieden ist, wieder zu Zeile 540 springen? und damit läuft das Prog neu an. wenn ich es komplett neu starte, gehts ja auch wieder.

[LambdaMikel]

Ja, das ginge auch. Ansonstent wäre auch gut, mal auf alle String operationen zu verzichten, damit die GC gar nicht erst anspringt.

Also:
1. alle Variablen als int% deklarieren.
2. locate x,y und "print chr$(...)" und ähnlich Zeichen für Zeichen verwenden - kein "print using"!

Oder, noch besser:
3. alles in MC schreiben

oder, noch besser:
4. warten bis TFM seine |gettime RSX fertig hat 

[Rennert]

Naja muss meine Basic Kenntnisse erst wieder auffrischen, bis Abfang der 90er habe ich am Basic von Robotron bissel gearbeitet.
Maschinencode ist nicht so mein Fall.

Ich lasse es mal laufen mit Sprung auf 540 im Fehlerfall, testen kostet ja nix

[LambdaMikel]

oh, du warst an der entwicklung bei robotron irgendwie beteiligt? 

[TFM]

Ich habe die Zeit für die "slow getters" reduziert... von 50 ms auf 10 ms. Ich kann das wieder hochsetzen. Ich denke, die 255 kommt NACH dem eigentlich Wert, nicht davor, oder? m.a.W., der CPC liest "zu spät" und verpasst den Wert.

10 ms ist fein! Sollte u.U. auch in ein Firmwareupdate für alle LS einfließen.

Ja, LS-Funktionen liefern erst den Wert, dann 255, dann das Bereitschaftsbyte.

[TFM]

M4 Datei Probleme? Dann bitte die Firmware updaten!

Die M4 Uhr hat höhere Priorität als die vom LS3. Das ist keine böse Absicht, ist einfach nur historisch bedingt. 

[TFM]

Ok, hab hier den halben Thread abgesucht... Wo ist denn die DSK mit Drummer.BAS etc.

Könnte jemand die DSK bitte hier posten (in GitHub ist auch nix).

[LambdaMikel]

Die LS300.DSK ist im Github, und attached.

Ach, jetzt habt Ihr mich doch wieder an meinem Ehrgeiz gepackt und wollte mal sehen, ob ich ich nicht doch noch ne Zeile Z80 hinkriege - hier mal ein RESET für LS und Warten, bis LS wieder Ready ist (loop until 128).

Code Select Expand

org #8000
.start
LD BC,#FBEE
LD A,#FF
OUT (C),A
.loop1
IN A,(C)
CP 128
JP NZ,loop1
RET


Ist auch als ASM.BAS mit Basic-Lader auf der LS300 DSK anbei.
Na und die Uhr-Abfrage könnte so ähnlich aussehen, man muss nur sehen dass man den mittels IN A,(C) gelesenen Wert dann in eine Speicherzelle schreibt, die man dann nach RET mittels BASIC PEEK auslesen kann. Also sowas wie

LD HL,&8010 ;; Speicher für Hours
LD A, (HL)
...
RET
Äh sorry, ging ja um DRUMLOAD.BAS.
Anbei in den anderen beiden DSKs. Auch im Github.