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

[LambdaMikel]

@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 

[TFM]

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

[TFM]

"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)

[LambdaMikel]

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

[LambdaMikel]

Koenntest Du bitte einmal versuchen, ein paar NOPs zwischen

Code Select Expand


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.

[LambdaMikel]

... und uebrigens -

Code Select Expand


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:

Code Select Expand


out &fbee,255
call ls_wait10
out &fbee,&14


evtl. ist das alles, was zu aendern ist. bitte ausprobieren.

[TFM]

Gut zu wissen, das ist mir neu. Danke! 

[LambdaMikel]

Gut zu wissen, das ist mir neu. Danke! 

Gerne doch - hoffe das war es... wenn nicht bitte um Info 

[TFM]

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

[LambdaMikel]

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

[TFM]

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

[TFM]

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.

[TFM]

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

[LambdaMikel]

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

[LambdaMikel]

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