Autor Thema: LambdaSpeak CPC Sprach-Synthesizer, Sample Player, RTC, MP3, UART Erweiterung  (Gelesen 28199 mal)

0 Mitglieder und 4 Gäste betrachten dieses Thema.

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
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  ;)

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS
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.  :)
TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
... und Alarm-Clock. Koennte Alarms im EEPROM speichern... natuerlich auch Temperatur-Alarme:
if temp > 30 then print "Bier trinken!"

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
Ich selbst bastele gerade an MIDI Input... BASIC ist zu langsam. Jetzt habe ich wirklich mal wieder einen Grund, etwas Z80 zu machen.

Offline oobdoo

  • CPC 6128
  • ****
  • Beiträge: 378
  • Liked: 91
  • Karma: +9/-0
  • Geschlecht: Männlich
  • :P
Jetzt habe ich wirklich mal wieder einen Grund, etwas Z80 zu machen.
:jubelaola:
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS
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:
TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
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.

« Letzte Änderung: 14. Juli 2019, 03:39:25 von LambdaMikel »

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
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:

« Letzte Änderung: 14. Juli 2019, 08:17:15 von LambdaMikel »

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS
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.
TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS
- 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.  :)

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

TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
- 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.  :)

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

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
- 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.
« Letzte Änderung: Heute um 02:04:40 von LambdaMikel »

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS
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.
« Letzte Änderung: Heute um 15:12:52 von TFM »
TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline TFM

  • Administrator
  • CPC 6128+
  • *****
  • Beiträge: 2617
  • Liked: 635
  • Karma: +27/-0
  • Geschlecht: Männlich
  • FutureSoft und CPC - Ein starkes Team!
    • FutureOS

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?
« Letzte Änderung: Heute um 15:10:14 von TFM »
TFM of FutureSoft
http://www.FutureOS.de --> Das Betriebssystem FutureOS (Update: 14.01.2019)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 02.07.2019)

Offline LambdaMikel

  • LambdaMikel
  • Moderator
  • CPC 464+
  • *****
  • Beiträge: 520
  • Liked: 227
  • Karma: +27/-0
  • Geschlecht: Männlich
    • Homepage
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  :)