Hi Board,
auf meiner Erkundungsreise in the Wunderwelt der CPC-Hardware mittels meines Breadboard-Adapters (s. anderer Thread von mir), habe ich mir jetzt einmal einen alten Wunsch erfüllt, und den Emic 2 Sprachsynthesizer an den CPC angeschlossen - ein YouTube Video des "Next Generation CPC Speech Synthesizers" gibt es hier:
https://youtu.be/C5BnD1NPwGw (https://youtu.be/C5BnD1NPwGw)
Die Sprachqualität des Emic 2 ist wirklich nett... :smiley027: da gibt es nicht viel dran auszusetzen - allerdings hat das Teil auch einen stolzen Preis, so um die 60 $ :banghead: Aber war es mir wert.
Viele Grüße,
Michael
Das da unten rechts auf Deinem Steckbrett sieht mir sehr nach der Arduino-Minimalschaltung aus.
&weg,
Mr. AMS
Genau, das ist der ATmega 328 aus dem Arduino Uno. "Geshrimped", wie man so schön sagt :-) Programmiert wurde er aber ohne Arduino IDE, mit der Atmel AVR toolchain (gcc etc.). Ich habe dazu den PocketAVR ISP Programmer verwendet; damit klappt es auch ohne Arduino Bootloader im ATmega.
Gruß,
Michael
Was gibt's Neues im Land der artifiziellen Sprache?
LambdaSpeak - SSA-1 Compatibility Check mit "Alex Higgins World Pool" Games:
Und auch Eliza kann's jetzt auf Deutsch:
Hoffentlich hält uns Michael weiterhin auf dem Laufenden, die Erweiterung ist mehr als interessant. :smiley027:
Man hört von einer Version 1.5 oder auch 2?!?
LabdaMichel, könntest Du uns bitte sagen, ob es hier neues zu berichten gibt?
Quote from: TFM on 06. December 2017, 13:06:43
Man hört von einer Version 1.5 oder auch 2?!?
Hi TFM und CPC-Freunde, danke fuer das Interesse, in der Tat, so ist es! :kaffee:
LambdaSpeak 1 ist nach wie vor die "de luxe"-Variante, mit Lautsprecher, etc.
Allerdings doch etwas sehr teuer in der Produktion - und so arbeite ich mit Meister Bryce himself zusammen, um eine CostDown-Variante auf die Beine zu stellen.
Auf halbem Wege haben wir nun LambdaSpeak 1.5 - hier wurde der teure Emic 2 mit dem wesentlich guenstigeren Text to Speech "click!" Board ersetzt:
https://www.mikroe.com/text-to-speech-click
Erforderte nun allerdings einen wesentlich groesseren Mikrocontroller als den zuvor verwendeten ATMega 328, da die Firmware des Epson-Sprach-IC S1V30120 erst ueber den Microcontroller in den Epson geladen werden muss - und die Firmware ist recht umfangreich. Passte also nicht mehr in den kleinen 328. So haben wir uns fuer den ATMega 644 entschieden, der mit 64 KB ausreichend ausgestattet ist.
Zudem wurde die ganze Adress-Dekodier-Glue-Logic in einen GAL22V10 gepackt, der jetzt zwar nur noch eine "IO-Adresse-Erkannt"-Leitung zum ATMega ausfuehrt, aber das ist eigentlich auch egal. So werden SSA1-Modus als auch Native-Modus vom LambdaSpeak eben auf der/den gleichen IO-Adressen angesprochen. LambdaSpeak 1.5 hat also nur noch 4 Chips (644, GAL22V10, 2 74LS374 FlipFlops als Datenbus Input/Output-Buffer), und das ClickBoard. Herstellung waere bereits wesentlich guenstiger -
wir werden es aber nicht zum Kauf anbieten, da es nur ein Zwischenschritt ist.
Die naechste Version - LambdaSpeak 2.0 - ist als Prototype / Breadboard ebenfalls fertig. Hier wurden nun die beiden verbleibenden 74LS374 FlipFlops wegoptimiert, und zusammen mit der Adress-Dekodierungs und Glue-Logik auf 2 Xilinx CPLDs aufgeteilt. 2 CPLDs, weil ich kein groesseres Xilinx Prototyping / DevBoard CPLD finden konnte.
Die endgueltige LambdaSpeak 2-PCB/Version wird, wenn alles gut geht, von Hardware-Meister Bryce persoenlich entwickelt, und hier werden die beiden 2 CPLDs in ein groesseres Xilinx CPLD kombiniert. Zudem geht der Epson Sprach-IC direkt auf die Platine - also nur noch 4 SMD ICs: Epson Sprach-IC, groessers XIlinx CPLD, ATMega 644, und ein Op-Amp fuer Audio. Das wird hoffentlich schoen kompakt und preisguenstig. :00008351:
Und was die Software angeht - nun, fuer SSA1-Modus brauchen wir keine. Der SSA1-Treiber tut es, und die existierende Software (Roland in Space). Fuer den wesentlich besser klingenden "native mode" ist es recht einfach - einfach ASCII bytes an out &fbee,<byte> senden und mittels <cr> (13) terminieren. Aber ich will auch noch eine RSX-Erweiterung schreiben, |lambdaspeak,@a$ oder aehnliches Kommando. Und ein paar weitere Befehle zum Aendern der Lautstaerke, der Stimme, Sprechgeschwindigkeit, etc. Nun, es ist > 30 Jahr her, dass ich mal eine RSX-Erweiterung programmiert habe... mal sehen, ob ich mich noch wieder schnell einarbeiten / erinnern kann. Hilfreiche RSX-Tutorial & Links nehme ich gerne!
Also, bis demnaechst,
Michael
PS Und - ach ja, MotherX4-kompatibel sind alle LambdaSpeak-Varianten.
Und laufen auf allen CPC-Modellen (getestet auf 3 verschiedenen 464 und 2 6128ern - habe keinen 664 zur Hand).
Vielen Dank für das umfangreiche Update! :jubelaola: Das ganze Projekt ist sehr vielversprechend. Ich warte dann aber auf die "finale" Version, die sich wahrscheinlich am meisten verkauft, und damit macht es am meisten Sinn die dann auch per Software zu unterstützen.
Mit Bryce hab ich auch schon zusammengearbeitet (das MegaFlash damals), leider wird's bei ihr immer sehr teuer. Tot0 schafft das immer Boards um 20 oder 30 Euros zu verkaufen - traumhaft.
Natürlich ist es klar, dass für PCB, ICs, Aufbau, Entwicklung etc. auch ein deutlich höherer Preis gerechtfertigt ist.
Also dann viel Glück, für den "Endspurt" und auf gutes Gelingen!!! :jubelaola:
P.S.: Testen auf dem CPC664 und 6128 Plus kann ich dann gerne übernehmen, aber wenn es am 464/6128 läuft, dann sollte es überall laufen. :)
P.P.S: Was natürlich ganz wichtig ist: Die I/O Adressen sollten eindeutig sein, damit die Kompatibilität zu anderer Hardware gewährleistet ist. So ein LambdaSpeak kommt ja erst wirklich gut mit Speichererweiterung und Massenspeicher (sprich: da passt ein ordentliches Game hinein). Mal sehen, ob ich das "zum testen" das Space Chicken für LambdaSpeak erweitern kann.
P.P.P.S: Cool! Der JavaCPC unterstützt ja den SSA1, dann kann ich ja schon mal ein bischen rumspielen :-)
Klingt interessant, werde ich sicher kaufen :whip2:
Quote from: TFM on 07. December 2017, 14:50:45
Vielen Dank für das umfangreiche Update! :jubelaola: Das ganze Projekt ist sehr vielversprechend. ...
Also dann viel Glück, für den "Endspurt" und auf gutes Gelingen!!! :jubelaola:
P.S.: Testen auf dem CPC664 und 6128 Plus kann ich dann gerne übernehmen, aber wenn es am 464/6128 läuft, dann sollte es überall laufen. :)
P.P.S: Was natürlich ganz wichtig ist: Die I/O Adressen sollten eindeutig sein, damit die Kompatibilität zu anderer Hardware gewährleistet ist. So ein LambdaSpeak kommt ja erst wirklich gut mit Speichererweiterung und Massenspeicher (sprich: da passt ein ordentliches Game hinein). Mal sehen, ob ich das "zum testen" das Space Chicken für LambdaSpeak erweitern kann.
Vielen Dank, TFM!
Wie waere es mit dem folgenden :00008351: DEAL :00008351: :bgdev:
Du bekommst ein LambdaSpeak 1.5 *fuer lau* :smiley027: :birthday:, mit finaler Firmware drauf (einige Kleinigkeiten gibt es noch einzubauen), und schreibst eine RSX-Erweiterung fuer uns?
An Befehlen schwebt mir vor:
|lambdaspeak,@a$
|ssa1
|lambda
|setvolume,<nibble>
|setvoice,<nibble>
|setspeed,<nibble>
|iotest
|reset
|getversion -> int
|speakinfo
|speakmode
|speakvolume
|speakvoice
|speakspeed
|hal9000
|getvolume -> int
|getvoice -> int
|getspeed -> int
|getmode -> int
|testleds
Was sagst Du?
PS IO mit LambdaSpeak ist relativ trivial - es gilt lediglich bytes an out &fbee zu senden, und teilweise wieder zu lesen fuer |get.... commands.
Wir werden dazu Control-Bytes definieren; alles mit gesetztem 8. bit kann Control-Byte sein, da Speech ja nur 7Bit ASCII unterstuetzt. So was wie
out &fbee,255 -> ssa1 mode,
&out &fbee, 254 -> native mode,
out &fbee,250, out &fbee,15 -> set volume to 15.
Lesen fuer z.B. |getvolume geht dann mittels out &fbee,249 (read volume control byte), dann volume = inp(&fbee) ( volume = 15), etc.
Alles klar? Alles ganz einfach also.
Quote from: TFM on 07. December 2017, 14:50:45
Tot0 schafft das immer Boards um 20 oder 30 Euros zu verkaufen - traumhaft.
Natürlich ist es klar, dass für PCB, ICs, Aufbau, Entwicklung etc. auch ein deutlich höherer Preis gerechtfertigt ist.
Kein Ahnung, wie er das macht... er muss irgendwo eine Fabrik mit Arbeits-Sklaven/Elektronikern in ..... haben :bgdev:
Ich bin ja kein Hardware-Mensch, sondern mache eigentlich Software. Das ist mein 1. Hardware-Projekt - fuer die PCB-Prototypen bin ich selbst auf relativ teure PCB-Services wie OshPark angewiesen ("Turn Key Services", die auch Bestueckung und vollstaendige Produktion machen, waren komplett unerschwinglich fuer kleine Auflagen und haetten mich finanziell ruiniert). Und SMD kann ich ja auch nicht. Aber
Bryce wird schon wissen, wie der Preis minimiert werden kann, er arbeitet daran, es so guenstig wie moeglich zu machen. Er hat mir sogar meine beiden LEDs und Reset-Taster weg-rationalisiert, wegen Kosten - ich glaube, jetzt haben wir uns auf 1 LED geeinigt, und kein Reset-Taster - insofern bin ich sehr zuversichtlich, dass er einen guten Preis wird realisieren koennen, er ist durch und durch Hardware-Profi!
Na dann kann ja nichts mehr schief gehen ;) Ich halt's auch lieber mit der Software :)
Schönes WE Euch allen! :00008351:
Quote
Wie waere es mit dem folgenden :00008351: DEAL :00008351: :bgdev:
TFM, was sagst Du zu dem DEAL? Fuer lau meint wirklich - Du kriegst es umsonst, ich bezahle sogar Porto und das SpeechToClick board.
Quote from: LambdaMikel on 06. December 2017, 22:21:54
Hilfreiche RSX-Tutorial & Links nehme ich gerne!
https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z98.htm#A
Hola! Ja, sorry hab den Post mit dem Deal verpasst. Im Prinzip könnten wir das schon machen, aber ich muss gleich schon mal sagen, dass ich nicht all zu viel Zeit habe. Die RSX Erweiterung könnte also etwas Zeit in Anspruch nehmen (also wohl eher 1-2 Monate anstatt Wochen - ja, ich bin jetzt lieber mal pessimistisch, dann kann's nur besser werden).
Falls der DEAL noch gilt, dann können wir ja den "Rest" per PM besprechen. :)
So eine RSX Erweiterung kann man dann auch in ein ROM integrieren. Gibt es eines für das SSA1? Dann können wir das u.U. auch da mit einbauen. :)
EDIT: Da ist ein SSA-1 ROM, und in dem sind 12 KB frei! Super! :00008351:
@Michael: Ok, die RSX machst Du jetzt selber hast ja gesagt, aber es wäre trotzdem interessant welche Control Bytes der Lambda-Speak nun verwendet. Könntest Du bitte die folgende Liste mal ergänzen? Das wäre super :-)
|lambdaspeak,@a$
|setvolume,<nibble>
|setvoice,<nibble>
|setspeed,<nibble>
|speakmode
|speakvolume
|speakvoice
|speakspeed
|ssa1
-----
out &fbee,255 ;-> ssa1 mode
|lambda
-------
out &fbee,254 ;-> native mode
|iotest
|reset
|speakinfo
|hal9000
|testleds
|getversion -> int
|getvolume -> int
-----------------
out &fbee,249 ;Read volume control byte
in a,(&fbee) ;A = Volume
|getvoice -> int
|getspeed -> int
|getmode -> int
Quote from: TFM on 13. December 2017, 15:24:44
@Michael: Ok, die RSX machst Du jetzt selber hast ja gesagt, aber es wäre trotzdem interessant welche Control Bytes der Lambda-Speak nun verwendet. Könntest Du bitte die folgende Liste mal ergänzen? Das wäre super :-)
Hi TFM,
werde ich machen, aber momentan kann die LambdaSpeak Firmware das noch gar nicht. Ich arbeite erst noch an den zusaetzlichen Control Bytes. Ich werde erst die Firmware von LambdaSpeak erweitern, und dann an den RSX-Befehlen arbeiten. Momentan gibt es nur die SSA-Software, die BASIC-Elizas die ich mit Sprache erweitert habe (Native und SSA1 Modus), und den kleinen BASIC-Treiber im SCreenshot.
Ich update diesen Thread, sobald wir mehr haben :00008351:
Bis dahin,
Viele Gruesse
Michael
Hallo zusammen, und frohes neues Jahr!
Nun hat es doch etwas laenger gedauert, bis ich die Control-Bytes / Firmware am Laufen hatte... tatsaechlich haben sich die Control-Bytes mehrfach geandert, insofern war es gut, dass ich mit dem Update gewartet habe. Aller Voraussicht nach wird die Firmware also wie folgt aussehen:
switch ( control_byte ) {
case 0xFF : process_reset(); break;
case 0xEF : native_mode_epson(); break;
case 0xEE : native_mode_dectalk(); break;
case 0xED : ssa1_mode(); break;
case 0xEC : non_blocking(); break;
case 0xEB : blocking(); break;
case 0xEA : confirmations_on(); break;
case 0xE9 : confirmations_off(); break;
case 0xE8 : english(); break;
case 0xE7 : spanish(); break;
case 0xDF : stop_command(); break; // will never be reached, because of blocking - only for documentation!!
case 0xDE : flush_command(); break;
case 0xCF : get_mode(); break;
case 0xCE : get_volume(); break;
case 0xCD : get_voice(); break;
case 0xCC : get_rate(); break;
case 0xCB : get_language(); break;
case 0xCA : get_delay(); break;
case 0xC9 : get_version(); break;
case 0xC8 : speak_copyright_note(); break;
case 0xC7 : speak_hal9000_quote(); break;
case 0xC6 : sing_daisy(); break;
case 0xC5 : echo_test_program(); break;
case 0xC4 : test_message(); break;
case 0xB0 : set_voice_default(); break;
case 0xB1 : set_voice(1); break; // default
case 0xB2 : set_voice(2); break;
case 0xB3 : set_voice(3); break;
case 0xB4 : set_voice(4); break;
case 0xB5 : set_voice(5); break;
case 0xB6 : set_voice(6); break;
case 0xB7 : set_voice(7); break;
case 0xB8 : set_voice(8); break;
case 0xB9 : set_voice(9); break;
case 0xBA : set_voice(10); break;
case 0xBB : set_voice(11); break;
case 0xBC : set_voice(12); break;
case 0xBD : set_voice(13); break;
case 0xBE : set_voice(14); break;
case 0xBF : set_voice(15); break;
case 0xA0 : set_volume_default(); break;
case 0xA1 : set_volume(1); break;
case 0xA2 : set_volume(2); break;
case 0xA3 : set_volume(3); break;
case 0xA4 : set_volume(4); break;
case 0xA5 : set_volume(5); break;
case 0xA6 : set_volume(6); break;
case 0xA7 : set_volume(7); break;
case 0xA8 : set_volume(8); break;
case 0xA9 : set_volume(9); break;
case 0xAA : set_volume(10); break;
case 0xAB : set_volume(11); break;
case 0xAC : set_volume(12); break;
case 0xAD : set_volume(13); break;
case 0xAE : set_volume(14); break; // default
case 0xAF : set_volume(15); break;
case 0x90 : set_rate_default(); break;
case 0x91 : set_rate(1); break;
case 0x92 : set_rate(2); break;
case 0x93 : set_rate(3); break;
case 0x94 : set_rate(4); break;
case 0x95 : set_rate(5); break;
case 0x96 : set_rate(6); break;
case 0x97 : set_rate(7); break;
case 0x98 : set_rate(8); break;
case 0x99 : set_rate(9); break;
case 0x9A : set_rate(10); break;
case 0x9B : set_rate(11); break;
case 0x9C : set_rate(12); break; // default
case 0x9D : set_rate(13); break;
case 0x9E : set_rate(14); break;
case 0x9F : set_rate(15); break;
case 0x80 : set_buffer_delay_default(); break;
case 0x81 : set_buffer_delay(1); break;
case 0x82 : set_buffer_delay(2); break;
case 0x83 : set_buffer_delay(3); break;
case 0x84 : set_buffer_delay(4); break;
case 0x85 : set_buffer_delay(5); break;
case 0x86 : set_buffer_delay(6); break;
case 0x87 : set_buffer_delay(7); break;
case 0x88 : set_buffer_delay(8); break;
case 0x89 : set_buffer_delay(9); break;
case 0x8A : set_buffer_delay(10); break; // default !!
case 0x8B : set_buffer_delay(11); break;
case 0x8C : set_buffer_delay(12); break;
case 0x8D : set_buffer_delay(13); break;
case 0x8E : set_buffer_delay(14); break;
case 0x8F : set_buffer_delay(15); break;
}
Die get_xxxx Reader legen den entsp. xxx Wert fuer ~ 200 ms auf den &FBEE Port; der Wert ist > 0 und nach 200 ms geht der Port wieder auf 0. Man muss also eine busy polling loop schreiben, um zu lesen: warte bis &FBEE <> 0, lese &FBEE, warte bis &FBEE = 0, raus aus der Schleife. Zudem ist das ein 4 Bit-Wert > 0, oberes Nibble, also bitte durch 16 teilen.
Die Firmware unterstuetzt nun auch den DecTalk-Mode, mit der Epson IC singen kann etc. Die EMic2-basierte Variante konnte diese Sachen auch schon, da der Emic2 einen eigenen Mikrocontroller und Command-Parser implementiert hatte. Da wir nun aber den Raw Epson IC verwenden, haben wir diese EMic2-Command Shell nicht mehr, und muessen alles selbst machen.
Ich habe das mit dem LambdaSpeak 2 Breadboard getestet, und werde es demnaechst in LambdaSpeak 1.5 einbauen. Die Hardware von LambdaSpeak 1.5 ist ja etwas anders, daher wird es ein bisschen dauern, bis LambdaSpeak 1.5 auch die neue Firmware hat.
Und dann kommt die RSX-Erweiterung fuer den CPC an die Reihe.
Hallo!!! :) Das sind ja gute Neuigkeiten! :)
:jubelaola:
Nur eine Frage, wenn man den Wert einliest, liegt der dann immer noch die vollen 200 ms auf dem Port? Oder ist es so, dass wenn man den Wert liest, der Port wieder 0 wird und dann für das nächste Kommando verwendet werden kann?
200 ms ist ja eine 1/5 Sekunde, eine Unendlichkeit. Oder meintest Du 200 us?
Wie ist das wenn ich Kommandos gebe um zwei Parameter zu lesen? Muss ich dann die 200 ms warten bis ich den 2. Wert lesen kann? Oder "überschreibt" das zweite Kommando das erste Kommando und ich kann dann sofort den 2. Wert lesen?
So, der Tag ist gerettet, das sind ja mal super Neuigkeiten!!! :smiley027: :smiley027: :smiley027:
EDIT: So hab mal ein bisschen an dem BASIC Proggy und der Doku gearbeitet. Das ist mehr didaktisch als sinnvoll, aber es sollte veranschaulichen was so passiert. Bitte drübergucken und kommentieren wer will. Schließlich ist ja alles noch in der Entwicklung.
Wie man sieht stimmt die RSX Liste nicht genau mit den Befehlen überein, es entwickelt sich ja alles weiter. Kommentare willkommen :-)
Hi TFM,
momentan ist es tatsaechlich eine fuenftel Sekunde. Ich wollte halt den Wert mit BASIC lesen. Wahrscheinlich kann ich diese Zeit, fuer die der Wert auf dem Port liegt, reduzieren. Also den kleinsten Wert finden, fuer den das noch klappt:
10 a = inp(&fbee)
20 if a = 0 then goto 10
25 print a
30 b = inp(&fbee) : if b = a then goto 30
... hmm.. ich erinnere mich gerade, mach das nicht ohnehin der BASIC WAIT Befehl so? Werde ich mal probieren. Den hatte ich ganz vergessen!
Ja, es muss ein Wert nach dem anderen gelesen werden, sequentiell. Uebrigens ist es so, dass die Command Bytes mit Ausnahme der get-xxx Reader den CPC auf RD_WAIT ziehen... also anhalten. Diese Anhalten des CPCs ist auch der Default fuer die Sprachausgabe - solange LambdaSpeakspricht, wird der CPC angehalten. Allerdings nur im native mode - der SSA1 mode ist immer non blocking. Es gibt ja das SSA1-Protokoll dafuer. Fuer den native mode habe ich allerdings auch etwas aehnliches eingebaut, der dann non-blocking funktioniert. Hier wird dann, statt den CPC anzuhalten bis Ende der Sprachausgabe, der CPC nicht angehalten. Der CPC laeuft also weiter waehrend der Lambda spricht, und man kann dann genau 2 Dinge tun: entweder das stop control byte senden (was die Sprachausgabe sofort stoppt), oder aber mittels inp(&fbee) lesen, ob der CPC noch spricht oder nicht. Bei gesetztem 7. Bit spricht er noch. Sobald er fertig ist, geht inp(&fbee) auf 0. Damit ist also Flusskontrolle moeglich.
Quote from: LambdaMikel on 18. January 2018, 17:49:11
Der CPC laeuft also weiter waehrend der Lambda spricht, und man kann dann genau 2 Dinge tun: entweder das stop control byte senden (was die Sprachausgabe sofort stoppt), oder aber mittels inp(&fbee) lesen, ob der CPC noch spricht oder nicht. Bei gesetztem 7. Bit spricht er noch. Sobald er fertig ist, geht inp(&fbee) auf 0. Damit ist also Flusskontrolle moeglich.
Sobald er fertig ist mit Sprechen, kann man natuerlich wieder alles machen.
Hab mal kurz einen Test gemacht: In BASIC kann man (innerhalb einer Schleife mit Zähler) einen Port 117 mal einlesen. Also... 1.000.000/100 = 10.000 us. Also mit 10 Millisekunden ist man auf der sicheren Seite. Solange man in BASIC sofort einliest und nicht wartet sollte das gut funktionieren. :)
Idee: Wäre es mögich per Kontroll-Byte die Warezeit zum setzen, z.B. zwischen 10 us und 10 ms? Das wäre beim MC coden ein super Vorteil. :-)
Ah mit den beiden:
&EC - non_blocking
&EB - blocking
kann man also entscheiden ob im native Mode der CPC angehalten wird. Super! Das ist klasse für Z80 code. Gerade wenn z.B. ein Spiel z.B. weiterlaufen soll.
Quote from: TFM on 19. January 2018, 01:26:08
Idee: Wäre es mögich per Kontroll-Byte die Warezeit zum setzen, z.B. zwischen 10 us und 10 ms? Das wäre beim MC coden ein super Vorteil. :-)
Gute Idee, habe ich eingebaut - 2 neue Control-Bytes also:
fast_getters = &E6 (10 micro seconds)
slow_getters (fuer BASIC) = &E5 (10 milli seconds)
Zudem habe ich das Protkoll nun doch noch mal überdacht, nun, wo ich den WAIT-Befehl widergefunden habe... im native mode wird READY auf dem Port mittels 32 angezeigt. Kommt ein Control-Byte, geht der Port sofort auf 0. Dann kann ein Wert gelesen werden, und nach 10 ms bzw. 10 us (s. oben) geht der Port wieder auf 0. Danach kann man mittels WAIT wieder darauf warten, dass LambdaSpeak wieder empfangsbereits ist (auf 32 warten). Das funktioniert sowohl im Blocking als auch im Non-Blocking-Mode. Anbei 2 Screenshots mit einem Testprogramm.
Zunächst ein Reset (&FF) Danach warten, bis sich der SSA1-Mode meldet (Default nach Reset / Einschalten). Dieser Mode meldet sich mittels 128 als "READY" (SSA1-Standard). Dann in den Epson-Mode schalten (&EF). Der Epson / Native Mode melde READY mittels 32, wie gesagt. Bestätigungen ausschalten (&E9), non-blocking mode (&EC), und dann 3 Werte lesen: Volume, Speak Rate, und Voice. S. Screenshots.
10 milli seconds funktionieren prima für BASIC, danke für den Test / Hinweis!
PS Man sieht doch - ausdenken kann man sich viel, wenn man es nicht selbst benutzt / programmieren tut, taugt es alles nichts. Jetzt scheint mir das Protokoll allerdings brauchbar; wenn ich mir den BASIC-Code anschaue, sieht das jetzt sauber aus (keine Warte-Schleifen mehr etc).
Übrigens - es scheint nicht möglich zu sein, mittels WAIT of ein 0-Byte zu warten?! Ist das richtig? Ich dachte an sowas wie WAIT &FBEE,255,255, aber das funktioniert nicht. Sollte doch eigentlich?!
Quote from: LambdaMikel on 19. January 2018, 08:32:20
PS Man sieht doch - ausdenken kann man sich viel, wenn man es nicht selbst benutzt / programmieren tut, taugt es alles nichts. Jetzt scheint mir das Protokoll allerdings brauchbar; wenn ich mir den BASIC-Code anschaue, sieht das jetzt sauber aus (keine Warte-Schleifen mehr etc).
Übrigens - es scheint nicht möglich zu sein, mittels WAIT of ein 0-Byte zu warten?! Ist das richtig? Ich dachte an sowas wie WAIT &FBEE,255,255, aber das funktioniert nicht. Sollte doch eigentlich?!
Der WAIT Befehl in BASIC. Da musste ich jetzt im Handbuch nachschlagen. Aber da ist ein Fehler. Mit einem Parameter wartet der WAIT Befehl bis die Antwort nicht 0 ist, allerdings wird bei einem Parameter die AND Verknüpfung verwendet. Stimmt also, 0-Bytes kann man nicht abfragen.
Aber um auf die Eingabe von 0 zu warten geht folgendes:
WHILE inp(&FBEE)<>0:WEND
Was ich noch nicht verstehe sind folgende Kommandos:
&EE - native_mode_dectalk - Ist das ein Dritter Modus neben Epson und SSA-1??
&EA - confirmations_on
&E9 - confirmations_off
&DE - flush_command
&C6 - sing_daisy
&C5 - echo_test_program
&C4 - test_message
Vielleicht kannst Du die ja kurz erklären? :)
Quote from: TFM on 19. January 2018, 14:31:37
Was ich noch nicht verstehe sind folgende Kommandos:
&EE - native_mode_dectalk - Ist das ein Dritter Modus neben Epson und SSA-1??
&EA - confirmations_on
&E9 - confirmations_off
&DE - flush_command
&C6 - sing_daisy
&C5 - echo_test_program
&C4 - test_message
Vielleicht kannst Du die ja kurz erklären? :)
Sehr gerne. Also:
- FE - der Epson-IC hat 2 Modi / Parser. Einen DecTalk-Parser, mit dem kann man sehr detailliert phonetisch modellieren. So kann er z.B. singen. Der Epson-Mode klingt etwas besser, und hat nur rudimentaere Modellierungs-Moeglichkeiten. Google mal nach DecTalk songs.
- FA, F9 - fuer die Setter/Getter-Funktionen, wenn Confirmations an sind, wird immer auch per Sprache ausgegeben. Also "Set Voice to 2", "Current Voice is 2". And so on.
- DE - das ganze funktioniert intern ja asynchron, es werden also Characters gepuffert bis entweder CR (13) kommt, oder aber - im SSA1-Modus - eine Zeit lang nichts mehr ankam. Dann wird der Puffer gesprochen. Der Puffer kann auch mittels dieses Kommandos geleert werden und wird dann gesprochen. Der Buffer hat 512 bytes. Ein echtes "synchrones Sprechen" - phoneme fuer phoneme in Echtzeit - ist mit dem Epson nicht moeglich. Der SSA1 kann das, aber diese Emulation eben nicht.
Fuer Spiele etc. bedeutet das halt, dass immer mit einer kleinen Verzoegerung gesprochen wird, und dass ab und zu eine Sprechpause einbaut werden muss, damit der Buffer nicht ueberlaueft (ansonstent wird er allerdings automatisch geleert). - C6 - eine demo, DecTalk singt. "Daisy Bell (Bicycle Built for Two)" is a popular song, written in 1892 by British songwriter Harry Dacre.
- C5 - ein ECho-Porttestprogramm. In diesem mode kann man Port IO auf &FBEE testen. Hardwaretest sozusagen. Alles, was auf out &fbee,x ausgegeben wird, wird mittels y=inp(&fbee) zurueckgeechoed. Also x=y. Der MOde kann nur durch Reset-Taste am LambdaSpeak verlassen werden.
- C4 - eine Test-SPrachausgabe, die den aktuellen Modus miteilt. NIcht wirklich essentiell. Funktioniert allerdings auch, wenn Confirmation Off sind. ALso doch nuetzlich.
... habe einmal ein Demo-Video der 2.0-Firmware hochgeladen:
https://youtu.be/9lcQwHY9uwA (https://youtu.be/9lcQwHY9uwA)
Demonstriert einige der oben diskutierten Control Bytes, und zeigt auch den DecTalk-Modus, mit dem LambdaSpeak "singen" kann. Das geht ganz einfach von BASIC aus.
Anbei das Programm aus dem Video; Happy Birthday DecTalk Song (teilweise) ab Zeile 190:
10 OUT &FBEE,&FF
20 a=INP(&FBEE):IF a<>128 GOTO 20
30 PRINT "hit space bar for quiet"
40 OUT &FBEE,&EF
50 WAIT &FBEE,32
60 OUT &FBEE,&EC
70 WAIT &FBEE,32
80 a$="hello how are you i am lambdaspeak 123456789"
90 FOR i=1 TO LEN(a$)
100 c$=MID$(a$,i,1)
110 OUT &FBEE,ASC(c$)
120 NEXT
130 OUT &FBEE,13
140 a=INP(&FBEE)
150 IF INKEY$=" " THEN OUT &FBEE,&DF:PRINT "quiet!"
160 IF a<>32 GOTO 140
170 REM
180 OUT &FBEE,&EE
190 a$="[:phone arpa speak on][:rate 200][:n1][hxae<300,10>piy<300,10> brr<600,22>th<100>dey<600,19>dih<600,15>rdeh<600,14>ktao<600,12>k_<120>_<120>][:n1]"
200 a$=a$+"[:phone arpa speak on][:rate 200][:n3][hxae<300,10>piy<300,10> brr<600,22>th<100>dey_<120>_<120>][:n3]"
210 FOR i=1 TO LEN(a$)
220 c$=MID$(a$,i,1)
230 OUT &FBEE,ASC(c$)
240 NEXT
250 OUT &FBEE,13
260 a=INP(&FBEE)
270 IF INKEY$=" " THEN OUT &FBEE,&DF:PRINT "quiet!"
280 IF a<>32 GOTO 260
290 REM
300 OUT &FBEE,&CE
310 WAIT &FBEE,255
320 PRINT INP(&FBEE)/16
330 a=INP(&FBEE):IF a<>0 THEN GOTO 330
340 WAIT &FBEE,32
350 OUT &FBEE,&CC
360 WAIT &FBEE,255
370 PRINT INP(&FBEE)/16
380 a=INP(&FBEE):IF a<>0 THEN GOTO 380
390 WAIT &FBEE,32
400 OUT &FBEE,&B2
410 WAIT &FBEE,32
420 OUT &FBEE,&CD
430 WAIT &FBEE,255
440 PRINT INP(&FBEE)/16
450 a=INP(&FBEE):IF a<>0 THEN GOTO 450
460 WAIT &FBEE,32
470 OUT &FBEE,&CD
Das Video verwendet LambdaSpeak 1.8-Hardware - eine weitere Zwischenversion auf dem Weg zu LambdaSpeak 2.0. Die Firmware von 1.8 ist identisch zu 2.0. Der Atmega644 wird die gleiche pin-Belegung etc. verwendet. In 2.0 wird das GAL 22V10, 74LS374 und 74LS244 gegen einen Xilinx XC9572xl TQ100 CPLD ersetzt. Alles in SMD, 3-Chip-Design (ATmega, Epson Speech IC, und Xilinx CPLD also). Leider gibt es noch ein Problem mit dem CPLD, sodass es noch etwas dauert, bis LS 2.0 fertig ist.
Anbei ein paar Bilder vom aktuellen Breadboard, dass noch etwas debugging braucht - bis auf den SSA1-Treiber funktioniert es (|say scheint Allophone-Bytes zu verschlucken, was sehr rästelhaft ist, dass Spiele wie Roland in Space diesen Defekt bei der Sprachausgabe nicht zeigen).
Quote from: LambdaMikel on 07. February 2018, 09:56:31
Anbei ein paar Bilder vom aktuellen Breadboard, dass noch etwas debugging braucht - bis auf den SSA1-Treiber funktioniert es (|say scheint Allophone-Bytes zu verschlucken, was sehr rästelhaft ist, dass Spiele wie Roland in Space diesen Defekt bei der Sprachausgabe nicht zeigen).
Good news - das Problem wurde behoben. Das LambdaSpeak 2.0 Breadboard funktioniert jetzt. Ich hatte die VCCIO-Stromversorgung für den Xilinx CPLD nicht richtig gemacht. Hat jetzt seinen eigenen Spannungsregler, und damit ist das Problem behoben
Also nur noch eine Frage der Zeit, bis LambdaSpeak 2.0 in SMD als 3-Chip-Version erscheint. Bryce macht das.
So, hab mal das BASIC Beispiel vervollständigt... siehe angehängte DSK.
Programm mit run"LS" starten
Man sollte den LambdaSpeak zuerst mittels Option 10 in den nativen EPSON Modus schalten, da er sonnst den SSA-1 emuliert (dafür ist die Software nicht).
Achtung: Wenn man mit 27 oder 28 die Sprache umstellt, dann anschließend Punkt 10 benutzen, sonnst wird die Sprache nicht umgestellt. (Anstatt 10 kann man auch 11 nehmen, das ist dann DECtalk anstatt Epson).
Bei Fragen und Anregungen bitte gerne hier. :)
Hi Stefan,
habe ich gerade mal ausprobiert auf meinem CPC 464 - gute Idee, alles zu bündeln!! :jubelaola:
Einige kleinere Problemchen:
- die Control-Bytes bei meiner Version haben sich geändert. Du könntest mittels getVersion abfragen, ob < 4, dann ist es Deine Belegung, sonst ist es die Belegung oben
- einige Kommandos funktionieren noch nicht richtig, z.B. gibt HAL9000 einen Syntax error in line 65423 o.ä. Ich denke, dass ist durch Ansprung der "leeren" BASIC-Zeilen bedingt! Weiss gar nicht, wie Du die eigentlich erzeugt hast... einfach nur Leerzeichen in der Zeile??? Vielleicht geht das nur auf 664 oder 6128 oder Emulator - der 464 hängt sich da weg.
Control bytes für Version > 3:
case 0xFF : process_reset(); break;
case 0xEF : native_mode_epson(); break;
case 0xEE : native_mode_dectalk(); break;
case 0xED : ssa1_mode(); break;
case 0xEC : dktronics_mode(); break;
case 0xEB : non_blocking(); break;
case 0xEA : blocking(); break;
case 0xE9 : confirmations_on(); break;
case 0xE8 : confirmations_off(); break;
case 0xE7 : english(); break;
case 0xE6 : spanish(); break;
case 0xE5 : fast_getters(); break;
case 0xE4 : slow_getters(); break;
case 0xDF : stop_command(); break;
case 0xDE : flush_command(); break;
case 0xCF : get_mode(); break;
case 0xCE : get_volume(); break;
case 0xCD : get_voice(); break;
case 0xCC : get_rate(); break;
case 0xCB : get_language(); break;
case 0xCA : get_delay(); break;
case 0xC9 : get_version(); break;
case 0xC8 : speak_copyright_note(); break;
case 0xC7 : speak_hal9000_quote(); break;
case 0xC6 : sing_daisy(); break;
case 0xC5 : echo_test_program(); break;
case 0xC4 : echo_test_program_dk(); break;
case 0xC3 : test_message(); break;
case 0xB0 : set_voice_default(); break;
case 0xB1 : set_voice(1); break;
case 0xB2 : set_voice(2); break;
case 0xB3 : set_voice(3); break;
case 0xB4 : set_voice(4); break;
case 0xB5 : set_voice(5); break;
case 0xB6 : set_voice(6); break;
case 0xB7 : set_voice(7); break;
case 0xB8 : set_voice(8); break;
case 0xB9 : set_voice(9); break;
case 0xBA : set_voice(10); break;
case 0xBB : set_voice(11); break;
case 0xBC : set_voice(12); break;
case 0xBD : set_voice(13); break;
case 0xBE : set_voice(14); break;
case 0xBF : set_voice(15); break;
case 0xA0 : set_volume_default(); break;
case 0xA1 : set_volume(1); break;
case 0xA2 : set_volume(2); break;
case 0xA3 : set_volume(3); break;
case 0xA4 : set_volume(4); break;
case 0xA5 : set_volume(5); break;
case 0xA6 : set_volume(6); break;
case 0xA7 : set_volume(7); break;
case 0xA8 : set_volume(8); break;
case 0xA9 : set_volume(9); break;
case 0xAA : set_volume(10); break;
case 0xAB : set_volume(11); break;
case 0xAC : set_volume(12); break;
case 0xAD : set_volume(13); break;
case 0xAE : set_volume(14); break;
case 0xAF : set_volume(15); break;
case 0x90 : set_rate_default(); break;
case 0x91 : set_rate(1); break;
case 0x92 : set_rate(2); break;
case 0x93 : set_rate(3); break;
case 0x94 : set_rate(4); break;
case 0x95 : set_rate(5); break;
case 0x96 : set_rate(6); break;
case 0x97 : set_rate(7); break;
case 0x98 : set_rate(8); break;
case 0x99 : set_rate(9); break;
case 0x9A : set_rate(10); break;
case 0x9B : set_rate(11); break;
case 0x9C : set_rate(12); break;
case 0x9D : set_rate(13); break;
case 0x9E : set_rate(14); break;
case 0x9F : set_rate(15); break;
case 0x80 : set_buffer_delay_default(); break;
case 0x81 : set_buffer_delay(1); break;
case 0x82 : set_buffer_delay(2); break;
case 0x83 : set_buffer_delay(3); break;
case 0x84 : set_buffer_delay(4); break;
case 0x85 : set_buffer_delay(5); break;
case 0x86 : set_buffer_delay(6); break;
case 0x87 : set_buffer_delay(7); break;
case 0x88 : set_buffer_delay(8); break;
case 0x89 : set_buffer_delay(9); break;
case 0x8A : set_buffer_delay(10); break;
case 0x8B : set_buffer_delay(11); break;
case 0x8C : set_buffer_delay(12); break;
case 0x8D : set_buffer_delay(13); break;
case 0x8E : set_buffer_delay(14); break;
case 0x8F : set_buffer_delay(15); break;
Ich weiss, hätte ich eigentlich abwärts-kompatibel gestalten sollen, aber.... ich wollte die Modi zusammenhängend haben.
Evtl. kommt noch Amdrum mode, aber der wird die Bytes nicht verschieden und kann seperat sein (E3 oder so).
Ja, lieber jetzt alles noch mal anpassen als später. Ist ja noch alles in der Entwicklung. Langsam wird der LambdaSpeak ja die Eier-legende Woll-Milch-Sau. :) :) :)
EDIT: Hier mal eine erste Idee einer RSX Erweiterung. Mit run"disc" starten. Bei Fragen bitte gerne hier :-)
Zum !SPEAKSCREEN. Man muss zuvor auf nativen Modus umschalten (!LAMBDA bzw. !DECTALK) und mit !BLOCKON auf Blocking-Mode gehen.
Achtung: Das !SPEAKSCREEN könnte auf dem 464 nicht laufen, muss ich noch testen. Auf dem 6128 funktioniert es (liest Bildschirminhalt vor).
cu. TFM
Liebe Leute,
Habe jetzt die relozierbare Version der RSX Software fertig.
Updates werde ich immer auf meiner Seite bereithalten:
http://www.futureos.de - Unter Downloads, am Ende der Seite
cu. Stefan
So, ROM fertig... Viel Spass! Direkter Link:
http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip
passiert nix bei mir :-[
ach ich vergaß, Modul fehlt :zunge0020:
So, kleines Update des LS-ROMs:
- Einschaltmeldung
- Fehlermeldung bei Prüfsummenfehler
- Kommando |LSHELP hinzugefügt um alle Befehle anzuzeigen.
Es sind noch fast 14 KB frei im ROM, also da ist noch Platz nach oben. :) :) :)
Kleines Update, RSX-Befehl !LSINIT hinzugefügt, keine Einschaltverzögerung mehr. Download wie immer auf meiner HP. Direkter Link:
http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip
Habe nun noch den Befehl |SPEAKFILE hinzugefügt, um Dateien sprechen zu lassen.
Was noch fehlt ist die Abfrage von ESC, aber das kommt dann beim nächsten Update.
Sehr cool! :jubelaola:
Muss ich bald ausprobieren.
Uebrigens, wenn einer sich selbst eines machen will - ist alles alles im GitHub nun:
https://github.com/lambdamikel/LambdaSpeak
TFM, koenntest Du evtl. einen Absatzt schreiben dafuer? Vielleicht mit Screenshot von |lshelp, Link auf Deine Homepage fuer die Software, und kurzer Erlaeuterung der Main-Features? Wenn nicht, mache ich das irgendwann :)
LG
Michael
Quote from: TFM on 09. April 2018, 17:11:41
Es sind noch fast 14 KB frei im ROM, also da ist noch Platz nach oben. :) :) :)
Na, eine Idee hätte ich ja noch.... wie wäre es mit einer Implementation des DK'tronics Deutsch-nach-DKtronics-Phonem-Translators :-)
Das ist das Basic Programm, dass die Sprachausgabe im deutschen Elisa macht, für SSA-1 oder DKtronics Mode. Nur so ne Idee. :smiley027:
Zwei gute Ideen! Aber ich hab grad auch a bisserl was um die Ohren, aber bis das schöne LambdaSpeak zum verkauf steht sollte das hinhauen :-)
Die dk'tronics Sache würde ich dann natürlich in MC umschreiben. Aber da muss ich mich auch erst mal einlesen. Da wäre es gut den entsprechenden BASIC Code allein (ohne Eliza) zu haben, kann mir jemand ein DSK anhängen? :-)
Hi TFM, das Programm fuer DKtronics spricht Deutsch ist aus der CPC-International.
Ich habe es in der LS195.dsk auf GitHub, "sprache.bas", DSK auch anbei.
Ah, super!
Update: !SPEAKSCREEN und !SPEAKFILE können nun durch (längeres) drücken von ESC beendet werden.
Ich wollte auch hier noch einmal darauf hinweisen, dass sich jetzt jeder selbst ein LambdaSpeak zusammenloeten kann:
https://github.com/lambdamikel/LambdaSpeak
Ich bin mir nicht sicher, ob es jemals eine groessere "Serieproduktion" geben wird. Dafuer ist das Interesse zu gering. Die PCB-Gerbers sind nun auch bei OshPark oeffentlich.
Viel Spass damit, fuer mich war's das jetzt erstmal mit dem Projekt.
Vielen Dank noch mal an TFM fuer die tolle Software!!
Ein super Projekt - und schön, dass es fertig geworden ist. Eine Serie gibt's ja dann von Bryce.
LamdaSpeak 1.99 mit SPO256-AL2-Option.
Die Gerbers sind hier:
https://oshpark.com/shared_projects/JyRKoPdz (https://oshpark.com/shared_projects/JyRKoPdz)
Sollte jemand das nachbauen wollen - ich kann gerne programmierte GALs und ATmega 644s per Post schicken
(allerdings nicht umsonst). Bei Interesse bitte per PM an mich. Porto von USA nach D beträgt ca. 14 $.
Das würde sich dann fast eine Sammelbestellung anbieten. :smiley027:
Langsam verliere ich den Überblick ;) :zunge0020:
Quote from: TFM on 27. May 2018, 01:43:38
Langsam verliere ich den Überblick ;) :zunge0020:
In der Tat, ich habe das Github Repository jetzt mal gründlich aufgräumt und die Beschreibung verbessert.
So sollten die verschiedenen Produkt-Varianten verständlicher sein.
Super toll wäre übrigens, wenn Deine RSX-Erweiterung noch |ssa1spo und |dktronicsspo anbieten würde -
die Control Bytes sind &E2 und &E1. Nur wenn Du noch mal gaaaanz viel lange Weile haben solltest ;)
Oder |ssaspo und |skspo oder wie auch immer :) Oder |spossa und |spodk ? Hmm :irre:
Kann ich gerne einbauen. :) Aber ich frage jetzt trotzdem nochmal, auch wenn Du das schon schön im CPCWiki erklärt hast. Was machen denn die Bytes E1 und E2 genau?
Edit: So, hab die RSX (im ROM) mal eingefügt, auch wenn ich nicht genau weiß was die machen. Selber nutze ich ja fast nur den LS Modus. Hier der Download Link (wie immer):
http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip
Über Feedback wäre ich wie immer froh, am besten mit konstruktiver Kritik. :smiley027:
Super, das ging ja schnell!
Allerdings ist in der DSK vom 28.5. die RSX-Version vom 18.3. drin.
Falsche Datei erwischt? Konnte |spodk etc also nicht finden.
Quote from: TFM on 27. May 2018, 20:07:44
Kann ich gerne einbauen. :) Aber ich frage jetzt trotzdem nochmal, auch wenn Du das schon schön im CPCWiki erklärt hast. Was machen denn die Bytes E1 und E2 genau?
Ganz vergessen zu antworten - E2 schaltet den SPO256-AL2 an, und dann SSA1-Modus. E1 ebenso, aber fuer DKtronics. Die Sprachausgabe wird dann also vom SPO256 erledigt in diesen Modi. Die beiden Modi unterscheiden sich nur unwesentlich voneinander. Der ATMega setzt eine Steuerleitung, je nachdem, ob SSA1 oder DKtronics, und der 2. GAL liest dieses Steuersignal. Der 2. GAL uebernimmt die Rolle des 74LS244, da nun etwas mehr Logik erforderlich war. SSA-1 schleift SBY und _LRQ vom SPO256 auf Bit 7 und Bit 6 vom Datenbus, waerend DKtronics nur _LRQ auf Bit 7 durchschleift. Und in den Epson-basierten Sprachausgabe-Modi wird natuerlich nach wie vor vom GAL der ATmega Port auf den CPC-Datenbus gegeben. Daher also der 2. GAL, der als Datenbus-Multiplexer (je nach Mode) fungiert.
PS, wie gesagt, die RSX-Erweiterung aus der DSK hat die beiden neuen Befehle noch nicht. Ich denke, Du hast die falsche Datei erwischt als Du die DSK gemacht hast. (BASIC Info zeigt dass das die Version vom 18.3. ist)
Probier das ROM, die anderen Sachen mache ich erst wenn wir eine Final-Version haben, denn ich muss da viel mit der Hand anpassen, wenn es schön elegant relozierbar sein soll.
Also nochmal: Nur das ROM ist auf der Disk in der neuesten Version :-)
Quote from: TFM on 29. May 2018, 22:38:29
Probier das ROM, die anderen Sachen mache ich erst wenn wir eine Final-Version haben, denn ich muss da viel mit der Hand anpassen, wenn es schön elegant relozierbar sein soll.
Also nochmal: Nur das ROM ist auf der Disk in der neuesten Version :-)
Hab's jetzt getested, mit meinem neuem RomboRedux und echtem EPROM - funktioniert! Super, danke!
Danke Dir für die Anregung :-)
Neue PCB von Seeed Studio sind eingetroffen :)
Quote from: LambdaMikel on 24. June 2018, 08:02:39
Neue PCB von Seeed Studio sind eingetroffen :)
sehr schön ;D
Und wie! Super schön! Nebenbei: Nix geht über blaue LED's :sign17:
Quote from: TFM on 24. June 2018, 19:26:03
Und wie! Super schön! Nebenbei: Nix geht über blaue LED's :sign17:
ist mir garnicht aufgefallen, aber sehe ich bald in Original 😉
Habe den 1.5er, aber eben auch mit wunderschöner LED! :flehan:
habe eben noch Steckplätze frei :)
hatte damals das originale DKTronics Speech Modul für den 464, hätte ich gewusst, das der eine Chip so rar ist und ich den benötige, hätt ich das nicht verkauft.
Freut mich, dass die LEDs gefallen :00008351:
Ja, was den SPO256-AL2 Chip angeht: interessant ist vor allem, dass das Ding gefälscht wird!
Also muss es wohl einen "Markt" dafür geben, dass sich das Umlabeln lohnt? Was es nicht alles gibt:
http://www.smbaker.com/counterfeitfakejustplainbad-sp0256a-al2-chips (http://www.smbaker.com/counterfeitfakejustplainbad-sp0256a-al2-chips)
Ich wollte die Sache mit den "Chip-Fälschungen" zuerst nicht glauben (schien mir weit hergeholt), hatte dann aber bei Ebay mal einen dieser NOS SPO's erworben, und in der Tat, die taugen nur für den Eimer.
Update der ROM Software (nicht RAM-RSX). ...
Quote from: TFM on 28. June 2018, 22:01:17
Update der ROM Software (nicht RAM-RSX). ...
was wurde geändert? 😉
Kleinigkeiten, Bugs, nix besonderes. :)
mein LS1. 99 ist heute gekommen, funzt schonmal, mal paar Tests gemacht. Warte nur noch auf diesen seltenen Chip, damit es dann auch wie original funzt. Sollte bald eintreffen.
Quote from: Rennert on 04. July 2018, 16:23:53
mein LS1. 99 ist heute gekommen, funzt schonmal, mal paar Tests gemacht. Warte nur noch auf diesen seltenen Chip, damit es dann auch wie original funzt. Sollte bald eintreffen.
Ah, das hört man doch gerne - hoffe, es geht mit und ohne Bus-Treiber ;) Und, auch schon Amdrum probiert? Du hattest ja angeregt, dass von DSK statt von CDT / TAPE zu laden Ich habe das noch nicht ausprobiert - klappt das bei Dir? Unterstützt die Amdrum-Software Diskette?
Ein Photo vom LS 1.99 am KC Compact wäre super ;)
Foto kommt heute 😄
die Amdrum Software habe ich gestartet, probieren tue ich mal wenn Zeit ist.
das LS1. 99 funzt hinter den Bustreibern ohne Probleme, die Karte steckt ganz hinten.
Komme mit der Amdrum Software nicht so zurecht :)
Wie kann ich ein Sample zum Test laden? Muss mich erst durch die englische Anleitung kämpfen.
Gut Amdrum funktioniert auch vom HxC, also Diskette. Habe mir bei Youtube ein Video angesehen und dann das AfroKit geladen und Demo abgespielt.
hier noch die Files fürs Amdrum :)
Quote from: Rennert on 06. July 2018, 20:10:02
hier noch die Files fürs Amdrum :)
Danke, muss ich mal ausprobieren!
Nett! Die AMDRUM Disk funktinoiert!
Quote from: LambdaMikel on 09. July 2018, 02:55:45
Nett! Die AMDRUM Disk funktinoiert!
Was nicht nett ist - sobald XMem mit LambdaSpeak ROM an Board mit von der Partie ist, semmelt Amdrum ab beim Laden des Drumkits....
ohne XMem geht's. :banghead:
Freue mich auf mein RomboReduxDelux mit Platinenstecker (!)
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/rombo-redux-deluxe-new-romboard/
und hoffe, damit geht es besser... zum Glück kann man den Amdrum-Mode ja einfach mittels
out &fbee,&e3 einschalten, auch ohne TFM's geniales ROM.
benutze grad auch ein X-Mem und funzt mit Drumkit laden.
Hmmm... es ist ein Trauerspiel. Wie kommt es, dass es in einer Config funtzt, und in der anderen nicht?
Na ja, u.a. liegt es ja auch irgendwie an den anderen ROMs, die ich geladen habe??
Quote from: LambdaMikel on 09. July 2018, 07:44:37
Na ja, u.a. liegt es ja auch irgendwie an den anderen ROMs, die ich geladen habe??
Ja, das könnte sein. Parke die mal Stück für Stück und schau, ob es einen Unterschied macht. Hoffentlich liegt's nicht am LS-ROM. :( Viel Glück in jedem Fall!
Nein ich benutze auch das LS-Rom und habe keine Probleme. Roms muss ich nicht deaktivieren.
Übrigens ist heut der SPO Chip inkl. Quarz gekommen und funktioniert super, Klar klingt emuliert besser, aber so kommt original aufm TV.
Quote from: Rennert on 09. July 2018, 18:46:01
Nein ich benutze auch das LS-Rom und habe keine Probleme. Roms muss ich nicht deaktivieren.
Übrigens ist heut der SPO Chip inkl. Quarz gekommen und funktioniert super, Klar klingt emuliert besser, aber so kommt original aufm TV.
TFM, glaube nicht, dass es Dein ROM ist. Vielleicht die Kombination mit anderen ROMS. Muss mal aufraeumen und alles andere rausschmeissen.
Rennert, das freut mich dass es alles klappt!! Hoffe, der SPO war nicht zu teuer. Foto am KC waere wie gesagt nett ;)
naja hab den von deinem eBay Link gekauft, nicht gerade ein Schnäppchen, Aber eben Original :)
Foto mache ich noch, wenn mein 4MB wieder da ist. Grad ne Lücke in der Modulkette :kaffee:
Quote from: LambdaMikel on 09. July 2018, 21:59:55
TFM, glaube nicht, dass es Dein ROM ist. Vielleicht die Kombination mit anderen ROMS. Muss mal aufraeumen und alles andere rausschmeissen.
Habe alles aus XMem rausgeschmissen, nur Maxam und TFM ROM.
Dann läuft es ohne Probleme. Vielleicht das DKtronics ROM o.ä. was das Problem war.
Das dk'tronics ROM könnte sicher eine Art Initialisierung durchführen. Einfach mal den Disassembler drüber laufen lassen ,-)
Hi Michael,
ich habe letzte Woche Dein Lambda-Speak Kit erhalten, zusammengelötet und heute versucht das Teil zu testen. Auf meinem MX4 Board steckt ein M4 und das Lambda eben, die ROMs von TFM auf Slot 4 geladen.
Am TexttoSpeech Board hängt ein Lautsprecher. Beim Einschalten der Stromversorgung (durch ein PC Netzteil) ertönt eine Stimme "LambdaSpeak initialized..." (der CPC ist aber zum Zeitpunkt noch aus). Sobald der CPC eingeschaltet wird, sagt Stefans ROM in der Einschaltmeldung, dass LambdaSpeak initialisiert wurde. Jedoch funktioniert diese nicht. Alle RSX werden zwar akzeptiert, aber keine Stimme ertönt.
Interessant ist, das die linke LED (wenn der CPC aus ist, die Stromversorgung aber an) dauerhaft leuchtet, wenn der CPC eingeschaltet wird die rechte LED kurz mitleuchtet und dann beide ausgehen.
Hast Du einen Rat woran das liegen könnte?
Viele Grüße.
Quote from: HAL6128 on 20. July 2018, 21:21:09
Hi Michael,
ich habe letzte Woche Dein Lambda-Speak Kit erhalten, zusammengelötet und heute versucht das Teil zu testen. Auf meinem MX4 Board steckt ein M4 und das Lambda eben, die ROMs von TFM auf Slot 4 geladen.
Am TexttoSpeech Board hängt ein Lautsprecher. Beim Einschalten der Stromversorgung (durch ein PC Netzteil) ertönt eine Stimme "LambdaSpeak initialized..." (der CPC ist aber zum Zeitpunkt noch aus). Sobald der CPC eingeschaltet wird, sagt Stefans ROM in der Einschaltmeldung, dass LambdaSpeak initialisiert wurde. Jedoch funktioniert diese nicht. Alle RSX werden zwar akzeptiert, aber keine Stimme ertönt.
Interessant ist, das die linke LED (wenn der CPC aus ist, die Stromversorgung aber an) dauerhaft leuchtet, wenn der CPC eingeschaltet wird die rechte LED kurz mitleuchtet und dann beide ausgehen.
Hast Du einen Rat woran das liegen könnte?
Viele Grüße.
lsinit ausgeführt?
Stimmt :-) Am Anfang bitte einmal !LSINIT aufrufen. Und vor dem !SPEAKSCREEN bitte einmal das !BLOCKON aufrufen (um Blocking einzuschalten). :)
obwohl es bei mir auch ohne Lsinit funktioniert
Quote from: HAL6128 on 20. July 2018, 21:21:09
Hi Michael,
ich habe letzte Woche Dein Lambda-Speak Kit erhalten, zusammengelötet und heute versucht das Teil zu testen. Auf meinem MX4 Board steckt ein M4 und das Lambda eben, die ROMs von TFM auf Slot 4 geladen.
Am TexttoSpeech Board hängt ein Lautsprecher. Beim Einschalten der Stromversorgung (durch ein PC Netzteil) ertönt eine Stimme "LambdaSpeak initialized..." (der CPC ist aber zum Zeitpunkt noch aus). Sobald der CPC eingeschaltet wird, sagt Stefans ROM in der Einschaltmeldung, dass LambdaSpeak initialisiert wurde. Jedoch funktioniert diese nicht. Alle RSX werden zwar akzeptiert, aber keine Stimme ertönt.
Interessant ist, das die linke LED (wenn der CPC aus ist, die Stromversorgung aber an) dauerhaft leuchtet, wenn der CPC eingeschaltet wird die rechte LED kurz mitleuchtet und dann beide ausgehen.
Hast Du einen Rat woran das liegen könnte?
Viele Grüße.
Hallo HAL,
wie kriegt denn das LambdaSpeak Strom? Es scheint so zu sein, dass es nicht vom CPC versorgt wird, sondern mit einem PC-Netzteil?
Ich muss sagen, dass ich so eine Konfiguration nicht getestet habe. Mit Lautsprecher meinst Du sicherlich einen Lautsprecher mit Verstärker?
Was passiert denn, wenn Du Reset drückst.
Ich würde einmal empfehlen, dass LambdaSpeak ohne ROMs etc. zu testen, und zwar mit Stromversorgung vom CPC.
Da es spricht, ist die CPU etc. iO. Evtl. liegt der Fehler dann im Flipflop oder im GAL, oder ein Zusammenbau-Fehler.
Falls Du es nicht hinkriegst, kannst Du es gerne zurück schicken, dann versuche ich, es zu reparieren.
Ein guter Test ist auch folgendes: LambdaSpeak Reset, dann out &fbee,&C5
Das sollte dann sagen "Echo Test Mode Program". Wenn nicht, kommt nichts an am LambdaSpeak, und irgendwas funktioniert nicht richtig.
Falls es in den Echo Test Mode gewechselt hat, dann folgendes BASIC-Programm zum Testen der Kommunikation:
10 a = round(rnd(1)* 255)
20 out &fbee,a
30 b = inp(&fbee)
40 if a<>b then print "!"
50 goto 10
Das sollte keine "!" auf den Bildschirm drucken. Wenn doch, ist es defekt.
LambdaSpeak benötigt kein ROM. Einfach mal ohne alles testen bitte, wie gesagt.
S. auch hier
https://github.com/lambdamikel/LambdaSpeak
So was wie out &fbee, &ff sollte z.B. ein RESET auslösen, etc.
Auch gut zum Testen: out &fbee, &c7 (HAL 9000 Sprüche)
Viele Grüße
Michael
PS Die Komponenten hatte ich einzeln getestet vorm Verschicken; das GAL z.B. wurde verifiziert, und die CPU ebenfalls und der text to speech. Aber die letzteren beiden funktionieren bei Dir ja auch. Wenn Du mir ein Foto von Deinem Aufbau schickst, kann ich den Aufbau meinem M4 und Mother4X replizieren.
Also ich habe jetzt mal 6128 + M4 + LambdaSpeak 1.95 zusammen getestet.
Wenn ich demo01.bas laufen lasse, habe ich keine Probleme. Allerdings scheint es ein Timing-Problem mit der RSX-Erweiterung zu geben, dass nur auftritt, wenn M4 mit von der Partie ist... Stefan, wenn ich |lambda und a$="test" mit |ls,@a$ verwende, hängt die Erweiterung manchmal und kommt nicht zum BASIC zurück nachdem gesprochen wurde. Eine Idee, woran das liegen könnte? Anscheinend kriegt die RSX-Erweiterung nicht mit, dass LambdaSpeak "zu Ende" gesprochen hat (verpasst das Ready-Signal).
Das Problem tritt übrigens nicht auf, wenn ich das ROM vom ROMBO-Redux laufen lasse. Scheint also irgendwie durch das M4 zu kommen.
OK, mein M4 scheint ein Defekt zu haben. Wenn ich ROLAND IN SPACE A.dsk lade mittels run "disc", nach der Abfrage "Are you using a green screen?", geht das Relais beim 464 Kassettenrekorder an, und wenn ich dann Escape drücke, gibt es ein Reset... hmmm. Diesen Effekt habe ich mit dem DDI3 nicht. Wohlgemerkt, dass tritt auf OHNE LambdaSpeak im Setup. Das M4 scheint mit der Abfrage von Roland In Space nach dem Sprachsynthesizer ein Problem zu haben???
Also, HAL, bitte erstmal M4 außen vor lassen. Das scheint etwas problematisch an sich zu sein.
Bitte mal ausprobieren mit M4:
http://www.cpcwiki.eu/index.php/Roland_in_Space
DSK Seite A auf SDKarte, dann a$="rolspacea.dsk" (habe ich umbenannt), dann |cd,@a$, run "disc - > Y / N -> hängt. Nach ESC reset vom CPC :-(
Ich habe mal hier nachgefragt für das M4 Problem:
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg163054/#msg163054 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg163054/#msg163054)
Quote from: LambdaMikel on 21. July 2018, 06:40:41
Ich habe mal hier nachgefragt für das M4 Problem:
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg163054/#msg163054 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/msg163054/#msg163054)
Das könnte evtl ein BZD-Problem sein... scheint so zu sein, dass nach run"disc der Lader versucht, von Kassette zu laden... aber warum? Unterstützt die M4-DSK-Emulation u.U. keine Amsdos-Lade-Routinen?
@hal6128 - das sollte mit M4 in jedem Fall funktionieren:
SSA-1.DSK laden mittels M4, run "ssa-1". Dann mit sowas wie a$= "hello how are you" :|say,@a$ testen.
Das funktioniert bei mir z.B. ohne Probleme.
@TFM - hast Du das ROM mit M4 ausprobiert / entwickelt, oder mit EPROM Board?
Falls es ein Timing-Problem ist, dass interessanterweise nur mit M4 auftritt, muss ich Dir evtl. doch noch mal ein LambdaSpeak 1.95 zuschicken, dass ja etwas andere Hardware hat als das LambdaSpeak 1.5, dass Du hast.
Quote from: LambdaMikel on 21. July 2018, 08:03:40
@TFM - hast Du das ROM mit M4 ausprobiert / entwickelt, oder mit EPROM Board?
Falls es ein Timing-Problem ist, dass interessanterweise nur mit M4 auftritt, muss ich Dir evtl. doch noch mal ein LambdaSpeak 1.95 zuschicken, dass ja etwas andere Hardware hat als das LambdaSpeak 1.5, dass Du hast.
... meine Zusammenfassung: TFM LS ROM funktioniert mit XMem, RomboRedux, aber nicht mit M4. Aus unerfindlichen Gründen.
Ok, ich werde den LS dann mal mit dem M4 ausprobieren, muss dazu nur noch etwas umbauen ;-) In ein paar Tagen weiß ich mehr. Mit dem M4 hab ich zum Teil auch Probleme, könnte aber auch daran liegen, dass der GT65 nicht wirklich viele Amps bringt. Werde es herausfinden.
Noch ein Tip! Bei mir gab's öfters mal Probleme, weil das Flachbandkabel (Quetsch-Stecker!) gezickt hat. Also sollte der LS mal nicht funktionieren, dann bitte die Datei... "ECHO.BAS" und "ECHO-DK.BAS" starten um das zu prüfen, wenn ein "X" erscheint ist da ein Kabel-Problem, wenn lauter "O" erscheinen ist alles ok. Es schadet auch nicht während des Laufs des Testprogramms mal die Erweiterung ein bisserl zu bewegen, kommt dann da ein "X" dann ist das Kabel nicht gut. Bitte testen!
Hab das LSROM aufm M4 drauf und funzt
Quote from: LambdaMikel on 21. July 2018, 03:22:21
Hallo HAL,
wie kriegt denn das LambdaSpeak Strom? Es scheint so zu sein, dass es nicht vom CPC versorgt wird, sondern mit einem PC-Netzteil?
Ich muss sagen, dass ich so eine Konfiguration nicht getestet habe. Mit Lautsprecher meinst Du sicherlich einen Lautsprecher mit Verstärker?
Viele Grüße
Michael
Yeah, das LambdaSpeak Board läuft. Ich habe es direkt (ohne MotherX4-Erweiterungsboard) and den Expansion-Port angeschlossen. Zumindest weiß ich nun, das ich richtig gelötet habe. Es meldet sich beim Einschalten des CPC und die linke LED läuft nun dauerhaft. Ich habe die Diskette von TFM geladen (mit RUN"DISC"). Es wird alles korrekt geladen. Alle RSX sind funktionsfähig, das LambdaSpeak spricht (und singt sogar :) )!
Ich vermute mal, dass das MotherX4-Erweiterungsboard einfach zu wenig Strom auf das LambdaSpeak Board gibt.
Schade, dass das MotherX4 so empfindlich ist.
Demo01.BAS von der Diskette funktioniert leider nicht. Nach dem Reset über OUT &FBEE,&FF bleibt der CPC in Zeile 30 hängen. Das LambdaSpeak scheint den Reset irgendwie nicht zu vertragen. Danach muß ich den CPC ein- und wieder ausschalten.
Der Reset mittels Taster auf dem Board funktioniert im laufenden Betrieb. Das Board resetet / bootet wieder.
Quote from: HAL6128 on 21. July 2018, 15:48:19
Ich vermute mal, dass das MotherX4-Erweiterungsboard einfach zu wenig Strom auf das LambdaSpeak Board gibt.
Schade, dass das MotherX4 so empfindlich ist.
Da hilt u.U. der "Hack" die Dioden auszulöten / zu überbrücken. Damit kann ich LambdaSpeak, XMem und DDI3 ohne Probleme betreiben am MotherX4, ohne externe Stromversorgung.
Quote from: HAL6128 on 21. July 2018, 16:09:19
Demo01.BAS von der Diskette funktioniert leider nicht. Nach dem Reset über OUT &FBEE,&FF bleibt der CPC in Zeile 30 hängen. Das LambdaSpeak scheint den Reset irgendwie nicht zu vertragen. Danach muß ich den CPC ein- und wieder ausschalten.
Der Reset mittels Taster auf dem Board funktioniert im laufenden Betrieb. Das Board resetet / bootet wieder.
Hmm, das ist nicht gut. Bitte einmal das Echo-Test-Programm eintippen und laufen lassen. Gibt es "!" auf dem Schirm?
Sonst bitte an mich schicken, ich gucke es mir an. Rück-Porto aus USA bezahle ich.
Und wie sieht es mit anderen Sachen aus? Ist Rest das einzige, das nicht funktioniert? Z.B. Roland in Space und SSA1 Disk?
Quote from: Rennert on 21. July 2018, 12:11:06
Hab das LSROM aufm M4 drauf und funzt
OK, Du hast alledings KC Compact und Bustreiber und LambdaSpeak 1.99
Ich werde LS 1.99 auch mal mit M4 testen.
I.Allg. ist es so, dass es eine 2-Wege-Kommunikation zwischen CPC Treiber und Lambdaspeak ist.
Geht denn ein einfaches out &fbee,&ff in BASIC direkt eingetippt nach Power Cycle, oder hängt
der CPC dann? (Wie gesagt, für OUT &FBEE, xx braucht man überhaupt keine Software auf dem CPC,
nur BASIC)
Hi,
die SSA1 Disc und "Roland in Space" funktionieren. Roland in Space nur bis Start Bildschirm inklusive Sprachausgabe, da ich das Programm auf Laufwerk B: (3,5 Zoll) habe, danach sucht das Programm auf Laufwerk A und hängt sich auf. Ich denke, dass geht soweit in Ordnung.
Beim Echo-Programm kommt eine Ansage und es werden "O" ausgegeben.
Ich habe mal das Board fotografiert, die Capacitors beschriftet und angehängt. Bei den Widerständen bin ich mir sicher, diese richtig (nach Deiner Beschriftung auf den Beuteln) eingesetzt und verlötet zu haben.
Blöde Frage (bin kein Elektroniker), die Einsteck-Richtung der Capacitors (anders als bei den LEDs / Dioden) ist doch egal, oder?
Quote
Da hilt u.U. der "Hack" die Dioden auszulöten / zu überbrücken. Damit kann ich LambdaSpeak, XMem und DDI3 ohne Probleme betreiben am MotherX4, ohne externe Stromversorgung.
Hättest Du eventuell ein Foto davon, wie Du das gemacht hast?
Quote from: HAL6128 on 21. July 2018, 17:43:33
Hi,
die SSA1 Disc und "Roland in Space" funktionieren. Roland in Space nur bis Start Bildschirm inklusive Sprachausgabe, da ich das Programm auf Laufwerk B: (3,5 Zoll) habe, danach sucht das Programm auf Laufwerk A und hängt sich auf. Ich denke, dass geht soweit in Ordnung.
Beim Echo-Programm kommt eine Ansage und es werden "O" ausgegeben.
Ich habe mal das Board fotografiert, die Capacitors beschriftet und angehängt. Bei den Widerständen bin ich mir sicher, diese richtig (nach Deiner Beschriftung auf den Beuteln) eingesetzt und verlötet zu haben.
Blöde Frage (bin kein Elektroniker), die Einsteck-Richtung der Capacitors (anders als bei den LEDs / Dioden) ist doch egal, oder?
Danke fürs Bild! Ja sieht alles gut aus. Lediglich der dicke Tropfen-Kondensator muss "+" auf der linken Seite haben (über dem GAL).
Ich meinte das Test-Programm aus dem Thread - das druckt "!" wenn a<>b. Ich kann mich gerade nicht an das Test-Program auf der DSK erinnern. Das druckt dann "0"? I.d.R. sollte gar nichts ausgegeben werden denke ich (zumindest nicht mit dem Test-Programm aus dem Thread hier - if a<> then print "!" (sonst gar nichts)).
Sollte also a= output <> b = input sein, funktioniert die Kommunikation / Handshake nicht, und das kann natürlich alles mögliche erklären. Evtl. ist das GAL defekt... obwohl ich das eigentlich gestestet hatte. Evtl. ist das 244, oder das GAL defekt (Kommandos senden scheint ja zu gehen, also ist das Flipflop 374 ok, und das GAL funktioniert zumindest "ein bisschen"???)
Also bitte entweder einsenden, oder ich kann Dir ein neues GAL und neues 244 und 374 schicken, natürlich umsonst.
Quote from: HAL6128 on 21. July 2018, 17:46:01
Quote
Da hilt u.U. der "Hack" die Dioden auszulöten / zu überbrücken. Damit kann ich LambdaSpeak, XMem und DDI3 ohne Probleme betreiben am MotherX4, ohne externe Stromversorgung.
Hättest Du eventuell ein Foto davon, wie Du das gemacht hast?
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/mother-x4-and-ddi3-mods/
ABER ACHTUNG - dann geht die externe PSU Buchse nicht mehr!! S. TOTOS Kommentar..
:00008351:
Quote from: HAL6128 on 21. July 2018, 17:43:33
Hi,
die SSA1 Disc und "Roland in Space" funktionieren. Roland in Space nur bis Start Bildschirm inklusive Sprachausgabe, da ich das Programm auf Laufwerk B: (3,5 Zoll) habe, danach sucht das Programm auf Laufwerk A und hängt sich auf. Ich denke, dass geht soweit in Ordnung.
Beim Echo-Programm kommt eine Ansage und es werden "O" ausgegeben
OK, für SSA1 funktioniert nicht nur "Hello" am Anfang, sondern auch |say ?
Wie sieht es mit Eliza und elisa-dk (für DK Tronics / Deutsch) aus?
In jedem Fall schon mal sorry für die Probleme... aber wir kriegen das schon hin :)
Quote from: LambdaMikel on 21. July 2018, 17:51:48
Danke fürs Bild! Ja sieht alles gut aus. Lediglich der dicke Tropfen-Kondensator muss "+" auf der linken Seite haben (über dem GAL).
Ich meinte das Test-Programm aus dem Thread - das druckt "!" wenn a<>b. Ich kann mich gerade nicht an das Test-Program auf der DSK erinnern. Das druckt dann "0"? I.d.R. sollte gar nichts ausgegeben werden denke ich (zumindest nicht mit dem Test-Programm aus dem Thread hier - if a<> then print "!" (sonst gar nichts)).
Sollte also a= output <> b = input sein, funktioniert die Kommunikation / Handshake nicht, und das kann natürlich alles mögliche erklären. Evtl. ist das GAL defekt... obwohl ich das eigentlich gestestet hatte. Evtl. ist das 244, oder das GAL defekt (Kommandos senden scheint ja zu gehen, also ist das Flipflop 374 ok, und das GAL funktioniert zumindest "ein bisschen"???)
Also bitte entweder einsenden, oder ich kann Dir ein neues GAL und neues 244 und 374 schicken, natürlich umsonst.
Ich habe eben das Programm aus dem Thread eingetippt und es werden tatsächlich "!" ausgeben, aber auch zeitgleich erfolgt eine Sprachausgabe bis sie immer leiser wird und danach stirbt. Die Ausgabe der "!" bleibt.
Der Tropfen-Kondensator hat sein "+" auf der linke Seite wie beschrieben.
Quote from: LambdaMikel on 21. July 2018, 17:53:41
In jedem Fall schon mal sorry für die Probleme... aber wir kriegen das schon hin :)
...überhaupt kein Thema :)
|quote]
Ich habe eben das Programm aus dem Thread eingetippt und es werden tatsächlich "!" ausgeben, aber auch zeitgleich erfolgt eine Sprachausgabe bis sie immer leiser wird und danach stirbt. Die Ausgabe der "!" bleibt.
[/quote]
Wow, dann ist wirklich was stark im Argen!!
Bitte einmal statt print "!" sowas wie print a;: print b
machen... ist es nur ein Bit, dass nicht stimmt? Evtl. ist dann eine einzelne Datenbus-Leitung nicht richtig verlötet oder der Pin von einem Chip nicht richtig eingedrückt, etc. Bitte auch alle Lötpunkte, speziell am IDC Connector, nach Lötbrücken nachschauen mit der Lupe.
Ah, bitte sicher stellen, dass der Echo Test Mode vorher eingeschaltet wird! Also, bevor das Programm läuft, mittles
out &fbee,&c5:
&C5: an echo test program to check IO port communication. In this mode, every byte sent to port &FBEE and &FAEE is immediately "echoed" back onto the databus, such that it can be read and compared with the byte that was sent. The sent and returned byte should be identical, of course. This mode can only be exited by pushing the LambdaSpeak reset button, or by power cycling of course.
Also eher sowas wie
5 out &fbee, &c5
8 input "hit enter after 5 seconds"
10 a = round(rnd(1)* 255)
20 out &fbee,a
30 b = inp(&fbee)
40 if a<>b then print a;:print b
50 goto 10
Das scheint nun zu laufen. Keine "!" mehr nachdem der "Echo-Test-Modus" eingeschaltet wurde.
Ich werde trotzdem nochmals das Board genauer auf Lötfehler von mir untersuchen. Eventuell hab ich doch einen Fehler gemacht?
OK, das ist ein gutes Zeichen. Das zeigt eigentlich, dass alles soweit funktioniert. Ich würde natürlich noch Amdrum / PCM test ausprobieren.
M4 is ein bißchen ein Rätsel, ich werde da auch noch weiter nachforschen. Die Antwort von duke im anderen CPC-Forum ist nicht befriedigend (ich denke, er sollte ein Firmware-Update rausbringen...)
Bitte noch mal bzgl. reset antworten - geht out &fbee,&ff immer? Oder hängt der CPC?
@TFM - im http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip ZIP ist einmal LS.ROM, und dann in der DSK selbst ist auch noch mal LS.ROM. Beide unterscheiden sich anscheinend? Welches ist denn nun das aktuelle?
Bitte auch noch mal - ohne ROMS und M4 -
Eliza.bas und Eilisa-dk.bas von
https://github.com/lambdamikel/LambdaSpeak/blob/master/cpc/lambda/LS195.dsk
testen. Geht alles?
Quote from: LambdaMikel on 22. July 2018, 01:38:43
@TFM - im http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip ZIP ist einmal LS.ROM, und dann in der DSK selbst ist auch noch mal LS.ROM. Beide unterscheiden sich anscheinend? Welches ist denn nun das aktuelle?
Uups, das auf der Disk ist neuer, habs angepasst und hochgeladen, jetzt sind beide gleich neu. Sorry.
Ah, danke Stefan!
Strange, jetzt geht es mit dem M4 und dem ROM.
Vorgestern hatte ich das Problem, dass er nach
|lambda
und
|ls, "hello 123"
nach dem Sprechen nicht aus der RSX-Routine zurückkam.
Heute funktioniert alles perfekt.
Würde mich interessieren, ob es für HAL6128 nun auch mit dem M4 klapp?
Hier ist ein Foto von meiner 6128 Konfiguratino mit MotherX4, allerdings mit Dioden-Hack.
Hi, ich habe das MotherX4 mit Dioden-Hack durchgeführt und die Stromversorgung läuft tatsächlich viel stabiler. Jedoch habe ich immer noch Probleme beim Testen des Lambda Boards. Vielleicht auch ein Anwendungsfehler (meist liegt es ja am User), deswegen muss ich nochmals dumm fragen. Ich habe zwar die Seite auf dem GitHub durchgelesen, bin mir aber nicht sicher.
Demo01 funktioniert leider immer noch nicht (WG. Dem Out Befehl zum Reset). Es scheint, das damit das Board komplett deaktiviert wird und lässt sich nur durch ein Aus-Einschalten des CPC erst wieder aktivieren. Eliza-DK funktioniert , Eliza nicht. Nach aktivieren des Decatronic Modus nimmt das Board keine Befehle mehr an. Die Sample DSK funktioniert auch nicht.
Noch eine (dumme?) Frage zu den Buchsen J3 J4. Wann kommt die zum Einsatz?
J3 ist der Ausgang vom Audio-Mixer.
J3 mixt den PCM / Amdrum / Sample-Output vom ATMega 644 mit dem Sprach-Signal vom click! speech board.
Der Audio-Ausgang vom click! speech board geht auf J4 - das ist der Eingang vom Audio-Mixer.
Damit also Sprache UND PCM am J3 ankommt, ist diese Verkabelung (s. auch letztes Bild oben mit M4) erforderlich.
In LambdaSpeak 1.99 habe ich J3 sinnvollerweise in "OUT" und J4 in "IN" umbenannt.
Leider hat das click! Board keinen "pin" für Audio-Ausgang, sodass diese Kabel-Lösung erforderlich ist.
Also, click!-Ausgang an J4, und Verstärker / Lautsprecher an J3 = Mixer-Ausgang.
Damit sollte dann |pcmtest funktionieren, und |amdrum
Dass Du kein PCM hörst liegt also wahrscheinlich daran, dass Du J3 nicht verwendest bisher.
@TFM, Duke sagt, dass |ls ein M4-RSX ist! Sollten wir es umbennen, in |speak (|say is vom DKtronics Sprach-ROM belegt),
oder einfach entfernen? Du hast ja schon |lambdaspeak (|ls ist nur eine Kurzform davon, wenn ich mich recht erinnere).
@HAL - falls es dann immer noch nicht geht, bitte einsenden an mich. Ich teste & repariere
es dann bei mir, und schicke ein funktionierendes zurück.
@HAL6128 - ich denke, es ist das Beste, wenn ich Dir ein von mir getestetes und funktionierendes, zusammengebautes LambdaSpeak 1.95 schicken.
@HAL6128 - kannst Du bitte noch einmal folgenden Test machen, und mir mitteilen, was passiert:
1. power cycle CPC, OHNE m4 und OHNE LS.ROM
2. warten bis "LambdaSpeak initialized" gesprochen wurde
3. out &fbee,&ff
Was passiert?
Wenn das klappt, einfach ein paar mal out &fbee, &ff hintereinander probieren... haengt LambdaSpeak irgendwann, or gibt es immer einen sauberen Reset?
Die Stromversorgung koennte tatsaechlich ein Problem sein, dass einen sauberen Reset verhindert.
Habe den Test wie beschrieben durchgeführt.
Im Prinzip passiert immer dasselbe: Sobald der OUT-Befehl gegeben wurde leuchten beide LEDs kurz auf (flackern) und danach erlöschen sie und das Board ist nicht mehr ansprechbar. Auch bei mehreren OUTs hintereinander nicht mehr.
Das passiert auch, selbst wenn das Board direkt am Expansion-Port (ohne MotherX4) angeschlossen wird.
Danke für den Hinweis mit den Audio-Ein-/Ausgängen.
Beim |PCMTEST zum Beispiel kommt zuerst die Stimme "PCM Test" danach ein Kratzen und das Board (LEDs) ist aus.
... und dabei ist der Lautsprecher an J3 fuer PCM Test, richtig?
Hmm, das klingt nach einem Quartz / MCU Problem. OK, I werde heute Abend ein neues zusammenloeten und testen.
Ist dann morgen in der Post. Sollte also naechste Woche ankommen. Neue Addresse habe ich. Das click! speech board
ist jedoch ok, sodass ich dass nicht mitsenden werde.
Zuruecksenden waere interessant, fuer Fehler-Diagnose, ist aber nicht dringend.
Ich habe den Fehler gefunden
Leider hatte ich hier mit einer älteren Version der LS 1.95 Firmware gearbeitet und getestet, dann aber eine "verbesserte" LS 1.95 an die Kunden rausgeschickt. Diese Verbesserung hat den DKtronics-Mode lahm gelegt, und ich hab's gar nicht mehr getestet... das war mein Verhängnis. Meine ältere Version der Firmware lief ja!
Rennert ist nicht betroffen, da er LS 1.99 hat.
TFM kriegt einen neuen ATMega 644.
HAL6128 sicherheitshalber das ganze Board neu.
Sorry für die Unanehmlichkeiten. Ein saublöder Fehler - eine Konstante vergessen zu editieren (ein ATMega Input-PIN stimmte nicht).
Quote from: LambdaMikel on 23. July 2018, 16:34:36
@TFM, Duke sagt, dass |ls ein M4-RSX ist! Sollten wir es umbenennen, in |speak (|say is vom DKtronics Sprach-ROM belegt),
oder einfach entfernen? Du hast ja schon |lambdaspeak (|ls ist nur eine Kurzform davon, wenn ich mich recht erinnere).
Genau es ist nur die Kurzform... Wie wäre es mit Umbenennung auf !SP ?
Gibt es !SP als RSX schon irgendwo?Quote from: LambdaMikel on 24. July 2018, 09:22:21
TFM kriegt einen neuen ATMega 644.
Danke, ich werde dann auch noch mal alles testen. :smiley027:
Quote from: LambdaMikel on 24. July 2018, 09:22:21
TFM kriegt einen neuen ATMega 644.
HAL6128 sicherheitshalber das ganze Board neu.
Sorry für die Unanehmlichkeiten. Ein saublöder Fehler - eine Konstante vergessen zu editieren (ein ATMega Input-PIN stimmte nicht).
Ist jetzt in der Post, sollte naechste Woche bei Euch einschlagen.
Super, vielen Dank!
@LambdaSpeak Nutzer :-)
Neues ROM hochgeladen, der RSX !LS heißt jetzt !SP (für Speak). Bitte Testen, bei Problemen Fehlerbericht an mich.
bei Github?
Nee, auf meiner Homepage. Direkter Link:
http://futureos.cpcwiki.de/files/LambdaSpeak_RSX_by_TFM.zip
du müsstest im neuen Rom noch die Hilfe in SP ändern, also mit lsp oder llambdaspeak wird ja ne kleine Hilfe angezeigt.
Wie lege ich nen Text in der Variable text$ an?
wofür steht das @ in dem lsp Befehl? weil bekomme nur ne Ausgabe mit lsp,text$
Quote from: Rennert on 31. July 2018, 22:21:36
wofür steht das @ in dem lsp Befehl? weil bekomme nur ne Ausgabe mit lsp,text$
@ brauchst Du nur fuer CPC 464 / BASIC 1.0.
Addresse / Startpointer vom String.
Hallo,
Das neue Lambda Board ist angekommen und es funktioniert prima. Alle Demos und Beispiele der Discs laufen. Der OUT Befehl für den Reset ist kein Problem mehr. Klasse, freut mich riesig!!
Nur das LS-Rom funktioniert nicht bzw. zeigt einen Checksum Error beim Booten, wird nicht initialisiert. Wenn ich die RSX von der Disk starte ist es kein Problem mehr.
@lambdamikel: ich sende dir dann das "alte" Board zurück.
Quote from: Rennert on 31. July 2018, 22:10:04
du müsstest im neuen Rom noch die Hilfe in SP ändern, also mit lsp oder llambdaspeak wird ja ne kleine Hilfe angezeigt.
Wie lege ich nen Text in der Variable text$ an?
Danke für den Hinweis erledigt und hochgeladen. :)
Variable? So:
text$="LambdaSpeak is great! Powered by FutureSoft"
oder was sinnvolles ;-)
Quote from: HAL6128 on 01. August 2018, 10:05:35
Nur das LS-Rom funktioniert nicht bzw. zeigt einen Checksum Error beim Booten, wird nicht initialisiert. Wenn ich die RSX von der Disk starte ist es kein Problem mehr.
Vermutlich eine uralte Version, lade die neue vom 2018.07.30 herunter.
Quote from: HAL6128 on 01. August 2018, 10:05:35
Hallo,
Das neue Lambda Board ist angekommen und es funktioniert prima. Alle Demos und Beispiele der Discs laufen. Der OUT Befehl für den Reset ist kein Problem mehr. Klasse, freut mich riesig!!
Nur das LS-Rom funktioniert nicht bzw. zeigt einen Checksum Error beim Booten, wird nicht initialisiert. Wenn ich die RSX von der Disk starte ist es kein Problem mehr.
@lambdamikel: ich sende dir dann das "alte" Board zurück.
Hallo HAL6128, das freut mich, da fällt mir ein Stein vom Herzen!! :jubelaola:
OK, gerne, shipping aus D per DHL sollten ja nur ein paar EUR sein wenn ich mich recht erinnere, oder?
Ich zahle gerne das Porto. Addresse etc. hast Du?
Quote from: TFM on 01. August 2018, 13:43:14
Variable? So:
text$="LambdaSpeak is great! Powered by FutureSoft"
oder was sinnvolles ;-)
gib mir mal ein Beispiel, ich komme mit dem Befehl nicht weiter.
Bei lsp,text$ kommt manchmal nur ein kurzer Ton oder was langes englisches Männer und Frauenstimme. Habe auch mal mit text$="hallo kc compact" was festgelegt und dann mit lsp,text$ kommt auch nix brauchbares.
LambdaSpeak ist by default im SSA1 Modus.
Vorher |lambda eingeschaltet, dann |sp ?
Sonst geht's nicht, wegen SSA1. |sp ist nur
fuer |lambda Modus, im SSA1 or DKtronics
Modus kommt sicherlich nur Schrott raus...
Also, am Besten |reset, |lambda, und dann |sp.
Danke das war's :flehan:
Oder am Anfang einfach einmal !LSINIT eintippen und los geht's :-)
Steht auch in der Anleitung, wer wer hat Lust bei 36 Grad irgendetwas zu lesen :zunge0020: :)
Quote from: TFM on 02. August 2018, 14:35:10
Oder am Anfang einfach einmal !LSINIT eintippen und los geht's :-)
Steht auch in der Anleitung, wer wer hat Lust bei 36 Grad irgendetwas zu lesen :zunge0020: :)
Danach geht |sp dann allerdings nicht, weil |lsinit ja immer in den SSA-1 Modus schaltet.
|lambda ist also erforderlich.
Echt? Ich guck mal nach... Nein der !LSINIT schaltet den Epson Modus ein. Wäre ja sonnst auch nix.
Gute Neuigkeiten: Habe den LS 1.95 erhalten und auch den Austausch Chip. Nur hier schon mal die erste Frage: Nachdem ich das Modus vom 1.5er auf den 1.95er umgesteckt habe stehen jetzt drei 3.5" Anschlüsse zur Verfügung. Wie soll ich die verschalten?
Und gleich Frage 2: Was soll ich mit dem Board zu erst testen? Wo drückt der Schuh?
:'( :'( :'( - das sind Smilies die schwitzen wie die Sxx. ;) :) :)
Ich habe an das Speech Modul Boxen angeschlossen und Audio Out vom KCC durch das Lambda Modul durchgeschliffen für Amdrum und original DKTronics Mode Ausgabe an TV
Quote from: TFM on 02. August 2018, 19:00:12
Echt? Ich guck mal nach... Nein der !LSINIT schaltet den Epson Modus ein. Wäre ja sonnst auch nix.
Echt? Neuerdings? Wird wohl wieder Zeit fuer ein ROM Update bei mir :smiley027:
Vielleicht auch ein Unterschied zu alter Firmware in Deinem LS 1.5... ich glaube, ich hatte nach einem Reset irgendwann auch einmal Epson als Default-Mode, nun ist es aber SSA-1. :bgdev:
Wie auch immer, jetzt ist es hier ja klar das |sp nur mit Epson = |lambda geht, nicht mit SSA-1 und DKtronics Modus.
Quote from: TFM on 02. August 2018, 19:00:12
Gute Neuigkeiten: Habe den LS 1.95 erhalten und auch den Austausch Chip. Nur hier schon mal die erste Frage: Nachdem ich das Modus vom 1.5er auf den 1.95er umgesteckt habe stehen jetzt drei 3.5" Anschlüsse zur Verfügung. Wie soll ich die verschalten?
Und gleich Frage 2: Was soll ich mit dem Board zu erst testen? Wo drückt der Schuh?
OK, also Buchse 1 ist fuer Satellitenfernsehen, Buchse 2 ist Hotline in den Kremel (Putin nimmt ab), und Buchse 3 fuer ET zum nach Hause telefonieren :zunge0020: :smiley027: :kaffee:
Nee, Spass beseite - CLick! Board Ausgang bitte mit kleinem Kabel an die *rechte* Buchse routen. Das ist der Mixer-Eingang. Click! Board speech wird dann mit PCM gemixt, und gemischtest Signal wird auf der *linken* LambdaSpeak-Buchse ausgegeben -> Verstaerker.
Druecken tut's glaube ich gar nimmer mehr, irgendwann gab es bei mir komische M4-Effekte mit dem ROM. Dass |sp nicht terminierte. Inzwischen konnte ich das nicht mehr reproduzieren.
PCM kannst Du ja bitte auch einmal ausprobieren, ob die Soundqualitaet vom |play evtl. noch verbessert werden kann.
Ich verwende sowas hier
https://www.amazon.com/L16-Stereo-Audio-Cable-Connectors/dp/B00KL7C10O/ref=pd_bxgy_23_img_2?_encoding=UTF8&pd_rd_i=B00KL7C10O&pd_rd_r=8JXN44EYG9YXSXWNZKZ8&pd_rd_w=F7Dwp&pd_rd_wg=iOl0U&psc=1&refRID=8JXN44EYG9YXSXWNZKZ8
(https://www.amazon.com/L16-Stereo-Audio-Cable-Connectors/dp/B00KL7C10O/ref=pd_bxgy_23_img_2?_encoding=UTF8&pd_rd_i=B00KL7C10O&pd_rd_r=8JXN44EYG9YXSXWNZKZ8&pd_rd_w=F7Dwp&pd_rd_wg=iOl0U&psc=1&refRID=8JXN44EYG9YXSXWNZKZ8)
Quote from: LambdaMikel on 02. August 2018, 19:40:52
Vielleicht auch ein Unterschied zu alter Firmware in Deinem LS 1.5... ich glaube, ich hatte nach einem Reset irgendwann auch einmal Epson als Default-Mode, nun ist es aber SSA-1. :bgdev:
Aha, das ist schon mal ein guter Befund. Mit dem 1.5er war es immer schon auf EPSON/Lambda geschalten durch den RSX. Werde das alles mal durchtesten.
Quote from: LambdaMikel on 02. August 2018, 19:40:52
OK, also Buchse 1 ist fuer Satellitenfernsehen, Buchse 2 ist Hotline in den Kremel (Putin nimmt ab),
Ja, wie genial! Hab's gerade ausprobiert, der spricht ja ein hervorragendes Deutsch. :smiley027: Er meinte dass man mit Funktelefonen vorsichtig sein sollte. :gruebel:
Quote from: LambdaMikel on 02. August 2018, 19:40:52
CLick! Board Ausgang bitte mit kleinem Kabel an die *rechte* Buchse routen. Das ist der Mixer-Eingang. Click! Board speech wird dann mit PCM gemixt, und gemischtest Signal wird auf der *linken* LambdaSpeak-Buchse ausgegeben -> Verstaerker.
Also ich verbinde den Click-Board mit der Buchse, die auf der Platine ganz außen ist, richtig?
Wie aber mache ich das Kabel? Plus an Minus, Plus auf Plus, oder identische Signale verbinden?
EDIT1: Danke für den Kabel-Link, ich bestelle mir das gleich :-)
EDIT2: Kann es mir doch nicht kaufen, doofes Amazon will eine Kreditkarte, und ich hab keine. Also schau ich dann mal bei Ebay oder so.
Quote from: LambdaMikel on 02. August 2018, 19:40:52
PCM kannst Du ja bitte auch einmal ausprobieren, ob die Soundqualitaet vom |play evtl. noch verbessert werden kann.
Mach ich :-)
Quote from: TFM on 03. August 2018, 14:22:42
Also ich verbinde den Click-Board mit der Buchse, die auf der Platine ganz außen ist, richtig?
Genau :birthday:
Musst Du aber nicht. PCM / Amdrum kommt immer links raus, gemischt mit was rechts / ganz außen reinkommt.
Speech kommt immer aus dem Click! board. Die Buchsen sind zwar Stereo, aber Mono verschaltet. Normales
Stereo-Kabel tuts also, und kommt dann auf beiden Kanälen raus (linke Buchse).
Falls Du lieber nur linken Kanal haben möchtest für Audio, bitte das Jumper-Kabel auf der PCB-Rückseite vom
LambdaSpeak durchtrennen.
Quote from: TFM on 03. August 2018, 14:22:42
EDIT2: Kann es mir doch nicht kaufen, doofes Amazon will eine Kreditkarte, und ich hab keine. Also schau ich dann mal bei Ebay oder so.
https://www.ebay.de/itm/Audio-Video-Kabel-2-5m-lang-beidseitig-3-5mm-Klinkenstecker-Stereo/232018777982?epid=1504234403&hash=item360565977e:g:wngAAOSwSB1aq2rO (https://www.ebay.de/itm/Audio-Video-Kabel-2-5m-lang-beidseitig-3-5mm-Klinkenstecker-Stereo/232018777982?epid=1504234403&hash=item360565977e:g:wngAAOSwSB1aq2rO)
Das scheint schön kurz zu sein (2.5 cm)
Wie gesagt, sorry für die blöde Konstruktion, das Click! board hat leider kein Audio-Out auf den Header-Pins... das wäre ja zu einfach gewesen. :bgdev:
EDIT 1 - upps, lesen müsste man könnten... das hat 2.5 meter.
Also lieber sowas
https://www.ebay.de/itm/Audiokabel-3-5mm-Klinke-0-2m-20cm-kurz-AUX-Klinkenkabel-Stereo-Qualitatskabel/261747389781?epid=1338015929&hash=item3cf15c3555:g:hEUAAOSw0e9UxLg4
Obwohl 20 cm schon zu lang ist eigentlich.
Perfekt:
https://www.ebay.de/itm/mumbi-Audio-Klinken-Kabel-3-5mm-Klinke-Stecker-Klinkenkabel-Audiokabel-10cm/202212859337?hash=item2f14d35dc9:g:ejwAAOSwgKBapqxz (https://www.ebay.de/itm/mumbi-Audio-Klinken-Kabel-3-5mm-Klinke-Stecker-Klinkenkabel-Audiokabel-10cm/202212859337?hash=item2f14d35dc9:g:ejwAAOSwgKBapqxz)
LS 1.95:
- !PCMTEST geht, wiederholt Meldung immer wieder, auch reset am LS stoppt es nicht. Gehört das so? (ich nehme es an, frage aber trozdem mal nach).
- Nach einem Reset der Karte kann es passieren, dass !LSINIT nicht zurückkehrt. Was hilft? Ein Reset des LS, dann der LS scheint den CPC anzuhalten, der Befehl selber beinhaltet keine Warte-Routinen.
Die Tests gehen weiter :-) Natürlich erwähne ich jetzt nicht die 99 Dinge die perfekt laufen, sonnst geht mir der Platz aus. ;D
Quote from: TFM on 07. August 2018, 19:51:45
LS 1.95:
- !PCMTEST geht, wiederholt Meldung immer wieder, auch reset am LS stoppt es nicht. Gehört das so? (ich nehme es an, frage aber trozdem mal nach).
- Nach einem Reset der Karte kann es passieren, dass !LSINIT nicht zurückkehrt. Was hilft? Ein Reset des LS, dann der LS scheint den CPC anzuhalten, der Befehl selber beinhaltet keine Warte-Routinen.
Die Tests gehen weiter :-) Natürlich erwähne ich jetzt nicht die 99 Dinge die perfekt laufen, sonnst geht mir der Platz aus. ;D
Jo, PCMTEST laeuft immer wieder in der Loop. Ich dachte eigentlich, dass Reset-Taste dort funktioniert, vielleicht erinnere ich mich falsch.
In jedem Fall ist die Reset-Taste blockiert im |AMDRUM Mode, da ich die ATmega Interrupts (fuer Reset-Taste und alles andere!) zu
Gunsten der maximalen Sample-Qualitaete gesperrt habe.
RESET ist in der Tat manchmal etwas frickelig, zur Not muss man halt den CPC power cyclen ;)
Das ist ja auch kein Problem, da man nur sehr selten in die 'Verlegenheit' kommt, dass Reset überhaupt gebraucht wird bzw. benutzt werden müsste. :)
So, die LambdaSpeak Software habe ich jetzt auch noch mal als Update ins Netz gestellt, die RSX Erweiterungen sind jetzt auf dem Stand vom ROM und alles habe ich mal so getestet, das einzige was mit aufgefallen ist, daß nach !SPANISH oft weiterhin Englisch gesprochen wird. Ist aber nicht so schlimm. Viel Spass mit dem Update (nix neues für die Nutzer des LS-ROMs - leider). :)
Ohne Dein ROM + RSX :flehan: waere LS nur halb so gut!! :jubelaola:
Quote from: TFM on 15. August 2018, 17:53:20
daß nach !SPANISH oft weiterhin Englisch gesprochen wird. Ist aber nicht so schlimm.
Genau, noch hat kein Spanier oder spanischsprechender User eines gekauft - Features gibt es nur gegen Bares :00008351: ;D
schmeiss Spanisch raus und mach Deutsch rein :P
Quote from: LambdaMikel on 15. August 2018, 19:28:26
Ohne Dein ROM + RSX :flehan: waere LS nur halb so gut!! :jubelaola:
Ach iwo, der LS hat ja schon alles per Hardware drin, die meisten RSXe haben nur 4 Bytes Code. Die Genialität liegt ganz klar in der Hardware. :flehan: Besser geht's nicht. :smiley027:
Quote from: Rennert on 15. August 2018, 19:50:47
schmeiss Spanisch raus und mach Deutsch rein :P
;D Damit habe ich schon angefangen, für den dk'tronics Mode würde das sogar gehen, aber der hört sich gelinde gesagt eben nicht an die die Epson bzw. DecTalk Modes des LS.
Für den nativen Epson Mode habe ich schon versucht eine Tabelle zu erstellen, um Deutsches auch Deutsch klingen zu lassen, aber das ist nicht so einfach. Wenn man z.B. "ei" hören will muss man "iie" ausgeben, aber eben nicht immer. Es kommt darauf an welche Buchstaben folgen. Das wird schnell kompliziert und ich glaube nicht, dass ich das in kurzer Zeit schaffe, aber ich arbeite immer mal wieder dran. :)
Ja, das ist gar nicht so einfach :kaffee:
https://ieeexplore.ieee.org/document/1169464/
... wie I di kenn schwätzalt do Lambda am enda Schwäbisch :00008351:
Naa, mir redn Boarisch, de Sprach vom Herrgott. Danke für den Link, den schau ich mir gleich mal an. :smiley027:
p.s.: Habs mal als PDF angehängt ;-)
p.p.s: Leider hat mir der keine Tabelle angehängt, aber das wäre ja zu einfach gewesen. Jedenfalls werde ich mir mal den dectalk Modus genauer ansehen :)
Quote from: TFM on 19. August 2018, 16:42:41
Naa, mir redn Boarisch, de Sprach vom Herrgott.
Gut, als Norddeutscher sind meine Erwartungen diesbzgl. recht hoch, s auch hier: :D
:zunge0020:
Es gibt ja auch Sprech-Kurse, die muss ich jetzt nur noch auf den LS rüberbringen, aber der hat ja mehrere Stimmen. ;) :)
... bald ist es wieder soweit - LambdaSpeak 2.5 kommt. Dann doch mit CPLD im PLLC-84 Package.
Die GALs und 74LSxxx Glue Logic Chips sind dann Geschichte.
SMD wird leider nichts, aber wenigstens CPLD im PLLC-84 Socket.
was kann das dann mehr?
Null komma gar nix.
Ist nur engineering ego trip.
... und weniger Chips. Mann strebt hald nach Perfektion. :smiley027:
... und wieder zu viel Zeit gehabt am WE:
[CPCEmulator]https://youtu.be/09xEWBEMHK0[/CPCEmulator]
LamdaSpeak 2.5 wird es nicht geben. Aber LambdaSpeak 3. Dieser wird 2 10-Segment-Bar-LED-Anzeigen für Input und Output haben. Und weitere 5 LEDs für Status-Anzeige (5-Bar-LED-Segment). Alles in allem also 26 LEDs (wg. +1 für Power). Also, schon mal sparen, Weihnachten kommt ja bald ;) ;D
[CPCEmulator]https://youtu.be/VLRJbIvIBPY[/CPCEmulator]
[CPCEmulator]https://youtu.be/n9J54v1USwo[/CPCEmulator]
Die 8 Input und 8 Output Ports werde ich in LS 3.0 einfach als Pin-Header ausführen. Die Ausgangs-Pins können dann z.B. Relais schalten, wie dieses hier:
https://www.amazon.com/ELEGOO-Channel-Optocoupler-Arduino-Raspberry/dp/B01HCFJC0Y/ref=sr_1_sc_1?ie=UTF8&qid=1537767564&sr=8-1-spell&keywords=arduinmo+8+relais
Die Eingänge sind einfach digitale Eingänge. Einfach per PullUp-Resistor und Taster bedienen.
Dazu kommt dann noch ein neuer Modus in der LambdaSpeak-Firmware: &E0. Hat nix mit Sprachausgabe zu tun, stattdessen wird in diesem Modus einfach jedes Byte das an &FBEE geschickt wird auf den digital Ausgang vom LS 3.0 (die Pin-Header) ausgegeben, womit man dann Relais o.ä. schalten kann. Ebenso kann man den momentanen Input von &FBEE lesen, also den Status der Eingänge (Input Pin-Header), zB. angeschlossene Taster oder Schalter. Die CPC-Software kann dann dementsprechend schalten.
Als ich noch einen Hardware-Entwicklungspartner hatte (der sollte die SMD-Version machen, hatte aber leider keine Zeit), hatte ich die Idee auch schon mal vorgeschlagen. Allerdings hatter der Parner Bendenken, dass dann die User das Gerät beschädigen könnten. Klar, ist natürlich ein Rikiko (auf eigene Gefahr), allerdings sind die GPIOs beim Raspberry PI und auch beim Arduino auch nicht anders implementiert. Und ich habe in all den Jahren nie einen meiner Arduinos oder RPIs kaputt gekriegt.. Insofern bin ich geneigt, diese Warnung enifach in den Wind zu schlagen.
Ich denke, dass die Input/Output LED-Segment-Bars ausschaltbar sein werden, dann kann man mehr Strom ziehen. Für ein Relais sollte es auf jeden Fall reichen. Ich hätte schon Ideen, was ich mit 8 GPIOs am CPC anstellen könnte - Home Automation (Zeit-Schaltuhr, ...) etc .
Was denkt ihr so? Macht das Sinn?
Hab's mal mit dem 4er Modul zusammengesteckt, für Proof of Concept. 8 Relays sind natürlich noch besser.
Konrad Zuse lässt grüßen:
[CPCEmulator]https://youtu.be/FM8kbuwGmSI[/CPCEmulator]
Du hast zuviel Zeit :irre:
Super Idee! Nun frage ich mich jetzt mal so (Sorry... offtopic!): Kann ich die selben Relais auch am Drucker-Port ansteuern? Und am Joystick-Port einlesen?
Die Idee finde ich jedenfalls gut, und mit Optokopplern sollte auch nix schief gehen. :smiley027:
Partner lassen sich auch schnell neue und zuverlässige finden ;-) Es gibt ja schon einige Leute die CPC-Hardware herstellen, wer weiß, da wären womöglich Kooperationen möglich. :smiley027:
EDIT: Heute ist einer dieser Tage, an dem ich das 'Likes' System hier echt vermisse!
Quote from: TFM on 25. September 2018, 14:42:02
Super Idee! Nun frage ich mich jetzt mal so (Sorry... offtopic!): Kann ich die selben Relais auch am Drucker-Port ansteuern? Und am Joystick-Port einlesen?
Die Idee finde ich jedenfalls gut, und mit Optokopplern sollte auch nix schief gehen. :smiley027:
Partner lassen sich auch schnell neue und zuverlässige finden ;-) Es gibt ja schon einige Leute die CPC-Hardware herstellen, wer weiß, da wären womöglich Kooperationen möglich. :smiley027:
EDIT: Heute ist einer dieser Tage, an dem ich das 'Likes' System hier echt vermisse!
Dankeschön, ja Druckerport ginge natürlich genau so... allerdings habe ich dafür kein Setup. Und dann wären es ja nur 7 Bit :zunge0020: Wenn es am LambdaSpeak läuft, gibt es zudem prinzipiell die Möglichkeit, dass der MCU auch was ohne CPC-Zutun schaltet (solange LambdaSpeak Strom kriegt, natürlich). Daher dann auch die Eingänge. So könnte die MCU / Atmega 644 z.B. einen Modus fahren in der LS 3.0 Firmware, der die Eingänge scannt, und selbständig Ausgänge toggelt. Das ginge dann also ohne CPC-Zutun. Aber meist will man natürlich, dass der CPC die Steuerlogik implementiert. Ich habe es in erster Linie im LS 3.0 drin, weil es ohnehin möglich ist, und nichts kostet.
Ja, Hardware-Entwicklungspartner brauche ich allerdings erstmal auch keine mehr. Der vorherige Partner hat mich ja in die richtige Richtung geschickt (mit CPLD usw), das war schon sehr "wertvoll" und bin sehr dankbar dafür, auch wenn er am Ende nichts entwickelt hat.
Quote from: TFM on 25. September 2018, 14:42:02
Die Idee finde ich jedenfalls gut, und mit Optokopplern sollte auch nix schief gehen. :smiley027:
Genau. Es ist genial, wie billig das Relais-Modul aus China daherkommt. Es hat echt ne gute Qualität -und 8 Relais für 10 $???! Wow.Schaltet 10 Amps bis 350 VA. Kann ich also direkt meine Lampe, Kaffeemaschine und Toaster ranhängen. Dann kann LS 30 mich morgen wachquatschen, und der Kaffee und Toast ist auch schon fertig ! Doc Brown lässt grüßen:
[CPCEmulator]https://youtu.be/WjX1jU9pQeY[/CPCEmulator]
Naja, der Drucker-Port hat auch 8 Bit (D0-D6 und Strobe), aber im Falle das Lambda-Speak wäre es dann sinnvoll beispielsweise Blöcke von Daten hinzuschicken, die angeben was wie lange eingeschalten werden soll. Ja, man könnte sich sogar eine Programmier-Sprache vorstellen.
Schön wäre es in jedem Fall mal generell darzustellen wie man so Relais am besten anschließen kann. Ich habe da selber schon welche am Drucker-Port, das ist aber eher für 5 Volt zum schalten, und auch eher nach CPCAI nachgebaut.
Wie viel "Platz" wäre denn im LS RAM noch frei? Ich denke da an eine simple Sprache...
Aha! Und was schaltest Du so damit, mit Deinen Relais?
Gute Idee, mit der Sprache... na ein paar 100 Byte waeren schon uebrig. Muss natuerlich als Token dann im "Programm-RAM (Array)" im MCU gespeichert werden, alles andere waere ja :irre:
Das sollte fuer einfach Programme reichen. Dann moechte man allerdings auch ne RTC haben... phhh. Wie krieg ich die denn noch eingebaut.
Zum Thema Bloecke schicken - waere super, insbesondere denke ich ja auch noch daran, einen non-streaming PCM Sample Player einzubauen. Workflow: PCM Bloecke sende, speicher, bei Event abspielen.
Leider habe ich dafuer nicht genuegend RAM frei. Ich werde mir jedoch mal diese SPI / I2C Serial EEPROMs ansehen. Evtl. sind die schnell genug, um PCM mit 115 kbps zu tun.
Hast Du eigentlich schon mal direkt I2C or SPI mit dem CPC gelesen / geschrieben, ist er dafuer schnell genug?
Ich denke ja auch noch an I2C / SPI header, womit man dann z.B. ein RTC-Modul anschliessen koennte, oder Temperatur-Sensor oder oder oder.... Die Kommunikation koennte mit der MCU abgewickelt werden, allerdings muesste man nach wie vor "Treiber" fuer I2C / SPI je nach Modul im CPC implementieren. Ich frage mich, wie eine deratige Schittschnelle aussehen koennte. Ideen? Es muesste sowas sein wie "I2C Block" send, "I2C BLock Receive", etc.
Der CPC schnell genug? Das ist der immer! Egal für was! :smiley027:
SPI? Das hat doch auch dem Mini-Booster? Ich mach die Software, wenn Du da etwas brauchst.
An RAM bräuchte man nicht viel... Aufbau je zwei Bytes: Erstes Byte ist Relais-Byte, das wird ausgegeben. Zweites Byte ist Zeit-Byte. Dabei gilt folgendes 0-127 sind Sekunden, 128-255 sind Minuten. Ist die Zeit abgelaufen, dann werden die nächsten beiden Bytes ausgeführt.
Beispiel:
DB &0F,&03
DB &F0,&87
Also werden zuerst für 3 Sekunden die unteren vier Relais eingeschalten,
dann für 7 Minuten die oberen Vier.
Man kann das noch erweitern, aber auf die Art wäre in 256 Bytes ein ganzer Tag unterzubringen.
Gute Idee TFM... allerdings fällt mir gerade auf, dass für all die Features der LambdaSpeak dann doch etwas überladen werden würde (und PCB zu gross und zu teuer). Der LambdaSpeak 3.0 wird also nur das 12LED-BarGraph für Status-Anzeige, und 8 LEDs für output bekommen, zum Spielen. Und die 8 Output-Header für Relais, damit man dann einfach schalten kann.
Ich spiele aber mit dem Gedanken, eine weitere CPC-Erweiterung zu machen, die dann solche Features zulassen würde - den "LambdaCombinator". Der LambdaCombinator könnte dann also folgendes haben:
- 8 GPIO mit LEDs für IN and OUT (LambdaSpeak wird nur output haben)
- 8LED-Segment displays für Input / Output
- Click! board socket wie LambdaSpeak für SPI und I2C ClickBoards, 3.5 und 5 V selektierbar per Jumper
- Voltage Regulator für 3.5 V
- Interessante Click boards:
https://www.mikroe.com/click?interface*=i2c,spi&input-voltage=33v,33v-or-5v,5v
Einige! RTC, Temperature / Humidity, MP3, Displays (OLED, LED, LED Matrix, ...)
Es wäre genial, wenn der LambdaCombinator es ermöglichen würde, dass die SPI / I2C-Steuerung für beliebige Click! Boards durch die CPC-Software gemacht würde. Ich kann ja keine Treiber für > 20 Click! boards in der ATMega-Firmware halten...
Dazu muss ich noch eine Möglichkeit einbauen, mehr (S)RAM für den ATMega bereitzustellen, sodass z.B. MP3 Files vom CPC hochgeladen werden können, die dann autark (dh, nur durch Senden eines Trigger-Signals vom CPC) von der MCU aus dem Speicher-Modul an das MP3-Module gestreamt werden.
Das wäre eine Menge Arbeit für TFM :) TFM, würde Dich so ein Projekt interessieren? Wir müssten also eine Art "SPI / I2C" und "Memory Block Upload Protokoll" für beliebige Click! boards implementieren (I2C oder SPI).
Ok, es ist mal wieder spät, ich versuche mich kurz zum fassen. Zuerst mal will ich noch anmerken, daß das nur meine persönliche Meinung ist, und ich niemandem auf die Zehen treten will. Aber Foren sind für Missverständnisse nun mal anfällig. Also - alles nur 'persönliche Meinung' :)
0.9 LambdaSpeak 8 Bit I/O: Wenn so eine 8 Bit-Ausgabe-Sprache den LS überfordert (Speichermangel etc.) denn werde ich das hald auf dem CPC programmieren. So einen sinnvollen Unfug hatte ich eh immer schon mal vor. ;)
1. LambdaSpeak: Es gibt nun mehr so viele Versionen, dass ich total den Überblick verliere, wenn nicht schon verloren habe. Da sollte mal eine Art "Ende" her, so dass sich die Anwender dafür entscheiden können, ohne zu denken "oh ich warte nochmal bis die Version 7.2 rauskommt". Nero kann alles, aber alles ist nicht immer Sinnvoll. Es ist schön wenn LS ganz viel kann, aber es muss ja keine Portale in die 9. Dimension öffnen können (obwohl... ;-)))
2. 8-Bit Output: Sehe ich jetzt nicht so richtig als wichtig an, da man ja das selbe bereits mit dem Druckerport des CPC machen kann, der hat genauso 8 Bit Daten auf einmal und GND, damit kann man kleine Relais ansteuern. Habe ich mir mal selber nach den CPCAI gebaut
3. LEDs: Ich liebe LEDs - vor allem wenn sie Blau sind. Aber nach einem Tag wirds nervig, wenn sie keine Funktion haben. Ob die nötig sind sei dahingestellt.
4. Neue Erweiterung: Super Coole Idee! Vor allem wenn man einen Click-Board-Port hat, oder vielleicht gleich Zwei davon (z.B. RTC und Temperatur messen?).
In jedem Fall wäre es da ganz gut erst mal rumzufragen, was denn bei den Leuten "gut ankommt". Am Ende kannst Du ja immer noch machen was Du willst. :zunge0020:
5. Software: Falls man vom CPC her die Firmware updaten kann ist das alles kein Problem. Einige dieser Module sind sehr interessant. Ich würde mit der Software in jedem Fall helfen.
Alles leibe Euch allen, ich bin jetzt Bett-reif und müde. Lasst uns bitte wissen wie ihr alle darüber denkt. :bussi:
Quote from: TFM on 01. October 2018, 00:34:06
Ok, es ist mal wieder spät, ich versuche mich kurz zum fassen. Zuerst mal will ich noch anmerken, daß das nur meine persönliche Meinung ist, und ich niemandem auf die Zehen treten will. Aber Foren sind für Missverständnisse nun mal anfällig. Also - alles nur 'persönliche Meinung' :)
I wo denn, des poast schoa!
Quote from: TFM on 01. October 2018, 00:34:06
0.9 LambdaSpeak 8 Bit I/O: Wenn so eine 8 Bit-Ausgabe-Sprache den LS überfordert (Speichermangel etc.) denn werde ich das hald auf dem CPC programmieren. So einen sinnvollen Unfug hatte ich eh immer schon mal vor. ;)
1. LambdaSpeak: Es gibt nun mehr so viele Versionen, dass ich total den Überblick verliere, wenn nicht schon verloren habe. Da sollte mal eine Art "Ende" her, so dass sich die Anwender dafür entscheiden können, ohne zu denken "oh ich warte nochmal bis die Version 7.2 rauskommt". Nero kann alles, aber alles ist nicht immer Sinnvoll. Es ist schön wenn LS ganz viel kann, aber es muss ja keine Portale in die 9. Dimension öffnen können (obwohl... ;-)))
Na ja, dass Anwender sich nun entscheiden müssten... es gibt ja ohnehin nur eine Version zu kaufen. Und wer es jetzt noch nicht gekauft hat, wird es auch in Zukunft nicht kaufen denke ich. Insofern ist das ganze Projekt ja ohnehin mehr oder weniger geistige Onanie :sign17:
Quote from: TFM on 01. October 2018, 00:34:06
2. 8-Bit Output: Sehe ich jetzt nicht so richtig als wichtig an, da man ja das selbe bereits mit dem Druckerport des CPC machen kann, der hat genauso 8 Bit Daten auf einmal und GND, damit kann man kleine Relais ansteuern. Habe ich mir mal selber nach den CPCAI gebaut
Druckerport, stimmt schon. Aber dann muss man ein Kabel basteln und so. Das liegt vielleicht auch nicht jedem. Wenn dagegen die Header schon da sind, ist es relativ einfach, mal ein Relais anzustecken mit Dupont-Kabeln, und zudem hat man nicht so viel Angst, was am CPC kaputt zu machen. Ich weiss noch, wie nervös ich damals war, als ich das Transferkabel zwischen PC und Druckerport gebastelt habe... ich weiss gar nicht mehr, woher das kam. War das mit CPCEmu irgendwie dabei, die Bauanleitung?
Quote from: TFM on 01. October 2018, 00:34:06
3. LEDs: Ich liebe LEDs - vor allem wenn sie Blau sind. Aber nach einem Tag wirds nervig, wenn sie keine Funktion haben. Ob die nötig sind sei dahingestellt.
Die Funktion ist Visualisierung des Datenworts :) Die 8Segment-LED-Bar-Module werde ich gesockelt machen. Dann kann man sie per Aufpreis mitbestellen, oder nicht. Und natürlich einfach entfernen wenn's nervt. Das 12Segment-LED-Bar-LED-Modul (verschiedenfarbige LEDs) werde ich aber fest einbauen, der LS hat ja inzwischen eine ganze Menge Modi, die durch die entsprechenden LEDs angezeigt werden.
0 = Power
1 = SSA1 Mode
2 = DKtronics Mode
3 = Native Epson
4 = Native DecTalk
5 = SPO SSA1 Mode
6 = SPO DKtronics Mode
7 = Amdrum Mode
8 = Epson Receive
9 = Epson Send
10 = SPO LRQ
11 = SPO _IRQ
Schon sinnvoll m.E. Und so ein Modul kostet nur 1.50 $...
Quote from: TFM on 01. October 2018, 00:34:06
4. Neue Erweiterung: Super Coole Idee! Vor allem wenn man einen Click-Board-Port hat, oder vielleicht gleich Zwei davon (z.B. RTC und Temperatur messen?).
2 wäre gut! Beide sollten zwischen I2C und SPI schaltbar sein, und zwischen 3.5 und 5 V.
Quote from: TFM on 01. October 2018, 00:34:06
In jedem Fall wäre es da ganz gut erst mal rumzufragen, was denn bei den Leuten "gut ankommt". Am Ende kannst Du ja immer noch machen was Du willst. :zunge0020:
Genau. Und das Rumfragen hatten wir ja auch alles schon ;)
Quote from: TFM on 01. October 2018, 00:34:06
5. Software: Falls man vom CPC her die Firmware updaten kann ist das alles kein Problem. Einige dieser Module sind sehr interessant. Ich würde mit der Software in jedem Fall helfen.
Eher nicht, da ich den Aufwand scheue. Allerdings m.E. auch nicht notwendig, wenn die I2C / SPI-Kontrolle vom CPC ausgeht! Wir müssen nur das Meta-Protokoll stabil genug implementieren. Dann braucht man keine Firmware updates mehr.
Wo ist der Like-Button wenn man ihn mal braucht? :jubelaola:
Quote from: TFM on 01. October 2018, 13:02:05
Wo ist der Like-Button wenn man ihn mal braucht? :jubelaola:
Like ::)
Zum Thema 'Firmware vom CPC aus updaten'. Man muss das Rad ja nicht neu erfinden. Der CPC-Booster hat ja auch eine AT-Mega CPU drin. Der kann die Firmware vom CPC aus updaten und der Source-Code ist vorhanden. Das wäre doch was?
Das würde dann auch ersparen Chips als Update per Post zu verschicken. Aber natürlich weiß ich nicht wie das beim LS jetzt alles ist, ob es da zusätzliche Hindernisse gibt. Jedenfalls ist das hald so ein Gedanke. :winke0002:
Klar, stimmt schon. Angucken kann ich mir das ja mal.
Aber jetzt kommt erstmal noch das Experiment mit dem kleinen 1024 KBit SPI-Eeprom 25LC1024, ob ich nicht doch noch PCM-Sample Playback ohne CPC-Zutun hinkriege... mal sehen.
Viel Glück! :jubelaola:
Gibt einen neuen Speech Chip aus China - 15$:
Kann dem Epson S1V30120 (Emic 2 und Click! Speech Board) aber nicht das Wasser reichen. Und frustrierende Doku... na, für den Spaß-Faktor werde ich dann doch lieber den Speak jet nehmen für eine Low Cost Version von LS (wenn überhaupt)
R2D2 meets dk'tronics! :smiley027:
Quote from: LambdaMikel on 04. October 2018, 09:19:57
Klar, stimmt schon. Angucken kann ich mir das ja mal.
Aber jetzt kommt erstmal noch das Experiment mit dem kleinen 1024 KBit SPI-Eeprom 25LC1024, ob ich nicht doch noch PCM-Sample Playback ohne CPC-Zutun hinkriege... mal sehen.
OK, das habe ich jetzt mal gemacht... 128 KB sind jetzt fuer PCM Samples verfuegbar. Damit habe ich die Breadboard-Hardware jetzt fertig, und ich kann das Projekt endlich mal abschliessen, und ein letztes PCB fuer LS 3.0 machen.
Die Firmware hat 2 neue Modi - einen "EEPROM PCM Upload Mode", und einen "EEPROM PCM Play Mode". Das EEPROM kann maximal 256 PCM-Samples (variabler Laenge) verwalten. Der Speicher ist in 256 Seiten a 256 Bytes aufgeteilt; minimale Sample-Laenge ist 2 Seiten, maximale Sample-Laenge 256 Seiten.
Zum Hochladen wird einfach PCM Upload Mode aktiviert (Kontroll-Byte senden), dann ein Byte fuer Seitennummer (Adresse), und ein Byte fuer die Anzahl der Seiten fuer das Sample. Dann folgenden die Sample Bytes (evtl. mit 0 Bytes auffuellen fuer volle Seite).
Modus zum Abspielen wird ebenfalls durch Kontroll-Byte aktiviert, gefolgt von einem Byte fuer Abspiel-Geschwindigkeit (Byte), Seitennummer (Byte), und Anzahl der Seiten (Byte). Abspielen kann auch durch senden einer anderen Seitennummer und Anzahl Seiten vorzeitig beendet werden, sodass "Unterbrechungsfreies" Abspielen moeglich wird.
Das SPI EEPROM ist mit 10 MhZ getaktet und schnell genug... evtl. kann ich sogar (wenn auch Mono) mehrere Samples "parallel" abspielen und mischen, sodass der Sample-Player polyphon wird. Damit koennte man einen einfachen polyphonen Synthesizer programmieren. Amdrum mischt ja ebenfalls 3 Kanaele, einfach durch PCM-Sample-Arithmetik. Das SPI EEPROM sollte eigentlich schnell genug sein, um 3 oder 4 Kanaele zu bedienen (wenn nicht mehr).
WoW! Gute Neuigkeiten! Schön, dass das Projekt langsam zum Abschluss kommt. Kannst mir ja die genauen Daten emailen, dann baue ich das in die LS-RSX/ROM Geschichte ein. :)
Quote from: TFM on 21. January 2019, 23:59:51
WoW! Gute Neuigkeiten! Schön, dass das Projekt langsam zum Abschluss kommt. Kannst mir ja die genauen Daten emailen, dann baue ich das in die LS-RSX/ROM Geschichte ein. :)
Klar, mache ich. Momentan kaempfe ich noch mit der Audio-Qualitaet vom Mixer (LS 3 wird auch den Sockel fuer den SPO256 Chip haben)... aber innerhalb der naechsten 4 Wochen sollte es fertig werden.
Also wird es ein schöner Frühling für uns! :jubelaola:
Quote from: TFM on 22. January 2019, 21:38:15
Also wird es ein schöner Frühling für uns! :jubelaola:
Hier schon einmal eine Frühlingsmelodie mittels CPC-PCM-Synthesizer gespielt ;)
[CPCEmulator]https://youtu.be/9VoMoj8Qr0s[/CPCEmulator]
Polyphonie kommt demnächst. Die Soundqualität sollte ganz anständig werden... Bitraten können natürlich viel höher sein als im Amdrum PCM Sample Playing Modus.
Nicht schlecht, da werden die c64 User weinen :zwinker0018: ;) :) :)
Quote from: TFM on 24. January 2019, 18:32:39
Nicht schlecht, da werden die c64 User weinen :zwinker0018: ;) :) :)
Wir werden sehen :D Ich habe ja auch ein paar 64er hier... :bgdev:
Jetzt auch polyphon:
[CPCEmulator]https://youtu.be/BKLnTiDfbk8[/CPCEmulator]
Super, wenn Du Dich noch mal ans RSX machen willst! :jubelaola:
Du kannst ja schon mal das BASIC-Programm aus dem YouTube Video ansehen. Ganz einfach also.
Hochladen ist &FE, abspielen ist &FD.
Zum Abspielen von PCM <sample number> auf Kanal <channel> mit Rate <rate>:
out &fbee, &fd
out &fbee,0
out &fbee,<channel> (1, 2, 3)
out &fbee,0
out &fbee,<sample number> (1 ... 254)
out &fbee,0
out &fbee,<rate> (1 ... 255)
Evtl. kommen noch weitere Bytes, Lautstaerke z.B.
Zum Hochladen:
out &fbee, &fe
out &fbee,<sample number> (1 ... 254)
out &fbee,<number of pages>
Jede page ist 512 Bytes. PCM muss mit 127 "aufgefüllt" werden bis Seite voll.
Es fehlen noch ein paar Command Bytes, z.B. zum Löschen.
Quote from: LambdaMikel on 27. January 2019, 18:38:06
Wir werden sehen :D Ich habe ja auch ein paar 64er hier... :bgdev:
Entzündet die Fackeln, scheitet das Holz! :bgdev:
Quote from: TFM on 31. January 2019, 17:31:13
Quote from: LambdaMikel on 27. January 2019, 18:38:06
Wir werden sehen :D Ich habe ja auch ein paar 64er hier... :bgdev:
Entzündet die Fackeln, scheitet das Holz! :bgdev:
...wie gemein! :bgdev: ;D
... nur dass es den Computern nicht kalt wird im Winter. :gruebel:
Quote from: TFM on 03. February 2019, 12:55:27
... nur dass es den Computern nicht kalt wird im Winter. :gruebel:
Ach so, die 64er sollen brennen, und ich dachte schon, ich sollte als Ketzer dem CPC-Gott geopfert werden! Nun ja, so oder so... :kaffee: :irre: :birthday:
Btw, in California wird es nicht kalt :00008351:
Genieß das Wetter, in München hats 30 cm Schnee. :motz:
Gegen Schnee hilft nur ein gaaaanz heißes Video:
[CPCEmulator]https://youtu.be/yAZAAMu1DfA[/CPCEmulator]
Das Video ist leider nicht so gut, er hätte mal die Dokumentation lesen sollen. Bei Speakscreen muss man hald vorher noch blocking on machen. Aber wer liest heue schon noch Handbücher? :zunge0020:
Quote from: TFM on 18. February 2019, 12:05:54
Das Video ist leider nicht so gut, er hätte mal die Dokumentation lesen sollen. Bei Speakscreen muss man hald vorher noch blocking on machen. Aber wer liest heue schon noch Handbücher? :zunge0020:
... ja, aber ich war ja froh, dass er es überhaupt noch gemacht hat (immerhin hatte ich ihm das schon letzten Sommer geschickt).
Und da wollte ich nicht länger rummeckern. Bei Änderungswünschen hätte er vielleicht abgesagt.
Und bei den "sagenhaften Verkaufszahlen" kann auch ein schlechtes Review nichts vermiesen - schlechte Publicity ist besser als gar keine :D
Immerhin, ein weiteren Käufer gibt es jetzt dank Video. :flehan:
Bin ja gespannt, wieviele Leute für ToTOS TechnoMusique Speech Synth zusammen kommen werden!
Die Verkaufszahlen können gar nicht so hoch sein, das Projekt ist ja immer noch im Ausbau, was ich toll finde, aber da wartet hald jeder noch ab was noch dazu kommt. Dieses Klick-Board ist ja auch nicht gerade billig. Und da gehen die meisten wohl "auf Nummer sicher" und warten bis es ganz sicher fertig ist.
Wer weiß was nach LS 3.0 noch alles kommt? :)
Das Video ist ja im großen und ganzen auch schön anzusehen. :smiley027:
Quote from: TFM on 19. February 2019, 15:08:19
Die Verkaufszahlen können gar nicht so hoch sein, das Projekt ist ja immer noch im Ausbau, was ich toll finde, aber da wartet hald jeder noch ab was noch dazu kommt. Dieses Klick-Board ist ja auch nicht gerade billig. Und da gehen die meisten wohl "auf Nummer sicher" und warten bis es ganz sicher fertig ist.
Wer weiß was nach LS 3.0 noch alles kommt? :)
Das Video ist ja im großen und ganzen auch schön anzusehen. :smiley027:
Yes, our business is seriously affected by the Osborne Effect ;D
https://en.wikipedia.org/wiki/Osborne_effect
Ah, wieder was gelernt. Andererseits ist es doch menschlich sich über das was man entwickelt zu freuen und manchmal der Zeit etwas voraus zu sein. :)
Na, wird schon noch werden! :smiley027:
Jetzt können wir demnächst mit der "universal SPI Mikrobus"-Funktionalität beginnen!
Jetzt, da LS 3.0 ein EEPROM an Board hat (128 KB), kann man das natürlich nicht nur für PCM-Samples nutzen (s. LambdaDrum-Demo), sondern auch, um "SPI Device Treiber" hochzuladen, für Mikroelektronika SPI Click! boards. Die Kommunikation mit SPI soll natürlich möglichst über den Mikrocontroller an Board abgewickelt werden, nicht über den CPC Bus. Dafür benötigt man dann eine Art LambdaSpeak-"SPI Programmiersprache", mit einem Instruktionsset, dass SPI Kommunikation ermöglicht mit dem entsp. Click! board. Die "SPI Treiber" können dann in dieser Bytecode-Interpreter-Programmiersprache auf das LambdaSpeak in das EEPROM geladen werden, und entsprechende "Seiten-Aufrufe" des EEPROM werden dann als "SPI Programme" ausgeführt, die entsp. SPI-Kommunikation mit dem Device ermöglichen.
Ich werde mal mit der SPI RTC und dem Temperatur-Sensor anfangen und anhand dessen rauskriegen, was die "SPI Programmiersprache" denn können muss, damit man diese Click! boards vom CPC aus nutzen kann.
https://www.mikroe.com/rtc-5-click
SPI Commands sind hier:
http://ww1.microchip.com/downloads/en/DeviceDoc/MCP7951X-MCP7952X-Battery-Backed-SPI-RTCC-20002300C.pdf
Faszinierend!!! :jubelaola:
Hier eine Sing-Diskette vom LambdaMikel...
Quote from: TFM on 01. March 2019, 11:04:11
Hier eine Sing-Diskette vom LambdaMikel...
Falls Du nochmal Langeweile haben solltest - eine MC version wäre toll, dann wäre das Problem mit der Pause zwischen den Segmenten behoben.
War noch ein Fehler drin... RESET Routine.
Quote from: LambdaMikel on 01. March 2019, 17:58:06
Quote from: TFM on 01. March 2019, 11:04:11
Hier eine Sing-Diskette vom LambdaMikel...
Falls Du nochmal Langeweile haben solltest - eine MC version wäre toll, dann wäre das Problem mit der Pause zwischen den Segmenten behoben.
Daran wird es wohl nicht liegen. In MC läuft zwar alles im Mikrosekunde-Bereich. Aber auch im BASIC läuft alles im Milli-Sekundenbereich (oder schlimmstens 10tel Sekunden ;-)). Da sollte keine Pause hörbar sein.
Danke für das Update (3), ich werde es mir gleich mal ansehen. :smiley027:
Quote from: TFM on 04. March 2019, 17:13:24
Daran wird es wohl nicht liegen. In MC läuft zwar alles im Mikrosekunde-Bereich. Aber auch im BASIC läuft alles im Milli-Sekundenbereich (oder schlimmstens 10tel Sekunden ;-)). Da sollte keine Pause hörbar sein.
Danke für das Update (3), ich werde es mir gleich mal ansehen. :smiley027:
Ja, das Problem ist halt, dass LS keine Bytes empfaengt waehrend es spricht. Und dann braucht BASIC halt ne Zeit, bis der Buffer wieder gefuellt ist.
Wollte hier auch noch einmal auf die neue LS 195 und LS 199 Firmwares hinweisen - siehe GIthub!
Flashen geht mit dem EEPROMMER -
https://www.amazon.de/WINGONEER-TL866II-Hochleistungs-EEPROM-Programmierer-ATMEGA/dp/B07B985LBS/ref=sr_1_2_sspa?ie=UTF8&qid=1551813167&sr=8-2-spons&keywords=eeprom+programmer&psc=1
https://www.ebay.de/itm/TL866CS-Programmiergeraet-USB-EPROM-FLASH-BIOS-Programmierbare-Logikschaltu-X5M2/263897940197?hash=item3d718b00e5:g:~hkAAOSw8b9bgQTF:rk:1:pf:0
oder natuerlich mit nem ATMega/AVR programmer und avr-dude...
Sonst halt den EEPROMER nehmen, aber nicht vergessen, die Fuses richtig einzustellen:
https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/atmega644/atmega-flash-config.jpg?raw=true
Wer's nicht kann oder will kann den Chip einsenden, Rueckporte ist allerdings 14 $ (USPS).
Das ist wahrscheinlich die allerletzte Firmware fuer LS 195 und LS 199.
LS 30 kommt im Sommer. Aber nur 10 bis 15 Exemplare, dann ist Schluss.
nen LS30 kannst mir gern reservieren ;D
Update meines LS195 oder 199 mache ich dann später, muss mal gucken welches ich von dir gekauft hatte.
Kannst nochmal den Link posten zur Firmware?
https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/atmega644/ls199-and-ls21-with-spo256-al2/ls199-ls21-firmware.hex
Das ist die Firmware fuer den LS 199 (-> Rennert)
Kann ich damit den 1.95 in einen 1.99 verwandeln? Haben wir eine Schritt-für-Schritt Anleitung?
Quote from: TFM on 06. March 2019, 16:59:31
Kann ich damit den 1.95 in einen 1.99 verwandeln? Haben wir eine Schritt-für-Schritt Anleitung?
Nein, leider nicht.
LS 195 Firmware ist hier:
https://github.com/lambdamikel/LambdaSpeak/tree/master/firmware/atmega644/ls195-and-ls20
Hast Du einen EEPROMER? Wenn ja, welchen? Kann er die AVR Fuses "brennen"?
Wenn nicht, muss ich mal sehen, ob ich nicht auch eine Anleitung erstellen kann, wie man den per Arduino flashed.
Ich muss das mal ausprobieren:
https://riktronics.wordpress.com/2016/07/26/program-avr-using-arduino-simplest-way/#more-621
Das sollte gehen.
Hier der Changelog:
-internal version change from 8 to 12
- support for LS 1.5, LS 1.8, LS 1.9, LS 2.0 and LS 2.1 dropped
- support for LS 3.0 added
- internal optimizations (removed an unnecessary char buffer for speech)
- reset button works for PCM test
- LS 3.0 added support for new EEPROM functions:
- EEPROM clear all
- EEPROM PCM Sample Play Test
- EEPROM upload
- EEPROM play (1, 2, and 3 channels)
- EEPROM test
- significantly reduced number of HAL9000 quotes
- PCM sample for LS 3.0 changed from other versions, because of PROGMEM shortage
- fixes to Spanish speaking mode - language change command was ignored, missing Epson re-initialization (fixed)
- fixes to EPSON parser for Spanish speaking mode: now supports accents and ~ etc.
Since LS only support 7 bit ASCII for content (everthing with 8th bit set is control byte!),
ASCII characters > 127 have to be specified using \xHH (where H is Hex nibble). See test2.bas
for some Spanish accents using this method.
Also, ich habe einen VS4000 Stager EPROM Brenner, ich kann folgende CPUs wählen:
- ATMEGA644A(PDIP40)
- ATMEGA644AP(PDIP40)
Ich habe so eine LS 1.95 MPU Dank Michael hier rumliegen, da steht auch ein P drauf. Die genaue Bezeichnung ist: ATMEGA644 20PU 1707
Also selektiere ich den zweiten Typen, den ATMEGA644AP(PDIP40)
Mit dem VS4000 kann ich die CPU einlesen, 64 KB Daten sind da, das EEPROM ist leer.
Also lösche ich die CPU, funktioniert.
DUMMERWEISE hat aber die Firmware in Git-Hub 860 KB. Die passen schwer in 64 KB RAM der r ATMEGA644. Laden kann ich als Binär, Intel Hex und noch ein paar Sachen. Lade ich die .HEX Datei von Git-Hub dann mault der Brenner, verwende ich sie als Binäre dann passen wie gesagt 860 KB nicht in 64 KB. Vor allem frage ich mich warum in dieser Firmware von Git-Hub irgendwas von html drin steht. Git-Hub hat wohl alles durcheinander gewürfelt.
Könnte also jemand bitte hier eine ganz normale Datei anhängen die ich brennen kann? Das wäre wirklich super! Über Fuses und so Zeug sagt bzw. fragt der Brenner nichts.
Ich fange gerade an dieses Git-Hub wirklich zu hassen! :motz:
EDIT: Ok, habe so eine Datei aus diesem doofen GitSchutt geladen, dabei musste ich erst auf RAW umschalten, habe die dann als .TXT gespeichert mit dem Brenner als HEX importiert und die CPU gebrannt. Bin gespannt ob das jetzt funktioniert....
EDIT2: Das Brennen schein geklappt zu haben. Nur leider blinken beide LEDs des LS1.95 beim Einschalten, auch kommt keine Sprachmeldung. Mit !GETVERSION zeigt er immerhin 8 an. Da aber viel nicht mehr geht, tuh ich jetzt wieder die 7er Version der CPU rein. Leider komme ich auch hier nicht weiter. :(
Ich hab nur nen billigen Top853, der kann keine Atmegas.
Hab noch nen AVR USB Teil, aber damit gehen die Atmels/Atmegas nur per JTAG, das hat das Modul aber nicht. Muss ich mir ne Schaltung bauen.
OK, Github "save as" gibt ne HTML Datei... also "per raw" anzeigen, und dann save as. Oder besser das ganze Archiv per ZIP "auschecken" oder "clonen" (mit nem Gittool). Anbei das ZIP.
Also, die Firmware HEX Dateien sind i.o.! Habe ich gerade noch mal ausprobiert. Mit den folgenden Fuses. 644P oder 644A oder 644PA ist eigentlich egal; ich kann bei meinem Programmer einfach "Check ID" ausschalten, und dann macht es keinen Unterschied welchen Chip (P, A, PA) ich selektiere. Es kann sein, dass Dein Programmer die "AVR FUSES" versaubeutelt. Dann musst Du erst einmal rausfinden, wie Du damit dieF FUSES richtig einstellen kannst. Ich verwende diese Einstellungen, und damit kann ich sowohl einen alten LS Chip updaten, auch einen neuen Brennen.
Für einen neuen Chip musst Du die Fuses zwingend programmieren. Für einen alten Chip kannst Du die alten Fuses-Einstellungen behalten, allerdings darf der Programmer die Fuses dann nicht überschreiben mit Default-Werten o.ä. Das wird wohl das "Blinken" erklären.
Der Brenn-Prozess mit dem MiniPro Programmer funktioniert am besten, wenn man erst das HEX lädt, dann gibt es eine "versteckte Seite" für die Fuses-Einstellungen (s. Screenshot), evtl. auf "Check ID" ausschalten, dann geht man auf "P" für Programm, und da gibt es dann noch Einstellungen wie gezeigt im Screenshot - Data, Code, Fuses, Lock Bit, also welchen Bereich er programmieren soll. Für einen jungfräulichen Chip muss man alles ausser Data flashen, für einen Update reicht eigentlich Code, WENN nicht der Programmer die Fuses dann mit Default-Werten versaubeutelt! Dann ist natürlich schlecht und man muss die richtigen Fuses einstellen!
PS Also, keine Panik, wenn er 15 mal blinkte, ist das ein gutes Zeichen! Ich hatte das auch bei einem Versuch, und dann einfach noch mal versucht, beim nächsten Mal ging es!
Quote from: TFM on 07. March 2019, 13:45:02
EDIT2: Das Brennen schein geklappt zu haben. Nur leider blinken beide LEDs des LS1.95 beim Einschalten, auch kommt keine Sprachmeldung. Mit !GETVERSION zeigt er immerhin 8 an. Da aber viel nicht mehr geht, tuh ich jetzt wieder die 7er Version der CPU rein. Leider komme ich auch hier nicht weiter. :(
Du hast es fast geschafft - wahrscheinlich die FUSES! Mal rauskriegen, was der Programmer da macht und wo die Einstellungen dafür sind!
Die FUSES stellen u.a. die Takfrequenz ein. Er blinkt tatsächlich 15 mal beim Einschalten, allerdings mit einem viel viel höherem Takt! Daher siehst Du das blinken nur als "leicht gedimmte LEDs". Die CLockFrequency Fuses werden nicht richtig geschrieben bei Dir.
Beim MiniPro screenshot siehst Du, dass die "Low Fuse Bytes " alles aus sind... so muss es sein! Die sind für die 20 MHz clock erforderlich!
Sonst clockt der AVR mir 1 Mhz oder was auch immer default ist.
Ein Wunder! Es hat geklappt, bei getversion ist es jetzt 12 anstatt 7. Und es scheint zu funktionieren. Anbei ein Bild, ich kann das mit den Fuses doch einstellen. Encrypt gibt's auch, brauch ich das?
Fuses was sind das überhaupt? So eine Art Jumper in Software?
Na egal, Hauptsache es tut. Schön wäre es wenn das USIfAC auch tun würde, aber das kostet mir noch den letzen Nerv.
Wenigstens tut der LS und der Platten am Auto ist repariert. :irre:
Quote from: TFM on 08. March 2019, 00:18:12
Ein Wunder! Es hat geklappt, bei getversion ist es jetzt 12 anstatt 7. Und es scheint zu funktionieren. Anbei ein Bild, ich kann das mit den Fuses doch einstellen. Encrypt gibt's auch, brauch ich das?
Fuses was sind das überhaupt? So eine Art Jumper in Software?
Na egal, Hauptsache es tut. Schön wäre es wenn das USIfAC auch tun würde, aber das kostet mir noch den letzen Nerv.
Wenigstens tut der LS und der Platten am Auto ist repariert. :irre:
Super! Herzlichen Gluehstrumpf!! :00008351:
Ja genau, jumper in Software... die Dinger sind kompliziert und haben schon manchen AVR in den Dornroeschenschlaf versetzt. Es gibt sogar spezielle Programmier-Boards, die einen kaputt-geflaschten ATMega wieder aus dem Koma zurueckholen, mittels 12 V-Programmierspannung.
So eine Art Elektroschock-Therapie fuer Mikrocontroller :irre:
Ach, Auto auch noch... mensch scheint ja eine unglueckliche Woche zu sein... hoffe der Schnee ist wenigstens weg :winke0002:
Encypt verhinder das Stehlen der Firmware per Auslesen... wenn Du Deinen Mitbewohnern traust, dann brauchst Du das nicht ;)
Hier mal ein Link zum Fuse Repair Programmer, nur fuer den Fall dass es mal daneben geht -
https://www.ebay.com/itm/ATMEL-AVR-ATMEGA-ATTINY-Fuse-Repair-Programmer-Fuse-Doctor-Express-USA-Shipping/222853556885?hash=item33e31b6a95:g:HSYAAOSwm~1cUG8d
Zuerst dachte ich, dass Ding waere reiner Hokuspokus (so was wie Sprit-Optimierung im Auto mittles OBD-II Dongle), aber der tut!!! Habe ich inzwischen auch. Klar, man muss erstmal ein paar kaputt kriegen bis er sich lohnt, aber dann tut er wahre Wunder!
Hoffe, Du wirst ihn nicht brauchen.
Die ersten 3 LambdaSpeak 3 PCBs sind in der Produktion :)
Nun kann es demnächst los gehen mit einem anderen hochinteressanten Projekt... @TFM weiß wovon ich rede. ;)
Na ja, der dicke Xilinx CPLD 9572. Gleiches Ding das überall verwendet wird - auch schon schön retro.
Da ich volle Addressdekodierung mache und das Ding noch ein paar mehr Funktionen hat (sind nur 6 PINs oder so unbelegt), brauchte ich die größere Version, mit 84 Pins. Die meisten CPC Platinen nehmen den XC 9536 oder den kleinen XL 9572 (36 Pins).
EDIT - ups, jetzt habe ich Deine Frage überschrieben :zunge0020: Sorry - muss mich noch an die Macht der Moderator Rolle gewöhnen ;D
Frage von TFM war: Was ist der große Brummer? FPGA?
Verkloppe ein paar Platinen der älteren Generation, da Auslaufmodell - wer Lust hat, kann sich selbst was zusammen brutzeln:
https://www.ebay.com/itm/Amstrad-CPC-Speech-Synthesizer-LambdaSpeak-1-99-PCB-ATMega-and-2-PALs/192865065571?hash=item2ce7a75a63:g:tEAAAOSwUf9ckwnJ
https://www.ebay.com/itm/Amstrad-CPC-Speech-Synthesizer-LambdaSpeak-1-99-PCB-only/192865065785?hash=item2ce7a75b39:g:wBMAAOSwMDhckwov
https://www.ebay.com/itm/Amstrad-CPC-Speech-Synthesizer-LambdaSpeak-1-95-PCB-ATMega-and-PAL/192865065158?hash=item2ce7a758c6:g:VVwAAOSwGhFckwj4
https://www.ebay.com/itm/Amstrad-CPC-Speech-Synthesizer-LambdaSpeak-1-95-PCB-ONLY/192865053739?hash=item2ce7a72c2b:g:RGcAAOSwzCRckwgT
https://www.ebay.com/itm/Amstrad-CPC-Expansion-Port-Connector-UNASSEMBELD-KIT/192865068530?hash=item2ce7a765f2:g:5xYAAOSwmU1ckwvt
Was ist denn jetzt eigentlich die "offizielle" Version? Gibt es so etwas überhaupt? :)
Tzz tzzz... was für ne Frage! ::) Offiziell und amtlich ist natürlich alles was von mir kommt :motz: ;D :zunge0020: :smiley027: :irre: :bgdev: :jubelaola: Das Du das noch nicht weißt... ;D
Spaß beiseite - LS 1.99 ist mit zusätzlichem, optionalem echten SPO256-AL2, also DKtroncs Speech Synth und SSA-1 Speech Re-Implementation IN HARDWARE.
Zusätzlich zu den Emulationen. @Rennert hat so einen, der Rest der Welt hat LS 1.95.
Hier noch einer:
https://www.ebay.co.uk/itm/192865622873
Also ich bin mit dem 1.95 super zufrieden! :) :) :)
Wenn der 3er fertig ist, dann muss ich mich wieder an die RSX Schreiberei machen, aber ich glaube das hat ja noch Zeit. :00008351:
Quote from: TFM on 22. March 2019, 01:22:43
Also ich bin mit dem 1.95 super zufrieden! :) :) :)
Wenn der 3er fertig ist, dann muss ich mich wieder an die RSX Schreiberei machen, aber ich glaube das hat ja noch Zeit. :00008351:
Na ja, habe gerade von OshPark email gekriegt, dass die Boards schon in der Post sind... am WE werde ich wissen, ob das Design durchgeht :)
Koennte also schon naechste Woche sein...
Fuer LS 3.0 muss ja gar nicht viel geaendert werden... es sind ja nur so 20 neue Befehle ;D
(OK, eher 5 oder 6... also gar nicht so schlimm).
Um so mehr um so besser, im ROM ist Platz genug! :P
Gar kein Problem! 8)
Quote from: TFM on 22. March 2019, 15:06:26
Um so mehr um so besser, im ROM ist Platz genug! :P
Gar kein Problem! 8)
Hätte auch noch ein paar Ideen für Extra-Funktionen - z.B. könnte man einen einfachen Tracker / Patttern-basierten Sequencer machen, der die PCM Kanäle bedient. So eine Art Drumcomputer. PCM Samples und Patterns können ja im EEPROM gespeichert werden.
Hätte sogar selbst auch Lust, mal wieder etwas Z80 zu machen... müsste aber wohl alles neu lernen :-( Na ja, heutzutage fällt einem das ja wesentlich leichter als vor 35 Jahren - mit den ganzen guten Tutorials und Videos online.
Das ist wie Radfahren, verlernt man nicht. :motz: :smilie_winke_029:
Quote from: TFM on 22. March 2019, 16:24:23
Das ist wie Radfahren, verlernt man nicht. :motz: :smilie_winke_029:
:bgdev:
Hoffen wir's... entwickelst Du eigentlich am Emulator? Ist ja etwas einfacher, oder...
Na, mit dem Sequencer stelle ich mir das in etwa so vor (der Sequencer laeuft in der Firmware selbst):
- 2 Arten von "Patterns": Pattern und Song
- Upload der Patterns / Songs wie bei PCM Upload (Seitennummer, Anz. Seiten - muss 1 sein fuer Patterns und Songs! - , dann Nutzbytes senden)
- Nutzbytes sind im Pattern Mode:
- Anzahl Schritte, dann 3x Anz. Schritte Bytes
- jede Note im Pattern hat 3 Bytes: Sample-Nummer (Seite), Anz. Pages, und Pitch. 0,<Laenge>,0 ist fuer Pause
- da eine Seite 256 Bytes hat, kann eine Page max. 64 Schritte haben (und es bleiben noch ein paar Bytes fuer Pattern-Info)
- Nutzbytes sind im Song Mode:
- Song Nummer (Page), Anzahl Schritte; dann 3 x Anzahl Schritte Bytes: Pattern fuer Kanal1, Kanal2, Kanal3 (Seite)
- 3 neue Kontroll-Bytes:
- Play Pattern: PCM-Kanal, Pattern Nummer (Seite), Geschwindigkeit
- Play Song: Song Nummer (Seite), Geschwindigkeit
- Read EEPROM Page: Seite -> Bytes
- Anspielen kann jederzeit abgebrochen werden (Stop Kontroll-Byte senden)
Happy Birthday, LambdaSpeak 3! :birthday: ;D
Funktionierte sofort, "out of the box"!
So, nach 2 Jahren kommt dieses Projekt endlich zum Abschluss - man glaubt es kaum!
Ein paar weitere Firmware Features (Sequencer, s.o.), und ich habe fertig ;D :00008351:
Sehr schön ;D
Gratuliere zum Erfolg.
WoW! Super! Sieht ja echt toll aus! Mal eine Frage, den SP0256 Chip kann man doch auch sicher weglassen, da der ja vom LS softwareseitig emuliert wird oder?
ja geht auch ohne, hab bei mir allerdings auch einen drauf, der Originalität halber ;D
Hört man denn da einen Unterschied? Also mehr als "naja, könnte anders klingen, bin mir aber nicht ganz sicher"...?
Naja, ich arbeite eh mit den neuen Modi, die versteht man sehr gut. :)
muss ich nochmal vergleichen, aber glaube emuliert klingt etwas besser.
Quote from: TFM on 24. March 2019, 20:12:49
Hört man denn da einen Unterschied? Also mehr als "naja, könnte anders klingen, bin mir aber nicht ganz sicher"...?
Naja, ich arbeite eh mit den neuen Modi, die versteht man sehr gut. :)
Also, man muss zwischen Emulation und Emulation unterscheiden.
Du meinst mit Emulation die PCM-basierte SPO-Emulation. Das hat LambdaSpeak nicht. Dafür den echten SPO.
Rennert meint mit Emulation die SSA1/DK Emulation im LambdaSpeak - die geht allerdings über DECtalk, und ist somit gar nicht vergleichbar in der Sprachqualität. Natürlich klingt das besser als der Original-SPO.
Ganz zu schweigen von den "echten" DECtalk und Epson "native" Modi, die natürlich (fast!) natürliche Sprache erzeugen.
In LS ist der SPO natürlich optional. Wer ihn hat, rein damit, klingt sicherlich nicht schlechter als die PCM-Sample-basierte Version im Emulator! Es klingt sogar besser als der DKtronics, da ich einen echten 3.12 MHz verwende (DKtronics hat geschummelt und 4 Mhz vom CPC abgegriffen - damit klingt das Ding allerdings bescheiden!)
Also, Original-SPO ist besser, insbesondere wegen der echten "Kontroll-Logik" fürs SBY / LRQ - Laden der Allophones, die für das richtige "Timing" der Allophone-Längen sorgt, und richtige Taktfrequenz.
OK, LS 3.0 ist jetzt fertig. Es muss ja mal Schluss sein; mit der letzten Firmware bin ich zufrieden.
Auf den Pattern-Sequencer in der Firmware verzichte ich - das kann alles viel besser extern vom CPC aus erledigt werden, s. LambdaDrum 10 Track Sequencer im anderen Thread.
Ich werde ca. 10 LS 3.0 produzieren, nicht mehr. Davon sind 3 oder 4 bereits vergeben:
- TFM kriegt ihn umsonst demnaechst per Post, fuer evtl. RSX Update (keine Verpflichtung zu Nix natuerlich :) )
- Rennert meinte, er wuerde auch gerne einen haben
- Bryce kriegt auch einen umsonst von mir, fuer wegweisende Hinweise im letzten Jahr
Wer noch einen moechte, bitte melden. Ich kann ihn nur ohne SPO256-AL2 liefern. Wie gesagt, der Chip ist optional. Und kann bei Ebay fuer ca. 20 $ erworben werden.
Fuer alle, die schon das click text to speech Daughterboard haben - der Preis ist 50 $, inkl. Shipping. Der dicke CPLD ist leider extrem teuer.
Fuer alle anderen - das click to text speech board kostet 40 $, also alles zusammen 90 $.
Bei Interesse bitte PM an mich.
Dann ist der CPLD wohl schon ziemlich voll. :)
Für mich bitte ein Klick-Board mitschicken, mit umgelöteter Brücke, ich zahle auch gerne per PayPal was auch immer das mit dem Porto etc kostet.
Was die Software angeht, bitte ich hier mal alle Mitlesenden um Vorschläge und Wünsche. In das 16 KB LS3 ROM passt dann schließlich so einiges rein. :)
Ich nehme eins ohne Click to Speech :D
OK, es gibt eine kleinere Verzögerung....
zhulien aus dem anderen CPC-Board hat mich angeregt, doch noch die Schlafende Serielle (klingt fast nach Raumschiff Orion, oder?) freizusetzen (er will so ein billiges 4 $ MP3-Modul damit steuern... s. Bild - getestet habe ich es mit dem alten Emic 2, der auch ein USART-Gerät ist), jetzt muss ich noch ein bisschen an der Firmware arbeiten für den neuen Modus, und die PCBs müssen natürlich auch noch wieder neu... und wir haben noch 2 mehr DIP-Schalter, da links / rechts Audio-Ausgang von der Klinke nun auch in den CPC SND-Pin gespeist werden kann, zur Konsumierung durch den internen CPC-Lautsprecher und Verstärker. Aber ein/ausschaltbar, wie gesagt. Ansonsten ist es aber fertig :zunge0020: Also, es dauert noch 2 Wochen.
[CPCEmulator]https://youtu.be/E_u7NzCXM1k[/CPCEmulator]
Na ja, gut dass der Lötkolben noch heiß war! Immer wenn man denkt, jetzt hat man fertig, kommt doch noch wieder einer mit was :D
Aber ist ja gut so!
Neue Funktionen sind immer gute Neuigkeiten. :00008351:
Lass Dir ruhig Zeit, so dass es am Ende auch alles gut funktioniert. :smiley027:
OK, serielle Schnittstelle funktioniert, nun in beide Richtungen.
Ich habe testweise mit dem Emic 2 (ein USART device) in beide Richtungen kommuniziert, ueber ein BASIC-Programm. Die LambdaSpeak Firmware hat intelligente Befehle zum Senden und Empfangen ueber das USART (gepuffert).
Ich habe mir auch so ein FTDI-Kabel bestellt, damit kann ich auch PC-Terminal testen.
PCBs kommen naechste Woche, dann ist es fertig.
Hier mal eine Frage:
wie sieht ein maximal praktische Interface zum Empfangen von USART bytes aus?
Bisher habe ich:
- lese <n> Bytes vom USART
- lese Bytes vom USART bis <byte> empfangen (CR oder LF oder 0 oder...)
- lese Bytes vom USART fuer <n> Millsekunden
Die Bytes werden autark vom LambdaSpeak gelesen und gepuffert und koennen dann sukzessive vom CPC ausgelesen werden, indem man ein Kontroll-Byte / Command zum Auslesen schickt. Bis der Puffer vollstaendig gelesen wurde.
Was nicht gut geht ist, immer nur 1 Byte lesen, dann diese Bytes vom Puffer lesen, dann wieder 1 USART Byte lesen, etc. Denn um mit dem CPC zu kommunizieren, muss der USART abgeschaltet werden, und die Kommunikation mit dem CPC kostet dann zu viel Zeit, sodass man Bytes verpassen wuerde. Wenn aslo lange USART Nachrichten zu empfangen sind, muss dass die LS Firmware autark und ohne CPC-Zutun (und ohne Unterbrechungsmoeglichkeiten) tun. Daher also <n> Bytes am Stueck lesen, oder bis zu einem Ende-Token.
Noch andere Ideen?
Schreiben auf das USART ist natuerlich trivial - erst alle Nutzbytes senden, dann Controll Byte / Kommando zum senden des Puffers ueber USART.
Hier ist uebrigens das Teil das man braucht wenn man echtes DB9 aus dem TTL USART benoetigt:
https://www.amazon.com/gp/product/B07GP9SLCH/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
Habe mir mal 2 bestellt. Dann kann sich LambdaSpeak endlich mit meinen DECtalk unterhalten :smiley027:
Also was wäre mir persönlich wichtig?
- I/O Kompatibilität zum USIfAC bzw. CPC-Booster(+) bzw. irgendetwas anderem seriellem
- Abfrage-Möglichkeit, ob dieses neue LS3 Serielle da ist oder nicht
- Puffer für Bytes im LS3
- Diverse Datenraten
- Datensicherheit, wenn möglich kein "Rauschen" wie bei anderen Produkten
Zum schreiben:
Man schickt die Zeichen einfach. Dazu eventuell noch eine Möglichkeit um abzufragen, wie viele ich schicken kann (falls die Datenrate langsam ist und der CPC schneller als der LS3)
Zum lesen:
Funktion um abzufragen wie viele Bytes im Empfangspuffer sind (also gelesen werden können). Und natürlich Byte lesen.
Es wäre auch cool wenn man Funktionen hätte um z.B. 128/256/??? Bytes zu senden und empfangen. Also im Block, das würde alles schneller machen.
Quote from: TFM on 08. April 2019, 20:46:37
Also was wäre mir persönlich wichtig?
- I/O Kompatibilität zum USIfAC bzw. CPC-Booster(+) bzw. irgendetwas anderem seriellem
Eher nicht machbar. USIfAC funktioniert anders, und ich habe nur einen CPC Port...
Quote
- Abfrage-Möglichkeit, ob dieses neue LS3 Serielle da ist oder nicht
Mittels Verionsnummer?
Quote
- Puffer für Bytes im LS3
Genau, so ist es gemacht. Gepuffert fuers Schreiben und fuers Lesen. Byte *direkt rausschreiben* (ungepuffert) kann ich auch machen, ist aber langsamer...
Quote
- Diverse Datenratn
- Datensicherheit, wenn möglich kein "Rauschen" wie bei anderen Produkten
So ist es.
Quote
Zum schreiben:
Man schickt die Zeichen einfach. Dazu eventuell noch eine Möglichkeit um abzufragen, wie viele ich schicken kann (falls die Datenrate langsam ist und der CPC schneller als der LS3)
Wie gesagt, momentan ist gepuffert. Puffer vollschreiben, dann Senden Kontroll-Byte senden. Ab geht die Post an den USART.
Ich kann allerdings auch noch einen *senden einzelnes empfangenes CPC Byte sofort* implementieren.
Puffer-Ueberlauf-Schutz brauchen wir glaube ich nicht. Jedes Byte wird in diesem Modus sofort rausgeschrieben. Und zur Not kann ich den CPC jederzeit anhalten.
Quote
Zum lesen:
Funktion um abzufragen wie viele Bytes im Empfangspuffer sind (also gelesen werden können). Und natürlich Byte lesen.
So ist es.
Quote
Es wäre auch cool wenn man Funktionen hätte um z.B. 128/256/??? Bytes zu senden und empfangen. Also im Block, das würde alles schneller machen.
Genau, haben wir.
Weisst Du evtl. wie gross der Buffer im USIFAC ist?
EDIT - hab's gefunden - 920 bytes.
Genau! Hier kurz das Handbuch dazu...
Nur eines noch... also persönlich finde ich es doof wenn externe Hardware den CPC auf WAIT setzt und damit anhält. Egal ob CPC-Booster oder USIfAC. Es nervt tierisch! Und für BS wie SymbOS nervt es vermutlich noch viel mehr. Da ist mir Hardware lieber, die ich abfragen kann ob ich als Programm was tun muss, anstatt das mir so ein Ding das ganze System ausbremst. (Damit kann man Multitasking (fast) vergessen und jegliche Synchronisation mit dem Bildaufbau ist auch dahin). Das alles kann man sicher sehen wie man will, aber als Programmierer sehe ich es hald so, als Hardware-Macher mag man es diametral anders sehen. Meine Meinung (es ist ja nur eine einzige) soll auch niemandem auf die Füße treten, aber ich wollte es mal loswerden und fühle mich jetzt schon entspannter.
Für den LS3 würde ich mir einfach etwas wünschen das zuverlässig funktioniert. Programmieren kann man es dann schon. :smiley027:
LambdaSpeak 3 serial interface ist jetzt fertig. Wait wird nur minimalsbenutzt, um ein neues Byte vom CPC Datenbus zu lesen wenn es ankommt, um sicherzustellen dass die Synchronisation klappt - aber das ist im Microsekunden Bereich (und LS 30 hat das schon immer gemacht). Ich denke, ich bräuchte das eigentlich gar nicht, aber sicher ist sicher. Wenn Du es bisher nicht negativ bemerkt hast, wirst Du es auch im seriellen Modus nicht merken, da der Mechanismus schon vorher verwendet wurde fürs Datenbyte-Lesen ("Latchen") vom CPC. M.aW., sobal IOREQ WRITE an &FBEE erscheint, wird der CPC kurz angehalten, dann wir das Datenbyte vom Bus gelesen, und dann wird fortgesetzt. Das ist nur, um "Glitches" und "verpasste Bytes" zu verhindern.
Hier ist eine Demo in BASIC - serial Terminal. Funktioniert mit Emic 2 in beide Richtungen (Senden um es zum Sprechen zu bringen, und Query Commands wie "I" geben die aktuellen Settings zurück - ich kann heute Abend mal ein Video schicken, allerdings warte ich damit lieber, bis ich den PC und den NC100 per Kabel ueber LS30 mit dem CPC verbunden habe).
Also, Interface ist ganz einfach:
- LS 30 in den serial mode versetzen: out &fbee,&f1
- dann laeuft der LS in einer "serial mode listener loop", in der man USART senden und empfangen kann. S. screenshots fuer Illustration.
"out &fbee,255" und dann "out &fbee,<val>" sendet serial command control byte "<val>". Um 255 selbst in den Puffer zu schreiben füer den USART, muss man natürlich "out &fbee,255" und dann nochmal "out &fbee,255" schreiben. Alle anderen Nutzbytes <> 255 kann man natürlich direkt schreiben, "out &fbee,<val>" für <val> < 255.
Anbei die Listener Loop - ist etwas unschön, da ich 2 existierende Buffer "wiederverwenden" muss (SRAM-Platzmangel!), aber funktioniert:
void usart_on0(uint8_t rate, uint8_t width, uint8_t parity, uint8_t stop_bits) {
SERIAL_BAUDRATE = rate;
SERIAL_WIDTH = width;
SERIAL_PARITY = parity;
SERIAL_STOP_BITS = stop_bits;
UBRR0H = 0;
switch (rate) {
case 0 : UBRR0H = ( 520 >> 8) & 0xFF; UBRR0L = 520 & 0xFF; SERIAL_RATE = 2400; break; // 2400
case 1 : UBRR0H = ( 259 >> 8) & 0xFF; UBRR0L = 259 & 0xFF; SERIAL_RATE = 4800; break; // 4800
case 2 : UBRR0L = 129; SERIAL_RATE = 9600; break; // 9600
case 3 : UBRR0L = 86; SERIAL_RATE = 14400; break; // 14400
case 4 : UBRR0L = 64; SERIAL_RATE = 19200; break; // 19200
case 5 : UBRR0L = 42; SERIAL_RATE = 28800; break; // 28800
case 6 : UBRR0L = 32; SERIAL_RATE = 38400; break; // 38400
case 7 : UBRR0L = 21; SERIAL_RATE = 57600; break; // 57600
case 8 : UBRR0L = 15; SERIAL_RATE = 76800; break; // 76800
case 9 : UBRR0L = 10; SERIAL_RATE = 115200; break; // 115200
case 10 : UBRR0L = 4; SERIAL_RATE = 250000; break; // 250000
default : UBRR0L = 129; SERIAL_RATE = 9600; // 9600
}
UCSR0C = 0;
switch (parity) {
case 0 : break; // no parity
case 1 : UCSR0C |= (1 << UPM01) | (1 << UPM00) ; break; // odd parity
case 2 : UCSR0C |= (1 << UPM01) ; break; // even parity
default : break;
}
switch (stop_bits) {
case 2 : break; // 1 stop bit
case 1 : UCSR0C |= (1 << USBS0); break; // 2 stop bit
default : break;
}
switch (width) {
case 8 : UCSR0C |= (1 << UCSZ00) | (1 << UCSZ01); break; // 8bit
case 7 : UCSR0C |= (1 << UCSZ01); break; // 7bit
case 6 : UCSR0C |= (1 << UCSZ00) ; break; // 6bit
case 5 : break; // 5bit
default : UCSR0C |= (1 << UCSZ00) | (1 << UCSZ01); // 8bit
}
UCSR0B = (1 << TXEN0) | (1 << RXEN0) | (1 << RXCIE0);
}
//
//
//
void usart_mode_loop() {
cli();
LEDS_ON;
speech_native_busy;
command_confirm("Serial mode. Serial commands start with 255.");
speech_native_ready;
z80_run;
usart_on();
SERIAL_ON;
uint8_t lo_byte = 0;
uint8_t hi_byte = 0;
uint8_t direct_mode = 0;
while (1) {
READ_ARGUMENT_FROM_DATABUS(databus);
if (databus == 255) {
// command sent!
// receive command byte - what to do?
READ_ARGUMENT_FROM_DATABUS(databus);
if (databus == 255) {
// escape: 255 255 -> 255 !
if (direct_mode) {
USART_Transmit(databus);
} else {
if (from_cpc_input_buffer_index < SEND_BUFFER_SIZE) {
send_msg[ from_cpc_input_buffer_index++ ] = databus;
} else if ( (from_cpc_input_buffer_index - SEND_BUFFER_SIZE) < SPEECH_BUFFER_SIZE) {
buffer[ from_cpc_input_buffer_index++ - SEND_BUFFER_SIZE] = databus;
}
}
break;
} else {
// dispatch, decode command byte
switch (databus) {
case 1 : // write USART single byte
READ_ARGUMENT_FROM_DATABUS(databus);
USART_Transmit(databus);
break;
case 2 : // print buffer to serial
USART_sendBuffer(from_cpc_input_buffer_index);
from_cpc_input_buffer_index = 0;
break;
case 3 : // ask for low byte number of bytes in USART input buffer
SEND_TO_CPC_DATABUS(usart_input_buffer_index & 0xFF);
break;
case 4 : // ask for high byte number of bytes in USART input buffer
SEND_TO_CPC_DATABUS( usart_input_buffer_index >> 8);
break;
case 5 : // ask if buffer is full
SEND_TO_CPC_DATABUS(usart_input_buffer_index == (SPEECH_BUFFER_SIZE + SEND_BUFFER_SIZE));
break;
case 6 : // flush receive buffer
usart_input_buffer_index = 0;
cpc_read_cursor = 0;
break;
case 7 : // check if byte available
SEND_TO_CPC_DATABUS( cpc_read_cursor < usart_input_buffer_index );
break;
case 8 : // get byte for CPC at current USART input buffer position
if (cpc_read_cursor >= 0 && cpc_read_cursor < usart_input_buffer_index ) {
uint8_t data = 0;
if ( cpc_read_cursor < SEND_BUFFER_SIZE) {
data = send_msg[ cpc_read_cursor ];
} else if ( (cpc_read_cursor - SEND_BUFFER_SIZE) < SPEECH_BUFFER_SIZE) {
data = buffer[ from_cpc_input_buffer_index - SEND_BUFFER_SIZE];
}
SEND_TO_CPC_DATABUS( data);
}
case 9 : // get next byte for CPC in USART input buffer
if (cpc_read_cursor >= 0 && cpc_read_cursor < usart_input_buffer_index ) {
uint8_t data = 0;
if ( cpc_read_cursor < SEND_BUFFER_SIZE) {
data = send_msg[ cpc_read_cursor++ ];
} else if ( (cpc_read_cursor - SEND_BUFFER_SIZE) < SPEECH_BUFFER_SIZE) {
data = buffer[ from_cpc_input_buffer_index++ - SEND_BUFFER_SIZE];
}
SEND_TO_CPC_DATABUS( data);
}
break;
case 10 : // get previous byte for CPC in USART input buffer
if (cpc_read_cursor >= 0 && cpc_read_cursor < usart_input_buffer_index ) {
uint8_t data = 0;
if ( cpc_read_cursor < SEND_BUFFER_SIZE) {
data = send_msg[ cpc_read_cursor-- ];
} else if ( (cpc_read_cursor - SEND_BUFFER_SIZE) < SPEECH_BUFFER_SIZE) {
data = buffer[ from_cpc_input_buffer_index-- - SEND_BUFFER_SIZE];
}
SEND_TO_CPC_DATABUS( data);
}
break;
case 11 : // set cursor to given byte position
READ_ARGUMENT_FROM_DATABUS(lo_byte);
READ_ARGUMENT_FROM_DATABUS(hi_byte);
cpc_read_cursor = lo_byte + (hi_byte << 8);
break;
case 12 : // reset CPC cursor
cpc_read_cursor = 0;
break;
case 13 : // set CPC cursor to last byte
if (usart_input_buffer_index > 0) {
cpc_read_cursor = usart_input_buffer_index-1;
}
break;
case 14 : // check status
SEND_TO_CPC_DATABUS(direct_mode);
break;
case 15 : // announce mode!
LAMBDA_EPSON_ON;
sprintf(command_string, "Serial interface active at %lu bauds, %d bits, %d stop bits, and %s parity. %s mode.",
SERIAL_RATE, SERIAL_WIDTH, SERIAL_STOP_BITS,
( SERIAL_PARITY == 1 ? "odd" : ( SERIAL_PARITY == 2 ? "even" : "no" )),
(direct_mode == 1 ? "direct" : "buffered" ));
command_confirm(command_string);
usart_input_buffer_index = 0;
cpc_read_cursor = 0;
break;
case 16 : // turn on databus direct printing
direct_mode = 1;
break;
case 17 : // turn off databus direct printing -> print to buffer!
from_cpc_input_buffer_index = 0;
direct_mode = 0;
break;
case 20 :
usart_off();
LAMBDA_EPSON_ON;
speech_native_busy;
BLOCKING = 1;
command_confirm("Quitting serial mode.");
process_reset();
return;
break;
case 30 : // set BAUDRATE
READ_ARGUMENT_FROM_DATABUS(SERIAL_BAUDRATE);
usart_off();
usart_on();
break;
case 31 : // set WIDTH
READ_ARGUMENT_FROM_DATABUS(SERIAL_WIDTH);
usart_off();
usart_on();
break;
case 32 : // set PARITY
READ_ARGUMENT_FROM_DATABUS(SERIAL_PARITY);
usart_off();
usart_on();
break;
case 33 : // set STOP_BITS
READ_ARGUMENT_FROM_DATABUS(SERIAL_STOP_BITS);
usart_off();
usart_on();
break;
}
}
} else {
// not a control byte, send or buffer:
if (direct_mode) {
USART_Transmit(databus);
} else
if (from_cpc_input_buffer_index < SEND_BUFFER_SIZE) {
send_msg[ from_cpc_input_buffer_index++ ] = databus;
} else if ( (from_cpc_input_buffer_index - SEND_BUFFER_SIZE) < SPEECH_BUFFER_SIZE) {
buffer[ from_cpc_input_buffer_index++ - SEND_BUFFER_SIZE] = databus;
}
}
}
}
Quote from: TFM on 10. April 2019, 15:27:59
Da ist mir Hardware lieber, die ich abfragen kann ob ich als Programm was tun muss, anstatt das mir so ein Ding das ganze System ausbremst.
...
Für den LS3 würde ich mir einfach etwas wünschen das zuverlässig funktioniert. Programmieren kann man es dann schon. :smiley027:
Hoffentlich ist das der Fall - es gibt keinen Modus, in dem LS serial den CPC anhält, um Bytes zum USART zu lesen oder zu schreiben. RX USART lesen geht "automatisch" die ganze Zeit, über einen Interrupt ISR handler im LS 30, der empfangene RX USART Bytes in einen Puffer schreibt. Dann kann man den Puffer vom CPC aus abfragen, ob er Bytes enthält etc., und man kann mitteles eines "Read Cursors" vom CPC aus durch den Puffer navigieren und Bytes davon auslesen. Cursor vor, zurück, Cursor-Position setzen, Cursor ans Ende des Puffers, an den Anfang, Puffer löschen, etc.
S. auch Erläuterungen oben bzgl. Datenbus Byte "latchen".
Neue LS300.DSK anbei, mit serial.bas Programm.
Ich denke, es sollte auch mit laengeren Kabeln gut funktionieren, da die Serial TX0/RX0 port vom ATmega durch den CPLD geschleift werden, und das resultiert in Signal-Verstaerkung/ Auffrischung / Verbesserung.
Ich teste demnaechst mal 115 k BAUD und mehr.
Wir immer besser! :smiley027:
Quote from: TFM on 12. April 2019, 05:27:12
Wir immer besser! :smiley027:
Dankeschön! Und auch noch gleich einen Firmware-Fehler gefunden - ein break; war zuviel im Kontroll-Byte dispatcher.
255 255 wurde nicht korrekt nach 255 abgebildet (255 muss mittlels 255 "escaped" werden, da 255 normalerweise Kontroll-Byte signalisiert!)
Gut, dass ich den MP3-Player doch noch mal ausprobiert habe, der benötigt nämlich USART-Befehlssequenzen die 255 enthalten - und ich hatte mich schon gewundert, warum es nicht klappte! Manchmal ist es doch was ganz triviales in der Software, wie ein ; an der falschen Stelle, oder ein break zu viel - wie hier.
Jetzt klappt es:
[CPCEmulator]https://youtu.be/NtUVlTJrOkU[/CPCEmulator]
Sicherlich ein guter Kauf für 4 $ das Module :smiley027:
Und ein letzter Test für heute:
[CPCEmulator]https://youtu.be/uKeZEkyIqtg[/CPCEmulator]
Ich verwende den RS232 level converter mit MAX3232 der inzwischen eingetroffen war:
https://www.amazon.com/gp/product/B07GP9SLCH/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&p;sc=1
Neue DSK anbei; diesesmal mit MP3.bas und auch SERIAL.BAS wurde überarbeitet.
Damit gibt es jetzt die ultimative Sprech- und Sound-Maschine am CPC. :jubelaola:
Passt diese RTC auch am LS3?
https://www.ebay.de/itm/RTC-DS3231-I2C-Echtzeituhr-AT24C32-Real-Time-Clock-Modul-Arduino-Raspberry-Pi/253651685225?hash=item3b0ed18f69:g:jAcAAOSwHORb4Yjp
So ist es! :) :smiley027:
Na, dann kauf ich die mal... :jubelaola:
Hier kommt die Uhr:
[CPCEmulator]https://youtu.be/5vfmYaa_OPY[/CPCEmulator]
Und Software-Update - RTC.bas in LS300.dsk zeigt wie's geht mit der Uhr.
OK, die letzten beiden Tests - eine Sprechende CPC Echtzeituhr:
[CPCEmulator]https://youtu.be/Dsok873zTjM[/CPCEmulator]
Und der Test der Seriellen Schnittstelle mit 115200 BAUDs über FTDI-Kabel:
[CPCEmulator]https://youtu.be/8MZMzynYyxI[/CPCEmulator]
Coole Sache! Da kannst ja dann auch ein Komplett-Paket anbieten. Hab mir die RTC schon bestellt. :)
@TFM: gib mal bitte nen Link zur RTC
I2C - jetzt wirds langsam interessant. Das heisst, ich kann jedes 5voltige I2C-Device am CPC nutzen? In die Arduino-Welt schielend ist da vieles für kleines Geld verfügbar.
Quote from: Rennert on 25. April 2019, 06:30:55
@TFM: gib mal bitte nen Link zur RTC
Hab mir die hier bestellt (heute angekommen):
https://www.ebay.de/itm/RTC-DS3231-I2C-Echtzeituhr-AT24C32-Real-Time-Clock-Modul-Arduino-Raspberry-Pi/253651685225?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649
Oder beim Hersteller direkt:
https://www.makershop.de/module/rtc/rtc-ds3231-i2c/
Dazu noch die CR2032 Batterie, auf Ebay im 10er Pack auch super billig :-)
Quote from: almasys on 25. April 2019, 12:04:01
I2C - jetzt wirds langsam interessant. Das heisst, ich kann jedes 5voltige I2C-Device am CPC nutzen? In die Arduino-Welt schielend ist da vieles für kleines Geld verfügbar.
Im Prinzip ja, alledings ist mir nicht klar, wie ein entsp. I2C-API für LS 3.0 / für den CPC aussehen soll. Vielleicht ist es ähnlich wie bei UART / Serial Interface. Aber I2C ist kompliziert.... und man will ja nicht die ATMega Firmware flashen müssen um ein I2C-Device nutzen zu können. So ist der RTC-Support momentan fest eingebaut in die LS 3.0 Firmware. Der ATmega ist zudem voll, ich habe keinen Platz mehr für neue Funktionen / API. Ich müsste also Funktionalität rausschmeißen.
Im Prinzip kann man also mit der LS 3.0 Hardware ein belibiges SPI und ein beliebiges I2C-Device benutzen, allerdings muss man die ATMega Firmware programmieren. Ich werde irgendwann eine alternativen Firmware anbieten, für genau diesen Aspekt der LS 3.0-Hardware.
Für beliebige USART; I2C und SPI-Erweiterungen dachte ich eigentlich an ein neues Projekt:
https://cpcwiki.de/forum/index.php/topic,749.0.html
Quote from: TFM on 25. April 2019, 13:43:22
RTC für LS3:
https://www.makershop.de/module/rtc/rtc-ds3231-i2c/
Die RTC zum LS3 wird ja mit dem LS3 direkt eingelötet ausgeliefert (hab ich gerade vom Michael erfahren). Jetzt habe ich eine übrig und frage mich ob ich auch über das USIfAC (z.B.) benutzen kann. Man spielt ja gerne mal mit so Zeugs.
Meine Frage: Wie kriege ich eine Beschreibung (Programmierung!) zu dem Ding?
Habe ich mal angehängt.
... und hier vom MP3 Modul.
So, die neuen PCBs vom Seeed Studio sind gestern angekommen, und so musste ich natürlich bis 2 Uhr morgens arbeiten um zu sehen, ob es auch funzt - und in der Tat, so ist es :smiley027:
Ich fange jetzt an, die vorbestellten Exemplare zu bauen (@tfm, @rennert).
Wer noch eines möchte, bitte PM an mich.
SPO256-AL2, MP3-Modul und RTC sind optional, und kosten extra. SPO256-AL2 nur solange der Vorrart hält... Wer kein MP3 und/oder RTC will, kriegt einfach Pin-Header eingelötet, dann kann man mittels DuPont-Kabeln was anschließen.
Über den Preis für die verschiedenen Versionen muss ich noch etwas nachdenken.
@tfm kriegt es natürlich umsonst, wg. RSX-Software Support. Alle anderen müssen blechen :P
Quote from: LambdaMikel on 30. April 2019, 16:31:28
So, die neuen PCBs vom Seeed Studio sind gestern angekommen, und so musste ich natürlich bis 2 Uhr morgens arbeiten um zu sehen, ob es auch funzt - und in der Tat, so ist es :smiley027:
Herzlichen Glückwunsch!!! Die Bilder sehen toll aus. Damit braucht man am CPC nur noch den LS3 und das SF3 - und damit ist alles abgedeckt. :jubelaola:
Ich mag mit RTC und MP3, aber ohne Click2Speech :)
Quote from: TFM on 30. April 2019, 15:34:49
Quote from: TFM on 25. April 2019, 13:43:22
RTC für LS3:
https://www.makershop.de/module/rtc/rtc-ds3231-i2c/
Die RTC zum LS3 wird ja mit dem LS3 direkt eingelötet ausgeliefert (hab ich gerade vom Michael erfahren). Jetzt habe ich eine übrig und frage mich ob ich auch über das USIfAC (z.B.) benutzen kann. Man spielt ja gerne mal mit so Zeugs.
Meine Frage: Wie kriege ich eine Beschreibung (Programmierung!) zu dem Ding?
Also das PDF hatte ich ja angehängt - per USIfAC nutzen geht wohl eher nicht, weil es ja nicht UART ist, sondern I2C...
allerdings kannst Du das MP3-Modul per USIfAC nutzen.
OK, jetzt mal Schluss mit lustig, hier kommt die Rechnung 8) ;D
Basic LS 3.0 - no SPO256-AL2, no MP3, no RTC, no LambdaDrum, no Epson board:
- PCB: 8 $
- CPLD: 8 $
- ATmega 644 20pu: 8 $
- weitere Teile: 12 $
- Versand aus den Staaten nach Europa: 14 $
Summe: 50 $ (USD)
Optional dazu:
- click Epson speech board: 39 $
(das ist nicht wirklich optional, sondern zwingend erforderlich, aber vielleicht hast Du ja schon eines)
- SPO256-AL2 (I only have ~ 5 of these): 35 $
für retro-authentischen SSA1 and DKtronics modus (nicht emuliert)
- 128 KB EEPROM: 5 $
(für LambdaDrum - der 4-Kanal 16 khz 8Bit PCM Sample Player / Drum Computer)
- RTC option: 6 $
- MP3 option: 4 $
So, ein "deluxe LS 3.0 mit allem" gibt es also für schlappe
50 + 39 + 35 + 5 + 6 + 4 = 139 $.
Falls jemand eine günstigere Quelle für SPO256-AL2 findet, bitte bescheid sagen!
Für jemanden wir @Rennert der schon einen SPO256-AL2 und click Epson board hat, ist es also nicht zu teuer - 65 $.
Eventuall macht es ja Sinn die "im Pack" nach DE zu schicken und von hier aus dann zu verteilen. Dann wird's Porto billiger. :)
Ja, allerdings besteht die Kundschaft in D ja auch nur aus 2 Leuten, insofern... aber wenn Du dem Rennert gerne sein Porto reduzieren moechtest (Du zahlst ja ohnehin nix), kannst Du das gerne machen :smiley027:
Na sicher, ist Bryce nicht auch in DE? Ich kann die Dinger auch gerne von hier unsonst weiterschicken, die paar Euro sind ja nicht das Thema. Overseas on the other hand... :-//
Quote from: TFM on 02. May 2019, 18:48:56
Na sicher, ist Bryce nicht auch in DE? Ich kann die Dinger auch gerne von hier unsonst weiterschicken, die paar Euro sind ja nicht das Thema. Overseas on the other hand... :-//
Stimmt, Bryce auch.. ok, dann machen wir das so! Du kriegst ein Paket mit 3 LS 3 und kannst dann an Rennert und Bryce versenden. Super, Danke!
Prima klingt super :)
TFM hat mir schonmal ein Paket geschickt, damals noch ein Smartwatch Armband aus den USA.
Quote from: Rennert on 02. May 2019, 19:27:41
Prima klingt super :)
TFM hat mir schonmal ein Paket geschickt, damals noch ein Smartwatch Armband aus den USA.
Ja, TFM ist vertrauenswuerdig ;) Genau, viele gute Sachen kommen aus den USA :winke0002:
PS Rennert, willst Du noch nen 2. SPO kaufen von mir?
Nee einer reicht ;D
Quote from: Rennert on 02. May 2019, 21:25:35
Nee einer reicht ;D
OK - je mehr ich fuer mich behalten kann, umso besser :zunge0020:
Haha! Ich verzichte gerne darauf, ist jetzt wirklich nicht böse gemeint, aber ich glaub ich hör den Unterschied nicht so wirklich. Hauptsache der Epson Modus funktioniert :-)
Dann lieber Michael, PM mir bitte bei Gelegenheit die aktuellen Adressen von Rennert und Bryce. Jaja ich bin etwas Paranoid, aber das kommt davon wenn man mit Black Sabbath aufwächst. :zunge0020:
Ach Herr TFM hast wohl meine Adresse nicht mehr :P
Naja ist auch schon paar Jahre her.
Quote from: Rennert on 03. May 2019, 15:07:05
Ach Herr TFM hast wohl meine Adresse nicht mehr :P
Naja ist auch schon paar Jahre her.
Naja, ich nehme das mit dem Datenschutz sehr ernst, mein CPC-Adressbuch löscht sich gerne mal selber :-)
Quote from: TFM on 03. May 2019, 14:52:21
Haha! Ich verzichte gerne darauf, ist jetzt wirklich nicht böse gemeint, aber ich glaub ich hör den Unterschied nicht so wirklich. Hauptsache der Epson Modus funktioniert :-)
Dann lieber Michael, PM mir bitte bei Gelegenheit die aktuellen Adressen von Rennert und Bryce. Jaja ich bin etwas Paranoid, aber das kommt davon wenn man mit Black Sabbath aufwächst. :zunge0020:
Ja Rennert ist ja hier, und Bryce werde ich fragen ob er damit einverstanden ist... ein Problem könnte zudem der Zoll sein. Ein einzelnes PCB kann man immer irgendwie als Geschenk und nicht funktionierendes altes Retro-Computer-Board deklarieren. Bei 3 bin ich mir nich mehr so sicher... wäre blöd, wenn Zoll darauf bezahlt werden müsste. Das würde es wieder sehr viel teurer machen, und die Einsparungen zunichte machen. Das war mir mal mit Bryce passiert... der hat mich tagelang verflucht because "he was hit with a 20 $ bil" :banghead: dabei hatte ich alles als Geschenk deklariert, aber der Zoll in D ist pfiffig!
PS - Sorry, Du musst auch einen SPO kriegen damit Du SOftware für diesen Modus machen kannst ;D SPO ist gut! :)
Also, ich hab hier den dk'tronics speech synthesizer, der hat den Chip ja auch. Brauchst nicht schicken. :)
Gerbers:
https://www.seeedstudio.io/LambdaSpeak-3-g-1230571
Project GitHub / firmware:
https://github.com/lambdamikel/LambdaSpeak3
Readme.md wird so langsam... phh, echt viel zu schreiben...
Hier ein paar Hinweise von meiner Seite zur Software, auch wenn das hier die Hardware Rubrik ist, aber es passt hald hier schön mit dazu. Hier also meine Verbesserungsvorschläge...
Basic-Programm RTC.BAS
Zeile.......: 120 FOR i=1 TO 100:NEXT:WAIT &FBEE,128
Verbesserung: 120 WAIT &FBEE,128
Begründung..: LS3 muss sowieso warten bis zur Bereitmeldung (Port &FBEE = &80)
Zeile.......: 160 IF h<1 OR h>23 THEN 150
Verbesserung: 160 IF h<0 OR h>23 THEN 150
Begründung..: Zeit zwischen Mitternacht und 00:59 morgens
... bin am Löten... ein Batch von 6 ist schon ein Stück Arbbeit muss ich sagen... 2 weitere Abende und dann sollte ich am Donnerstag fertig sein.. also leichte Verzögerung.
Kein Stress und alles nur in Ruhe :smiley027:
Der Lötkolben ist noch heiß, aber so langsam wird er kühler...
Test-Session morgen, Versand (wenn alles gut geht) am Freitag oder nächster Montag.
Die Welt wird nie wieder die selbe sein. :flehan:
Quote from: TFM on 09. May 2019, 17:30:47
Die Welt wird nie wieder die selbe sein. :flehan:
Sind nun in der Post.
New York - Frankfurt: 1 Tag
Frankfurt - München: 7 Tage
ENDLICH sind die heute angekommen, und zwei schon in der Post zum Rennert und Bryce...
Hier ein Bild der hypnotisierenden Lichter. Der Effekt kommt aber im Foto nicht rüber. Für war waren die alle noch gleich? Glaube Michael hat das schon mal irgendwo geschrieben...
LambdaSpeak III rocks!!!
das klingt ja super ;D
womit haste es versandt? Muss wissen, welchen Postboten ich auflauern muss
Ähm... Postamt, ganz normal...
Hier der
Cylon Mode
des LambdaSpeak III:
[CPCEmulator]https://youtu.be/zmBOmZLTOAk[/CPCEmulator]
In echt sieht das besser aus, aber meine Kamera nimmt das hald so auf. :zunge0020:
OK,
|cylon
und
|knightrider
also. :D
Soll ich es einbauen? :irre:
Nett wäre natürlich ne Kombi aus PCM Sample Playing und Cylon - also sowas we "Destroy all humans" alle 3 Sekunden, und Cylon light :irre:
Das sollte eigentlich gehen, da im EEPROM PCM Sample Play Mode die Play Sample Commands sehr spezielles Format haben
(8 bytes - sowas wie 0 <channel> 0 <start page> 0 <länge> 0 <sample play speed>) - alle anderen Bytes die an &fbee gesendet werden und nicht in dieser Sequenz kommen, sollten nur dazu führen, dass die LEDs geändert werden und werden vom Modus ignoriert. Wenn die 8 Play Sample Command Bytes schnell genug gesendet werden, führt das auch nur zu einer kleinen "Unterbrechung / Flackern" im Cylon Light.
In welchem Modus machst Du Cylon? Echo Test Program modus? Also mal probieren, ob das auch im PCM Play EEPROM modus funktioniert.
Und hoffentlich lassen sich auch die Sprach-Bestätigungen abschalten ("Send Page number, number of pages, ...") in den EEPROM Upload / Play modi, ich habe das leider nie gestestet. Zur Not Firmware update :zunge0020:
Insbesondere bin ich gespannt, wie lange / wie schnell Du einen WAV hochladen kannst (zunächst muss natürlich "Destroy all Humans" hochgeladen werden, dann Cylon light und Play EEPROM Sample Commands).
Hab heute schon mal angefangen RSXe zu machen. Cylon als RSX wäre zu aufwendig, da müsste man einen Interrupt ins AMS-OS einhängen, aber ein keines BASIC Proggy tut es ja auch. Na eines nach dem anderem. So ganz schlau werde ich aus einigen Sachen noch nicht, bin jetzt beim testen. In ASM ist das hald wieder anders als in BASIC, da das mit dem Status abfragen einfach sein muss. :) Mal sehen ob ich bin Anfang der Woche was gebacken bekomme. :)
Nur kein Stress, gut Ding will Weile haben! :smiley027:
Mein LS3 ist heute auch gekommen, funktioniert soweit alles. hab gleich mal die RTC gestellt. MP3 will ich mal testen.
@TFM: wie startest du den Cylon Mode? hast sicher ein Prog geschrieben.
MP3 geht auch, vielleicht könnte man noch einbauen, das der nächste Song abgespielt wird, wenn der aktuelle zuende ist. und eine Ordnerauswahl. In der Beschreibung zum Modul steht ja, das man Ordner anlegen soll mit 01, 02 usw.
Wo sitzt denn genau der Temperatursensor? die Temperatur ist sehr hoch, da strahlt die Wärme vom Modul bissel ab ;)
Wenn ich RTC ne Weile laufen lasse, verschiebt sich das Zeitbild nach links und irgendwann kommt nen Out of Range.
Upps... Zeitbild verschiebt sich nach links?? Wie ist das denn möglich?
Hmm, ja das ist interessant... ist das reproduzierbar der Fall, in jedem Slot? Stromversorgung etc.? Bustreiber? Solche Sachen habe ich nicht....
Das ist am KC Compact, richtig? Hast Du die letzte Version der LS300 dsk from Github Repository genommen?
Der Temperatursensor ist im Uhrmodul.... das gibt sich evtl. nach einiger Laufzeit. Der muss sich nämlich erst etwas kalibrieren. Ich hatte das zunächst auch dass der 80 Grad oder so war, und nach ein paar Minuten Luafzeit ist die Temperatur normal. Evtl. ist die Puffer-Batterie nicht gut.
Das könnte evtl. auch nur das BASIC-Programm und die Kommunikation mit LS betreffen. Kannst Du mal laufen lassen und einfach nur out &fbee,&DD verwenden. Wenn das die Zeit immer richtig sagt, ist es intern eigentlich i.O. Das gleiche für Datum, out &fbee,&dc
Diese kleinen BASIC-Programme sind all nur Proof of Concept... ach ja, und TFM hatte auch einen Patch gepostet für das Program, betreffend die Lese-ROutine. Ich glaube, das Betraf eine Warteschleife und folgendes WAIT command. Evtl. mal etwas mit der Schleifenlänge spielen, oder ganz weglassen, oder oder oder....
Hintergrund ist - man sendet ein Kommando wie "get hours" oder "get minutes", und LS legt dann für eine gewisse Zeit das Zeit-Byte auf den Port. Man muss also den richtigen Momentan "abpassen", um zu pollen. Ich habe das mittels "
void cpc_input_8bit(uint8_t byte) {
DATA_TO_CPC(byte);
z80_run;
CPC_READ_DELAY;
DATA_TO_CPC(255);
CPC_READ_DELAY;
DATA_TO_CPC(0);
}
synchronisiert. Es erscheint zunöchst also "byte" (also die Stunden, Minuten, ...) auf dem Datenbus. Das kann ja leider auch 0 sein!
Man sollte also den Port nach "get hours" command so lange lesen, bis man 255 liest. Dann ist man sicher, dass man das "richtige" Byte gelesen hat - das Byte direkt vor 255. Danach kann man dann auf den Übergang 255 -> 0 warten.
Wie gesagt, das Timinig macht es etwas kritisdch für BASIC. TFM hatte die Warteschleife vor dem WAIT moniert, aber ich glaube, sogar dafür hatte ich einen Grund.
Ich denke also, dass es nur ein BASIC Problem ist.
Und, by the way, CPC READ DELAY:
#define CPC_READ_DELAY FAST_CPC_GETTERS ? _delay_us(50) : _delay_ms(10)
Evtl. also mal Port-Kommunikation auf "SLOW GETTERS" umstellen.
Ja KC Compact, habe das letzte Dsk von Github.
Werde das Modul mal weiter vorne platzieren, ist grad das letzte im Glied.
Ja, die Warteschleife-Unterroutine hat einen Grund ... prüft Space bzw. D für Datum. Ist wohl ein BASIC Fehler irgendwo ein Überlauf oder so.
Das Programm ist ja auch nur eine Demo, die darf jeder nach Herzenslust umschreiben und erweitern und wie auch immer. :)
Die Zeit wird richtig angesagt. Bei der Zeit sind nach kurzer Zeit die Sekunden vierstellig, aber die vorderen Zahlen der Sekunden laufen normal weiter. Beim Datum kommt das dann auch später.
Hab das Modul mal weit vorne gesteckt, mal schauen ob das Out of Range in 850 noch kommt. Die komische Anzeige kommt trotzdem noch.
Out of range kann ja nur vom Wochentag kommen denke ich.
Das Out of Range in 850 kam immernoch.
Habe mal die Zeile 850 gelöscht und kam nicht wieder. Ist die Zeile wo der Wochentag angezeigt wird.
Welchen wert hat denn weekday wenn es knallt?
Na Samstag, also 6.
Wegen den doppelten Zeichen am Ende: habe mal bei Zeile 810, 830, 850, 870 jeweils ein ;:PRINT" " angehängt, da kommen erstmal keine doppelten Sekunden usw.
Mal sehen ob auch das Out of Range weg ist.
Na 1 bis 7 sollte aber keinen out of Ränge produzieren...
Also bisher keine doppelten Zeichen am Ende der Zeilen, Die 4 eingefügten Leerzeichen haben geholfen.
Out of Range in Zeile 850 ist auch weg mithilfe der 4 Leerzeichen. lasse das aber mal ne Stunde laufen.
Habs mal angehangen. RTC1.BAS ist jetzt meine Version.
Noch ne Frage, wie kann man das programmieren, das einstellige Zeitwerte und Kalenderwerte mit einer Vornull angezeigt werden?
Out of range in 850 kam trotzdem wieder nach einiger Zeit.
Nun habe ich mal das Listing angeschaut, in zeile 400 wird der Wochentag als Variable d festgelegt. In Zeile 790 und 850 wird dann wd angegeben. habe das mal in 790 und 850 auf d gesetzt und teste grad.
Probiere mal in das original RTC.BAS in Zeile 125 folgendes:
125 out &fbee,&e4
"Slow getters"
... und wenn das nicht klappt, versuche mal jedes
var = inp(&fbee)
zu verdoppeln, also einfach 2x lesen:
dt = inp(&fbee)
dt = inp(&fbee)
Das funktioniert bei mir auch noch.
Und das für alle Zuweisungen, also h, m, s etc.
Evtl. ist der KC Compact etwas schneller als der CPC beim Lesen?
Wer weiss.
Werde mal testen.
Allerdings haut es hin, wenn ich Zeile 850 deaktiviere.
Würde trotzdem gerne wissen, ob es mit den Variablen in Zeite 400, 790 und 850 so richtig ist. Also in 400 mit d festgelegt und dann als wd.
@LambdaMikel:
Deine Tips haben nicht geholfen, bei slow getters kommt Out of Range bissel später, so nach knapp ner Stunde. Deaktiviere ich Zeile 850, da läufts jetzt schon über 2 Stunden.
Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.
Bei mir versagt die Statistik ;D
Kommt jedesmal nach längerem Betrieb. 30-50 Minuten geht's.
Ich lasse die Zeile 850 jetzt deaktiviert, den Wochentag brauch ich nicht unbedingt.
Wenn es nur darum geht die Uhrzeit zu sehen, dann hab ich hier ein FutureOS Update (gerade frisch aus dem Ofen). Bitte mal angucken und bescheid sagen wenn was nicht tut oder fehlt. Viel Spaß damit. :)
Quote from: Rennert on 26. May 2019, 09:53:34
Würde trotzdem gerne wissen, ob es mit den Variablen in Zeite 400, 790 und 850 so richtig ist. Also in 400 mit d festgelegt und dann als wd.
Ja, das ist ok... d wird ja nur zum Setzen verwendet. wd wird eingelesen, ist also egal. Variablen brauch man in BASIC nicht zu deklarieren.
Quote from: TFM on 26. May 2019, 15:38:07
Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.
Genau, wir würden gerne den Wert von wd wissen, wenn out of range kommt.... 1 bis 7 kann es ja nicht sein, sonst würde es kein Out of Range geben. Ist muss also etwas > 7 sein.
Quote from: Rennert on 26. May 2019, 14:30:57
@LambdaMikel:
Deine Tips haben nicht geholfen, bei slow getters kommt Out of Range bissel später, so nach knapp ner Stunde. Deaktiviere ich Zeile 850, da läufts jetzt schon über 2 Stunden.
Und hast Du mal versucht, doppelt zu lesen, also wd = inp(&fbee): wd = inp(&fbee)?
Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...
@Rennert, Hier ist noch einmal ein Test:
5 out &fbee,&C5
10 a=round(rnd(1)*255)
20 out &fbee,a
30 b=inp(&fbee)
40 if a<>b then print "*";
50 goto 10
Kannst Du das bitte einmal für ne Stunde laufen lassen und gucken, ob irgendwelche "*" auf dem Schirm erscheinen.
Quote from: TFM on 26. May 2019, 15:38:07
Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.
Hast Du den Effekt auch beobachtet, TFM?
Ich muss gestehen dass ich die BASIC-Uhr nie länger also 20 Minuten an hatte... evtl. muss ich etwas länger warten, wenn ich das Resultat per I2C abhole von der RTC:
void ds3231_get(void) {
twi_start();
twi_send(0xD0);
twi_send(0x00);
twi_start();
twi_send(0xD1);//ds3231 address+1 to read
rtc_seconds = twi_receive(1);//1 to send ACK
rtc_minutes = twi_receive(1);//1 to send ACK
rtc_hours = twi_receive(1);//0 to send NACK
rtc_hours &= 0b01111111;
rtc_weekday = twi_receive(1);//1 to send ACK,read day
rtc_date = twi_receive(1);//1 to send ACK,read date
rtc_month = twi_receive(1);//1 to send ACK,read month
rtc_year = twi_receive(0);//0 to send NACK,read year
twi_stop();
twi_start();
twi_send(0xD0);
twi_send(0x11);
twi_start();
twi_send(0xD1);//ds3231 address+1 to read
rtc_msb_temp = twi_receive(0);
twi_stop();
rtc_hours_dec = BCDtoDEC(rtc_hours);
rtc_mins_dec = BCDtoDEC(rtc_minutes);
rtc_secs_dec = BCDtoDEC(rtc_seconds);
rtc_year_dec = BCDtoDEC(rtc_year);
rtc_month_dec = BCDtoDEC(rtc_month);
rtc_date_dec = BCDtoDEC(rtc_date);
rtc_weekday_dec = BCDtoDEC(rtc_weekday);
}
EVtl. brauche ich ein paar Delays... hier und dort.
Falls es nicht die CPC-Kommunikation ist, muss es die Leseroutine oben sein. Ich werde mal ein Testprogramm schreiben und laufen lassen auf dem ATmega, dass immer wieder die Zeit liest, und wenn was anderes für Wochentag für 1...7 kommt, weiss ich woran es liegt. Und kann entsp. Delays einbauen. Falls es das ist...
Aber zunächst bitte einmal die Port-Kommunikation mit dem KC Compact testen, mittels BASIC-Program oben. (&C5 mode).
Quote from: LambdaMikel on 26. May 2019, 17:33:41
@Rennert, Hier ist noch einmal ein Test:
5 out &fbee,&C5
10 a=round(rnd(1)*255)
20 out &fbee,a
30 b=inp(&fbee)
40 if a<>b then print "*";
50 goto 10
Kannst Du das bitte einmal für ne Stunde laufen lassen und gucken, ob irgendwelche "*" auf dem Schirm erscheinen.
hab das mal über eine Stunde laufen lassen, du bekommst 0 Sterne!!!!
im RTC Prog hab ich mal eine Zeile eingefügt zum Test
845 if wd<1 or wd>7 then print"wd-error";wd:goto860
mal sehen was kommt.
0 Sterne ist schon Mal gut dass zeigt dass die Kommunikation prinzipiell I.O. ist. Der Rest kann durch Software Firmware etc. Korrigiert werden.
Cylon... in BASIC...
Quote from: LambdaMikel on 26. May 2019, 17:28:30
Quote from: TFM on 26. May 2019, 15:38:07
Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.
Genau, wir würden gerne den Wert von wd wissen, wenn out of range kommt.... 1 bis 7 kann es ja nicht sein, sonst würde es kein Out of Range geben. Ist muss also etwas > 7 sein.
Es ist &FF, das kommt kurz noch dem "zur Verfügung stellen" eines Wertes vor. In dem Falle einfach nochmal lesen.
Quote from: LambdaMikel on 26. May 2019, 17:31:53
Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...
Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))
Quote from: TFM on 26. May 2019, 20:31:23
Quote from: LambdaMikel on 26. May 2019, 17:31:53
Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...
Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))
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.
In LS 1.95 und LS 1.99 war die slow getters Zeit glaube ich sogar 100 ms, nun sind es nur 10 ms, da ich dachte, das richt selbst für BASIC immer.
Falls es alledings os ist, dass ERST 255, dann der Wert, dann wieder 255, dann 0 gelesen wird, dann liest der CPC evtl. "zu schnell".
Für den Fall, das CPC "zu schnell" liest, kann man ja einfach noch einmal lesen, und sogar ohne Command:
also entweder reicht wie gesagt
dt = inp(&fbee)
dt = inp(&fbee)
schon, oder sowas wie
10 dt = inp(&fbee): if dt = 255 then goto 10
Mit dem doppelten Abfragen hatte ich probiert, aber hat nix geändert.
Bei Zeit und Datum gibt's ja keine Probleme, da muss nix doppelt abgefragt werden. Nur der Wochentag zickt.
So mein kleiner Test hat ergeben: siehe Foto
Habe wenn wd<1 oder >7 ist, dann das Prog beenden lassen und die gelesene Zahl anzeigen lassen.
Also 128... interessant.
Gut, probiere mal mittels
<zeile> wd= inp(&fbee): if wd = 128 then goto <zeile>
EDIT: Frage mich, ob das evtl. mit Garbage Collection etc. zu tun hat. Ich meine die Zeitverzögerungen.
Um das auszuschließen, dass das BASIC da kurzzeitig hängt, wäre es mal interessant, die Reihenfolge der Lese-Kommandos zu ändern. Also als erstes Wochentag, dann die anderen. Kommt dann evtl. der Lesefehler wieder beim letzten Lese-Kommando (Jahr oder so?)
Das spräche für die BASIC ist Schuld-Hypothese.
Quote from: TFM on 26. May 2019, 20:31:23
Quote from: LambdaMikel on 26. May 2019, 17:31:53
Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...
Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))
Prinzipiell könnte man natürlich die Hardware so auslegen, dass der LS mittels IOREQ & READ (also INP(&FBEE)) synchronisiert, dann wüsste LS, wenn der CPC gelesen hat. Würde aber andere Hardware erfordern.
Allerdings würde LS dann auch "hängen", wenn der CPC mal ein Byte nicht in dieser Weise "abholt". So ist es also asynchron und timing ist etwas kritisch. Synchron mit "Handshake" hätte sicherlich auch Vorteile.
Müsste ich nochmal testen, obs wieder 128 ist.
Werde morgen mal Jahr mit Wochentag tauschen.
Hier ist mal eine Version mit der "if x = 128 then goto ..." Variante (RTC2.BAS)
Quote from: TFM on 26. May 2019, 17:09:07
Wenn es nur darum geht die Uhrzeit zu sehen, dann hab ich hier ein FutureOS Update (gerade frisch aus dem Ofen). Bitte mal angucken und bescheid sagen wenn was nicht tut oder fehlt. Viel Spaß damit. :)
Hi TFM,
habe ich mit 6128 und M4 mit Installer installiert in Standard-ROM-Positionen.
Rom slot 10 ROM RemoveUpload
Rom slot 11 RemoveUpload
Rom slot 12 RemoveUpload
Rom slot 13 RemoveUpload
Rom slot 14 RemoveUpload
Rom slot 15 RemoveUpload
Rom slot 16 ROM RemoveUpload
Rom slot 17 ROM RemoveUpload
Rom slot 18 ROM
|OS geht auch, und meldet auf das LS ROM - hatte alle anderen ROMs gelöscht btw. Also "firsches" M4.
Wie kann ich denn die Uhrzeit sehen damit?
Das Datum wird angezeigt, das kommt aber glaube ich vom M4... und die Uhrzeit started bei 0:0:0.
Sehe, dass das LS ROM da auch mit dabei ist??
EDIT - BZD Fehler für LS ROM... irgendwie kriege ich das gerade nicht deinstalliert mit dem M4 Browser. Zeigt keine ROMs, aber ist immer noch drin. Wie resette ich mein M4 Komplett???
OK, |lshelp zeigt das "LS ROM" in ROM 5 ist. Der Webbrowser vom M4 zeigt es aber als unbelegt an.
Weiss jemand, wie ich ein ROM per RSX aus dem M4 löschen kann?
EDIT - ah ok, M4 brauchte ein Reset... jetzt ist es weg. OK, noch mal mit neuem FOS installer versuchen...
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.
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.
Man kann ja fix mit lM4ROMOFF das Teil deaktivieren und so Drumload laden
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?
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.
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 :zunge0020:
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.
Quote from: Rennert on 27. May 2019, 13:13:15
Man kann ja fix mit lM4ROMOFF das Teil deaktivieren und so Drumload laden
Oh gut, dass wusste ich noch gar nicht...
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.
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 :bgdev:
:zunge0020: :smiley027:
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 :)
oh, du warst an der entwicklung bei robotron irgendwie beteiligt? :smiley027:
Quote from: LambdaMikel on 26. May 2019, 21:22:29
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.
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. :)
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).
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).
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.
Quote from: LambdaMikel on 27. May 2019, 17:38:08
oder, noch besser:
4. warten bis TFM seine |gettime RSX fertig hat :bgdev:
:zunge0020: :smiley027:
Ja, ja, übermorgen oder so. :zunge0020:
hab mal dir RTC.BAS bissel angepasst, im Fehlerfall beim Wochentag initialisiert er neu und geht weiter dann.
könnt ja mal reinschauen. Zeile 790 und ab Zeile 950. in 540 habe ich mir ein CLS gesetzt, dann sehe ich die Uhrenstellabfrage nicht mehr.
Quote from: LambdaMikel on 27. May 2019, 17:50:03
oh, du warst an der entwicklung bei robotron irgendwie beteiligt? :smiley027:
Nein, habe aber als Jugendlicher bissel programmiert im Basic am DDR Computer.
Quote from: Rennert on 27. May 2019, 18:47:41
hab mal dir RTC.BAS bissel angepasst, im Fehlerfall beim Wochentag initialisiert er neu und geht weiter dann.
könnt ja mal reinschauen. Zeile 790 und ab Zeile 950. in 540 habe ich mir ein CLS gesetzt, dann sehe ich die Uhrenstellabfrage nicht mehr.
Wenn's für Dich funktioniert, super!
Besser wäre als DSK, BAS ist nicht ASCII kodiert... wie lädst Du dass direkt? Mit Emulator? Oder auf M4?
Na ja, kann ja selbst ne DSK erstellen... never mind.
Upps vergessen wieder als Dsk.
In 790 muss am Ende noch ein :goto 860, sonst gibt's in 850 noch den Fehler.
Es funktioniert, aber Goto 880 ist besser.
Quote from: TFM on 27. May 2019, 17:58:04
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. :)
Update hat geklappt:
M4 Firmware version 2.0.5B6
ESP firmware v2.0.5B6 found.
ESP flash: 0x00EF4016
ESP CRC match: 0xD5B92827
Programming...
ESP programming success
Jetzt klappt es mit dem Wifi wieder in 5 Sekunden.
Hatte sich wohl intern irgendwas zerschossen.
Danke für den Tipp!
Ist das die neuste FW? Habe ich von hier ausm M4 Thread.
Vergesse immer, dass ich ja auch ein XMem habe!
Super - damit funktioniert's!! RTC vom LS3 in FOS, wer hätte das gedacht. Cool!! :flehan: :smiley027: :jubelaola:
... wo ich gerade dabei bin - wie kriege ich jetzt Joan Landor als Background Image für FOS? Das ROM hatte ich ja heruntergeladen.
Bitte noch mal kurz erläutern, TFM.
2.0.5B11 ist die letzte FW fürs M4, poste ich dann zuhause. Mit dem Hntergrund kann ich dir dann auch später sagen oder du guckst in den FOS Thread Hintergrundbilder, da steht das auch.
so hier mein Paket, hab Cylon.bas mit dazu und das RTC in Englisch und Deutsch. wenn der Wochentag mal falsch ausgelesen wird, dann wird das neu initialisiert und neu gestartet.
für LambaMikel noch die neue Firmware fürs M4.
Und noch TFMs Worte zum Hintergrundstart:
Hier mal ein schnelles HinterGrundBild ROM mit Joan (Autostart).
Das HGB ROM bitte an Position 14 installieren. FutureOS muss auf 10-13 sein. Wenn nicht, dann ROM mit dem ROManager installieren, der passt die Nummern an.
ach Mist kleiner Fehlerteufel, leider ist die Zeit zum Ändern von beiträgen so kurz.
Quote from: LambdaMikel on 28. May 2019, 02:25:27
Update hat geklappt:
M4 Firmware version 2.0.5B6
Ist das die neuste FW? Habe ich von hier ausm M4 Thread.
Neueste Firmware angehängt... (siehe M4 Homepage)...
Quote from: LambdaMikel on 28. May 2019, 05:31:30
... wo ich gerade dabei bin - wie kriege ich jetzt Joan Landor als Background Image für FOS? Das ROM hatte ich ja heruntergeladen.
Bitte noch mal kurz erläutern, TFM.
Das ROM einfach mit dem ROManager installieren, der passt dann alle im ROM kodierten Vektoren an. :)
Hier der aktuelle ROManager...
Zurück zum Thema... heute Abend soll mein LS3 ROM PCM Samples hochladen und spielen können, drückt mir die Daumen. :whip2:
EDIT: So weit so gut, einiges geht, anderes nicht, manches fehlt...
Super gut! Wird heute Abend getestet.
kannst mir auch gerne zum Test senden
... dass müsste TFM bitte selbst machen, weiß nicht ob es ihm recht ist wenn ich die unfertige Version hier anhänge.
Meinte ja TFM, hab vergessen es hinzuschreiben ;D
Gebt mir noch ein paar Tage Zeit, bin zwar gerade im Stress, aber die erste Version die halbwegs gut tut stelle ich dann gleich hier rein. :)
Ansonsten kann mein Zeugs bitte immer gerne weitergegeben werden. Ob es sich schon lohnt sei dahingestellt :)
Quote from: Rennert on 28. May 2019, 13:25:42
so hier mein Paket, hab Cylon.bas mit dazu und das RTC in Englisch und Deutsch. wenn der Wochentag mal falsch ausgelesen wird, dann wird das neu initialisiert und neu gestartet.
für LambaMikel noch die neue Firmware fürs M4.
Und noch TFMs Worte zum Hintergrundstart:
Hier mal ein schnelles HinterGrundBild ROM mit Joan (Autostart).
Das HGB ROM bitte an Position 14 installieren. FutureOS muss auf 10-13 sein. Wenn nicht, dann ROM mit dem ROManager installieren, der passt die Nummern an.
Danke, hat geklappt! Habe endlich Joan :love:
Ok Freunde, hier mal was ich bisher habe...
!PCMUP tut immer noch nicht. Läd zwar ins EEPROM rein, aber danach geht nix mehr. Also LS3 resettieren. Kann es daran liegen, dass die Übergebene Page-Anzahl immer eins höher ist als man angibt?
Hier ist das ROM und die Disk... einige Kommandos schalten die "conformations" aus, mit !CONFON kann man die wieder einschalten.
!PCMMODE gibt immer die Meldung des LS3 aus. Das kann man wohl nicht abschalten. Ist keine Kriitik, nur was ich so höre. :)
!LSHELP zeigt die Befehlen an.
Der Rest... naja, probierts mal aus und sagt mir wo es Probleme gibt. Anregungen sind auch willkommen - ist doch klar :)
Quote from: TFM on 31. May 2019, 17:30:57
Ok Freunde, hier mal was ich bisher habe...
!PCMUP tut immer noch nicht. Läd zwar ins EEPROM rein, aber danach geht nix mehr. Also LS3 resettieren. Kann es daran liegen, dass die Übergebene Page-Anzahl immer eins höher ist als man angibt?
Gut moeglich, dass da irgendwo ein +1 Page Numbers oder ae. erforderlich ist. Bitte noch einmal genau die Parameter und Bytes von drumload.bas (BASIC-Hochlader) anschaun. Wenn er RESET braucht um aus dem PCMUP rauszukommen, wartet er noch auf Bytes. Der MOdus wird automatisch verlassen, wenn alle "versprochenen" PCM BYtes angekommen sind, sonst wartet er eben bis das der Fall ist.
Ausserdem sollte er dann "Testing", 5x den PCM Sound, und dann "Done Testing" sagen. TUt er das nicht, wartet er noch.
Quote from: TFM on 31. May 2019, 17:30:57
!PCMMODE gibt immer die Meldung des LS3 aus. Das kann man wohl nicht abschalten. Ist keine Kriitik, nur was ich so höre. :)
Was ist PCMMODE? Welche MEldung?
Quote from: LambdaMikel on 31. May 2019, 18:50:03
Quote from: TFM on 31. May 2019, 17:30:57
!PCMMODE gibt immer die Meldung des LS3 aus. Das kann man wohl nicht abschalten. Ist keine Kriitik, nur was ich so höre. :)
Was ist PCMMODE? Welche Meldung?
Die akustische Meldung. Ist super zum Testen und wenn man "per Hand" arbeitet. Aber für eine Applikation wäre es schön, wenn man die akustische Meldung auch mit "Confirmations OFF" still schalten könnte.
Page-Anzahl Problem gelöst... Timing noch nicht
Quote from: LambdaMikel on 31. May 2019, 18:48:05
Ausserdem sollte er dann "Testing", 5x den PCM Sound, und dann "Done Testing" sagen. TUt er das nicht, wartet er noch.
Bin gerade dabei zum testen wie lange man warten muss zwischen dem Senden von Daten-Bytes beim !PCMUP. Es scheinen mehr als 50 us zu sein. Bisher ist es so dass von 512 Bytes so ca. 45-50 verloren gehen, also ist der CPC noch etwas zu schnell. Nun ja so ein EEPROM muss ja schließlich auch gebrannt werden... so im Vorbeigehen. :)
Sollte ich das hinbekommen, dann muss ich mir nur noch den MP3 Player ansehen. Die Temperatur lesen kann er schon. Und dann haben wir die Grundfunktionen. Auf denen bauen wir auf :-)
Quote from: TFM on 01. June 2019, 16:24:01
Page-Anzahl Problem gelöst... Timing noch nicht
Quote from: LambdaMikel on 31. May 2019, 18:48:05
Ausserdem sollte er dann "Testing", 5x den PCM Sound, und dann "Done Testing" sagen. TUt er das nicht, wartet er noch.
Bin gerade dabei zum testen wie lange man warten muss zwischen dem Senden von Daten-Bytes beim !PCMUP. Es scheinen mehr als 50 us zu sein. Bisher ist es so dass von 512 Bytes so ca. 45-50 verloren gehen, also ist der CPC noch etwas zu schnell. Nun ja so ein EEPROM muss ja schließlich auch gebrannt werden... so im Vorbeigehen. :)
Sollte ich das hinbekommen, dann muss ich mir nur noch den MP3 Player ansehen. Die Temperatur lesen kann er schon. Und dann haben wir die Grundfunktionen. Auf denen bauen wir auf :-)
Okay, jetzt verstehe ich mit der Bestätigung... können wir in der nächsten Version ausbauen.
Ich weiß leider nicht, was die theoretische Grenze ist. Ich glaube, da ist nur minimale Warte-Verzögerung in LS3 Receiver-Schleife. Können wir evtl, noch versuchen, das auch noch zu beschleunigen. Übernächste Woche dann.
Ja, bin auch in ein paar Tagen verschwunden. Lassen wir die User allein und genießen unseren Urlaub, mit den Einnahmen vom LS3. :zunge0020:
Macht doch :zunge0020:
Aber vorher gib mir mal ein Beispiel für gettemp, also wie die Variable dahinter richtig zu setzen ist.
Das ist ein Tippfehler... natürlich t anstatt v am Ende ;)
Update von heute. Geht alles außer pcmup, da bin ich noch dran...
Quote from: TFM on 01. June 2019, 17:02:54
Ja, bin auch in ein paar Tagen verschwunden. Lassen wir die User allein und genießen unseren Urlaub, mit den Einnahmen vom LS3. :zunge0020:
Genau las Vegas und Casino weiss gar nicht wohin mm it der ganzen Kohle. Da heissst es halt zocken und Party. ,,
So, liebe Leute hier mein letztes Update vor meinem Urlaub im Jahre 1917. Jetzt solle _SOLLTE_ alles funktionieren. Aber ich hab's noch nicht getestet. Viel Spass.
Software zum famosen LambdaSpeak III ab jetzt wieder auf meiner Homepage. Siehe Link da unten. Viel Spass!
Schönen Urlaub ;D
Schoenen Urlaub!!!
Super Sache... bin auch im Urlaub.
Kann's hier leider am Roulette-Tisch nicht testen, zu Hause dann. :)
Setzt auf Blau! :irre:
EDIT: Neues Update... mit erweiterter Dokumentation.
Hier das erste(?) LambdaSpeak III Review:
https://auamstrad.es/2019/05/review-del-nuevo-lambdaspeak-3/
Super, das |pcmup jetzt funzt! :jubelaola:
Allerdings ist es noch etwas langsam... ist das schon at MaxSpeed, oder hast Du noch ne Zeitverzögerung drinne?
Die Verzögerungen sind hardwarebedingt. Pro Byte hochladen braucht man weniger als 10 Mikrosekunden. Aber das EEPROM muss so eine Seite zuerst löschen, bevor sie neu beschrieben werden kann. Das dauert eben seine Zeit.
Hier einige Bilder vom LambdaSpeak_III auf der AmsDAP Basiskarte. der LS3 kann im Schacht 3 eingesteckt werden. Mit den anderen ist es nicht ganz so einfach. Ich werde ihn wohl auf Schacht 4 verwenden, da man dann am besten auf die Rückseite Zugriff hat. Allerdings muss ich da beim AmsDAP vorher noch ein Plastikohr abflachen (siehe Bilder).
Zusammenfassung: Es geht! :smiley027:
Quote from: TFM on 12. June 2019, 20:26:43
Die Verzögerungen sind hardwarebedingt. Pro Byte hochladen braucht man weniger als 10 Mikrosekunden. Aber das EEPROM muss so eine Seite zuerst löschen, bevor sie neu beschrieben werden kann. Das dauert eben seine Zeit.
Hmm ja, das nächste LS Firmware update kommt bestimmt ;)
Jupp, und für das bisherige hab ich ein ROM Update. Damit kann man jetzt auch toll mit MP3's spielen. Viel Spass! :)
... und an der "alternativen" Firmware arbeiten wir gerade etwas :bgdev:
Mache gerade einen Belastungstest... !MP3PLAYF,1 spielt bei mir seit Stunden den Captain Future Soundtrack (in Schleife). :00008351: Und das am CPC, ohne dass der sich groß anstrengen muss. Nun ja, er zeigt das Captain Future Video :00008351:
So, habe die Firmware (von heute!) installiert, läuft. Zur Installation hab ich auch ein kleines Handbuch geschrieben und in das Archiv vom LS3 ROM gestellt (auch das von heute).
Meine MP3 Befehle scheinen jetzt alle zu tun. Am Anfang sollte man aber einmal !MP3RES benutzen.
Viel Spaß! :winke0002:
ist die Firmware schon veröffentlicht?
Quote from: Rennert on 21. June 2019, 18:55:36
ist die Firmware schon veröffentlicht?
Hänge die neueste Version hier mal als Datei an (sonnst bei GitHub LambdaSpeak)...
Wie immer, Hammer das neue LS3 ROM vom @TFM ! :smiley027:
Da es so gut läuft ist die "alternative Firmware" nun die "offizielle" Firmware. Hänge mal die neuste Version an.
Änderungen:
- PCMUP is nun super schnell - seitenweises Schreiben (Faktor 512 oder so) :irre:
S. "DRUMLD2" auf MIDEFSEQ2.DSK. Alle Drums können nun in wenigen Sekunden hochgeladen und ins EEPROM gebrannt werden.
Das dauert voher 5 Minuten bzw. 15 Minuten (BASIC). Schön wäre natürlich jetzt ein |PCMUPFILE, sodass ich gleich Captain Future
128 KB in einem Rutsch aus ner Datei hochladen kann :) Wunschkonzert für's nächste LS3 ROM Update.... ;)
- READY und BUSY wird nun konsistent überall im seriellen Modus verwendet. Auch wenn Argumente von Seriellen Kommandos erwartet werden.
- Für alle seriellen Kommandos, die Werte liefern (z.B. Empfangs-Puffer auslesen, Byte für Byte), wird nun das altbekannt "Protokoll" zur LambdaSpeak 3 -> CPC Datenübermittlung verwendet:
1. sende Nutzbyte
2. warte (s. fast oder slow getters) - 50 us oder 10 ms
3. sende 0
4. warte (wie 2.)
5. dann 32 (READY) wenn bereits für nächstes Kommando.
Ich habe das "SERIAL.BAS" auf der LS300.DSK angepasst. Diese Protokoll kann man gut im Screenshot anbei sehen, wo Byte x eingelesen wird vom Seriellen Interface (aus dem Eingangs-Puffer). Dieses Byte aus dem Puffer wird mittles 255, 9 angefordert, und dann kann man sehen, wie die Schritte 1 bis 5 durchlaufen werden. S. Screenshot.
Für TFM ergibt sich dadurch keine Änderungen, da er noch keine Seriellen Kommandos implementiert hat, die Daten vom LS3 im Seriellen Modus lesen (wäre ja schön, wenn das MP3 Modul was senden würde, tut es ja aber leider nicht).
Ausserdem gibt es auf den MIDEFSEQ2.DSK nun "DRUMMER2.BAS", der ebenfalls |PCMPLAY verwendet.
Bitte beachten - das MP3 Modul sendet mir nix als Bestätigung!! Da hilft also nur warten und Kommandos nicht zu schnell hintereinander schicken damit nichts verschluckt wird. Wie TFM das schon richtig macht. Wie gesagt, ein READY vom LS3 heisst hier eben nicht, dass das MP3-Module ebenfalls READY ist. Ich weiß es eben nicht.
Ansonsten - die MP3 Funktionen funktionieren super! Tolle Sache, TFM.
Außerdem habe ich die Github Doku und Dateien dort alle aktualisiert und angepasst. Die DSK Images und Firmware haben gleichen Stand, wie hier angehängt.
https://github.com/lambdamikel/LambdaSpeak3
WoW! Super! Da geht's ja richtig vorwärts! :jubelaola:
Dann werde ich mich mal wieder ans RSX ROM setzen und da noch ein paar Ideen verwirklichen :)
Klar, lass Dich nicht aufhalten ;D
Frage / Idee...
Wenn man im seriellen Modus ist, dann meldet der LS3 ja &20 als Bereitschafts-Byte. Das ist auch so im Epson- und Dec Modus. Wie kann man wissen in welchem Modus man ist? (Die Frage kommt jetzt deswegen, weil manchmal der Ausstieg aus dem seriellen Modus nicht klappt).
Wenn es keinen sicheren Weg gibt, um festzustellen ob man im seriellen Modus ist, könnte man dann nicht z.B. &10 (anstatt &20) als Bereitschafts-Byte nutzen?
Den aktuelle Modus koenntest Du mittels &F2 auslesen, oder?
Allerdings habe ich das laenger nicht getestet.
EDIT - hmm, ne das geht nicht, da hast du Recht... denn das muesste ja also 255, &f2 gesendet werden im seriellen. OK, wir koennen das Bereitschaftsbyte gerne aendern! Mache ich in der naechsten Version.
Falls es NICHT geht um den seriellen Modus zu unterscheiden von den anderen, kann ich das gerne noch aendern.
Uebrigens - die typischen "get voice", "get volume", "get version" commands sind all 4-bittig... und zwar wird da auch noch eine Konvertierung "right shift um 4 Bits" gemacht, weil ich urspruenglich in LS 1.5 nur 4bit Ausgang hatte! D.h., "get version" is momentan 15, der LS 3 sendet das als 11110000 und RSX shiftet das um 4 nach rechts, damit wieder 00001111 = 15 zurueckkommt.
TFM, koennen wir das mal aendern? Dann koennte ich naemlich auch die Versionsnummer mal hochzaehlen, die momentan bei 15 "maximal" ist. Und ausserdem koennte "get mode" dann einen 8bit Deskriptor zurueckgeben. Das waere nett. Ich habe jetzt ja volle 8BIt als Ausgang. Also, die 4 RRAs einfach mal weg lassen in der naechsten Version.
Allerdings ist das nicht mehr abwaertskompatibel zur alten RSX, da diese wie gesagt das Bitshifting der oberen 4 Bits in die unteren 4 Bits macht.
... und hier ein interessantes neues UART Modul - Sprachsteuerung fuer den CPC:
[CPCEmulator]https://youtu.be/8cJCXA7OfCk[/CPCEmulator]
Habe ich mir mal bestellt.
Na Mist, wollte den AVR programmieren und habe gar keinen Programmer 8)
und keine Anschluß am Modul ;D Muss ich ne Fassung nehmen und dort die Drähte anlöten vom Diamex AVR Stick.
Falls Du nicht den
https://www.ebay.com/itm/New-High-Speed-Programmer-USB-TL866II-Plus-EPROM-EEPROM-FLASH-BIOS-AVR-AL-PIC/351525357292?
hast, kann ich
https://www.ebay.com/itm/AVR-ATMEGA16-Minimum-System-Board-ATmega32-USB-ISP-USBasp-Programmer-For-ATMEL/201622104604?hash=item2ef19d2a1c:g:TbEAAOSwG8ZcotYo
empfehlen... billiger wird's nicht (5 $). Nur der Quartz muss gegen 20mhz getauscht werden.
hab die Kabel ans LS1.99 gelötet und dann am Modul über meinen Diamex USB ISP Programmer geflasht.
werde mir aber mal noch für 5Dollar so ein Teil holen.
Gut, dass der ollle LS 1.99 noch für was gut ist! Als AVR-Programmer genutzt, wer hätte das gedacht!
+1 for MacGyver Award. :birthday:
Quote from: TFM on 24. June 2019, 19:30:21
Frage / Idee...
Wenn es keinen sicheren Weg gibt, um festzustellen ob man im seriellen Modus ist, könnte man dann nicht z.B. &10 (anstatt &20) als Bereitschafts-Byte nutzen?
OK, habe ich einmal ausprobiert - bitte testen. Es wird &10 als READY im seriellen Modus verwendet.
S. SERIAL2.BAS auf LS300.DSK.
Außerdem - ich gebe die Werte nun, wie besprochen, 8bittig aus, also bitte keinen rechtsshift mehr machen für |getvolume, |getversion etc. |getversion sollte jetzt 16 liefern. S. WELCOME2.BAS auf LS300.DSK. Einziger Unterschied zu WELCOME.BAS ist dass ich für Get Volume, Get Voice, nicht mehr durch 16 teile.
MP3 Befehle gehen mit dieser Version nicht mehr, da diese auf 32 warten, im Seriellen Modus mit der alternative Firmware aber 16 (&10) wie gewünscht ausgegeben wird.
Wenn es gut läuft, können wir das gerne offiziell so machen!
Frage - würdest Du auch gerne geänderte "READY" bzw. "WAITING FOR INPUT" für die anderen "Modi" haben, also z.B., wenn Parameter für das Setzen der Uhrzeit, das Hochladen der EEPROM Samples, |pcmplay bzw. |pcmup etc.? Auch hier wird ja 32 verwendet um anzuzeigen, dass das nächste Byte gesendet werden kann. Wir könnten das ebenfalls auf z.B. 8 oder 4 oder 2 oder 1 ändern. Ganz wie Du magst!
Prinizipiell könnte LS3 in diesen Modi natürlich ebenfalls "festhängen", und es reagiert in diesen Modi nicht auf Reset Command, sodass diese Modi nur verlassen werden können, wenn die geforderte Anzahl von Parametern gesendet wurde. Und da könnte es natürlich gut sein zu wissen, in welchem Modus man gerade ist indem man auf das READY Signal achtet. Allerdings wüsste man dann immer noch nicht, wie viele Bytes noch ausstehen bzw. gesendet werden müssen, damit der Modus verlassen wird. Insofern würde ich sagen, lassen wir's wie es ist (also Standardy READY Signal in diesen Siutation = 32).
Und für den seriellen Modus machen wir's so, wie Du vorgeschlagen hast, und wie in der alternative Firmware hier angehängt. Also &10.
:schonwieder ne neue FW? Hab doch gestern erst geflasht :)
Werde mir an der Rückseite des LS3 Stifte anlöten zum schnellen Programmieren.
Muss nicht immer der 644 raus aus der Fassung.
... also die alternative Firmware ist erstmal nur für TFM, der dann die RSX / ROM erst mal anpassen müsste... falls alles läuft können wir diese dann offiziell machen. So langsam pendelt es sich ein.
Gute Idee mit den Löt-Stiften!
Stifte sind dran ;)
Sag mal ist in der neuen Firmware die Sprachausgabe am Start entfernt?
Sonst kam immer LambdaSpeak initialized, SSA1 Mode
Quote from: LambdaMikel on 24. June 2019, 20:55:20
OK, wir koennen das Bereitschaftsbyte gerne aendern! Mache ich in der naechsten Version.
Sehr schön! Dann weiß die Applikation / der RSX ob (noch) der Serielle Modus an ist.
Quote from: LambdaMikel on 24. June 2019, 20:55:20
"get version" is momentan 15, der LS 3 sendet das als 11110000 und RSX shiftet das um 4 nach rechts, damit wieder 00001111 = 15 zurueckkommt.
TFM, koennen wir das mal aendern? Also, die 4 RRAs einfach mal weg lassen in der naechsten Version.
Alles klar, ich lass den 4x rechtsschieben weg, dann empfehle ich Dir aber auf die Version 16 zu gehen und nicht auf &x11110001, ok?
Klar mit der Kompatibilität ist es dann nix mehr, aber die Funktion wird doch bisher eh in keinem Programm oder was auch immer eingesetzt. Also gute Idee! :)
EDIT: Ok, hab's geändert. Um das zu unterscheiden hab ich den RSX auf !GETVER umbenannt (zuvor war es !GETVERSION). :zwinker0018:
Quote from: Rennert on 25. June 2019, 12:45:38
Sag mal ist in der neuen Firmware die Sprachausgabe am Start entfernt?
Ja, so ist der LS3 schneller einsatzbereit.
Quote from: LambdaMikel on 25. June 2019, 06:22:55
An sich würde es ja reichen das NUR mit !GETVER zu machen :-)
P.s.: Wäre super, wenn die Firmware auch immer ein Datum im Namen hätte. :flehan:
OK, let's make it so.
so programmieren funzt jetzt am Modul, stecke es aber vom CPC dabei ab. Der andere ATmega wird erstmal nicht mehr erkannt. Gab beim programmieren nen Error. Muss ich mal nen Quarz als Takt anschliessen, so hatte ich schonmal einen gerettet. aber hab nur 25MHz und das ist zuviel ohne Schaltung, bei AVR nimmt er nur 1,845MHz als höchstes 1/4 ISP Takt.
Quote from: Rennert on 25. June 2019, 15:38:51
so programmieren funzt jetzt am Modul, stecke es aber vom CPC dabei ab. Der andere ATmega wird erstmal nicht mehr erkannt. Gab beim programmieren nen Error. Muss ich mal nen Quarz als Takt anschliessen, so hatte ich schonmal einen gerettet. aber hab nur 25MHz und das ist zuviel ohne Schaltung, bei AVR nimmt er nur 1,845MHz als höchstes 1/4 ISP Takt.
Falls Du ihn ganz versemmelt hast, hilt der Fuse Doktor mit Elektroshock-Therapie:
https://www.ebay.de/itm/ATMEL-AVR-ATMEGA-ATTINY-Fuse-Repair-Programmer-Fuse-Doctor/222853553561?hash=item33e31b5d99:g:busAAOSwEfVcUG7O
Ich werde in der naechsten Firmware noch versuchen eine weitere neue Funktion unterzubringen:
das Auslesen vom EEPROM. Damit koennte man dann beliebige Daten bis zu 128 KBs speichern.
Und ins RAM kopieren mittels |eeprom2ram,<startpage>,<number of pages>, <cpcram start address>
Wie waere es mit |hibernate und |resume als Anwendungsfall fuer das EEPROM?
Ich jedenfalls wuerde es cool finden wenn ich im BASIC -Coden bin und einfach |HIBERNATE machen koennte und aus, und dann setze ich mich wieder ran und |RESUME. Dann muesste ich nicht rumfummeln mit DDI3 und so weiter.
Ach soviel ist der Atmega nicht wert ;D
Interessant.... naja, ein EEPROM könnte man sicherlich oft genug beschreiben. :)
Anbei das neueste ROM (fast ungetestet) für die Firmware die in wenigen Stunden rauskommt.
Quote from: TFM on 25. June 2019, 20:30:53
Interessant.... naja, ein EEPROM könnte man sicherlich oft genug beschreiben. :)
Anbei das neueste ROM (fast ungetestet) für die Firmware die in wenigen Stunden rauskommt.
Upps, da warst Du ja wieder schnelle als die Polizei erlaubt! :bgdev:
Klar, EEPROM ist robust, und selbst wenn es mal kaputt geht, kann man ja einfach fuer 5 EUR ein neues reinstecken.
Und gesockelt ist es ja auch... also her mit dem Firmware-Update, die Nacht hält nicht ewig. :zunge0020:
@TFM, hier ist die neuste "Beta (nicht offizielle) Version".
Neue Control Bytes:
#ifdef LS300
case 0xFE : eeprom_pcm_upload_mode(1); break;
case 0xFD : eeprom_pcm_play_mode(4); break;
case 0xFC : eeprom_pcm_play_mode(3); break;
case 0xFB : eeprom_pcm_play_mode(2); break;
case 0xFA : eeprom_pcm_play_mode(1); break;
case 0xF9 : eeprom_pcm_upload_mode(0); break;
case 0xF8 : eeprom_pcm_clear_all(); break;
case 0xF7 : eeprom_get_data(); break;
// case 0xF6 : eeprom_get_id(); break;
case 0xF5 : eeprom_full_check(); break;
case 0xF4 : non_blocking_confirmations(); break;
case 0xF3 : blocking_confirmations(); break;
case 0xF2 : get_full_mode(); break;
case 0xF1 : usart_mode_loop(); break;
#endif
Zum Daten-Upload gibt es jetzt F9 - das ist genauso wie FE, allerdings macht er kein "Now testing", da es sich ja nicht um einen PCM Sample handelt. Wäre also gut, wenn wir dafür |eepromupload hätten.
Zudem kann man dann genau EINE SEITE (512) Bytes auslesen, mittels F7.
Bitte einmal auf LS300.DSK EEPROM2.BAS ansehen, dann wird es klar. Es wird nur ein Argument übermittelt, die Start-Seite. Und die kann auch 0 sein. Beim Hochladen (|pcmup, |eepromup) kann Startseite ebenfalls 0 sein. Nur beim |pcmplay ist 0 nicht erlaubt als Start-Seite. Außerdem gibt es wie gesagt nur die Möglichkeit, 1 Seite pro F7 auszulesen. Für die nächste Seite muss man eben noch einmal F7 mit der nächsten Start-Seitennummer aufrufen. Seite für Seite.
|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).
Die Getversion ist wie gesagt 8bittig, und auch get-full-mode (F2). Alles andere wie gehabt 4bittig.
|pcmtest habe ich auch mal geändert, in etwas schöneres das auch noch weniger PROGMEM benötigt ;D
Gruß und bis bald
Michael
WoW! Da bist da ja nicht 24/7 sondern eher 36/9 dran! :jubelaola:
Wie ist denn &F2 (get full mode) aufgeschlüsselt? Welches Bit heißt was?
Quote from: TFM on 26. June 2019, 17:25:56
WoW! Da bist da ja nicht 24/7 sondern eher 36/9 dran! :jubelaola:
Wie ist denn &F2 (get full mode) aufgeschlüsselt? Welches Bit heißt was?
Kommt heute Abend, bin auf der Arbeit.
Mich interessiert natuerlich insbesondere, wie schnell Du 64 KBs mittels F7 auslesen kannst... schreiben wissen wir ja jetzt dass das in 3 bis 4 Sekunden geht.
Evtl. will ich mal nachsehen, ob ich nicht mehr als 1 Seite lesen kann. Sollte eigentlich auch machbar sein.
Fuer die naechste Version kannst Du davon ausgehen, dass F7 nicht nur Startseite, sondern auch Anzahl Seiten als Argument erwartet.
typedef enum { SSA1_M = 0, LAMBDA_EPSON_M = 1, LAMBDA_DECTALK_M = 2, DKTRONICS_M = 3, AMDRUM_M = 4, SSA1_SPO_M = 5, DKTRONICS_SPO_M = 6, EEPROM_PCM_UPLOAD_M = 7, EEPROM_PCM_PLAY_M = 8, SERIAL_M = 9, START_OVER_SAME_MODE = 10 } LS_MODE;
static volatile LS_MODE CUR_MODE = SSA1_M;
....
void get_full_mode(void) {
uint8_t bout = CUR_MODE; // 0 - 9 : 4 bits
bout |= BLOCKING << 4;
bout |= NON_BLOCK_CONFIRMATIONS << 5;
bout |= LANGUAGE << 6;
bout |= CONFIRM_COMMANDS << 7;
cpc_input("Current full mode ", bout, 0); // 8 bit
}
[code]
Quote from: LambdaMikel on 26. June 2019, 08:01:52
|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 :-)
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).
Quote from: LambdaMikel on 26. June 2019, 08:01:52
|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).
Quote from: LambdaMikel on 27. June 2019, 08:28:22
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? :00008351:
EDIT 3: u.U ist EDIT besser als EDIT2 ??? Bei 36 Grad kann man schlecht denken. :irre:
Quote from: LambdaMikel on 27. June 2019, 08:28:22
PCMUP und EEPROMUP sollten verschieden sein ( eeprom_pcm_upload_mode(1) vs. eprom_pcm_upload_mode(0) für PCM-Test des hochgeladenen Samples).
?????
Quote from: TFM on 27. June 2019, 15:22:17
Quote from: LambdaMikel on 27. June 2019, 08:28:22
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.
Quote from: TFM on 27. June 2019, 15:24:50
Quote from: LambdaMikel on 27. June 2019, 08:28:22
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.
Quote from: TFM on 27. June 2019, 15:10:43
Quote from: LambdaMikel on 26. June 2019, 08:01:52
|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 ;)
Quote from: TFM on 27. June 2019, 15:22:17
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.
Quote from: LambdaMikel on 27. June 2019, 16:01:55
Wie gesagt, aufgrund von Hardware-Beschränkungen geht es leider nicht anders.
Doch, bitte siehe editierter Post von mir oben :-)
Quote from: TFM on 27. June 2019, 16:37:21
Quote from: LambdaMikel on 27. June 2019, 16:01:55
Wie gesagt, aufgrund von Hardware-Beschränkungen geht es leider nicht anders.
Doch, bitte siehe editierter Post von mir oben :-)
OK, hast Recht ;D ;D 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.
Welche von den beiden Ideen hast denn jetzt genommen? :)
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!
Hier ist mal der Code für EDIT:
//
// 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]
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?
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!
Wie gesagt, nur bei letztem Seiten-Byte 0 oder 32 müsstest Du etwas vorsichtig sein...
S. Antworten oben. Bin jetzt erstmal arbeiten.
Na klar, Danke deweil :) Mal sehen ob ich das hinbekomme. :)
Quote from: TFM on 27. June 2019, 17:40:36
Na klar, Danke deweil :) Mal sehen ob ich das hinbekomme. :)
... habe da groesste Zuversicht - Du schaffst das schon :jubelaola: :smiley027:
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!!
Vielen Dank für deine Updates in Lichtgeschwindigkeit. :smiley027: 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... :)
... bin schon sehr gespannt, was Du wieder geniales ausheckst :bgdev:
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! :) :) :)
Quote from: TFM on 28. June 2019, 22:32:40
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.
Quote from: TFM on 28. June 2019, 22:32:40
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.
.. 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.
Cool! Danke! :00008351:
Wird gleich mal verwendet, gähn, und dann ab in die Kiste ;) :)
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 :jubelaola: :jubelaola: 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.
Hier noch ein kleiner Bug:
|getvolume, |getvoice etc. liefern alle "4". |getver funktioniert richtig.
... anbei eine Version mit kleiner Schönheitskorrektur (|eeup und |pcmup Sprachmeldungen gefielen mir nicht mehr). v21.
Zudem DSK images aufgeräumt.
Diese Firmware habe ich jetzt ersteinmal als "offiziell" deklariert, scheint ja alles zu laufen. S. Github.
@TFM, sollten wir in den CPC Boards Bescheid sagen dass neues FW Update jetzt lohnt?
Quote from: LambdaMikel on 29. June 2019, 05:41:26
HOWEVER, es kann den Bildschirmspeicher nicht restaurieren.
Stimmt, da die RSXe im ROM ausgeführt werden, kann man den Bildschirmsspeicher nicht auslesen. Wenn es also unbedingt sein muss, dann das V-RAM z.B. vom &C000 bis &FFFF nach &4000 kopieren, und dann sichern. Aber IMHO ist der Bildschirm ja nicht so wichtig. Oder?
Ansonsten: Klar AF', BC', SP und der Stack-Inhalt sind auch noch zum sichern (neben dem RAM). :)
Quote from: LambdaMikel on 29. June 2019, 06:34:50
Diese Firmware habe ich jetzt ersteinmal als "offiziell" deklariert, scheint ja alles zu laufen. S. Github.
@TFM, sollten wir in den CPC Boards Bescheid sagen dass neues FW Update jetzt lohnt?
Ich komme ja kaum noch mir dem brennen mit, muss diese erst mal installieren. Sicherlich sollten wir so ziemlich jetzt mal eine stabile Version anstreben (also nur noch debugging und keinen neuen Funktionen), da ja bald das Review stattfinden soll. Außer Du verschiebst das in die Zukunft.
Genau! Die Firmware ist jetzt erstmal final, wenn Du nicht noch was findest. Neue Funktionen fallen mir keine mehr ein :-)
Der Rest geht in's ROM... wie gesagt, Register sichern und Bildschirmspeicher bzw. den gesamt CPC Zustand per |hibernate and |resume würde ich super finden!
.... übrigens - ist das |ee easteregg von Dir ? :smiley027: oder ist das im xmem rom....
Den kleinen Bug report hattest Du gesehen?
|getvolume, |getvoice etc. liefern alle "4". |getver funktioniert richtig.
LG
Quote from: LambdaMikel on 29. June 2019, 21:13:57
|getvolume, |getvoice etc. liefern alle "4". |getver funktioniert richtig.
Da habe ich im ROM nichts geändert, wir wollten das ja zum LS 1-2 kompatibel halten. Oder hab ich was falsch verstanden?
Ja, interessanter Effekt! Nein, hast Du richtig verstanden... und sollte auch funktionieren.
Es scheint ein Timinig-Problem zu sein? Es sollte der gleiche Wert wie bisher rauskommen, also 16 * <wert>.
Für get Volume default = 13: 13 * 16 = 208. Das kommt auch raus, wenn man BASIC macht. Oder erwartest Du dass die unteren 4 Bit gesetzt sind? S. auch WELCOME.BAS. Die Werte werden zur Ausgabe durch 16 geteitl ("Current Volume 13" -> 208 / 16 = 13 wird angezeigt). Strange!
Habe das LS3 ROM gerade mit LS 1.95 getestet - da kommt der richtige Wert zurück!
Das einzige was ich mir vorstellen kann - der Wert erscheint u.U. einige us später auf dem Port als mit der letzten Firmware Version. Kan es das sein, dass Du "zu früh" liest? Das sollte wirklich eine minimalste Änderung sein... evtl. reichen schon 3 NOPs.
PS. Ich würde ja die Routine vom letzten Mal wieder einbauen, aber ich habe nicht genügend Platz in der Firmware! So habe ich die Funktion die den Wert auf den Datenbus schreibt mit einem weiteren ARgument versehen, dass angibt, ob 4 oder 8bittiger Wert. D.h., der einzige Unterschied zur vorherigen Firmware ist ein "if (four_bit) { ... }" und ein weiteres Argument. Das kann wie gesagt zu einer leichten Verzögerung von einige us führen.
Naja, ich hoffe Du bekommst das noch hin. im ATmega ist ja ab &EAA0 noch Platz frei, zuvor warst Du doch schon bis &F2xx voll. Da müsste sich doch eine simple, schnelle Lese-Routine einbauen lassen. Also wie zuvor. :)
Also wenn der 4 MHz Z80 auf den 20 MHz ATmega warten muss, dann fühlt sich da komisch an. :irre:
Klar, ich könnte das ROM ändern und probieren wie lange ich warten muss, aber dann wäre der LS3 langsamer als der alte LS 1.x. Ich warte jetzt mal ab, bin mir sicher Du kannst das noch irgendwie hinzaubern. :) :) :)
Entzwischen versuche ich das mal mit dem Code im ROM zu kompensieren.
Quote from: TFM on 30. June 2019, 15:17:27
Naja, ich hoffe Du bekommst das noch hin. im ATmega ist ja ab &EAA0 noch Platz frei, zuvor warst Du doch schon bis &F2xx voll. Da müsste sich doch eine simple, schnelle Lese-Routine einbauen lassen. Also wie zuvor. :)
Also wenn der 4 MHz Z80 auf den 20 MHz ATmega warten muss, dann fühlt sich da komisch an. :irre:
Klar, ich könnte das ROM ändern und probieren wie lange ich warten muss, aber dann wäre der LS3 langsamer als der alte LS 1.x. Ich warte jetzt mal ab, bin mir sicher Du kannst das noch irgendwie hinzaubern. :) :) :)
Entzwischen versuche ich das mal mit dem Code im ROM zu kompensieren.
Danke fürs Hartnäckig-Bleiben!
In der Test, es ist etwas noch eigenartigeres... denn im EPSON / LAMBDA / DECTALK Modus funktionieren die Commands.
Es liegt also gar nicht an BASIC oder MC, sondern an der Hardware-Konfiguration... muss ich mal nachsehen was das ist.
Und ich bin derweil an !HIBERNATE und !RESUME, irgendetwas will da noch nicht, und ich finde den Fehler nicht. Hat aber nix mit dem LS3 zu tun. Eher ein Problem mit dem nativen CPC-OS.
Hier das aktuelle ROM, es kompensiert die "Wartezeit" bei den GETxxx Befehlen, in dem es wartet bis der LS3 nicht-&40 sendet.
Quote from: TFM on 30. June 2019, 18:42:09
Und ich bin derweil an !HIBERNATE und !RESUME, irgendetwas will da noch nicht, und ich finde den Fehler nicht. Hat aber nix mit dem LS3 zu tun. Eher ein Problem mit dem nativen CPC-OS.
Hier das aktuelle ROM, es kompensiert die "Wartezeit" bei den GETxxx Befehlen, in dem es wartet bis der LS3 nicht-&40 sendet.
INteressant... und |getvolume funktioniert im SSA1 (DEFAULT) mode dann?
Quote from: TFM on 30. June 2019, 18:42:09
Und ich bin derweil an !HIBERNATE und !RESUME, irgendetwas will da noch nicht, und ich finde den Fehler nicht. Hat aber nix mit dem LS3 zu tun. Eher ein Problem mit dem nativen CPC-OS.
Hier das aktuelle ROM, es kompensiert die "Wartezeit" bei den GETxxx Befehlen, in dem es wartet bis der LS3 nicht-&40 sendet.
Super, jetzt funktioniert es, vielen Dank für die Kompensation!
Es scheint so zu sein, dass ein Unterprogrammaufruf |getvolume im |lambda / Epson modus weniger Zeit benötigt als im SSA1 Emu modus, und die vorherige Version hat den Wert vom Port "zu schnell" gelesen... das Umschalten des CPLDs Routings etc. dauert eben auch ein bißchen. Die Hardware und Firmware ist wesentlich komplexer als LS 1.95, daher scheint das Timinig an einige Stellen etwas schlechter geworden zu sein.
War am Untersuchen, aber es wäre recht schwierig gewesen, es er Firmware-Änderung hinzukriegen. Vielen Dank daher für die Software-Lösung.
Letzte Firmware anbei.
Hmm, wenn alle Register und so weiter gesichert werden, und Interrupts werden gesperrt währen HIBERNATE? Viel Glück...! Hat sowas nicht schon einmal einer gemacht wo man was klauen kann?
Quote from: LambdaMikel on 30. June 2019, 20:12:07
Hmm, wenn alle Register und so weiter gesichert werden, und Interrupts werden gesperrt währen HIBERNATE? Viel Glück...! Hat sowas nicht schon einmal einer gemacht wo man was klauen kann?
Ja, hab soetwas im FutureOS, und ... hab's da genau so gemacht. Aber es geht nix über selber machen. Kopieren ist pfui! :stop:
So, habe heute den ganzen Tag versucht !HIBERNATE und !RESUME zum laufen zu kriegen, geht nicht.
Aber: Wenn man zuerst !LSINIT eingibt, dann funktioniert es. Also damit kann man arbeiten und dann wird es in der nächsten Version auch hoffentlich immer laufen :-)
Quote from: LambdaMikel on 30. June 2019, 19:27:02
Interessant... und |getvolume funktioniert im SSA1 (DEFAULT) mode dann?
Ja, tut es. :-)
Quote from: TFM on 01. July 2019, 01:44:13
Quote from: LambdaMikel on 30. June 2019, 20:12:07
Hmm, wenn alle Register und so weiter gesichert werden, und Interrupts werden gesperrt währen HIBERNATE? Viel Glück...! Hat sowas nicht schon einmal einer gemacht wo man was klauen kann?
Ja, hab soetwas im FutureOS, und ... hab's da genau so gemacht. Aber es geht nix über selber machen. Kopieren ist pfui! :stop:
So, habe heute den ganzen Tag versucht !HIBERNATE und !RESUME zum laufen zu kriegen, geht nicht.
Aber: Wenn man zuerst !LSINIT eingibt, dann funktioniert es. Also damit kann man arbeiten und dann wird es in der nächsten Version auch hoffentlich immer laufen :-)
Quote from: LambdaMikel on 30. June 2019, 19:27:02
Interessant... und |getvolume funktioniert im SSA1 (DEFAULT) mode dann?
Ja, tut es. :-)
Super Fortschritt!
Ach, dann liegt es irgendwie am LS3 Zustand ob es geht oder nicht?? Also nach einem LS3 Reset klappt es?
Muss ich denn nun noch was ändern in der Firmware oder nicht?
Bei mir hat es leider nicht geklappt am 6128 mit XMem und LS3. Beim |resume hängt er.
Quote from: LambdaMikel on 01. July 2019, 02:56:47
Super Fortschritt!
Ach, dann liegt es irgendwie am LS3 Zustand ob es geht oder nicht?? Also nach einem LS3 Reset klappt es? Muss ich denn nun noch was ändern in der Firmware oder nicht?
Bei mir hat es leider nicht geklappt am 6128 mit XMem und LS3. Beim |resume hängt er.
Anders rum. :) Nach dem Reset geht es nicht. Aber nach !LSINIT geht es.
Du kannst ja mal probieren, welche der Befehle: !getfast, !englisch, !blockoff, !lambda, !setdelay,1 es braucht das es klappt. Ich habe das heute schon länger getestet, aber irgendwie ist da schwer zu reproduzieren. Aber das kriegen wir auch noch hin :smiley027:
Fehlerbericht:
Hier ein paar Sachen, die im ROM funktionieren sollten, aber nicht tun. Bitte in der Firmware nachschauen wo da Probleme vorhanden sind. Einfach mal selber ausprobieren.
- !GETMODE funktioniert zwar, aber nach dem Einschalten in SSA1 Modus gibt er den Wert &00 aus, und sagt es wäre Modus 4.
- Kommandos !saytemp, !saytime und !saydate sollten auch im (Confirmations OFF) Modus noch ihre Daten ansagen, da diese Kommandos ja extra aufgerufen werden um zu sprechen. Allerdings sind sie bisher nach !CONFOFF still.
Quote from: TFM on 01. July 2019, 21:32:57
Fehlerbericht:
Hier ein paar Sachen, die im ROM funktionieren sollten, aber nicht tun. Bitte in der Firmware nachschauen wo da Probleme vorhanden sind. Einfach mal selber ausprobieren.
- !GETMODE funktioniert zwar, aber nach dem Einschalten in SSA1 Modus gibt er den Wert &00 aus, und sagt es wäre Modus 4.
- Kommandos !saytemp, !saytime und !saydate sollten auch im (Confirmations OFF) Modus noch ihre Daten ansagen, da diese Kommandos ja extra aufgerufen werden um zu sprechen. Allerdings sind sie bisher nach !CONFOFF still.
Bzgl. |getmode (&cf) - wenn ich
10 out &fbee,&cf
20 print inp(&fbee)
30 goto 20
mache, sehe ich 64 = 4 * 16 = "Current mode 4".
Allerdings liefert |getmode in der Tat 0... könntest Du hier bitte ebenfalls die gleiche Verzögerung einbauen; all diese Bytes
case 0xCF : get_mode(); break;
case 0xCE : get_volume(); break;
case 0xCD : get_voice(); break;
case 0xCC : get_rate(); break;
case 0xCB : get_language(); break;
case 0xCA : get_delay(); break;
case 0xC9 : get_version(); break;
case 0xF2 : get_full_mode(); break;
sollten die gleiche Verzögerung haben.
Falls |getmode die schon hat, ist sie u.U. zu kurz, und ich würde Dich bitten, das noch weiter zu verzögern.
Ich kann da in der Firmware leider nichts ändern.
Ja, |saytemp |saytime |saydate werde ich ändern, Danke! - Done: v23 anbei.
Also Warteschleifen sind mir ein Gräuel und deshalb verwende ich sie nur wo bitter nötig. Im Falle der GET Kommandos warte ich zuerst bis der LS3 ungleich &40, dann lese ich den Wert. Das klappt super, aber eben nicht dann wenn der LS3 den Wert 4 liefert, also &40. Daran hätte ich denken sollen, aber es war hald mal wieder spät in der Nacht. Habe es jetzt geändert, ein paar Befehle umgestellt, und schaue mal ob das mit dem dadurch erzwungenem "Warten" zwischen OUT Kommando und IN Daten auch ausreicht. Will es aber erst mal testen. :)
Danke für die neue Firmware!!! :smiley027:
EDIT: Neue Version der ROMs hochgeladen. Link: Siehe meine Signatur. Scheint alles zu klappen.
:director: Liebe LS3 Nutzer, bitte Fehlerberichte hier ins Forum stellen. Bin für jeden Kommentar dankbar.
Super dass |getmode jetzt funtz! Vielen Dank! :jubelaola:
Allerdings hängt |resume,0 bei mir meist noch. Mit oder ohne |lsinit.
Ich habe aus der "eeget" Routine noch einmal ein paar CPC z80 halt statements ausgebaut... macht aber keinen Unterschied. Anbei.
Hier die letzte Version, v26 - hoffentlich endlich final!
https://github.com/lambdamikel/LambdaSpeak3/blob/master/firmware/atmega644/lambdaspeak3-firmware-v26-07-02-19.hex
Neu in dieser Version - jetzt haben wir auch MIDI.
https://ubld.it/products/midi-breakout-board/
Die erforderliche BAUD Rate 31250 ist nun eingebaut (BAUD Setting 6).
Siehe MIDI.BAS demo auf LS300.DSK anbei.
Erst mal Danke für's Firmware Update, werde es gleich installieren. :whip2:
Quote from: LambdaMikel on 03. July 2019, 03:30:02
Allerdings hängt |resume,0 bei mir meist noch. Mit oder ohne |lsinit.
Schau mal auf "LambdaSpeak_III_RSX_2019-07-02.DSK" in die Datei "LS3-ROM.MAX" rein, Und suche da nach dem Wort "RESUME", ab da steht der Source Code. Mein Z80 Teil scheint mir korrekt zu sein. Ich hab mir einen "Emulator" für diesen Zweck geschrieben, und so konnte ich den Z80 code testen, es scheint alles zu passen. Aber vielleicht fällt Dir ja noch etwas auf, z.B. irgendetwas nicht berücksichtigt oder so. :-X
Meine Tests haben nur ergeben, dass die EEPROM lesen/schreiben Schleife nicht verlassen wird. Warum? Keine Ahnung!
Quote from: TFM on 03. July 2019, 16:59:24
Erst mal Danke für's Firmware Update, werde es gleich installieren. :whip2:
Quote from: LambdaMikel on 03. July 2019, 03:30:02
Allerdings hängt |resume,0 bei mir meist noch. Mit oder ohne |lsinit.
Schau mal auf "LambdaSpeak_III_RSX_2019-07-02.DSK" in die Datei "LS3-ROM.MAX" rein, Und suche da nach dem Wort "RESUME", ab da steht der Source Code. Mein Z80 Teil scheint mir korrekt zu sein. Ich hab mir einen "Emulator" für diesen Zweck geschrieben, und so konnte ich den Z80 code testen, es scheint alles zu passen. Aber vielleicht fällt Dir ja noch etwas auf, z.B. irgendetwas nicht berücksichtigt oder so. :-X
Meine Tests haben nur ergeben, dass die EEPROM lesen/schreiben Schleife nicht verlassen wird. Warum? Keine Ahnung!
Also HIBERNATE scheint immer zu funktionieren. Nur beim RESUME haengt er meist und es scheint so zu sein, dass er einfach aufhoert, Daten anzufordern. Evtl. ist er der Meinung, er haette schon alle Daten oder "verzaehlt" sich, sodass er einfach aufhoert und LS3 haengt dann?
Zudem hatte ich den sehr komischen Effekt, dass er in eine Endlosschleife ging, und immer wieder "EEPROM Get Data. Send start page number" usw sagt, als ob das Command in einer Schleife immer wieder abgesetzt wurde.
OK, ich gucke mal in den Source Code demnaechst. EEUP und EEGET scheinen das Problem uebrigens nicht zu haben. Ich habe einmal den gesamten Speicherbereicht von &2000- &C000-1 ins EEPROM geladen, "Checksumme" ueber diesen Speicherbereich gemacht (einfach Summe MOD 256), dann wieder eingeladen mittels |EEGET und erneut "Checksumme", und die Werte waren identisch. Auch haengte er nicht fest.
Ja, danke, hab derweil !LED eingebaut.
Wegen !RESUME, probier mal !CONFOFF davor. Hilft das?
Quote from: TFM on 03. July 2019, 18:16:55
Ja, danke, hab derweil !LED eingebaut.
Wegen !RESUME, probier mal !CONFOFF davor. Hilft das?
Nein, nicht wirklich. Auch |lsinit hilft nicht wirklich.
Cool, das |LED RSX! :smiley027:
lLED ist aber noch nicht im Rom?
Nein, ich abreite an BIGWATCH, das tut aber nicht wie es soll...
Michael, könntest Du Dir bitte in der Firmware mal den Funktion GET_HOUR ansehen?
Das geht zwar in BASIC, aber nicht im MC.
Wenn ich das Werte lese, wechseln die durch, aber keiner davon ist die Stunde, und der erste gelesene Wert scheint eher zufällig zu sein. Keine Ahnung woran es liegt :irre:
Beispiel, gib mal folgendes im Maxam Assember (ROM) ein:
org &9000
ld bc,&fbee
ld a,&d5
out (c),a
ld hl,&4000
loop in a,(c)
ld (hl),a
inc hl
ld a,h
rlca
jr nc,loop
ret
Dann assemblieren, ab &9000 aufrufen und mit Edit ab &4000 im RAM nachschauen.
Die Routine schreibt &4000 bis &7FFF voll mit Bytes die vom LS3 gelesen werden.
Allerdings ist keines davon die Stunde.
Andere LS3 Nutzer bitte auch mal probieren! Danke!
Anbei als HOURS.BAS (MAXAM 1.5).
Ich glaube, Du hast die Sekunden erwischt :zwinker0018:
Du hast ein paar Nächte zu viel / lang durchgemacht, schlaf mal aus :zwinker0018: ;)
Clevere Idee mit der Schleife und rlca und jr nc, loop übrigens... um das zu verstehen musste ich tatsächlich noch mal in's Z80 Buch reingucken, mein Z80 ist ja schon 30+ Jahre her :zunge0020:
Quote from: TFM on 03. July 2019, 22:12:54
Nein, ich abreite an BIGWATCH, das tut aber nicht wie es soll...
Oh, BIGWATCH? Da hätte ich auch noch eine :jubelaola:
... aber funktioniert noch nicht mit LS3. Musste nur dran denken als Du es erwähntest.
Ähm, ja Schlafmangel und Komplexität des LS3... hab heute mal 9 Stunden geschlafen...
Ja, sollte Stunde (D3) lesen und nicht die Sekunden, glaube das Problem ist dass der LS3 die Daten im Binärformat liefert, also man erhält hex &13 für 19 dezimal. Mein Fehler. Und vor dem Lesen der Daten muss man 2 NOPs warten (8 us ist fein, 4 reicht nicht), denn sonnst liest man &40 (LS3 noch beschäftigt). Bei über 100 Funktionen verliere ich wohl langsam die Übersicht, da hilft's in Deinem super Online-Manual nachzulesen. :)
EDIT: Ein weiteres Problem sind (erstaunlich aber wahr), die Systeminterrupts des nativen CPC-OS! Die brauchen so viel Zeit, dass sie (zumindest bei FAST GETTERS) zu Problemen führen. Das lösen wir einfach mit DI und EI und gut ist es.
... BIGWATCH läuft. :)
Yeah! Download please :flehan:
Wir können die Fast Getters sonst auch etwas ausbremesen und länger machen.... wie Du meinst.
Interrupts sind leider oft destruktiv... beim ATMega hatte ich das Problem auch (obwohl der gar kein OS hat! :irre:). Disablen ist manchmal das Beste :smiley027:
Kann ich Dein Assembler-Beispiel zum Auslesen auf's Github tun?
... wo wird gerade dabei sind - weiß einer von einem MID file song player für den CPC in BASIC?
Stefan, hier ist unser nächstes Projekt :love: Schmeiss mal Deinen Windows Media Player an (der spielt MID)
Wäre doch nett, wenn das aus dem CPC käme, oder? :smiley027:
Quote from: LambdaMikel on 04. July 2019, 17:45:53
Yeah! Download please :flehan:
Wir können die Fast Getters sonst auch etwas ausbremesen und länger machen.... wie Du meinst.
Interrupts sind leider oft destruktiv... beim ATMega hatte ich das Problem auch (obwohl der gar kein OS hat! :irre:). Disablen ist manchmal das Beste :smiley027:
Kann ich Dein Assembler-Beispiel zum Auslesen auf's Github tun?
Nee, fast getters passt schon, hab ein paar DI's und EI's eingebaut. ;)
Download ist oben, siehe Signatur unten.
Michael, Du kannst gerne alles immer von mir auf GitHub tun. :) :) :)
Wow! |BIGWATCH ist super!! Tolle Anzeige :love: :smiley027: ;D
|LED funktioniert auch prima, und man sieht gar kein Flackern von &F0.
Hier noch ne Idee für|BIGWATCH: Datum und Temperatur, und auf Tastendruck ("t") sagt er die Zeit und ("d") Datum und Temperatur ("t"). Stellen der Uhr (des Datums, der Temperatur :irre:) über BIGWATCH wäre natürlich auch nett! Nur für den Fall dass Du noch Ideen suchst ;)
Danke! :flehan:
Ja gute Ideen, nur stellen der Temperatur... Elend! Meinen Heizung hat kein RS232! :irre:
Wegen BIGwatch... naja so ganz zufrieden bin ich mit den Zahlen noch nicht, aber vielleicht findet sich ja jemand der künstlerisch deutlich begabter ist. :)
... und Alarm-Clock. Koennte Alarms im EEPROM speichern... natuerlich auch Temperatur-Alarme:
if temp > 30 then print "Bier trinken!"
Ich selbst bastele gerade an MIDI Input... BASIC ist zu langsam. Jetzt habe ich wirklich mal wieder einen Grund, etwas Z80 zu machen.
Quote from: LambdaMikel on 07. July 2019, 22:07:59
Jetzt habe ich wirklich mal wieder einen Grund, etwas Z80 zu machen.
:jubelaola:
Quote from: LambdaMikel on 07. July 2019, 22:07:59
Jetzt habe ich wirklich mal wieder einen Grund, etwas Z80 zu machen.
:smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027: :smiley027:
Quote from: TFM on 03. July 2019, 16:59:24
Schau mal auf "LambdaSpeak_III_RSX_2019-07-02.DSK" in die Datei "LS3-ROM.MAX" rein, Und suche da nach dem Wort "RESUME", ab da steht der Source Code. Mein Z80 Teil scheint mir korrekt zu sein. Ich hab mir einen "Emulator" für diesen Zweck geschrieben, und so konnte ich den Z80 code testen, es scheint alles zu passen. Aber vielleicht fällt Dir ja noch etwas auf, z.B. irgendetwas nicht berücksichtigt oder so. :-X
Hallo Stefan,
also das EEGET schlägt fehl oder gibt m.E. den "Endlosschleifeneffekt" (dass |eeget immer wieder aufgerufen wird), sobald man dem OS bzw. BASIC in die Quere komt, d.h., von BASIC aus, wenn man über > &AC00 oder so versucht was wiederherzustellen. Unterhalb dieses Bereiche klappt es gut. Es scheint also so zu sein, dass man noch was anderes tun muss, um das OS wiederherzustellen? Ich nehme an, dass RESUME noch mehr macht als EEGET, d.h., dass es die Register usw auch sichert in eine Seite (und evtl. auch noch ein paar BASIC-Rücksprungaddressen so anpasst, dass das RETURN aus dem RSX funktioniert?)
Übrigens kann ich den Code von "RESUME" und "EEGET" irgendwie nicht finden im LS3-ROM.MAX.
Ich sehe zwar Sachen wie
JP LS_RESU
...
LS_RESU_ERR DB "Use: ",&18," |RESUME,page",&00
...
s. Attachment, aber LS_RESU kann ich nicht finden in der LS3-ROM.MAX Datei!
Ist die u.U. nicht aktuell auf der DSK? Habe ich heute gerade noch einmal heruntergeladen.
Hmm, und MAXAM 1.5 hat den Texteditor nicht mehr drin?? Habe dann MAXAM 1 verwendet, da ich mich damit aber nicht so gut auskenne (Suchen von Text?), habe ich die LS3-ROM.MAX Datei mit DSKtool.jar extrahiert und von Windows mit Emacs angesehen (s. Screenshot). Evtl. ist dabei was kaputt gegangen...
Welches MAXAM ROM empfiehlst Du denn.
EDIT: NEVER MIND... mit MAXAM 1 ROM kann ich den source lesen. Irgendwie scheint das extract to ASCII nicht zu funktionieren mit DSKTool.jar. Scheint wohl doch nicht 100% ASCII zu sein so eine MAX Datei? Anyhow.
Also wenn ich das richtig sehe, dann sichert HIBERNATE nur den Stackpointer, im RAM, an Addresse &BF40 - dann werden 96 = &60 pages rausgeschrieben, und der Stackpointer wird hinterher von &BF40 wiederhergestellt. Das scheint alles zu sein? 2 Fragen:
- warum &BF40? Macht das nix kaputt, da was rein zu schreiben?
- und die anderen Register?
Ich hatte eigentlich gedacht, dass 96 Seiten unveränderter Speicher rausgeschrieben werden, plus 1 weitere Seite, die nur die Register enthält. Und die dann natürlich auch wieder hergestellt werden müssten.
Mit der Bitte um Erleuchtung :flehan: :smiley027:
Ok, da hatte ich jetzt viel zu lesen. K.A. was davon noch aktuell ist.
- Der Source für das ROM ist in drei ASCII Dateien drin: LS3-RA.MAX, LS3-ROM.MAX, LS3-ROMB.MAX.
- Das sind alles ASCII Dateien, die man mit jedem Texteditor oder mit MAXAM lesen kann.
- Hauptproblem bei Bugs ist die Unstetigkeit der Firmware. Ein Beispiel: Einfach mal !BIGWATCH eingeben und zugucken. Zwischendrin kommen immer wieder die Werte 32 für Stunde, Minute oder Sekunde vor. 32 ist aber die Bereitmeldung des LS3.
Was sagt uns das? Wenn man Werte vom LS3 lesen will muss man etwas warten und dann sind die Daten für einige Zeit verfügbar. Diese nötigen Pausen sind aber nicht gleich sondern zum Teil sehr unterschiedlich - beim Aufruf der selben Funktion. Bei !BIGWATCH kann man das schön sehen.
Es ist auch so, dass ich öfters mal Kommandos "nachjustiere", weil manchmal das Timing anders ist von Firmware zu Firmware. Da kann ich nicht alles testen, aber ich werde mir mal die EEGET Sachen nochmals ansehen.
Von meiner Seite aus kann ich nicht viel mehr tun, da der LS3 für mich eine Black-Box ist.
Quote from: LambdaMikel on 14. July 2019, 03:37:13
- warum &BF40? Macht das nix kaputt, da was rein zu schreiben?
Hier ist Platz, außerdem wird der Wert von &BF40 und &BF41 zuvor auf den Stack gesichert.
Einfach mal angucken der Source ist ja ausführlich dokumentiert. :)
Quote from: LambdaMikel on 14. July 2019, 03:37:13
- und die anderen Register?
Nötige Register (AF', BC', SP) werden gesichert und restauriert. Einfach mal ab Hibernate / Resume in den Z80 Source gucken.
Das ganze habe ich ohne LS3 simuliert (E-RAM anstatt LS3) und es läuft perfekt. :00008351:
Quote from: TFM on 14. July 2019, 23:02:26
Quote from: LambdaMikel on 14. July 2019, 03:37:13
- warum &BF40? Macht das nix kaputt, da was rein zu schreiben?
Hier ist Platz, außerdem wird der Wert von &BF40 und &BF41 zuvor auf den Stack gesichert.
Einfach mal angucken der Source ist ja ausführlich dokumentiert. :)
Quote from: LambdaMikel on 14. July 2019, 03:37:13
- und die anderen Register?
Nötige Register (AF', BC', SP) werden gesichert und restauriert. Einfach mal ab Hibernate / Resume in den Z80 Source gucken.
Das ganze habe ich ohne LS3 simuliert (E-RAM anstatt LS3) und es läuft perfekt. :00008351:
OK, ich gucke auch noch mal. Was ich nicht verstehe - EEGET funktioniert ja. Wenn ich 32 KB oder so sichere über einen Speicherbereich, den ich vorher mit Random vollgeschrieben habe, die Checksummer berechne, und dann wieder einlese, wieder Checksumme, kommt das gleiche Ergebnis bei raus. Also scheint es doch nicht an EEGET oder der Kommunikation zu liegen, sonst würden ja Byte-Fehler auftreten, oder?
Quote from: TFM on 14. July 2019, 22:54:53
- Hauptproblem bei Bugs ist die Unstetigkeit der Firmware. Ein Beispiel: Einfach mal !BIGWATCH eingeben und zugucken. Zwischendrin kommen immer wieder die Werte 32 für Stunde, Minute oder Sekunde vor. 32 ist aber die Bereitmeldung des LS3.
Was sagt uns das? Wenn man Werte vom LS3 lesen will muss man etwas warten und dann sind die Daten für einige Zeit verfügbar. Diese nötigen Pausen sind aber nicht gleich sondern zum Teil sehr unterschiedlich - beim Aufruf der selben Funktion. Bei !BIGWATCH kann man das schön sehen.
Es ist auch so, dass ich öfters mal Kommandos "nachjustiere", weil manchmal das Timing anders ist von Firmware zu Firmware. Da kann ich nicht alles testen, aber ich werde mir mal die EEGET Sachen nochmals ansehen.
Von meiner Seite aus kann ich nicht viel mehr tun, da der LS3 für mich eine Black-Box ist.
OK, also LS 3 hat ja einen unabhängigen Takt, und der ist nicht synchron mit dem CPC. Das macht es etwas schwieriger...
Zum "get time"-Protokoll: ich habe die Unstetigkeiten in Bigwatch jetzt tatsächlich einmal gesehen. Kommt zwar recht selten vor, aber passiert!
Das Protokoll für get_hours, get_minutes, etc., ist ja folgendes:
1. hours (minutes, ...) auf den Datenbus
2. read delay - ja nach fast oder slow getters
3. dann 255 auf den Bus
4. read delay
5. dann 0 auf den Bus.
Idealerweise sollte die Lese-Schleife also folgendes tun (Pseudo Code):
wait_for_ready:
read byte from databus
if byte <> 32 then goto wait_for_ready
byte = 255
loop:
last_byte = byte
read byte from databus
if byte <> 255 then goto loop
byte = last_byte
// now we have hours (minutes, ...) in "byte"
wait_for_ready2:
read byte
if byte <> 32 then goto wait_for_ready2
etc.
Verwendet Bigwatch denn fast oder slow getters? Mit so einer "Schleife" sollte es eigentlich in beiden Fällen funktionieren, und hoffentlich auch "sich selbst" justieren.
In den BIGWATCH sourcen sehe ich:
;|BIGWATCH
;
;Zeigt die aktuelle Uhrzein im Grossformat an
LS_BIGW LD HL,BIWM2:CALL PRIL ;MODE 2
LS_BWL1 CALL &BB09:RET C ;Taste? Ja, Ende!
LD BC,&FBEE:CALL LS_WALP ;Warten bis LS3 bereit!
;
DI:LD A,&D5:OUT (C),A ;Kommando-Byte &D5 an LambdaSpeak III schicken (Sekunde)
;
DB &DD:LD H,L ;XH = Sekunde_ALT
;
W40S IN A,(C):CP A,&40:JR Z,W40S ;<>&40
EI:DB &DD:LD L,A ;XL = Sekunde_NEU
CALL LS_WALP
DI:LD A,&D4:OUT (C),A ;&D4 = Minute, von RTC lesen
;
LD A,(BC) ;2 us Zeit schinden
....
würde ich also empfehlen, das 2 us Zeit schinden raus (und alle Statements, die ein feste Zeitverzögerung annehmen), und dafür die Schleife oben implementieren - lesen und merken, bis 255 gelesen, dann ist es der Wert direkt vor 255 ("last_byte").
Also, alles was irgendwie feste Wartezeiten verwendet, wird in LS3 nicht zuverlässig funktionieren m.E., da ja der Takt auch nicht mal synchron ist mit dem CPC... Schleifen sind also erforderlich für die Synchronisation.
Bei EEGET ist das Protokoll wiederum anders... da ja hier das nächste Byte mittels "out &fbee,<beliebig>" "getaktet bzw. angefordert wird, und das read delay zu langsam wäre... und ausserdem kann ja auch 255 als Byte vorkommen, sodass wir das nicht als Synchronisationsmarker wie bei der Uhrzeit nehmen können. Das einzige Problem hier ist, dass man etwas warten muss, nachdem das letzte Byte einer Seite gelesen wurde.
für jede Seite:
- lege busy marker auf den Bus (0)
- lese und puffere eine Seite vom EEPROM
- lege ready marker (32) auf den Bus
- jetzt, 512 mal:
- warte auf "out &fbee,<beliebig>" vom CPC
- lege <byte> vom EEPROM-Puffer auf den Datenbus (0 Zeitverzögerung!)
- read delay (je nach fast oder slow getters - nach 512 gelesenen Bytes)
An dieser Stelle muss der CPC aufpassen beim Lesen - das LETZTE Byte
einer Seite "verschwindet" vom Datenbus automatisch, bzw. ist nur für
eine kurze Zeit sichtbar, wärend alle vorherigen Bytes der Seite (Bytes 0 bis 510)
solange sichtbar sind, bis mittels "out &fbee,<beliebig>" das nächste Byte
angefordert wird. Wir können das auch gerne ändern, sodass man das letzte Byte
auch noch "wegtakten" muss.
Quote from: LambdaMikel on 15. July 2019, 01:09:09
OK, ich gucke auch noch mal. Was ich nicht verstehe - EEGET funktioniert ja. Wenn ich 32 KB oder so sichere über einen Speicherbereich, den ich vorher mit Random vollgeschrieben habe, die Checksummer berechne, und dann wieder einlese, wieder Checksumme, kommt das gleiche Ergebnis bei raus. Also scheint es doch nicht an EEGET oder der Kommunikation zu liegen, sonst würden ja Byte-Fehler auftreten, oder?
Keine Ahnung, ich kenn die Firmware nicht. Das Protokoll benutze ich so wie es in der LS3 Doku steht. Der Z80 Source zeigt das ja.
p.s.: Das von Dir angegebene Protokoll ist für EEUP und nicht EEGET.
Quote from: LambdaMikel on 15. July 2019, 01:30:00
Das Protokoll für get_hours, get_minutes, etc., ist ja folgendes:
1. hours (minutes, ...) auf den Datenbus
2. read delay - ja nach fast oder slow getters
3. dann 255 auf den Bus
4. read delay
5. dann 0 auf den Bus.
Also, Zeit-Daten werden bei "1" gelesen, richtig?
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.
Und bei Punkt "5": Müsste da nicht &20 oder &80 auf dem Bus sein?
Quote from: TFM on 15. July 2019, 14:14:02
p.s.: Das von Dir angegebene Protokoll ist für EEUP und nicht EEGET.
Nein, das angegebene Protokoll ist für EEGET... das geht wirklich so :)
Quote from: TFM on 15. July 2019, 14:17:43
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.
Quote
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.
Quote
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.
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.
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.
Ja, irgendwie fehlt hier einiges. Hauptsache die Firmware ist verfügbar. :)
EDIT: Am Server gibt's auch Probleme, hier das neueste ROM...
Quote from: TFM on 18. July 2019, 03:05:36
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.
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.
Quote from: Rennert on 18. July 2019, 07:49:30
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.
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
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
Quote from: Rennert on 18. July 2019, 19:23:24
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
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
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.
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.
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.
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
ok, bei rtc.bas hatte allerdings fast jeder probleme, da das timinig bei rtc.bas eigentlich fast nicht beherschbar ist von basic. momentan habe ich es komplett kaputt reparier.
gehen die tfm rsx command bei dir? bigwatch, gettime etc.?
du hast aber ein sehr schwerwiegendes weiteres problem, dass andere cpc nutzer nicht haben - wait funktioniert nicht richtig beim kc compact.
ist ja ein wunder, dass ueberhaupt etwas von den basic-progammen auf er ls300.dsk laeuft.
https://github.com/lambdamikel/LambdaSpeak3/tree/master/cpc/lambda
Quote from: Rennert on 18. July 2019, 20:15:37
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.
das ist gut! dass heisst, es liegt am kc compact wait, und tfm muss noch einmal sein timing ueberarbeiten.
prinizipiell sollte dann mit aehnlichen aenderung bei drumload.bas (wait ersetzen) das auch funktionieren.
was ist denn mit server los... der schiebt posts rein die gestern waren und so weiter..
Habe bei eeprom3 eine Zeile 65 eingefügt.
65 if inp(&fbee) <>128 then 65
Jetzt läuft das Prog durch. Also die Wait Kommandos sind noch drin.
Ja Bigwatch und gettime geht.
Drumload teste ich auch nochmal mit meiner Änderung.
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. ;)
ist das irgendwo dokumentiert, dass der kc compact nicht kompatibel ist in einigen sachen? waere super wenn diese erkenntnis irgendwo festgehalten wuerde.
Puhhh, das ist ein Zwischending zw. CPC464 und CPC6128. C3 Mode ist vorhanden, aber nur Rom Remapped. Und es gehen nicht alle CRCT Modes.
Es gibt Handbücher dafür, aber ist nix konkretes zum Unterschied.
So Drumload getestet. &fbee wird als - 1042 angezeigt.
Habe mal die Zeile110 mit dem Wait gelöscht und er lädt alle Files und das Prog läuft bis zum Ende.
Quote from: Rennert on 18. July 2019, 22:35:16
So Drumload getestet. &fbee wird als - 1042 angezeigt.
Habe mal die Zeile110 mit dem Wait gelöscht und er lädt alle Files und das Prog läuft bis zum Ende.
Fantastisch! Dann bitte einmal drummer.bas testen, und wenn das geht, ebenfalls drummer2.bas
Hoerst Du denn ebenfalls die Tests von den Drums beim Hochladen?
Evtl. musst Du dort ebenfalls waits ausbauen. Die sind auf der midefseq2.dsk.
PS Mit TFM's RSX (eeup, pcmup) geht das Hochladen einer Drum PCM uebrigens in ein bis zwei Sekunden pro Drum..
Drummer.Bas geht, hab das wait gelöscht.
Drummer teste ich später.
Quote from: Rennert on 18. July 2019, 22:55:30
Drummer.Bas geht, hab das wait gelöscht.
Drummer teste ich später.
Du meinst drummer2.bas?
Also wenn Du die Drums spielen kannst, und es klingt nach Trommeln, und EEPROM3.BAS ist auch durchgelaufen, dann ist die LS3 Hardware und Kommunikation mit dem KC Compact prinzipiell in Ordnung. Der Rest sind Software-Probleme.
Ich teste die drums morgen nochmal, hatte es nicht so laut. Habe bei den einzelnen Instrumenten nur die Sprachausgabe gehört. Also bei Bass kam als Sprach Bass vom LS3
Quote from: Rennert on 18. July 2019, 23:05:10
Ich teste die drums morgen nochmal, hatte es nicht so laut. Habe bei den einzelnen Instrumenten nur die Sprachausgabe gehört. Also bei Bass kam als Sprach Bass vom LS3
??? Habe ich ueberhaupt nicht verstanden. Wenn Du die DIP Schalter in Standard-Stellung hast, solltest Du PCM Output auch hoeren. Hat der KC Compact den SOUND IN Pin vom CPC? Hoerst Du denn was bei |pcmtest ?
Der Sound Pin ist doch Pin2 am Systemstecker? der geht durch. Höre ja auch Sound am TV.
ich habe am KC Kompact einen Scart Ausgang, wo der Ton mit rauskommt. Am Scart habe ich den Ton abgenommen und ins LS3 rein und dann vom LS3 wieder zum Scart.
Die einzelnen Mods habe ich damals am LS1.99 durchgespielt und es ging auch alles.
Hab jetzt mal den DKTronics Mode eingeschalten, JumpJet geladen. Die Musik kommt übern TV und die Sprachausgabe aus den Boxen die am Speech Module angeschlossen sind.
PCMTest: aus den Boxen kommt die Ansage "PCMTest" "Use Reset....", am TV kommt was,verstehe ich aber nicht. Klingt wie "End the line" in Dauerschleife. bei LS Reset ist wieder Ruhe.
Sag mal wo finde ich die Belegung der Jumper am LS3?
noch ein kleiner Test:
Auf der LS300.dsk gibt es ein Prog SP-GERM.bas. Mit echtem SPO kommt die Sprachausgabe auf dem TV, ohne kommt sie aus den Lautsprechern am Speech Modul. Also funktioniert das ja normal.
Also eeprom3 läuft jetzt ohne Modifikation, warum auch immer. drumload lädt auch alle files, drummer funktioniert, aber ich höre kaum was. hab den TV auf voller Lautstärke. Man hört irgendwas ganz leise z.B. crash läuft aber man hört fast nix.
drummer2 ist nix zu hören.
bei pcmtest höre ich die Ausgabe gut, auch wenn ich den Satz nicht verstehe ;)
habe noch sequenc2 mal geladen, aber man hört nur Schnulli. Was muss man da hören?
eventuell werden die Files nicht richtig in den EEprom geladen und dann wird nix richtiges abgespielt. Getestet mit den Basic Programmen, bei den RSX hängt sich ja der Rechner auf
bei lEETEST sagt der da EEPROM cleared?
was mir auffällt: wenn er mit Drumload lädt, zeigt er bei jedem File Bytes=0 an, da sollte doch die Größe angezeigt werden.
Das Amdrum Kit läuft auch, hab mal bissel komponiert.
Also Problem ist, das er nix in den EEprom lädt. Nach Drumload sagt eetest immer EEprom clear.
Ebenfalls von der GitHub Page -
Quote
From left to right, the DIP switches 1 to 5 and 6 to 10 are:
MIX (1 = left, 6 = right): MIX is the output of LambdaSpeak's OP amp. The OP amp is a summing OP amp with Gain control that amplifies and recovers the mono PCM output generated by the ATmega (PCM Sample Playing), and the sound generated by the SPO256-AL2 vintage speech chip. The corresponding DIP switch determines if the OP amp's output is routed to the left and/or right output channel (or turned off completely). Notice that using an OP amp always results in some degradation of the audio quality. Hence, it is also possible to exclusively route the PCM output or exclusively route the SPO256-AL2 output to the left or right channel (see switches SPO and AT below). If no SPO256-AL2 is being used, then there is no need for the MIX output, and the switch should be in the off position.
EPS (2 = left, 7 = right): Turn on or off routing of the stereo audio signal received over LambdaSpeak's stereo audio input jack (the right stero jack on the board). Usually, this connects to the output output jack of the Epson click daughter board. The output of the Epson speech board is mono, but heard on the left and right channel. The TTS click daughterboard is already equipped with an audio amplifier, so it also possible to directly connect a loudspeaker or audio amplifier to the audio socket of the daughterboard itself. In the case, LambdaSpeak's stereo input jack is available to receive either the audio output generated by the CPC, using the audio stereo output jack of the CPC (and left or right channels will be routed accordingly), or to the output of the MP3 module can be used (see below). In any way, the left or right channels will be routed accordingly (i.e., left to left and right to right). Note that EPS input is not amplified by the internal OP amp.
AT (3 = left, 8 = right): the raw PCM output from the ATmega; used for the Amdrum mode and the autonomous PCM Sample Playing mode. This signal has higher quality than the MIX output. If no SPO256-AL2 is being used, then there is no need for the MIX output, and the AT raw PCM output achieves higher PCM quality and bandwidth.
SPO (4 = left, 9 = right): the raw speech output from the optional SPO256-AL2 chip; used for the SPO-based SSA1 and DK'tronics modes. This signal has higher quality than the MIX output. If no SPO256-AL2 is being used, then this switch should be in the off position.
CPC (5 = left, 10 = right): determines if the left (resp. right) output channel of LambdaSpeak's stereo output jack should be routed into the CPC's internal audio amplifier and speaker. Please note that the assignment of the left and right output of LambdaSpeak's stereo jack is determined by the DIP switches 1 to 5, and 6 to 9, resp., as just explained. This does not work on the Plus line of CPC computers, so these switches should be in the off position for a CPC Plus computer.
A reasonable default configuration for a LambdaSpeak 3 with SPO256-AL2 is 10001-01001. Hence, MIX on the left output channel, and Epson speech on the right output channel. Moreover, both are being heard in the CPC's internal speaker as well, so no need for an external amplifier.
End of line:
Quote from: Rennert on 19. July 2019, 13:37:24
bei lEETEST sagt der da EEPROM cleared?
was mir auffällt: wenn er mit Drumload lädt, zeigt er bei jedem File Bytes=0 an, da sollte doch die Größe angezeigt werden.
Das passiert, wenn das AMSDOS nicht an der richtigen Stelle / ROM ist.... genau, er braucht die Datei-Länge aus den Headern für die Anzahl der Bytes. Daher kommt da evtl. auch das M4 in die Quere.
:jubelaola:
Quote from: LambdaMikel on 19. July 2019, 16:09:45
Quote from: Rennert on 19. July 2019, 13:37:24
bei lEETEST sagt der da EEPROM cleared?
was mir auffällt: wenn er mit Drumload lädt, zeigt er bei jedem File Bytes=0 an, da sollte doch die Größe angezeigt werden.
Das passiert, wenn das AMSDOS nicht an der richtigen Stelle / ROM ist.... genau, er braucht die Datei-Länge aus den Headern für die Anzahl der Bytes. Daher kommt da evtl. auch das M4 in die Quere.
M4 habe ich nicht an, nur X-Mem. AMSDOS ist original auf 7 vom Rom im Floppycontroller.
Hab nur ACMEDos noch geladen.
Quote from: Rennert on 19. July 2019, 09:55:30
Der Sound Pin ist doch Pin2 am Systemstecker? der geht durch. Höre ja auch Sound am TV.
ich habe am KC Kompact einen Scart Ausgang, wo der Ton mit rauskommt. Am Scart habe ich den Ton abgenommen und ins LS3 rein und dann vom LS3 wieder zum Scart.
Die einzelnen Mods habe ich damals am LS1.99 durchgespielt und es ging auch alles.
S.Antwort oben für DIP-Belegung. Also den LS3 als "Verstärker" für den CPC zu benutzen war so nicht gedacht. Verstehe nicht wie Du das machst... der Epson Ausgang geht doch in den Eingang, und die andere Buchse ist ein Ausgang... und Augänge / Kabel einfach zusammenlöten oder drillen vermindert den Audio-Level erheblich. Ich würde 2 getrennte Verstärker empfehlen, oder einen Mixer... also KC Compact in den Mixer, und LS3 Ausgang in den Mixer... und dann in den Scart.
Quote from: Rennert on 19. July 2019, 15:51:48
Das Amdrum Kit läuft auch, hab mal bissel komponiert.
Also Problem ist, das er nix in den EEprom lädt. Nach Drumload sagt eetest immer EEprom clear.
??? EETEST testet einige Sachen und sagt ab und zu EEPROM cleared - EEPROM PCM / DATA UPLOAD kann das eigentlich gar nicht sagen. Wenn Du EEPROM cleared hörst beim Versuch, Samples hochzuladen, hat er das Controll-Byte missverstanden. Diesen Effekt hatte ich noch nie. Das ist die EETEST Prozedur, kannst ja mal nach command_confirm für die Sprachausgaben gucken. Der Test braucht übrigens 20 Sekunden oder so.... mit Gedult bis zum Ende abwarten.
void eeprom_full_check(void) {
speech_native_busy;
uint32_t byteFoundAt = 0;
uint32_t byteAddress = 0;
uint8_t testByte = 123;
uint8_t badByte = 0;
LAMBDA_EPSON_ON;
sprintf(command_string, "EEPROM determine size.");
command_confirm(command_string);
EEPROM_PCM_UPLOAD_ON;
EEPROM_writeEnable();
EEPROM_disableWriteProtection();
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
EEPROM_writeEnable();
SLAVE_SELECT;
SPI_tradeByte(EEPROM_CE);
SLAVE_DESELECT;
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
//
//
//
SLAVE_SELECT;
SPI_tradeByte(EEPROM_READ);
EEPROM_send24BitAddress(0);
for (uint32_t i = 0; i < EEPROM_BYTES_MAX; i++) {
SPI_tradeByte(0);
badByte = SPDR;
if ( badByte != 255 ) {
break;
}
byteFoundAt++;
}
SLAVE_DESELECT;
LAMBDA_EPSON_ON;
if (byteFoundAt != EEPROM_BYTES_MAX) {
sprintf(command_string, "EEPROM not cleared. Found byte %d at address %lu.", badByte, byteFoundAt);
} else {
sprintf(command_string, "EEPROM cleared. All bytes 255.");
}
command_confirm(command_string);
EEPROM_PCM_UPLOAD_ON;
//
// write test byte
//
byteFoundAt = 0;
EEPROM_writeByte(byteAddress, testByte);
//
// read test
//
SLAVE_SELECT;
SPI_tradeByte(EEPROM_READ);
EEPROM_send24BitAddress(byteAddress);
uint8_t flag = 0;
while (1) {
SPI_tradeByte(0);
if ( SPDR == testByte && byteFoundAt != 0 ) {
flag = 1;
break;
}
byteFoundAt++;
}
SLAVE_DESELECT;
//
LAMBDA_EPSON_ON;
if (flag) {
sprintf(command_string, "EEPROM has %lu bytes.", byteFoundAt);
} else {
sprintf(command_string, "ERROR OCCURED!");
}
command_confirm(command_string);
//
// 2nd test, page-wise write and read
//
EEPROM_PCM_UPLOAD_ON;
EEPROM_writeEnable();
EEPROM_disableWriteProtection();
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
EEPROM_writeEnable();
SLAVE_SELECT;
SPI_tradeByte(EEPROM_CE);
SLAVE_DESELECT;
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
LAMBDA_EPSON_ON;
sprintf(command_string, "EEPROM cleared.");
command_confirm(command_string);
//
// write all bytes in page <page> to <page>
//
EEPROM_PCM_UPLOAD_ON;
uint16_t i;
uint16_t page = 0;
byteAddress = 0;
while (byteAddress < EEPROM_BYTES_MAX) {
EEPROM_writeEnable();
SLAVE_SELECT;
SPI_tradeByte(EEPROM_WRITE);
EEPROM_send24BitAddress(byteAddress);
for (i = 0; i < EEPROM_BYTES_PER_PAGE; i++) {
SPI_tradeByte(page >> 1);
}
page++;
SLAVE_DESELECT;
byteAddress += EEPROM_BYTES_PER_PAGE;
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
}
LAMBDA_EPSON_ON;
sprintf(command_string, "EEPROM pages written.");
command_confirm(command_string);
//
// read pages test
//
EEPROM_PCM_PLAY_ON;
page = 0;
byteAddress = 0;
while (byteAddress < EEPROM_BYTES_MAX) {
SLAVE_SELECT;
SPI_tradeByte(EEPROM_READ);
EEPROM_send24BitAddress(byteAddress);
for (i = 0; i < EEPROM_BYTES_PER_PAGE; i++) {
byteAddress++;
SPI_tradeByte(0);
if (SPDR != (page >> 1)) {
break;
}
}
page++;
SLAVE_DESELECT;
}
LAMBDA_EPSON_ON;
if (page != 512) {
sprintf(command_string, "EEPROM page error at page %d.", page);
} else {
sprintf(command_string, "EEPROM pages okay. Done testing EEPROM.");
}
command_confirm(command_string);
DATA_TO_CPC(0);
z80_run;
CUR_MODE = START_OVER_SAME_MODE;
return;
}
Quote from: Rennert on 19. July 2019, 16:13:27
:jubelaola:Quote from: LambdaMikel on 19. July 2019, 16:09:45
Quote from: Rennert on 19. July 2019, 13:37:24
bei lEETEST sagt der da EEPROM cleared?
was mir auffällt: wenn er mit Drumload lädt, zeigt er bei jedem File Bytes=0 an, da sollte doch die Größe angezeigt werden.
Das passiert, wenn das AMSDOS nicht an der richtigen Stelle / ROM ist.... genau, er braucht die Datei-Länge aus den Headern für die Anzahl der Bytes. Daher kommt da evtl. auch das M4 in die Quere.
M4 habe ich nicht an, nur X-Mem. AMSDOS ist original auf 7 vom Rom im Floppycontroller.
Hab nur ACMEDos noch geladen.
OK, ACMEDos wird von meinem kleinen BASIC Programm Demo nicht unterstützt. Kenne ich nicht. Da müsstest Du bitte selbst die Header Positionen für Dateilänge im RAM rausfinden :zunge0020:
Audio Mischer
https://www.amazon.de/ammoon-Audio-Kan%C3%A4le-Ultrakompakt-Netzteil/dp/B01EWWIQ7U/ref=sr_1_9?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=mini+audio+mixer&qid=1563546161&s=gateway&sr=8-9
Quote from: LambdaMikel on 19. July 2019, 16:14:44
Quote from: Rennert on 19. July 2019, 09:55:30
Der Sound Pin ist doch Pin2 am Systemstecker? der geht durch. Höre ja auch Sound am TV.
ich habe am KC Kompact einen Scart Ausgang, wo der Ton mit rauskommt. Am Scart habe ich den Ton abgenommen und ins LS3 rein und dann vom LS3 wieder zum Scart.
Die einzelnen Mods habe ich damals am LS1.99 durchgespielt und es ging auch alles.
S.Antwort oben für DIP-Belegung. Also den LS3 als "Verstärker" für den CPC zu benutzen war so nicht gedacht. Verstehe nicht wie Du das machst... der Epson Ausgang geht doch in den Eingang, und die andere Buchse ist ein Ausgang... und Augänge / Kabel einfach zusammenlöten oder drillen vermindert den Audio-Level erheblich. Ich würde 2 getrennte Verstärker empfehlen, oder einen Mixer... also KC Compact in den Mixer, und LS3 Ausgang in den Mixer... und dann in den Scart.
Der EpsonSpeech Modul Ausgang geht bei mir direkt auf Lautsprecher. Der Sound Out vom KCC direkt in den Eingang vom LS3 und der Mixer Ausgang dann wieder ins Scart. Im Scartkabel ist keine direkte Verbindung mehr. Das funktioniert so super.
Das ist auch nicht das Problem hier.
Quote from: Rennert on 19. July 2019, 13:07:21
habe noch sequenc2 mal geladen, aber man hört nur Schnulli. Was muss man da hören?
[CPCEmulator]https://youtu.be/M7aI7KLEi1s[/CPCEmulator]
Acme DOS ist für das X-Mass, damit ich aufs Dom zugreifen kann.
Sollte eigentlich keine Probleme bereiten. Kann aber mal ausschalten, dann ist nur AMSDOS noch aktiv.
Den Mixer schaue ich mir mal an, aber meine Lösung funktioniert ja auch. Die Sprache ist eben nur aus anderen Speaker wie der Rest, außer bei originalen SPO. Sound klingt auch super über das LS3 und zum Scart dann.
Anleitung für das RSX ROM online:
https://cpcwiki.de/index.php?title=LambdaSpeak_III_ROM
Quote from: LambdaMikel on 18. July 2019, 06:45:31
- 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.
Quote from: LambdaMikel on 18. July 2019, 21:57:53
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?
Quote from: TFM on 19. July 2019, 16:51:45
Quote from: LambdaMikel on 18. July 2019, 06:45:31
- 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 :D
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
Quote
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...
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.
Quote from: LambdaMikel on 19. July 2019, 18:05:05
Quote from: TFM on 19. July 2019, 16:51:45
Quote from: LambdaMikel on 18. July 2019, 06:45:31
- 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 :D
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
Quote from: Rennert on 19. July 2019, 18:43:47
Quote from: TFM on 19. July 2019, 16:56:59
Quote from: LambdaMikel on 18. July 2019, 21:57:53
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?
Kann es sein, dass man die RTC nicht lesen kann wenn Kommando &F4 zuvor gesendet wurde?
(Nicht, dass das jetzt wichtig wäre). :)
Quote from: LambdaMikel on 19. July 2019, 18:05:05
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.
Quote from: TFM on 19. July 2019, 19:00:11
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.
Quote from: Rennert on 19. July 2019, 18:43:47
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...
Quote from: TFM on 19. July 2019, 16:51:45
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!! :winke0002: :jubelaola:
Quote from: TFM on 19. July 2019, 18:59:12
Quote from: Rennert on 19. July 2019, 18:43:47
Quote from: TFM on 19. July 2019, 16:56:59
Quote from: LambdaMikel on 18. July 2019, 21:57:53
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 :P
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]
;D ;D Nix fuer ungut - Spass muss sein! ;D
Ahhh, habe immer End the line verstanden. Also funzt der PCMTest.
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
Quote from: Rennert on 19. July 2019, 20:51:17
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" ?
eetest sagt:
...
eeprom cleared
größenangabe
...
eeprom cleared
eeprom pages written
eeprom pages ok
eeprom done
bei drumload scheint tatsächlich die Länge das Problem zu sein. habe mal eine Standardlänge von 2345 Bytes gemacht und er lädt die Files alle und spielt sie beim Laden ab. mit drummer mal sehen, aber paar wavs gehen.
Quote from: Rennert on 19. July 2019, 21:13:10
eetest sagt:
...
eeprom cleared
größenangabe
...
eeprom cleared
eeprom pages written
eeprom pages ok
eeprom done
bei drumload scheint tatsächlich die Länge das Problem zu sein. habe mal eine Standardlänge von 2345 Bytes gemacht und er lädt die Files alle und spielt sie beim Laden ab. mit drummer mal sehen, aber paar wavs gehen.
gut, eeprom geht noch (hatte ich ja auch getestet bevor losgeschickt).
drummer.bas zeigt dir die groessenangabe in pages. im array. die kannst mal 512 und dann hast du die anzahl bytes. die eigentlichen dateien sind aber u.u. kuerzer als das... die restlichen bytes muessen immer mit 127 aufgefuellt werden, bis die letzte seite voll ist. das ist das was in drumload.bas in zeile 440 passiert.
schau ich mal, hatte jetzt die Zeile 310 mit REM versehen und 311 Length=2345 festgesetzt als Test.
da blick ich nicht mehr durch, dazu sind meine Basic Kenntnisse zu gering 8)
Quote from: Rennert on 19. July 2019, 21:30:31
schau ich mal, hatte jetzt die Zeile 310 mit REM versehen und 311 Length=2345 festgesetzt als Test.
ok damit laedst du eben nur einen teil von jedem wav. dass problem bei drummer.bas ist, dass die fest einprogrammierten startseiten-addressen fuer die einzelnen trommeln nun nicht mehr stimmen. du muesstest dir also beim drumload.bas die "startpage" notieren und dann entsprechend die arrays anpassen in drummer. dann soltest du jede datei spielen koennen.
in zeile 210 in drummer.bas siehst du z.b. v[1]=11. das bedeutet, dass die 2. trommel bei seite 11 anfaengt. wenn du jetzt die laenge auf 2345 aenderst, aenderst du auch die startseiten.
ist mir leider zu hoch, kann nur die einfachen Sachen im Basic 8)
Zumindest weiß ich jetzt, das das PCM Abspielen geht.
warum läuft das nicht mit M4 Rom?
lade grad Drumload mit M4 Rom und fester Größenangabe zum Test und er lädt das rein.
habe das Drumload mal angepasst, vorher im Emulator das originale laufen lassen wegens der Werte.
Im Emulator lädt es alles mit den richtigen Werten, später mal am KCC testen.
10 OUT &FBEE,255
20 FOR i=1 TO 1000:NEXT
30 CLS
40 PEN 1
50 PRINT "Loading LambdaDrums into EEPROM Memory"
60 PRINT
70 PEN 3
80 PRINT "DOES NOT WORK WITH M4 FIRMWARE ROM"
90 PRINT "REQUIRES STANDARD AMSDOS OR PARADOS"
100 PEN 2
110 WAIT &FBEE,128
120 n$[0]="bd.wav"
125 l[0]=4435
130 n$[1]="snare.wav"
135 l[1]=6471
140 n$[2]="hhcl.wav"
145 l[2]=4174
150 n$[3]="hhop.wav"
155 l[3]=8208
160 n$[4]="clap.wav"
165 l[4]=7151
170 n$[5]="finger.wav"
175 l[5]=1559
180 n$[6]="ride.wav"
185 l[6]=21435
190 n$[7]="crash.wav"
195 l[7]=29112
200 n$[8]="lolotom.wav"
205 l[8]=5373
210 n$[9]="lotom.wav"
215 l[9]=5402
220 n$[10]="midtom.wav"
225 l[10]=5645
230 startpage=1
240 MEMORY &1FFF
250 FOR fi=0 TO 10
260 nn$=n$[fi]
265 ll=l[fi]
270 PRINT
280 PRINT "PCM: ",nn$
290 OUT &FBEE,&FE
300 LOAD nn$,&2000
310 REM length=VAL("&"+HEX$(PEEK(&A76E),2)+HEX$(PEEK(&A76D),2))
315 length=ll
320 pages=ROUND(length / 512)+1
330 PRINT "Bytes: ", length:PRINT "Pages: ", pages
340 n=startpage
350 PRINT "Start page: ", n
360 PRINT "Next start: ", pages + n
370 startpage=pages + n
380 WAIT &FBEE,32
390 OUT &FBEE,n
400 WAIT &FBEE,32
410 OUT &FBEE,pages
420 WAIT &FBEE,32
430 FOR i=&2000 TO &2000+length-1:a=PEEK(i):OUT &FBEE,a:NEXT
440 FOR i=&2000+length-1 TO &2000+(pages * 512):OUT &FBEE,127:NEXT
450 NEXT fi
Gute Idee!
Muss jetzt erstmal für ne Woche weg, versuche mich aber zwischenzeitlich mal hier zu melden.
Quote from: LambdaMikel on 20. July 2019, 04:23:23
Gute Idee!
Muss jetzt erstmal für ne Woche weg, versuche mich aber zwischenzeitlich mal hier zu melden.
Viel Spaß :)
Also mein Prog läuft ohne Probleme, jetzt höre ich mit drummer alle Instrumente richtig.
das ganze läuft auch mit aktiviertem M4 Rom :)
@tfm: bei pcmmode kommt der Cursor nicht zurück und z.B. auch drummer2 hängt dann bei dem Befehl. also dasselbe bei eeget und eeput
Congrats! Die gleiche Method kannst verwenden, um sequence2.bas anzupassen.
ja, tfm hat ja auch keinen kc kompakt wenn ich das richtig weiß, also konnt er das nie testen.
Stimmt sequenc2 gibt's ja auch noch
was macht denn das Prog. sequenc2 genau?
Also meinte, wenn ich es starte. müssen da die Files mit drumload schon eingelesen sein? muss erst den Sinn vom Prog verstehen 8)
Quote from: Rennert on 20. July 2019, 17:51:45
was macht denn das Prog. sequenc2 genau?
Also meinte, wenn ich es starte. müssen da die Files mit drumload schon eingelesen sein? muss erst den Sinn vom Prog verstehen 8)
Ich hatte oben mal das Video gepostet ;)
Hier noch mal
Einmal laden der Drums mittle drumload.bas reicht ja - ist ja nicht-flüchtiger Speicehr das EEPROM.
Wenn ich Drumload mache und danach sequenc2, bekomme ich memory full beim Laden.
Blicke leider bei dem Listing nicht so durch wo ich was ändern müsste. Das ist soviel vom einfachen Basic entfernt :binkybaby:
Warum willst Du denn drumload.bas schon wieder machen? Du hast das doch schon mal geladen! Du hattest doch gestern geschrieben, dass Du die Trommeln bereits gespielt hast mittels drummer.bas. Dann musst Du die nie wieder laden (es sein denn, Du löscht das EEPROM oder überschreibst was=. Einmal reicht, das bleibt doch im EEPROM erhalten auch nach Spannungsverlust / Ausschalten.
Also, KC Kompakt aus, dann an, dann sequence2.bas laden. Das ist alles :smiley027:
Du schaffst das schon! Einfach nur sequence2.bas nach Einschalten laden.
OK, nach Drumload einen Softreset und es lädt der Sequenzer2 ;D
Da braucht nix geändert werden, das läuft auch so am KCC. Dank Video weiß ich auch wie man Kreuze macht.
Super, viel Spaß damit... BASIC kommt da ein bisschen an seine Grenzen. Wenn Du volle Geschwindkeit machst, kannst Du nix mehr am Pattern ändern weil er dann keine Zeit mehr hat - alles Zeit geht dann in die "every ... gosub ..." Unterprogramme :D
Muss mal in Assembler geschrieben werden.
Ich vergaß das es ein EEprom ist ;D
Quote from: LambdaMikel on 19. July 2019, 19:01:11
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.
Nein, habe weder lese noch schreibe Fehler. Nur am Ende, nach dem lesen der letzten(!) Seite hängt er.
Quote from: Rennert on 20. July 2019, 10:11:47
@tfm: bei pcmmode kommt der Cursor nicht zurück und z.B. auch drummer2 hängt dann bei dem Befehl. also dasselbe bei eeget und eeput
Werde mir das mal ansehen und versuchen herauszufinden wo es Probleme gibt.
Quote from: Rennert on 20. July 2019, 21:50:45
Wenn ich Drumload mache und danach sequenc2, bekomme ich memory full beim Laden.
Blicke leider bei dem Listing nicht so durch wo ich was ändern müsste. Das ist soviel vom einfachen Basic entfernt :binkybaby:
Gib mal in BASIC folgendes ein:
PRINT HIMEM
Dann sagt er Dir die Speicherobergrenze, vielleicht ist die zu niedrig.
Danke TFM werde ich mal testen.
Wäre schön, wenn wir das mit PCMMODE, EEGET und EEPUT noch hinbekommen. Kann ja nicht soviel sein, wenn es mit der Basic Variante hinhaut.
Das ist ein großer Unterschied, BASIC ist 100-1000 mal langsamer. Leider hab ich auch keinen KCc, aber ich versuche es hinzubekommen. :) :) :)
EDIT: Worin unterscheiden sich CPC und KCc denn nun, dass es für den LS3 Unterschiede gibt?
Hat der KCc kein Wait Signal, so dass der LS3 den KCc nicht anhalten kann?
Gibt es sonnst noch etwas zu beachten?
@Rennert: Was genau läuft denn beim !EEUP schief?
der KCC reagiert wie bei PCMMODE und EEPUT nicht mehr. Deshalb geht auch DRUMLD2 und DRUMMER2 nicht, da hängt der KCC.
wie schon geschrieben, gehen die reinen Basic Progs ohne Probs, also Drumload und Drummer. das einzige was bei Drumload Probleme macht, ist die Berechnung der Byte Größe der Dateien, die musste ich festlegen für die einzelnen Dateien.
Ja, das hast schon gesagt, ich versuche mal die Frage präziser zu stellen. Was passiert wenn Du:
!EEUP,1000,1,1
eingibst?
Bleibt der CPC hängen?
Kann man mit Control+Shift+ESC einen Reset durchführen?
Es kommt die Sprachausgabe, aber kein Cursor zurück.
Softreset mit Tastenkombi geht.
Sagt er auch "Data altered into Eprom" ?
Ok, probier mal folgendes: Zuerst den Befehl !confoff eingeben.
Geht es dann?
Nein der Satz kommt nicht., das letzte ist was mit Page now oder so.
Mit conoff vorher geht auch nix
Ok, dann werden die Daten zu schnell übertragen... ein guter Ansatz zum debugging.
Nur... @LambdaMikel... wo soll ich hier ansetzen?
Bisher geht das so:
!EEUP - Funktionsweise:
- Wert &F9 an Port &FBEE schicken
- Warten bis LS3 Port &FBEE = &20 oder &80
- Start Page Nummer (0-255) an Port &FBEE schicken
- Warten bis LS3 Port &FBEE = &20 oder &80
- Anzahl Pages (1-256) an Port &FBEE schicken
- Kombiniertes Warten: Zuerst etwa 40 us warten, dann auf LS3 Port = &FF warten, dann 2,8 ms warten
X Daten-Wert aus RAM lesen und an LS3 Port senden
- Wenn noch nicht alle Daten transferiert sind, dann nach X springen (siehe oben)
- Wenn Fertig, dann:
- Warten bis LS3 Port &FBEE = &20 oder &80
Liebe LS3 Benutzer!
Bitte mal folgendes ausprobieren:
- Rechner und LS3 sind ausgeschalten (bzw. für 10 Sekunden ausgeschalten)
- CPC einschalten
- Befehl: OUT &FBEE,&DF eingeben
Fragen: Hängt er sich auf. Wenn nein, bitte 5 mal testen. Denn bei mir hängt es fast immer. Da ist ein Problem in der Firmware, warscheinlich setzt der LS3 den WAIT dauerhaft aktiv.
Bitte auch am KCc testen, ist der toleranter?
@tfm:
Ja der KCC hängt auch, nach LS3 Reset kommt dann der Cursor wieder
Danke, da hilft nur ein Firmware-Update. :winke0002:
Quote from: TFM on 24. July 2019, 23:52:43
Liebe LS3 Benutzer!
Bitte mal folgendes ausprobieren:
- Rechner und LS3 sind ausgeschalten (bzw. für 10 Sekunden ausgeschalten)
- CPC einschalten
- Befehl: OUT &FBEE,&DF eingeben
Fragen: Hängt er sich auf. Wenn nein, bitte 5 mal testen. Denn bei mir hängt es fast immer. Da ist ein Problem in der Firmware, warscheinlich setzt der LS3 den WAIT dauerhaft aktiv.
Bitte auch am KCc testen, ist der toleranter?
Hi Stefan,
das &DF hat aber nichts mit dem anderen Problem hier zu tun, oder? EEPROM-Bezug? Oder unabhaengig?
Stimmt, davon unabhängig. Es gibt noch ein paar Baustellen.
Hier eine weitere:
Bitte mal folgendes eintippen:
- CPC einschalten
!LAMBDA
!SP,"Hello this is a test":OUT &FBEE,&DE
Nun wird der Satz doppelt gesprochen. Das sollte aber wohl nicht so sein (denn das !SP Kommando sendet schon &0D am Ende).
Interessant. Gucke ich mir an, wenn ich wieder zu Hause bin.
Auch mal probiert und wird zweimal gesagt
Momentan arbeite ich an einem weiterem Problem. FutureOS kann jetzt Meldungen sprechen (z.B. bei Copy, I-Icon, OK-Icon, Space drücken etc), aber anstatt dass er spricht und sofort zurück kehrt, ist es so, dass er zu Ende spricht und erst dann den CPC weiterlaufen lässt.
Hier mal ein Beispiel, falls es interessieren sollte... siehe Anhang.
Klar, die Non-Blocking Sachen sind alle eingeschalten, trotzdem wartet der LS. Aber: Ich kann es mit BASIC nicht ganz so leicht rekonstruieren. Also guck ich hier auch mal was los ist.
EDIT: Es scheint so, daß die Abfrage des LS3 Status Port &FBEE dazu führt, daß auf Blocking umgeschalten wird. Habe zur Verdeutlichung mal die DSK "TEST-LS3" angehängt.
Die Sources TEST1 und TEST2 unterscheiden sich nur in Zeile 62! Bitte anschauen! Und bitte Firmware reparieren. :)
Hi Stefan,
bin wieder da... test1 und test2 sehe ich, aber load gibt mir "direct command found".
Was fuer Datein sind denn das? MAXAM?
Genau, Source für Maxam. Bitte alle meine Posts lesen, das mit dem "Einfrieren" bei !STOP gibt mir am meisten zu denken. :)
Hi TFM, |stop command sollte repariert sein. Anbei. Bitte testen.
LS3-TEST habe ich noch nicht angeschaut - one bug at a time. Vielleicht hat es sich ja in Wohlgefallen aufgelöst?
EDIT: OK, habe ich getestet. Prinzipiell ist es so, da LS3 keine Threads hat, dass solange LS3 spricht, keine anderen Kommandos abgearbeitet werden können, mit einer Ausnahme: STOP funktioniert. Reine Status-Abfragen sollten allerdings funktionieren. Der non-blocking mode ist also nur dazu da, dem CPC eine Gelegenheit gegeben wird, STOP zu senden (sonst würde er ja angehalten werden bis zu Ende gesprochen).
Nun, WALP macht mehr als nur lesen... sobald &80 gelesen wird, versucht er ein Kommando zu senden - nämlich Umschalten auf den EPSON Modus mittels &EF. Genau da blockiert er m.E. dann, solange er noch spricht. Anderseits zeigt &80 ja bereits an, dass er wieder bereit ist, Kommandos anzunehmen... hmm. Ich muss mal nachschauen, ob LS3 evtl. &80 ZU FRÜH sendet. Anscheinend zeigt er bereits &80 an, ist aber noch am Sprechen. Das sollten wir verhindern, um genau diesen Effekt zu vermeiden. Muss ich genauer anschauen.
Kommt &80 denn eigentlich SOFORT, auch wenn er noch spricht, im Non-Blocking Mode? Genau das wäre dann das Problem. Muss ich testen. Anderseits, vielleicht benötigt er eine etwas längere Zeitverzögerung zwischen &80 erscheint auf dem Bus, und nächstes Kommand kann gesendet werden. Ist es denn wirklich so, dass der CPC an dieser Stelle ANGEHALTEN wird?
Lass uns mal nur vom Epson Modus reden (vergiss alles mit &80, im SSA1 Modus ist das eh anders).
Ja, er sollte das sprechen starten und dann sofort &20 melden und die Kontrolle an den CPC geben, spricht also den CPC nicht auf WAIT setzen, dazu ist ja der non-blocking modus schließlich da. :)
Werde die neue Firmware jetzt mal testen...
Quote from: TFM on 31. July 2019, 18:30:16
Lass uns mal nur vom Epson Modus reden (vergiss alles mit &80, im SSA1 Modus ist das eh anders).
Ja, er sollte das sprechen starten und dann sofort &20 melden und die Kontrolle an den CPC geben, spricht also den CPC nicht auf WAIT setzen, dazu ist ja der non-blocking modus schließlich da. :)
Werde die neue Firmware jetzt mal testen...
Gut, und ich habe inzwischen gesehen, dass READY im EPSON modus sofort angezeigt wird im Non-Blocking mode. Auch wenn er noch spricht. Das ist natuerlich ein Problem. Wird behoben in der naechsten Firmware.
Wie gesagt, neuer Firmware behebt nur das STOP Problem.
Quote from: LambdaMikel on 31. July 2019, 18:39:15
Gut, und ich habe inzwischen gesehen, dass READY im EPSON modus sofort angezeigt wird. Auch wenn er noch spricht. Das ist natuerlich ein Problem. Wird behoben in der naechsten Firmware.
NEIN! Wir verstehen uns da falsch! Es ist ja RICHTIG, dass er &20 anzeigt, denn er darf ja ruhig sprechen und den CPC weiter machen lassen. Wir reden ja vom NON-blocking Modus. Oder hab ich den Faden verloren... ich guck's mir noch mal an.
Quote from: LambdaMikel on 31. July 2019, 18:39:15
Wie gesagt, neuer Firmware behebt nur das STOP Problem.
Problem behoben! Alles bestens! Danke!
Beispiel: Starte FutureOS (siehe Anhang) und drucke I oder O. Während er spricht kann man den Pfeil bewegen und er zeigt die Uhrzeit an. So soll es ja sein.
Quote from: TFM on 31. July 2019, 18:43:34
Quote from: LambdaMikel on 31. July 2019, 18:39:15
Gut, und ich habe inzwischen gesehen, dass READY im EPSON modus sofort angezeigt wird. Auch wenn er noch spricht. Das ist natuerlich ein Problem. Wird behoben in der naechsten Firmware.
NEIN! Wir verstehen uns da falsch! Es ist ja RICHTIG, dass er &20 anzeigt, denn er darf ja ruhig sprechen und den CPC weiter machen lassen. Wir reden ja vom NON-blocking Modus. Oder hab ich den Faden verloren... ich guck's mir noch mal an.
Beides richtig... wie gesagt, m.E. sollty READY &20 NUR angezeigt werden, wenn er wieder bereit ist, das naechste Kommando anzunehmen. Solange er noch spricht, ist das nicht der Fall, auch im Non BLocking Mode! Das einzige Kommando das funktioniert waehrend er spricht ist STOP.
Ich denke, wir moechten gerne einen READY Indikator, der anzeigt, dass JEDES Kommando wieder empfangen werden kann, und OHNE VERZOEGERUNG verarbeitet werden kann. Und da gibt &20 momentan den falschen Eindruck. STOP kann also jederzeit gesendet werden, OHNE dass man nach &20 testen muss, und ansonstent sollten im EPSON Modus erst wieder Kommandos gesendet werden, wenn &20 auf dem Bus ist. Was erst der Fall sein darf, wenn er mit Sprechen durch ist. Egal, ob Blocking oder nicht (na bei Blocking hat der CPC ja ohnehin keine Chance, VORHER was zu senden). Momentan wird &20 "zu frueh" auf den Bus gelegt.
Ja, glaube wir verstehen uns jetzt. :) Jedenfalls kann er ja schon z.B. die Uhr auslesen, während er spricht. Wenn das anders wäre, dann würde ja trotzdem das OS einfrieren. :)
Lassen wir es erst mal so, ich muss da noch testen...
Nebenbei: Wegen dem !STOP Problem, da wäre auch ein Firmware Uptdate für den 1.95 etc gut. (Falls !STOP nach dem 1. Einschalten auch alles einfriert). :smiley027:
Quote from: TFM on 31. July 2019, 18:51:36
Ja, glaube wir verstehen uns jetzt. :) Jedenfalls kann er ja schon z.B. die Uhr auslesen, während er spricht. Wenn das anders wäre, dann würde ja trotzdem das OS einfrieren. :)
Lassen wir es erst mal so, ich muss da noch testen...
Gute Beobachtung... das war mir gar nicht klar - aber jetzt, wo ich darueber nachdenke.
Ja, der Epson-Chip spricht prinzipiell alleine, und der ATMega kann machen. Wenn das Kommando das gesendet wird waehrend er spricht nichts mit dem Epson-Chip zu tun hat (z.B. Uhr), geht es prinzipiell. Nur alles was den Epson Chip involviert muss halt warten, bis er mit Sprechen durch ist, daher blockiert er dann.
Ok wunderbar.
Neues Problem: Sendet man einen Text (ohne &0D am Ende) und schickt dann &DE, dann spricht der LS zwar sofort, aber das letzte Zeichen wird unterschlagen. Man kann das in BASIC mit OUT Befehlen simulieren (im EPSON Modus getestet). Bitte beheben. Derweil arbeite ich drum herum, werde einfach &0D anstatt &DE senden, das sollte auch funktionieren.
Quote from: TFM on 31. July 2019, 20:06:43
Neues Problem: Sendet man einen Text (ohne &0D am Ende) und schickt dann &DE, dann spricht der LS zwar sofort, aber das letzte Zeichen wird unterschlagen. Man kann das in BASIC mit OUT Befehlen simulieren (im EPSON Modus getestet). Bitte beheben. Derweil arbeite ich drum herum, werde einfach &0D anstatt &DE senden, das sollte auch funktionieren.
Fixed.
Anbei auch für L195... bitte mal testen. Ist ebenfalls v41, aber natürlich ohne EEPROM und I2C etc. support.
Hab's beide gebrannt, und scheinen beide gut zu funktionieren. Die Fehler sind behoben, erstklassige Arbeit wie immer! :jubelaola: :jubelaola: :jubelaola:
Quote from: TFM on 01. August 2019, 18:17:27
Hab's beide gebrannt, und scheinen beide gut zu funktionieren. Die Fehler sind behoben, erstklassige Arbeit wie immer! :jubelaola: :jubelaola: :jubelaola:
Danke und freut mich!
Soll ich jetzt noch die Sache mit dem &20 Ready aendern?
Quote from: LambdaMikel on 01. August 2019, 18:39:43
Soll ich jetzt noch die Sache mit dem &20 Ready aendern?
Lass uns das erst mal gedanklich durchspielen, wir wollen ja auch kompatibel bleiben. Bitte um Ideen ;-)
Nebenbei, das hier können wir dank LS ja jetzt besser...
Top! Aber schwierig zu verstehen...ja LS würde etwas verständlicher klingen :bgdev:
OK, dann lassen wir's erstmal so. Du kannst ja sonst zur Sicherheit immer STOP senden um nicht in die Warte-Situation zu kommen.
Momentan bin ich Dank der Hitze meist recht lätscherd (= faul, träge, unlustig). Bin froh, wenn die Dinge laufen. Mir ist's lieber mal ein paar kleine sichere Schritte vorwärts zu machen, als nochmal etwas "größeres" zu ändern. Das können wir aber immer noch machen. :)
Wegen dem KCc (siehe viele Mitteilungen hier zuvor), da weiß ich nicht wo ich ansetzen soll. Es geht ja auch nicht, dass ich dem Rennert mal schnell 21 DSKs schicke und sage "Guck mal, ob eines davon funktioniert". Mal sehen, ob da noch jemand von Euch eine zündende Idee hat. :)
Quote from: TFM on 02. August 2019, 15:49:23
Momentan bin ich Dank der Hitze meist recht lätscherd (= faul, träge, unlustig). Bin froh, wenn die Dinge laufen. Mir ist's lieber mal ein paar kleine sichere Schritte vorwärts zu machen, als nochmal etwas "größeres" zu ändern. Das können wir aber immer noch machen. :)
Wegen dem KCc (siehe viele Mitteilungen hier zuvor), da weiß ich nicht wo ich ansetzen soll. Es geht ja auch nicht, dass ich dem Rennert mal schnell 21 DSKs schicke und sage "Guck mal, ob eines davon funktioniert". Mal sehen, ob da noch jemand von Euch eine zündende Idee hat. :)
Die einzige Idee die ich noch hätte wäre ihm eine Version der |eeup etc. Kommandos bereitzustellen, die es ermöglicht, Verzögerungszeiten einzustellen. Könnte ja gerne einfach eine Reihe von 16 Bit Wert irgendwo im Speicher sein den man von BASIC aus POKEn kann und der dann zu Verzögerungen in ms o.ä. an kritischen Programmstellen z.B. bei EEUP und EEGET führt (Verzögerung nach 256 bzw. 512 gelesenen / gesendeten Bytes etc.) Dann könnte er ausprobieren mit welchen Werten es funktioniert und wir hätten ne Idee.
Programmmäßig wäre das ja einfach nur ein Unterprogramm CALL an bestimmten Stellen, sollte also nicht zu schwierig sein das einzubauen. Und falls Unterprogrammaufrufe den Stack durcheinanderbringen, hat der MAXAM eigentlich Macros?
Wie viel muss man denn zählen beim CPC damit 1 ms Verzögerung kriegt in Z80?
Muss mal wieder in die Sourcen gucken am WE - machst Du inzwischen die Verzögerung nach
512 gesendeten Bytes bei EEGET und RESUME (und natürlich auch bei EEUP und HIBERNATE nach
256 Bytes? )
Ich weiß, Du kanst kein C lesen, aber hier ist nocheinmal die Schleife für EEGET und RESUME funktioniert genauso, siehe C-Kommentare; Details sind nicht so wichtig, einfach nur den groben Ablauf angucken und die Kommentare sind das wichtigste:
// bis all bytes gesendet:
while (pcm1_address < pcm1_endAddress) {
// 0 auf den Bus -> busy
speech_native_busy;
// CPC anhalten, Puffer mit EEPROM DAten füllen
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;
LAMBDA_EPSON_ON;
// Puffer ist gefüllt, Z80 weiterlaufen lassen
z80_run;
// &20 auf den Bus -> bereit, nächste Seite zu lesen
speech_native_ready;
// für 512 Bytes:
for(uint16_t i = 0; i < ((uint16_t) EEPROM_BYTES_PER_PAGE * 2); i++) {
// LEDS_ON;
// warte bis nächstes Byte angefordert wird mittels out &fbee,<beliebig>
loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);
// z80_halt;
// LEDS_OFF;
if (i < SEND_BUFFER_SIZE) {
byte = send_msg[i];
} else {
byte = buffer[i - SEND_BUFFER_SIZE];
}
// lege das nächsste Byte aus dem Puffer auf den Bus
DATA_TO_CPC(byte);
// z80_run;
}
// Seite komplett gesendet, mach weiter in WHILE Schleife oben
// bis alle Bytes gesendet worden sind -
// kuze Verzögerung hier (fast / slow / medim getters!!) da oben
// gleich wieder 0 für Busy und dann &20 für READY auf dem Bus
// erscehint, und wir dürfen das 512. Byte der Seite ja nicht verpassen
// HIER muss der CPC nun etwas warten, obwohl ich ihn ja sogar anhalte...
// needed, otherwise the last byte will not appear long enough on the databus!
CPC_READ_DELAY;
}
Und hier ist nocheinmal die UPLOAD EEUP / HIBERNATE Prozedur - bitte beachten, hier sind es 256 Bytes, nicht 512 nach denen eine kleine Verzoegerung erfolgen sollte:
uint8_t byte = 0;
// bis noch nicht alle Bytes gesendet wurden:
// EVTL. SOLLTE ICH HIER BUSY (0) auf den Bus legen, damit Du nicht zu früh sendest!
// Werde ich noch einmal ändern...
while (pcm1_address < pcm1_endAddress) {
EEPROM_writeEnable();
SLAVE_SELECT;
SPI_tradeByte(EEPROM_WRITE);
EEPROM_send24BitAddress(pcm1_address);
// Bereit für 256 Bytes -> &20 auf den Bus
speech_native_ready;
// Empfange 256 Bytes:
for (int i = 0; i < EEPROM_BYTES_PER_PAGE; i++) {
z80_run;
// warte auf Byte mittels out &fbee,<byte>
loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);
loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
// z80 anhalten
z80_halt;
// _delay_us(3);
// byte einlesen, liegt ja auf dem Datenbus
DATA_FROM_CPC(byte);
// byte ins EEPROM schreiben
SPI_tradeByte(byte);
pcm1_address++;
}
// EEPROM seite vollends gesendet (256 bytes), jetzt 0 auf den Bus -> BUSY
speech_native_busy;
// WARTEN bis EEPROM Puffer weggeschrieben wurde
SLAVE_DESELECT;
while (EEPROM_readStatus() & _BV(EEPROM_WRITE_IN_PROGRESS)) {};
// bis alle Seiten geschrieben worden sind (s. WHILE oben)
}
// alle Bytes wurden gesented -> Busy
speech_native_busy;
// anhalten, dann Bestätgung sprechen etc., zurück
z80_halt;
Ganz klar, SENDE der Daten ist einfacher, da Du nicht zwischen READY/ BUSY und Nutzbyte auf dem Datenbus unterscheiden musst.
Ich moechte die Firmware ungerne noch aendern. Sonst koennten wir auch probieren, ob wir aus BUSY und READY komplett verzichten, oder ob ich nicht Z80 RUN und HALT konsistent und brutal verwende. Oder aber HALT und RUN komplett raus. Momentan wird beides verwendet, was etwas inkonsistent ist. Na, kann ja auch verstehen, wenn Du erstmal keinen Bock mehr hast auf das Problem - ich kann mich ja auch noch mal ransetzten irgendwann, aber momentan arbeite ich an einem MIDI IN fuer den CPC, sodass man AY mittels Keyboard spielen kann. Das geht auch nur in Z80, gar nicht so einfach fuer einen wie mich!
Das könnte helfen...
Würde also 4 16 Bit Werte v1, v2, v3, v4 vorschlagen:
- EEGET, RESUME: Leseverzögerung in v1 us nach jedem Byte. Default 5 us.
- EEGET, RESUME: Leseverzögerung in v2 ms nach 512 Bytes. Default 50 ms.
- EEUP, HIBERNATE: Schreibverzögerung in v3 us nach jedem Byte. Default 5 us.
- EEUP, HIBERNATE: Schreibverzögerung in v4 ms nach 512 256 (!) Bytes. Default mit 50 ms.
Wenn ich ausm Urlaub wieder da bin, kann ich auch wieder testen.
Genau, aber zuerst sollte es einmal bei mir funktionieren. Wenn es auf einem normalen CPC nicht richtig funktioniert, brauchst gar nicht est testen am KC Compact...
Quote from: LambdaMikel on 02. August 2019, 18:19:59
Genau, aber zuerst sollte es einmal bei mir funktionieren. ...
Klaro, Source ist ja im Netz, Dokumentiert ist es auch... und bei Fragen bin ich immer gerne da. :)
Leider hat es wohl mit dem Firmware Update einen (neuen?!) Bug gegeben. Es äußert sich folgerdermaßen:
- Wenn ich FutureOS laufen lasse / benutze, dann friert die Oberfläche nach einiger Zeit ein.
- Drücke ich Reset am LS3, dann geht es weiter... (aber hald mit LS3 uninitialisiert).
- Drücke ich Reset am CPC, dann passiert nix (außer MODE Anderung), also ist wohl der CPC durch WAIT vom LS3 blockiert. Hier hilft ein Reset am LS3.
Was könnte los sein?
- Unter FutureOS wird ständig die LS3 RTC abgefragt, und da scheint es zu hängen.
- Wenn ich auf das LED-Display gucke, dann zeigt das Werte wie &D3, &D4, &D5, &D7, &D9.
Michael, könntest Du bitte mal in die LS3 Firmware Funktionen &D3 bis &D9 schauen, ob da manchmal WAIT gesetzt - aber nicht zurück gesetzt wird?
Es könnte sein, dass es damit zusammenhängt, dass ich kurz zuvor Funktion &F4 nutze.
Bitte um Hilfe! :flehan: :flehan: :flehan:
Hmm, also es gibt in diesem Zyklus eigentlich nur einen einzigen z80_halt, und der passiert sobald ein Byte am Datenbus ankommt. Dass Byte wird dann entweder weggepuffert fürs Sprechen, oder aber wenn es ein Kontroll-Byte ist, geht es in process_control - dort wird es dispatched. In proces_control wird der Z80 sofort wieder freigegeben mittels z80_run, WENN non blocking confirmations an sind:
void process_control(uint8_t control_byte) {
LEDS_ON;
stop();
if (NON_BLOCK_CONFIRMATIONS) {
z80_run;
}
...
}
LS3 Epson Hauptschleife:
while (1) {
TRANSMIT_OFF;
READY_ON;
speech_native_ready;
z80_run;
loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE);
DATA_FROM_CPC(databus);
loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE);
z80_halt;
speech_native_busy; // to 0...
TRANSMIT_ON;
READY_OFF;
if (databus & 0b10000000 ) {
if (databus == 0xF0) {
// do nothing for next byte! just for databus LED display
loop_until_bit_is_set(IOREQ_PIN, IOREQ_WRITE_DK);
_delay_us(3); // don't change... it works
DATA_FROM_CPC(databus);
loop_until_bit_is_clear(IOREQ_PIN, IOREQ_WRITE_DK);
} else {
process_control(databus);
if (!BLOCKING)
z80_run;
if (CUR_MODE != LAST_MODE) {
if (CUR_MODE == START_OVER_SAME_MODE)
CUR_MODE = LAST_MODE;
else
LAST_MODE = CUR_MODE;
break;
}
}
} else {
....
}
Das einzige z80_halt passiert also direkt nach Empfang eines Bytes, wird aber sofort wieder frei gegeben im Falle eines Kontroll-Bytes. Wenn allerdings die LS3 Hardware abschmiert... das ist momentan das einzige, was ich mir vorstellen kann.
Wie oft pro Sekunde sendest Du denn die Uhrzeitabfrage? Evtl. etwas moderater in der Abfrage-Frequenz, passiert es dann auch?
Ich frage die Uhr locker 50x in der Sekunde ab, aber selbst wenn ich nur einmal abfragen würde, wo wäre der Vorteil? Der Fehler tritt hald dann eventuell später auf.
Wann tritt der Fehler auf? Manchmal nach Sekunden, manchmal nach 1-2 Minuten.
Der Source von Dir sagt mir nix, das ist kein Z80, sorry. Es scheint so als ob das Z80 HALT in seltenen Fällen nicht zurückgenommen wird. Bitte einfach mal selber ausprobieren.
Eventuell hängt es mit einem Interrupt der Atmel CPU zusammen?
Das Problem hat in der Firmware zuvor ja nicht bestanden, guck mal was sich geändert hat. :)
Quote from: TFM on 08. August 2019, 17:01:47
Ich frage die Uhr locker 50x in der Sekunde ab, aber selbst wenn ich nur einmal abfragen würde, wo wäre der Vorteil? Der Fehler tritt hald dann eventuell später auf.
Wann tritt der Fehler auf? Manchmal nach Sekunden, manchmal nach 1-2 Minuten.
Der Source von Dir sagt mir nix, das ist kein Z80, sorry. Es scheint so als ob das Z80 HALT in seltenen Fällen nicht zurückgenommen wird. Bitte einfach mal selber ausprobieren.
Eventuell hängt es mit einem Interrupt der Atmel CPU zusammen?
Das Problem hat in der Firmware zuvor ja nicht bestanden, guck mal was sich geändert hat. :)
Hmm, also in der Beziehung hat sich aber nichts geaendert in der Firmware. Ist diese Version von FOS online? Dann kann ich es selbst mal laufen lassen.
Nach welcher Zeit tritt denn das auf.
Und welche Version Firmware verwendest Du nun? Slow, Medium, oder Fast Getters?
Stellst Du denn sicher, dass Du das naechste &D3..D9 Kommando erst sendest, wenn der LS3 wieder bereit ist? Diesen Fall koennte man einfach verhindern indem man die Uhr nur alle 500 ms oder so aufruft.
Quote from: LambdaMikel on 08. August 2019, 17:16:54
Quote from: TFM on 08. August 2019, 17:01:47
Ich frage die Uhr locker 50x in der Sekunde ab, aber selbst wenn ich nur einmal abfragen würde, wo wäre der Vorteil? Der Fehler tritt hald dann eventuell später auf.
Wann tritt der Fehler auf? Manchmal nach Sekunden, manchmal nach 1-2 Minuten.
Der Source von Dir sagt mir nix, das ist kein Z80, sorry. Es scheint so als ob das Z80 HALT in seltenen Fällen nicht zurückgenommen wird. Bitte einfach mal selber ausprobieren.
Eventuell hängt es mit einem Interrupt der Atmel CPU zusammen?
Das Problem hat in der Firmware zuvor ja nicht bestanden, guck mal was sich geändert hat. :)
Hmm, also in der Beziehung hat sich aber nichts geaendert in der Firmware. Ist diese Version von FOS online? Dann kann ich es selbst mal laufen lassen.
Nach welcher Zeit tritt denn das auf.
Und welche Version Firmware verwendest Du nun? Slow, Medium, oder Fast Getters?
Stellst Du denn sicher, dass Du das naechste &D3..D9 Kommando erst sendest, wenn der LS3 wieder bereit ist? Diesen Fall koennte man einfach verhindern indem man die Uhr nur alle 500 ms oder so aufruft.
- Neueste FutureOS Version gestern online geladen, siehe Forum Thread
- Firmware: Natürlich neuestes Update v41
- Fast Getters
- Klar warte ich bis LS &20 meldet
:)
So habe nochmal v40 geflasht und getestet.
Das Problem mit dem Einfrieren des CPC (da hilft auch kein Reset) tritt von Firmware v40 auf v41 auf.
Einfach mal FutureOS starten, warten bis alles steht, dann auf CPC Reset drücken. Erst der Druck auf LS3 Reset hilft da.
Bitte alle mal ausprobieren, ob das Problem reproduziert werden kann.
Danke für jegliche Hilfe :)
EDIT: Es passiert bei v40 auch, nur viel seltener und viel später... :irre:
Quote from: TFM on 09. August 2019, 15:16:35
So habe nochmal v40 geflasht und getestet.
Das Problem mit dem Einfrieren des CPC (da hilft auch kein Reset) tritt von Firmware v40 auf v41 auf.
Einfach mal FutureOS starten, warten bis alles steht, dann auf CPC Reset drücken. Erst der Druck auf LS3 Reset hilft da.
Bitte alle mal ausprobieren, ob das Problem reproduziert werden kann.
Danke für jegliche Hilfe :)
EDIT: Es passiert bei v40 auch, nur viel seltener und viel später... :irre:
Ja ich denke das hat nichts mit v41 vs v40 zu tun... ich werde es mal laufen lassen am WE. Wie lange braucht es bis es einfriert?
Ich hatte ASMCLOCK auch sehr lange laufen lassen,und keinen solchen Effekt.
... also habe gerade FOS neuste Version runtergeladen und installiert.
Uhr läuft schon seit 15 Minuten 20 Minuten mit v47 Firmware ohne Probleme - muss jetzt zur Arbeit...
Wie lange muss ich denn warten?
Sprachausgabe ist ja witzig! Stimme ist nicht so mein Fall... sagt er da "Medium In?"
Ich hänge v47 hier noch mal an. Ich glaube aber nicht, dass sich irgendetwas geändert hat zwischen 39 bis 47 das den Effekt erklären könnte... ich lasse es mal über Nacht laufen.
Gut dass ich jetzt 3 XMem habe... da kann ich schnell mal was testen und wechseln.
Meine Config ist 6128, XMem und LS3, am ToTO-MotherX4 ohne Diode.
Also, FOS und Uhr laufen jetzt seit über 3 Stunden, und keine Verklemmung. Muss ich noch länger warten?
Evtl. liegt es bei Dir an etwas anderem im Setup?
Nee, wie geschrieben, es ist weniger als 1 Minute. Werde die v47 brennen und dann berichten. :)
Quote from: TFM on 12. August 2019, 11:42:03
Nee, wie geschrieben, es ist weniger als 1 Minute. Werde die v47 brennen und dann berichten. :)
OK, dann ist es definitiv was anderes bei Dir. Evtl. Harware-Defekt... sonst musst Du LS3 einsenden.
@TFM, wie waere es wenn ich Dir einen 2. LS3 schicke... dann kannst Du damit gegenpruefen.
Zudem waere dass dann eine Version mit Serial UART Pins... waere ja schoen wenn Du auch die serielle unterstuetzen wuerdest in Software.
Sollte sowas wie mit Usifac (Programme reinladen) nicht auch mit LS3 gehen?
Und, hast Du alle anderen Karten / Erweiterungen rausgenommen beim Testen? Waere ja schoen wenn @Rennert auch mal die FOS Uhr im Dauerbetrieb testen koennte. Wie gesagt, bei mir laeuft das stundenlang ohne Probleme.
was muss ich im FOS machen zum Test?
habe jetzt bei der Konfiguration von FOS die RTC Rom Nummer auf 114 genommen. was muss ich für die RTC vom LS3 nehmen?
Quote from: Rennert on 12. August 2019, 19:52:04
was muss ich im FOS machen zum Test?
habe jetzt bei der Konfiguration von FOS die RTC Rom Nummer auf 114 genommen. was muss ich für die RTC vom LS3 nehmen?
Aeeh... gar nix? Ich hatte FOS Installer runtergeladen, rauf aufs XMem mit Default Einstellungen, und schon war es installiert. Und die Uhr kommt auch gleich.
Mit ROM-Positionen kenne ich mich nicht aus.
ich ändere immer die Farben, deshalb stelle ich da was ein.
Muss ich mal warten bis TFM antwortet. 114 ist vom CPC RTC Modul was ich noch habe, das M4 Wifi hat ja auch RTC noch
Wenn Du M4 drinne hast, hat die M4 RTC Prioritaet.
Musst also ohne M4 testen.
Kann grad nix mehr aufs XMem machen, der 39SF040 lässt sich nicht mehr beschreiben und löschen. Hab auch nur noch die schmaleren 29SF040 PLCCs oder im DIP Gehäuse da.
Quote from: LambdaMikel on 12. August 2019, 16:12:23
Quote from: TFM on 12. August 2019, 11:42:03
Nee, wie geschrieben, es ist weniger als 1 Minute. Werde die v47 brennen und dann berichten. :)
OK, dann ist es definitiv was anderes bei Dir. Evtl. Harware-Defekt... sonst musst Du LS3 einsenden.
IMHO liegt es nicht an der Hardware.
Der Test mit der Firmware v47 ist am schlimmsten, es dauert nur ca. 10 Sekunden bis der LS3 den CPC auf HALT setzt und dann geht nix mehr bis ich den LS3 zurücksetzte.
Wenn ich die Uhr unter FutureOS nicht abfrage, dann passiert auch nichts.
Folglich ist also das Problem die Abrage der RTC. Dabei scheint irgendwann der CPC auf Halt gesetzt zu werden. Und die Firmware "vergisst" das HALT wieder zurück zu nehmen.
@TFM: wie wird denn die Uhr vom LS3 unter FOS abgefragt?
Wie schon geschrieben, habe ich im FOS Installer den Port der RTC auf 114 gesetzt von der CPCRTC Karte. Weiß ja nicht was drinsteht ohne Änderung.
Quote from: Rennert on 13. August 2019, 14:46:36
@TFM: wie wird denn die Uhr vom LS3 unter FOS abgefragt?
Wie schon geschrieben, habe ich im FOS Installer den Port der RTC auf 114 gesetzt von der CPCRTC Karte. Weiß ja nicht was drinsteht ohne Änderung.
Das ist jetzt ein Unterschied. Die Nummer der Uhr muss man ja nur für die Dobbertin (bzw. dxs) RTC setzten. Steht ja auch so im Konfig. :)
Wenn das FutureOS erkennt, dass ein LS angeschlossen ist, dann wird auch angenommen, daß eine Uhr dabei ist.
OK, nochmal ganz deutlich:
Man kann auch unter BASIC die RTC des LS3 abfragen, und es gibt Probleme, einfach mal das Kommando des LS3 ROMs nutzen und einige Minuten warten.
1 bla:!gettime,bla:?bla
2 goto 1
:smiley027:Muss ich das in Zeile 1 so hinschreiben wie du es gepostet hast?
Weil dann kommt Syntax error in 1
! natürlich der Strich
habs das jetzt so gemacht:
1 hr%=0:mi%=0:sec%=0.lgettime,@hr%,@mi%,@sec%:print hr%,mi%,sec%
2 goto 1
das Prog läuft jetzt seit längerer Zeit. es wird immer 255 angezeigt, ist das so korrekt?
Datum und Uhrzeit stimmt, bigwatch und saytime sagtb alles richtig an.
Firmware ist V47
X-Mem geht wieder, hab Mist gebaut ;D
wollte am PC die Datei in den Xilinx flashen, klar geht das nicht. Am MegaFlash habe ich so PLCC 39SF040, am X-Mem sinds ja 40polige normale. hab jetzt nur LS3 Rom und das FOS drauf. FOS läuft jetzt ne ganze Weile ohne Probs, die Uhrzeit läuft weiter.
Quote from: Rennert on 13. August 2019, 17:31:36
habs das jetzt so gemacht:
1 hr%=0:mi%=0:sec%=0.lgettime,@hr%,@mi%,@sec%:print hr%,mi%,sec%
2 goto 1
das Prog läuft jetzt seit längerer Zeit. es wird immer 255 angezeigt, ist das so korrekt?
Datum und Uhrzeit stimmt, bigwatch und saytime sagtb alles richtig an.
Firmware ist V47
Nein, vorher bitte |lambda eintippen, sonst geht die Uhr nicht.
alles klar, lasse es jetzt mal paar Stunden laufen
Ok, nach vielen Tests habe ich wohl (97%) das Problem gefunden, es liegt an der Stromversorgung. Wenn die schwach ist läuft zwar "fast immer" alles, aber der Fehler mit der Uhrabfrage taucht auf.
Wenn ich z.B. einen CTM anstatt einem GT nutze, dann läuft alles prima, ganz ohne Fehler.
Habe mehrere Monitore und Keyboards, mit / ohne externen Netzteilen getestet.
Da wäre es cool, wenn man für den CPC so eine Art Wachhund hat, der im Notfall die Meldung "Problem mit der Stromversorgung" ausgibt.
ja bei mir läufts schon seit 3 Stunden, trotz allen gesteckten Modulen. Meine Buskarte hat eh ne extra Stromversorgung.
Quote from: TFM on 13. August 2019, 21:02:04
Ok, nach vielen Tests habe ich wohl (97%) das Problem gefunden, es liegt an der Stromversorgung. Wenn die schwach ist läuft zwar "fast immer" alles, aber der Fehler mit der Uhrabfrage taucht auf.
Wenn ich z.B. einen CTM anstatt einem GT nutze, dann läuft alles prima, ganz ohne Fehler.
Habe mehrere Monitore und Keyboards, mit / ohne externen Netzteilen getestet.
Da wäre es cool, wenn man für den CPC so eine Art Wachhund hat, der im Notfall die Meldung "Problem mit der Stromversorgung" ausgibt.
Na da fällt mir ein Stein vom Herzen... Zur Not sonst LS3 Netzteil anschließen Polarität wie bei CPC natürlich 20 A 5V Starkstrom😀
Quote from: LambdaMikel on 13. August 2019, 18:05:41
Quote from: Rennert on 13. August 2019, 17:31:36
habs das jetzt so gemacht:
1 hr%=0:mi%=0:sec%=0.lgettime,@hr%,@mi%,@sec%:print hr%,mi%,sec%
2 goto 1
das Prog läuft jetzt seit längerer Zeit. es wird immer 255 angezeigt, ist das so korrekt?
Datum und Uhrzeit stimmt, bigwatch und saytime sagtb alles richtig an.
Firmware ist V47
Nein, vorher bitte |lambda eintippen, sonst geht die Uhr nicht.
Und momentan bitte auch !GETMED, aber in wenigen Tagen will ich ein schnelleres ROM machen, dann ist das nicht mehr nötig.
Danke für das mit-testen, die Spannungsschwankungen/mengen sind wohl schuld.
Was macht das Getmed? Habe ich noch nie benutzt.
Mit !GETFAST, !GETMED bzw. !GETSLOW wird bestimmt wie schnell der LS3 Daten an den CPC / KCc überträgt. Das ist für schnellen, normalen Maschinen Code bzw. für BASIC Programme.
Steht auch im Handbuch noch etwas ausführlicher.
@Michael: Soll !GETTIME, !GETDATE automatisch auf Epson Modus umschalten?
Quote from: TFM on 13. August 2019, 22:19:36
Mit !GETFAST, !GETMED bzw. !GETSLOW wird bestimmt wie schnell der LS3 Daten an den CPC / KCc überträgt. Das ist für schnellen, normalen Maschinen Code bzw. für BASIC Programme.
Steht auch im Handbuch noch etwas ausführlicher.
@Michael: Soll !GETTIME, !GETDATE automatisch auf Epson Modus umschalten?
Ich denke, dass wäre ganz praktisch! :smiley027:
Gut, so soll es sein. Das Update ist oben. Angepasst an die schnelle v47 Firmware. Getestet und scheint alles zu laufen. :)
hab heute das RTC Modul abgemacht und FOS gestartet,die Uhrzeit und Datum war alles 0. einmal mit M4 und einmal X-Mem, alles 0
Woran kann das liegen?
Quote from: Rennert on 14. August 2019, 22:43:01
hab heute das RTC Modul abgemacht und FOS gestartet,die Uhrzeit und Datum war alles 0. einmal mit M4 und einmal X-Mem, alles 0
Woran kann das liegen?
Du meinst wenn Du das RTC Modul vom LS3 abklemmst kriegst Du keine Uhrzeit?? Nun, das verwundert mich nicht... :zunge0020: aber das meinst Du wohl nicht, oder?
I hatte das auch schon gehabt dass er die Uhrzeit zurueck auf 0 setzt... wenn Spannungsschwankungen oder Batteriewackler sind oder auch wenn das MP3 Module an/abgeklemmt wird (mit Kabeln).
nein meinte das CPCRTC Modul, aber habs gefunden. Hatte doch Rom Nummer 114 konfiguriert dafür. hab nochmal den Installer laufen lassen, jetzt gehts.
Quote from: TFM on 14. August 2019, 21:49:42
Gut, so soll es sein. Das Update ist oben. Angepasst an die schnelle v47 Firmware. Getestet und scheint alles zu laufen. :)
Laeuft das neue LS3 ROM auch mit dem alten v41 LS3 Firmware?
Waere gut wenn wir auch die v41 Version behalten koennten, denn das ist wohl die Version, die ChinnyVision testen wird. Da waere es gut, wenn diese Version vom LS3 ROM erhalten bliebe.
Die hab ich nimmer, probier's aus. Es sollte aber alles auch laufen. Denn nach dem Kommando senden warte ich ca. 5 us, das sollte für jeder FW funktionieren.
@Rennert: Danke, mit der Uhr müsste jetzt alles bestens laufen. Aber Du kannst auch einfach im "Konfig OS" die Echtzeituhr auf "keine" setzen, dann erkennt er die CPCRTC von dxs bzw. des M4 nicht, die vom LS3 aber trotzdem.
Ahhh super, da kann ich Port 114 lassen und dann im FOS abschalten.
Jetzt habe ich ja nur noch das Problem mit PCMMODE und EEUP, da kommt kein Cursor zurück und somit hängts. EEGET muss ich nochmal testen.
Ja, das ist jetzt das vordringlichste Problem. Bin jetzt übers WE mal im "Urlaub", aber dann guck ich mir das alles noch mal an und schicke Dir mal einen Test.
na da erhole dich mal ;D
Das Problem rennt nicht weg 8) 8) 8)
Quote from: TFM on 15. August 2019, 13:00:29
Ja, das ist jetzt das vordringlichste Problem. Bin jetzt übers WE mal im "Urlaub", aber dann guck ich mir das alles noch mal an und schicke Dir mal einen Test.
Mein Tipp ;) Mach die Zeitverzoergerungen rein und dann einstellbar, dann kann der @rennert das selbst rausfinden was geht.
Und hier noch einmal eine Gelegenheit einen zu erwerben - nach diesem gibt's er mal keinen bis Ende November oder so:
https://www.ebay.de/itm/Schneider-CPC-Erweiterungskarte-LambdaSpeak-3-MP3-UART-Speech-Synth-Samples/193054275914?hash=item2cf2ee794a:g:SCoAAOSwOFFdWOMt
Der Wievielte ist denn das bisher?
Quote from: TFM on 19. August 2019, 22:59:27
Der Wievielte ist denn das bisher?
Na ja, also
- 3 bei mir (davon 1 Prototyp mit angelöteten Kabeln und so)
- 3 nach D (Du, Rennert, Bryce)
- 2 nach Australien
- 2 nach Spanien
- 2 nach England
Also Nr. 13. Oder 12 wenn man den Prototyp nicht mitzählt.
Das müssen noch viel mehr werden. :smiley027:
Quote from: TFM on 19. August 2019, 23:10:24
Das müssen noch viel mehr werden. :smiley027:
... ja schon, aber wer soll die alle zusammen bauen. Bin ja nicht ToTO :zunge0020:
Bin ganz froh dass es nicht mehr Kaeufer gibt; ich brauche ca. 3 Std. fuer ein Exemplar... ist aufwaendig.
Na, dann verkaufe doch Bausätze. Ist ja kein Problem.
Jedenfalls finde ich es nicht so cool Wochen für Software zu investieren, die dann nur von weniger als 10 Leuten benutzt wird.
Ja, schon klar, es ist alles im Netz. Nur hilft es da nicht so viel. Denn irgendjemand muss immer ein paar Sachen koordinieren (Platinen kaufen, CPUs programmieren etc.). Ich würde da ja gerne helfen, aber es ist ja dein Kind. :020:
Quote from: TFM on 20. August 2019, 17:41:31
Na, dann verkaufe doch Bausätze. Ist ja kein Problem.
Jedenfalls finde ich es nicht so cool Wochen für Software zu investieren, die dann nur von weniger als 10 Leuten benutzt wird.
Ja, schon klar, es ist alles im Netz. Nur hilft es da nicht so viel. Denn irgendjemand muss immer ein paar Sachen koordinieren (Platinen kaufen, CPUs programmieren etc.). Ich würde da ja gerne helfen, aber es ist ja dein Kind. :020:
Ja klar, die Resonanz ist immer enttäuschend... ich mache die Hardware-Entwicklung in erster Linie weil es ein Hobby ist. Es scheint in der CPC-Gemeine mehr darum zu gehen, WER was macht, als WAS gemacht wird...
Wir können ja gerne versuchen, eine Liste von Käufern / Vorbestellungen zusammen zu kriegen. ToTO hatte innerhalb von 2 Wochen mehrere Dutzend potentielle Käufer für seinen French-Only Speech Synth, den er dann erstmal auf Eis gelegt hat (?) Aber das ist eben weil es von ToTO und aus Frankreich kommt. Denke ich mal.
Na, eine Liste kann ja nicht schaden. Allerdings will ich LS3 auch nicht wie warm Sauerbier anpreisen - ich glaube je mehr wir das machen, desto weniger Interessenten gibt es. Da scheint es ein paar interessante psychologische Effekte in der CPC Community zu geben, die ich noch nicht ganz verstanden habe.... Wie auch immer. Können wir gerne machen.
Ich kann gerne mal in Seeed Asssembly Service gucken und sehen, was das preislich bedeuten würde.
Nein, mit der Software RSX ROM ist LS3 inzwischen mindestens genauso Dein Kind! Insofern hast Du da volles Mitsprache- und Mitgestaltungsrecht! :knuddel: :smiley027:
PS Zum Thema Bausätze - hatten wir schon, und war keine gute Erfahrung... ist am Ende ein Minus-Geschäft weil die Leute es nicht zusammengebaut kriegen. LS3 ist zu komplex, selbst ich habe ca. 25 % Verlust-Rate momentan. Ich hoffe, dass das mit Seeed Assembly besser würde.
Ja, hoffen wir mal das Beste. :)
Für die XzentriX 2019 mache ich gerade einen MP3 Player für LS3... langsam wirds...
[CPCEmulator]https://youtu.be/t1YHsYCP2a4[/CPCEmulator]
Sehr nett!! Ist es Teil von Future OS?
Quote from: LambdaMikel on 22. August 2019, 18:33:41
Sehr nett!! Ist es Teil von Future OS?
Nee, ist ein BASIC Programm, nutzt die RSX Befehle. Später will ich auch mal eine Juke-Box für FutureOS machen, aber bis zum Meeting (am 30.8.2019) hab ich wohl die Zeit nimmer. Also BASIC, und des wird schon. Ich stell das dann auch mal hier rein, wenn es einigermaßen gut und getestet läuft. :00008351:
Quote from: TFM on 22. August 2019, 18:40:33
Quote from: LambdaMikel on 22. August 2019, 18:33:41
Sehr nett!! Ist es Teil von Future OS?
Nee, ist ein BASIC Programm, nutzt die RSX Befehle. Später will ich auch mal eine Juke-Box für FutureOS machen, aber bis zum Meeting (am 30.8.2019) hab ich wohl die Zeit nimmer. Also BASIC, und des wird schon. Ich stell das dann auch mal hier rein, wenn es einigermaßen gut und getestet läuft. :00008351:
Na BASIC ist ja k(l)eine Schande... :zunge0020:
Was auch noch mal interessant waere - den PCM EEPROM mal bis oben hin volle Kante mit PCM Sample fuellen und abspielen. Wollte ich auch immer noch mal machen.
Quote from: TFM on 22. August 2019, 17:48:16
... XzentriX 2019 ...
Kannst ja sehen ob Du Interesse und "Vorbestellungen" arrangieren kannst! Mit Demo im Handgepaeck vor Ort koennte es vielleicht den ein oder anderen Interessenten geben!
Die lesen hier eh schon alle mit. Aber dann ist mal so ein LS3 vor Ort. Vielleicht hat ja jemand Freude damit. :)
[CPCEmulator]https://youtu.be/MVEXi7fGHyc[/CPCEmulator]
@TFM, hier mal was Peinliches... das Ding heißt doch tatsächlich SP0256-AL2, NICHT SPO256-AL2... wäre gut wenn wir mal die RSXe die SPO im Namen haben umbennen könnten, ich mache das selbe für die Sprachausgabe ;)
Quote from: LambdaMikel on 24. August 2019, 21:25:26
@TFM, hier mal was Peinliches... das Ding heißt doch tatsächlich SP0256-AL2, NICHT SPO256-AL2... wäre gut wenn wir mal die RSXe die SPO im Namen haben umbennen könnten, ich mache das selbe für die Sprachausgabe ;)
Hmmm.... ok, wenn Du willst, dann mach ich das morgen...
"Fehler"-Bericht, oder sagen wir Anmerkung...
Sende ich Daten (z.B. ein MP3 Kommando) and den seriellen Port, dann sage ich dem LS3 anschließend "Flush" und der serielle Port übernimmt die Daten. So weit so gut.
Dann warte ich bis der LS3 = &10 meldet, also der serielle Port meldet "bereit".
Problem: Der LS3 ist nicht bereit.
Denn wenn ich direkt im Anschluss den seriellen Modus verlassen will, dann klappt das nicht (obwohl der LS3 = &10 meldet).
Hier ein Code Beispiel...
LD A,&FF:OUT (C),A ;&FF / ==> Schicke LS3 Puffer an Tx
LD A,&02:OUT (C),A ;&02 / = Flush LS3 buffer, max. 256+268 B
CALL LS_W10 ;Warten bis LS3 (serieller Modus!) bereit ist
LD A,&FF:OUT (C),A ;&FF / ==> Seriellen Modus verlassen!
LD A,&14:OUT (C),A ;&14 / = LS3 zurueckschalten
JP LS_WALX
;Unterprogramme...
;Wartet bis LS3 im Seriellen Modus bereit ist
;Einsp. BC = &FBEE(!)
;Manip. AF
LS_W10 IN A,(C)
CP A,&10:RET Z ;LS3 bereit im seriellen Modus
JR LS_W10 ;Warte bis Port &FBEE = &10
;Wartet bis LS3 bereit ist (Epson, DECtalk, SSA-1 und Serieller Modus)
;Einsp. BC = &FBEE(!)
;Manip. AF
LS_WALX IN A,(C)
CP A,&10:RET Z ;LS3 bereit im Seriellem Modus
CP A,&20:RET Z ;LS3 bereit im Epson, DECtalk Modus
CP A,&80:RET Z ;LS3 bereit im Amstrad SSA1 Modus
JR LS_WALX ;Warte bis Port &FBEE = &20 oder &80
Der LS3 dürfte also nach dem "Flush" nicht &10 (Bereit) melden, wenn er es nicht ist.
Wäre toll wenn das in einem zukünftigen Firmware Update eingebaut werden dann.
Ist der serielle Port nicht bereit, dann z.B. &00 melden oder was auch immer.
Momentan ist das kein Problem, da ich darum herum arbeite. Es wäre nur so eine Idee, falls mal Zeit ist. :)
(Meine Firmware v47, die neueste)
Quote from: TFM on 28. August 2019, 19:25:41
"Fehler"-Bericht, oder sagen wir Anmerkung...
Sende ich Daten (z.B. ein MP3 Kommando) and den seriellen Port, dann sage ich dem LS3 anschließend "Flush" und der serielle Port übernimmt die Daten. So weit so gut.
Dann warte ich bis der LS3 = &10 meldet, also der serielle Port meldet "bereit".
Problem: Der LS3 ist nicht bereit.
Denn wenn ich direkt im Anschluss den seriellen Modus verlassen will, dann klappt das nicht (obwohl der LS3 = &10 meldet).
Hier ein Code Beispiel...
LD A,&FF:OUT (C),A ;&FF / ==> Schicke LS3 Puffer an Tx
LD A,&02:OUT (C),A ;&02 / = Flush LS3 buffer, max. 256+268 B
CALL LS_W10 ;Warten bis LS3 (serieller Modus!) bereit ist
LD A,&FF:OUT (C),A ;&FF / ==> Seriellen Modus verlassen!
LD A,&14:OUT (C),A ;&14 / = LS3 zurueckschalten
JP LS_WALX
;Unterprogramme...
;Wartet bis LS3 im Seriellen Modus bereit ist
;Einsp. BC = &FBEE(!)
;Manip. AF
LS_W10 IN A,(C)
CP A,&10:RET Z ;LS3 bereit im seriellen Modus
JR LS_W10 ;Warte bis Port &FBEE = &10
;Wartet bis LS3 bereit ist (Epson, DECtalk, SSA-1 und Serieller Modus)
;Einsp. BC = &FBEE(!)
;Manip. AF
LS_WALX IN A,(C)
CP A,&10:RET Z ;LS3 bereit im Seriellem Modus
CP A,&20:RET Z ;LS3 bereit im Epson, DECtalk Modus
CP A,&80:RET Z ;LS3 bereit im Amstrad SSA1 Modus
JR LS_WALX ;Warte bis Port &FBEE = &20 oder &80
Der LS3 dürfte also nach dem "Flush" nicht &10 (Bereit) melden, wenn er es nicht ist.
Wäre toll wenn das in einem zukünftigen Firmware Update eingebaut werden dann.
Ist der serielle Port nicht bereit, dann z.B. &00 melden oder was auch immer.
Momentan ist das kein Problem, da ich darum herum arbeite. Es wäre nur so eine Idee, falls mal Zeit ist. :)
(Meine Firmware v47, die neueste)
Eigentlich sollte er das auch nicht machen... wenn doch, ist was faul. Das serial_ready wird nur direkt vor dem "warte auf CPC Input" gelesen... ich kann mal gucken, aber es sollte eigentlich nicht so sein.
Evtl. ist es ein Seiteneffekt von einem anderen Effekt.
Koenntest Du bitte einmal versuchen, ein paar NOPs zwischen
CALL LS_W10 ;Warten bis LS3 (serieller Modus!) bereit ist
NOP:NOP:NOP:NOP
LD A,&FF:OUT (C),A ;&FF / ==> Seriellen Modus verlassen!
einzubauen und dann sehen, ob es besser klappt?
EDIT: eher unwahrscheinlich, s. 2. Antwort unten.
... und uebrigens -
out &fbee,255
out &fbee,&14
sollte bitte ebenfalls auf 10 warten zwischen drin - es passiert naemlich einiges im LS3 firmware code zwischen &ff und &14.... also:
out &fbee,255
call ls_wait10
out &fbee,&14
evtl. ist das alles, was zu aendern ist. bitte ausprobieren.
Gut zu wissen, das ist mir neu. Danke! :)
Quote from: TFM on 28. August 2019, 19:57:34
Gut zu wissen, das ist mir neu. Danke! :)
Gerne doch - hoffe das war es... wenn nicht bitte um Info ;)
Nun, das von mir geschilderte Problem liegt ja woanders, denn der "Flush" funktioniert ja. Nur dann ist der LS3 "zu früh" auf "Bereit". Neues ROM hab ich gerade gemacht, wird auch gleich getestet. Ich arbeite ja jetzt darum herum, also kann ich es auch nimmer testen.
Wenn Du Zeit hast kannst Du es ja selber testen, dann siehst Du was ich meine, das Serial-Exit wird einfach "verschluckt".
Quote from: TFM on 28. August 2019, 20:14:53
Nun, das von mir geschilderte Problem liegt ja woanders, denn der "Flush" funktioniert ja. Nur dann ist der LS3 "zu früh" auf "Bereit". Neues ROM hab ich gerade gemacht, wird auch gleich getestet. Ich arbeite ja jetzt darum herum, also kann ich es auch nimmer testen.
Na ja, lieber erst testen... kann ja sein, dass der Flush zwar funktioniert, aber die gleiche Stelle beim Exit eben nicht, weil der ATMega vielleicht gerade noch dabei ist den UART Puffer wegzuschicken mittels interrupt, und so dauert es evtl. etwas laenger, bis er "&14" empfangen kann.... wenn 255, 2 empfangen werden kann, dann auch 255, &14, ist genau die gleiche Routine. Einziger Unterschied ist evtl. durch INterrupts im ATMega. Also lieber IMMER auf &10 warten zwischen OUTs im Serial Mode, das sollte das Problem beheben.
Ich bin mir fast sicher dass es daran liegt...
Ich gebe die folgenden Befehle ein:
!serial
!confoff
!seroff
Anstatt ruhe zu geben, sagt er "Quitting Serial Mode". Bitte beheben, nach !confoff sollte er ruhig sein. (Bitte nach dem einschalten testen).
Quote from: LambdaMikel on 28. August 2019, 20:22:13
Na ja, lieber erst testen... kann ja sein, dass der Flush zwar funktioniert, aber die gleiche Stelle beim Exit eben nicht, weil der ATMega vielleicht gerade noch dabei ist den UART Puffer wegzuschicken mittels interrupt, und so dauert es evtl. etwas laenger, bis er "&14" empfangen kann.... wenn 255, 2 empfangen werden kann, dann auch 255, &14, ist genau die gleiche Routine. Einziger Unterschied ist evtl. durch INterrupts im ATMega. Also lieber IMMER auf &10 warten zwischen OUTs im Serial Mode, das sollte das Problem beheben.
Ich bin mir fast sicher dass es daran liegt...
Nein, gar nicht. Habe es eingebaut und alles wird schlimmer. Leider ist da noch ganz schön der Hund begaben. Bitte teste das mal selber in Assembler. Du kannst ja meinen Source verwenden. Ich baue das jetzt alles wieder zurück.
Habe das aktuelle ROM hochgeladen. Bitte um Fehlerberichte, vor allem erst mal vom CPC (um den KCc kümmere ich mich wenn am CPC alles läuft).
Quote from: TFM on 28. August 2019, 20:47:38
Ich gebe die folgenden Befehle ein:
!serial
!confoff
!seroff
Anstatt ruhe zu geben, sagt er "Quitting Serial Mode". Bitte beheben, nach !confoff sollte er ruhig sein. (Bitte nach dem einschalten testen).
Falsche Reihenfolge:
|confoff
funktioniert nicht im Serial Mode!
BItte so machen:
|confoff
|serial
|seroff
Dann ist er ruhig. Der DIspatcher fuer confoff ist gar nicht aktiv, sobald Du Serial Mode einschaltest..
Das kann natuerlich ganz ueble Folgen haben, da Du ihm dann Nutz-Bytes (fuer confoff) in den UART Ausgang-Puffer reinknallst...
Der Serial Mode ist im Github in einer Tabelle dokumentier:
Byte Sequence Explanation Note
0...&FE Send Byte 0...254 Either buffered or TX directly
&FF, &FF Send Byte 255 Either buffered or TX directly
&FF, 1, x Read x from bus and TX x Transmit x directly to TX
&FF, 2 Send buffer to TX Flush buffer, max 256 + 268 bytes
&FF, 3 Get low byte number of bytes in input buffer Check if bytes have been received
&FF, 4 Get high byte number of bytes in input buffer Check if bytes have been received
&FF, 5 Check if send/receive buffer is full 1 if full, 0 otherwise
&FF, 6 Reset read and input cursors Sets input & read cursors to 0
&FF, 7 Check if another byte can be read from buffer 1 if read cursor < input cursor
&FF, 8 Get byte from buffer at read cursor position Byte will appear on databus
&FF, 9 Get byte at read cursor position, inc. cursor Read receive buffer byte by byte
&FF, 10 SERIAL MONITOR FOR MIDI IN ETC. Realtime monitoring of Serial In
&FF, 11, lo, hi Set read cursor to position hi*256 + lo Use &FF, 8 to read byte at pos
&FF, 12 Set read cursor to 0 Does not erase the buffer
&FF, 13 Set read cursor to input cursor position -1 Read cursor points to last byte
&FF, 14 Get mode - direct or buffered mode 1 = direct mode, 0 = buffered
&FF, 15 Speak mode (BAUD, Width, Parity, Stop Bits) Confirmations need to be enabled
&FF, 16 Direct mode on No CPC input buffering, direct TX
&FF, 17 Direct mode off Buffer CPC input, then &FF, 2
&FF, 20 Quit and reset Serial Mode Like Reset Button
&FF, 30, baud Set BAUD rate: baud = 0..15, see Baud Table Default 9600 (baud = 2, or > 15)
&FF, 31, width Set word width: width = 5...8 Default 8 bits
&FF, 32, par. Set parity: 0, 1, 2 0=No (Default), 1=Odd, 2=Even
&FF, 33, stop Set number of stop bits: 1, 2 1 = Default
&FF, &C3 Speak Current Mode Info Same &C3 as in speech modes
&FF, &F2 Get Mode Descriptor Byte
Quote from: TFM on 28. August 2019, 21:11:19
Quote from: LambdaMikel on 28. August 2019, 20:22:13
Na ja, lieber erst testen... kann ja sein, dass der Flush zwar funktioniert, aber die gleiche Stelle beim Exit eben nicht, weil der ATMega vielleicht gerade noch dabei ist den UART Puffer wegzuschicken mittels interrupt, und so dauert es evtl. etwas laenger, bis er "&14" empfangen kann.... wenn 255, 2 empfangen werden kann, dann auch 255, &14, ist genau die gleiche Routine. Einziger Unterschied ist evtl. durch INterrupts im ATMega. Also lieber IMMER auf &10 warten zwischen OUTs im Serial Mode, das sollte das Problem beheben.
Ich bin mir fast sicher dass es daran liegt...
Nein, gar nicht. Habe es eingebaut und alles wird schlimmer. Leider ist da noch ganz schön der Hund begaben. Bitte teste das mal selber in Assembler. Du kannst ja meinen Source verwenden. Ich baue das jetzt alles wieder zurück.
OK, ich lade mal was hoch heute Abend...
Quote from: LambdaMikel on 28. August 2019, 23:00:54
Der Serial Mode ist im Github in einer Tabelle dokumentier:
Klar, damit arbeite ich. ;)
Es ist hald doof, dass das MP3 Modul keinen Status liefert. Nach dem Meeting werde ich mich da mal langen hinhocken und das alles durchtesten. Momentan läuft mein "für's Meeting" MP3 Player. :)
Habe festgestellt dass man nach dem Einschalten MP3RES ausführen sollte (dann funktioniert - glaube ich - der Rest besser). Die Wartezeit danach habe ich auf ca. 16-18 Frames bestimmt. Naja, habe ja dann auch am Meeting Zeit damit zu experimentieren.
Da gibt es noch einiges an Mysterien zu lüften...
Du hast Recht - sieht so aus als ob er die ganze Zeit auf 16 bleibt. Rätselhaft. Bin dran.
EDIT - selbst nach 3 Stunden Detektivarbeit habe ich keine Ahnung warum das passiert! Ich denke, wir sollten einfach sagen, lass uns ne halbe Sekunde warten before &ff, 20 gesendet wird. Das funktioniert dann zuverlässig. Habe alles probiert, und der Effekt tritt immer noch auf. Das ist für mich ein "won't fix".
EDIT2 - gucke heute Abend noch mal, eine Idee habe ich noch....
Das kriegen wir jetzt auch noch hin! :smiley027:
... mit CPLD Update, ja...
Uups... nicht ganz so einfach...
Aber die gute Nachricht ist, dass letzten Freitag ein Fernsehteam der ARD auf der XzentriX war, und ich haben denen beim Interview gleich den LambdaSpeak III vorgestellt. ;)
Habe noch mal drüber nachgedacht - CPLD Update ist auch keine Lösung leider... sieht wohl so aus als ob es so bleiben müsste. Mit Wartezeit / Delay.
Also, wenn ich Dich richtig verstehe so macht es keinen Sinn im Seriellen Modus auf &10 zu prüfen, das der LS3 immer &10 zurückmeldet? Stimmt das so?
Quote from: TFM on 01. September 2019, 15:24:24
Uups... nicht ganz so einfach...
Aber die gute Nachricht ist, dass letzten Freitag ein Fernsehteam der ARD auf der XzentriX war, und ich haben denen beim Interview gleich den LambdaSpeak III vorgestellt. ;)
Lol... You must be kidding me :smiley027:
Ist für die Tagesthemen richtig?
Quote from: TFM on 01. September 2019, 19:17:06
Also, wenn ich Dich richtig verstehe so macht es keinen Sinn im Seriellen Modus auf &10 zu prüfen, das der LS3 immer &10 zurückmeldet? Stimmt das so?
Nein, das macht schon Sinn... ich werde in die nächste Firmware mal eine Echo-Test-Routine integrieren, dann können wir mal die Verzögerung testen. Es sollten eigentlich 10 und 0 auf dem Bus für Ready und Busy für Serial Mode erscheinen. Nur leider scheint nach dem "10" eine Zwangspause erforderlich. Ich bin nach wie vor dran und mache noch verschiedene Experimente.
Anscheinend benötigt das Umschalten des CPLD / der ATMega Pins einige Zeit...
Zwischenzeitlich habe ich mal v53 hochgeladen.
Neu in dieser Version:
- Serial Sub-Mode 10 ("Serial RX Monitor") macht jetzt RX -> TX Echo
In MIDI (s. MIDISYN.BAS) ist damit "Soft Midi Through" realisiert.
- Neuer Serial Sub-Mode 50 ("Serial RX/TX Monitor") - MIDI bzw. Serielle Echtzeit in Duplex geht jetzt in beide
Richtung Realtime, IN und OUT. Siehe neues Programm MIDISYNTX.BAS.
Das macht genau das gleiche wie Sub-Mode 10 (s. MIDISYN.BAS), ABER das Midi Through Serial Echo wird diesemal
vom CPC gemacht. D.h., was er per RX am UART empfängt, meldet er an den CPC, und der echoed es zurück. Der
LS300 gibt es dann auf TX wieder aus. Damit geht also MIDI IN / OUT in Echtzeit.
- Zudem gibt es nun besagten Sub-Modus 55. Im Serial Modus wird jedes Bytes das mittels
255, 55, <byte> gesendet wird, auch wieder an den CPC zurückgeschickt. Dabei sollten zwischen 255, 55, und
<byte> jeweils READY und BUSY (also 0 und &10) auf dem Datenbus zu sehen sein. Damit können wir die Zeitver-
zögerung messen.
Zudem habe ich mal SERRES.BAS auf LS300.DSK hochgeladen. Zum Testen der Verzögerung, die der 20 Exit aus dem Seriellen Modus benötigt. S. DELAY. Das sind schon eine ganze Menge NOPs...
Ok, werde ich mir nach dem Mittagessen gleich installieren...
Der Serial Mode wurde etwas überarbeitet. Ich hoffe, es benötigt keine umfangreiche "Neujustierung" der MP3 Kommandos etc. vom Timing.
Quote from: LambdaMikel on 03. September 2019, 15:46:28
Der Serial Mode wurde etwas überarbeitet. Ich hoffe, es benötigt keine umfangreiche "Neujustierung" der MP3 Kommandos etc. vom Timing.
Nun ja, ich kann den Serial Mode mittels Kommando &F1 nicht mal mehr einschalten. Da geht gar nix mehr. Probier mal OUT &FBEE,&F1 aus und dann ? INP(&FBEE). Dann wird 128 angezeigt, anstatt 16.
Äh sorry, nein. da hast Du Dich mal wieder ver-flashed ;-) Probier's noch mal. :smiley027:
Ist ja nicht so dass ich gar nicht teste... ich habe immerhin 3 Tage damit zugebracht, &f1 255 50 einzubauen ;)
Bei mir kommt 16. Das LS3 ROM von vor einiger Zeit funktioniert bei mir mittels |mp3play etc. auch noch.
Bitte noch einmal probieren.
Dann hefte das Update doch bitter hier an, ich habe es auf zwei Arten von Git-Hub runtergeladen und gebrannt. Andere Befehle (wie !lambda, !eeclr, !sp, die RTC etc.) funktionieren ja alle. Also liegt es am brennen?
EDIT: Nach dem 3. mal brennen funktioniert es. Früher gab es bei RAW immer einen Download Button, der war nicht da. Also Copy & Paste. Nur blöd, dass man wenn mal auf RAW und dann "Speichern unter... " klickt was anderes bekommt. GitHub hald. :blank:
Bitte die Firmware Updates IMMER hier posten!
Hab die V53 auch geflasht und die neueste LS3.Rom.
Teste dann mal
Quote from: Rennert on 04. September 2019, 17:57:13
Hab die V53 auch geflasht und die neueste LS3.Rom.
Teste dann mal
Super - bitte probiere mal
10 out &fbee,&f1:print inp(&fbee)
Danke!
MIchael
Quote from: TFM on 04. September 2019, 12:23:27
Dann hefte das Update doch bitter hier an, ich habe es auf zwei Arten von Git-Hub runtergeladen und gebrannt. Andere Befehle (wie !lambda, !eeclr, !sp, die RTC etc.) funktionieren ja alle. Also liegt es am brennen?
EDIT: Nach dem 3. mal brennen funktioniert es. Früher gab es bei RAW immer einen Download Button, der war nicht da. Also Copy & Paste. Nur blöd, dass man wenn mal auf RAW und dann "Speichern unter... " klickt was anderes bekommt. GitHub hald. :blank:
Bitte die Firmware Updates IMMER hier posten!
Hmm, evtl. wieder die Fuses? Kannst Du bitte noch einmal |pcmtest probieren?
Quote from: LambdaMikel on 04. September 2019, 19:14:10
Quote from: Rennert on 04. September 2019, 17:57:13
Hab die V53 auch geflasht und die neueste LS3.Rom.
Teste dann mal
Super - bitte probiere mal
10 out &fbee,&f1:print inp(&fbee)
Danke!
MIchael
Immer 16
PCMTest geht auch
Quote from: TFM on 04. September 2019, 12:23:27
EDIT: Nach dem 3. mal brennen funktioniert es. Früher gab es bei RAW immer einen Download Button, der war nicht da. Also Copy & Paste. Nur blöd, dass man wenn mal auf RAW und dann "Speichern unter... " klickt was anderes bekommt. GitHub hald. :blank:
Bitte die Firmware Updates IMMER hier posten!
Werde heute Abend hier anhaengen.
Evtl. mal einen besseren / neueren Brenner zulegen -
https://www.ebay.de/itm/TL866CS-Programmiergeraet-USB-EPROM-FLASH-BIOS-Programmierbare-Logikschaltu-D6Y5/282994026243?hash=item41e3c22703:g:1CsAAOSwhztbFJ2X
Oder der ATmega ist bald am Ende, das koennte auch sein... irgendwann lassen die sich einfach nicht mehr beschreiben.
Ich flashe ja immer am Modul, das geht gut und schnell.
Muss mir mal noch nen Atmega bestellen, damit ich Ersatz da habe ;D
Quote from: LambdaMikel on 04. September 2019, 21:43:29
Evtl. mal einen besseren / neueren Brenner zulegen -
Oder der ATmega ist bald am Ende, das koennte auch sein... irgendwann lassen die sich einfach nicht mehr beschreiben.
Beides nicht, mein Problem heißt Git-Hub. Das ist dämlich strukturiert, und man kann die selbe Datei dummerweise in 3 Versionen herunterladen, der Brenner frisst nur eine davon.
Die beste Method ist, einen Git Client zu installieren.
Z.B.
https://tortoisegit.org/download/
Damit ist es dann super einfach.
1. einmal "git clone https://github.com/lambdamikel/LambdaSpeak3.git"
2. zum updaten "git pull"
That's it.
Ach so, wollte ich ja hier anhängen:
PS Habe uebrigens mal den PCB Assembly Service durchrechnen lassen... bei einer Batch Size von 15 koennte ich LS3 fuer ca. 110 $ produzieren. Free shipping muesste also wegfallen. Aber falls wirklich viele Leute eines haben wollten, waere es wohl machbar. Ich muss dann nur noch den Edge Connector einloeten, den Header fuer das Daughterboard, den Power Jack, und MP3 / RTC. Und programmieren und Chips draufstecken. Sollte also pro Stueck dann in 20 Minuten machbar sein. Was natuerlich wesentlich besser ist als 3 bis 4 Stunden wie bisher... :P
Hmm... das ist immer noch ein Haufen (nicht, dass er es nicht wert wäre, hat ja zig Funktionen), aber was soll man da machen.
Was kostet denn am meisten?
Ist der der SP0256 Chip dabei?
Das Problem ist, dass ich keinen großen Batch produzieren lassen kann.
Hier mal die Preise für 3 Units, und dann für 30 (-> Screenshots im Anhang).
Das sind die PCB und Pre-Assembly Preise für 3 bzw. 30 Units. Wie man sieht, geht der Preis runter von 110 $ für 3 auf unter 50 $ für 30... aber wer soll 30 kaufen. Und zunächst müsste ich einmal 3 produzieren um zu sehen, ob der Prozess so hinhaut.
Zu diesen Pre-Assembly Preisen kommen dann noch:
- Epson board (35 - 40 $)
- ATMega : 6 $
- Xilinx XC9572: 10 - 15 $
- weitere komponenten (IDC Box Header, ...), LEDs, SPI EEPROM, Op Amp: 15 $
Also nochmal gut 60 $ obendrauf. So komme ich dann bei 20 - 30 Units auf ungefähr 110 $ für "Basis"-LS3.
Und günstiger als Seeed wird es nicht.
Für C64 sind solche Stückzahlen auch gar kein Problem, aber für den CPC schon ;)
Na wenigsten habe ich jetzt einen Plan B - falls wirklich viele Leute einen kaufen wollten, ist es machbar. Allein das erstellen der Bestückungsliste für Seeed Assembly hat 3 Stunden gedauert. DigiKey hat einen unmöglichen Katalog. Gar nicht so einfach aus 100000senden Komponenten was *hoffentlich* passendes auszusuchen! Wie gesagt, es käme mal auf einen Versuch drauf an, aber Scheitern ist teuer (> 300 $ für 3 Stück wie gesagt). Ich werde das trotzdem mal ausgeben denke ich wenn die nächste Order kommt.
ChinnyVision arbeit jetzt an seinem Review. Und natürlich hat er eine FIrmware von 2 Monaten (v38 oder so was)... wie auch immer.
Auch doof - Seeed gibt keinen "Umsonst-Sample": Sonst wäre das ja kein Problem das mal auszuprobieren. Auch muss man mehr PCBs bestellen als dann zusammengebaut werden - z.B. 5 und 3, 40 und 30, usw. Ist wohl Ausschuss dabei.
Warum sollten da keine 30 Boards rausgehen? Die M4 Karte hat sich bisher 700 mal verkauft, ok die ist auch billiger. Man könnte auch den Duke fragen, ob er weiß wie man den LS3 noch billiger machen könnte.
Das Epson Klick-Board ist hald ein heftiger Kostenfaktor, den man nicht senken kann.
Mein Rat wäre: Im Forum mit am meisten CPC Usern (also wohl CPC-Wiki) mal einen neuen Thread starten in dem man einfach mal fragt wer grundsätzlich Interesse an einem LS3 hätte.
Hier auf keinen Fall die Leute mit Text und Optionen erschlagen, das schreckt nur ab!!!
Am besten einen Thread mit 2-3 Sätzen. Beispiel wäre.
Der LS3 ist jetzt fertig entwickelt und getestet.
Wer von Euch hat Interesse?
Bitte hier einfach mal schreiben, dann können wir eine Liste erstellen. (First come, first get).
So würde ich das machen, und ja, es gibt sicher noch bessere Vorgehensweisen.
Den Versand in Europa würde ich übernehmen, und es wäre auch wieder kostenlos. Das Porto kann ich mir leisten ;-)
Irgendwann habe ich den Faden verloren, was das LambdaSpeak alles können soll. Sprachsynthesizer und MP3-Player finde ich uninteressant.
Ich hätte gerne eine Karte die mir vom CPC aus ansprechbar I2C, SPI und UART zur Verfügung stellt. Denn damit würden sich vom CPC aus diese herrlich billigen Platinchen aus der Arduino-Welt erschließen.
Grüßle,
AMSi
Quote from: almasys on 13. September 2019, 18:42:25
Irgendwann habe ich den Faden verloren, was das LambdaSpeak alles können soll.
*Kann*, nicht *koennen soll* ;D
mit den billigen karten ist ja genau die idee, und das haben wir mit i2c uhr, spi EEPROM und spi Epson board, und uart mp3 player und midi board ja auch demontriert :winke0002:
klar, die firmware sollte irgendwann nicht nur wie schon fuer uart, sondern auch fuer spi und i2c generische funktionen anbieten. machen wir irgendwann mal. kein problem fuer die ls 3 hardware (-> alternative firmware).
zudem:
i2c spi und uart gibt es doch alles schon... MegaBlaster.
lt. toto hat er das alles schon vor 10 jahren gemacht, und es gab nicht einen einzigen, der was programmiert / entwickelt hat fuer diese ganzen tollen funktionen.
fuer uart bin ich der einzige, der mal mit USIfAC was gemacht hat (-> MIDI board angeschlossen und CPC "MIDI IN synthesizer" programmiert)
also, geredet und gemeckert wird immer viel, gemacht wird wenig ;D
wollte auch noch mal auf diese projekt hinweisen:
https://cpcwiki.de/forum/index.php/topic,749.0.html
das naechste projekt wir stm32 und 2 click board adapter fuer uart, spi, i2c haben... kommt bald. click boards sind genial!
hast du hier mal geguckt was es alles fuer wenig geld gibt?
https://www.mikroe.com/click
falls es interessenten an diesem projekt gibt, koennen wir gerne zusammen daran arbeiten. open source.
klar, und dann gibt es noch die vogel strauss strategie - ich ignoriere alles was gemacht wird und sage
- lass uns mal was machen" :zunge0020:
Quote from: almasys on 13. September 2019, 18:42:25
Ich hätte gerne eine Karte die mir vom CPC aus ansprechbar I2C, SPI und UART zur Verfügung stellt. Denn damit würden sich vom CPC aus diese herrlich billigen Platinchen aus der Arduino-Welt erschließen.
Genau, lass uns frisch ans Werke gehen:
https://cpcwiki.de/forum/index.php/topic,749.0.html
Natuerlich machen wir nicht nur 2 Click Board Steckplaetze drauf, sondern auch Pin Header fuer SPI, I2C, UART.
Du bist dabei, richtig?
Und hier mein Weihnachtsgeschenk an Euch:
LambdaSpeak Firmware im Sourcecode ist online. GPL 3.
https://github.com/lambdamikel/LambdaSpeak3/tree/master/src/atmega644-20pu
Für das schöne LS3 gibt's jetzt (noch) ein Review...