Video Streaming STM32 -> Z80

[Sean G. (atmega318)]

Zuerst mal eine Warnung: Ich habe 0 Ahnung von ASM und werde deshalb 
vermutlich viele dumme Fragen stellen.

Zu meinem eigentlichen Problem:
Ich habe einen Z80, an dem ein LCD und eine Tastatur hängt. Nun möchte 
ich mein Programm aber auf einem STM32 laufen lassen, und die einzige 
Verbindung zwischen den zweien ist eine Open-Collector-Zweidraht 
Verbindung. Darüber möchte ich einerseits vom Z80 auf den STM32 ca. 
50-100 mal ein paar Bytes für die Tastatur übertragen, aber viel 
wichtiger vom STM32 auf den Z80 das LCD-Bild. Da ich mit Graustufen 
arbeiten will währen 100 FPS anstrebenswert (Bitwinkelmodulation mit 4 
Bit/25 FPS).
Pro Frame müssen 768 Bytes an Bilddaten übertragen werden. CRC oder 
ähnliches brauche ich nicht, wenn ab und zu mal ein Pixel falsch ankommt 
ist das egal.

Um das LCD anzusteuern brauche ich auf dem Z80 immer 8 Pixel in einem 
Register, danach muss ich eh auf das LCD warten, und kann ja in dieser 
Zeit die Kommunikation erledigen. Zugunsten hohen Durchsatzes wäre es ja 
gut, wenn ich immer 2 Bit aufs mal übertrage. Hier kommt aber mein 
Problem:
Vom Port lese ich 1 Byte ein, die 2 LSBs enthalten 2 Bit an Daten. Doch 
wie bekomme ich jetzt 8 Bit von 4 aufeinanderfolgenden Lesevorgängen in 
ein Register? Also ich bekomme:
XXXXXXAB
XXXXXXCD
XXXXXXEF
XXXXXXGH

und möchte das in ASM möglichst effizient (schnell) zu ABCDEFGH 
zusammensetzen. Eigentlich habe ich dafür vielleicht etwa 40 Takte zeit. 
Ist das überhaupt möglich? Und wenn ja wie?

Vielen Danke euch allen, Sean

[Dr. Sommer (Gast)]

Warum das LCD nicht direkt mit dem STM32 ansteuern? Der könnte die 
gewünschte Operation jedenfalls mit "BFI" in insg. 4 Takten erledigen 
;-)

[Sean G. (atmega318)]

Ja das ist mir schon klar, nur leider kommt das nicht in Frage, denn das 
LCD sitzt in einem Taschenrechner. Und ein auftrennen der Leitungen 
kommt nicht in Frage, weil dann die Originalfunktionalität nicht mehr 
gegeben ist. Sonst könnte ich auch gleich ein vernünftiges LCD nehmen, 
statt eines mit 64*96 Pixeln bei dem man die Graustufen in SW machen 
muss :(

[spess53 (Gast)]

Hi

>Eigentlich habe ich dafür vielleicht etwa 40 Takte zeit.

Ein einfaches Links shiften eines Registers (SLA r) dauert beim Z80 acht 
Takte. Das bräuchtest du 12 mal, also 96 Takte und dazu noch ein paar 
ORs.
Kannst du dir ja ausrechnen.

MfG Spess

[Sean G. (atmega318)]

spess53 schrieb:
> Hi
>
>>Eigentlich habe ich dafür vielleicht etwa 40 Takte zeit.
>
> Ein einfaches Links shiften eines Registers (SLA r) dauert beim Z80 acht
> Takte. Das bräuchtest du 12 mal, also 96 Takte und dazu noch ein paar
> ORs.
> Kannst du dir ja ausrechnen.
>
> MfG Spess

Danke, dann muss ich meine Anforderungen wohl ändern: So schnell wie 
möglich, im Notfall übertakte ich den Z80 halt. Trotzdem komme ich nicht 
wirklich weiter. Mein Ansatz wäre so: (Pseudocode, wird nachher in HEX 
ASM geschrieben...)

IN (data_port), b
IN (data_port), c
IN (data_port), d
IN (data_port), e

dann habe ich:
xxxxABxx
xxxxCDxx
xxxxEFxx
xxxxGHxx

(Sorry, es sind gar nicht Bit 0/1 sondern 2/3!)

aber shiften allein reicht ja nicht, denn die x können 0/1 sein, das ist 
nicht bekannt. Jetzt hat der Z80 ja aber opcodes für set/reset von 
einzelnen Bits. Wenn es jetzt eine einfache Möglichkeit gibt um zu 
testen ob z.B. im Bit 2 eine 1 steht könnte man ja dann die Bit-Set 
Instruktion in einem anderen Register anwenden, oder ist das der falsche 
Ansatz?

[Uwe B. (derexponent)]

Hi Sean Goff,

der Z80 hat ASM Befehle zum abfragen von einem einzelnen Bit
(ob gesetzt oder nicht) und zum setzen von einem einzelnen Bit

abfrage : BIT b,r (8 Takte)
setzen  : SET b,r (12 Takte)

dazwischen brauchst du noch einen Jump (if Zero)
der braucht 10 Takte



aber mal ganz was anderes, warum überträgst du nicht gleich
das komplette Byte in einem rutsch ?

damit erspast du dir vieles (die Kommunikation muss ja auch irgendwie
gesteuert werden...sprich wann darf der STM das neue Bit senden usw.

Gruss Uwe

[Sean G. (atmega318)]

Uwe B. schrieb:
> der Z80 hat ASM Befehle zum abfragen von einem einzelnen Bit
> (ob gesetzt oder nicht) und zum setzen von einem einzelnen Bit

Danke, jetzt wo dus sagst sehe ich es auch. Dann werde ich es wohl mit 8 
BIT abfragen mit Jump machen.

Uwe B. schrieb:
> aber mal ganz was anderes, warum überträgst du nicht gleich
> das komplette Byte in einem rutsch ?
>
> damit erspast du dir vieles (die Kommunikation muss ja auch irgendwie
> gesteuert werden...sprich wann darf der STM das neue Bit senden usw.

Also meinst du weshalb nicht 8 Parallele Datenleitungen? Die 2 Leitungen 
sind leider gegeben...

[Uwe B. (derexponent)]

> Also meinst du weshalb nicht 8 Parallele Datenleitungen? Die 2 Leitungen
> sind leider gegeben...

und wie machst du da die Synchronisation mit nur zwei Leitungen in eine 
Richtung ?

[Sean G. (atmega318)]

Uwe B. schrieb:
>> Also meinst du weshalb nicht 8 Parallele Datenleitungen? Die 2 Leitungen
>> sind leider gegeben...
>
> und wie machst du da die Synchronisation mit nur zwei Leitungen in eine
> Richtung ?

Nunja, das müsste ich ausprobieren aber die Idee war, dass am Anfang des 
Frames synchronisiert wird (Z80 gibt Signal --> IR auf STM32) und danach 
hoffen dass die clocks nicht auseinander laufen. Je nach dem wäre es 
auch möglich, dass der Z80 den Clock vom STM32 bekommt, dann können sie 
ja nicht mer weglaufen.

[Karl H. (kbuchegg)]

Sean Goff schrieb:


> auch möglich, dass der Z80 den Clock vom STM32 bekommt, dann können sie
> ja nicht mer weglaufen.

Wie - Du hast nicht noch mal eine seperate Clock-Leitung, sondern willst 
780 Bytes dadurch übertragen, dass das Timing 2-er unterschiedlicher 
Prozessoren absolut synchron verläuft? Noch dazu mit einer Z80 Gurke, 
mit der du Anweisungen so anordnen musst, dass alles aufgrund der 
internen OpCode-Zyklen taktgenau rauskommt. Und das alles dann auch noch 
mit einem gewissen Speed, der den Nachteil hat, dass du dir in das 
Timing nicht sehr große Reserven einbauen kannst, die dir akkumulierte 
Zeitfehler abfangen könnten.

Ich muss sagen: Du hast Gottvertrauen.
Wenn du das zuverlässig hinkriegst, dann setze ich Himmel und Hölle in 
Bewegung, dass dich der Papst nach deinem Ableben 'heilig' spricht. Das 
wäre dann wenigstens mal ein Heiliger mit einem echten Wunder.

[Sean G. (atmega318)]

Karl Heinz schrieb:
> Sean Goff schrieb:
>
>
>> auch möglich, dass der Z80 den Clock vom STM32 bekommt, dann können sie
>> ja nicht mer weglaufen.
>
> Wie - Du hast nicht noch mal eine seperate Clock-Leitung, sondern willst
> 780 Bytes dadurch übertragen, dass das Timing 2-er unterschiedlicher
> Prozessoren absolut synchron verläuft? Noch dazu mit einer Z80 Gurke,
> mit der du Anweisungen so anordnen musst, dass alles aufgrund der
> internen OpCode-Zyklen taktgenau rauskommst.
>
> Ich muss sagen: Du hast Gottvertrauen.
> Wenn du das zuverlässig hinkriegst, dann setze ich Himmel und Hölle in
> Bewegung, dass dich der Papst nach deinem Ableben 'heilig' spricht. Das
> wäre dann wenigstens mal ein Heiliger mit einem echten Wunder.

Ganz einfach:
Den Taktgeber durch einen Draht ersetzen, und den an einen Pin des STM32 
löten sollte kein Ding sein (grosses Pad, einfach zugänglich). Alles 
andere ist aber schon nicht mehr so leicht zugänglich, und ein Sync auf 
Z80 Seite braucht ja auch wieder Zeit die ich nicht habe. Dass es ohne 
nicht geht glaube ich gerne, dann muss halt der Draht hin.
Aber was meinst du mit
> Noch dazu mit einer Z80 Gurke,
> mit der du Anweisungen so anordnen musst, dass alles aufgrund der
> internen OpCode-Zyklen taktgenau rauskommst.
?
Die benötigten Zyklen sind ja bekannt, dann muss ich ja nur noch den 
genauen Takt kennen?!

[Uwe B. (derexponent)]

Sean Goff schrieb:

> Z80 gibt Signal --> IR auf STM32) und danach
> hoffen dass die clocks nicht auseinander laufen. Je nach dem wäre es
> auch möglich, dass der Z80 den Clock vom STM32 bekommt, dann können sie
> ja nicht mer weglaufen.

hmmm, wenn das mal gutgeht :-)


event. könntest du auch jedes Bit einzeln übertragen
und die zweite Leitung als "Clock-Signal" benutzten

also eine Art SPI-Bus (halt nur in eine Richtung)

aber ob du da auf die gewünschte Geschwindigkeit kommst ?

Wenn du mehr Leitungen zum STM hättest, könntest du 4 verschiedene
Adressen zum lesen benutzen

der STM müsste dann die zwei untersten Adressleitungen ausdekodieren
und das gewünschte Bitpaar ausgeben

zusätzlich noch den IORQ-Pin um die IO-Anfrage vom Z80 zu erkennen

egal wie, viel spass beim programmieren

Gruss Uwe

[Karl H. (kbuchegg)]

Sean Goff schrieb:

> Die benötigten Zyklen sind ja bekannt, dann muss ich ja nur noch den
> genauen Takt kennen?!

Hast du das schon mal gemacht?
Einen Code so hinzutrimmen, dass er EXAKT eine bestimmte Anzahl an 
Taktgeneratorzyklen braucht? Und zwar in allen überhaupt möglichen 
Pfaden durch den Code. Inklusive unterschiedlicher Anzahl an Taktzyklen 
für bedingte Sprünge, die du zur Schleifenbildung brauchst.

Bei nur 1 Byte hat man noch einen gewissen Spielraum, wenn das Timing 
nicht allzu eng ist. Aber bei 780 Bytes hintereinander ohne jegliche 
Synchronisation? Da summiert sich jeder einzelne Taktzyklusfehler auf.

Viel Spass dabei.

[Georg G. (df2au)]

Sean Goff schrieb:
> aber shiften allein reicht ja nicht, denn die x können 0/1 sein, das ist
> nicht bekannt.

Wieso das? Du liest einen Port, bei dem nur zwei Bits aktiv sind. Was 
hindert dich, die restlichen Bits auf einen definierten Pegel zu setzen? 
Im Zweifelsfall genügt ein HC125 dafür (dekodiertes /IORD auf Enable, 
Eingänge an GND, Ausgänge an die unbenutzten Bits des Datenbus).

Und noch ein Vorschlag: Nimm ein Schieberegister und hämmere damit die 4 
Doppelbits zusammen, lies sie 8 Bit Wert ein. Dann kommst du deinen 40 
Zyklen langsam näher.

[Sean G. (atmega318)]

Karl Heinz schrieb:
> Hast du das schon mal gemacht?

Nein, wie gesagt, das ist mein erster Kontakt mit Z80 und ASM. Der Teil 
des codes dessen Taktzyklen ich kennen muss ist aber sehr klein. Es geht 
wirklich nur ums Port lesen, Bits setzen, schreiben. Der Rest ist egal! 
Also entweder mache ich NOPs rein bis alles gleich schnell ist, oder 
aber der STM berechnet wie lange der Z80 brauchen wird. Vermutlich eher 
ersteres. Der Programmablauf ist auch hardcoded, ausser bei der 
Bitabfrage selbst, und das sollte ja zum Glück überschaubar sein.

[Kein Name (Gast)]

Oder der lesende Z80 gibt den Takt vor. STM32 muss dann schnell genug 
reagieren.

- Z80 zieht die Leitung kurz auf low.
- STM reagiert sofort auf diesen Impuls.
  - 0 übertragen: STM zieht Leitung auf auf Low.
  - 1 übertragen: STM macht nichts.
- Z80 gibt die Leitung wieder frei.
- Z80 liest das Bit auf der Leitung

[Kein Name (Gast)]

... danach ist etwas Zeit.

- STM wartet ein paar Takte
- STM gibt die Leitung wieder frei

- Z80 verarbeitet das Bit
- Z80 springt wieder an den Anfang der Schleife

[Sean G. (atmega318)]

Kein Name schrieb:
> Oder der lesende Z80 gibt den Takt vor. STM32 muss dann schnell genug
> reagieren.
>
> - Z80 zieht die Leitung kurz auf low.
> - STM reagiert sofort auf diesen Impuls.
>   - 0 übertragen: STM zieht Leitung auf auf Low.
>   - 1 übertragen: STM macht nichts.
> - Z80 gibt die Leitung wieder frei.
> - Z80 liest das Bit auf der Leitung

Ja, diese Idee gefällt mir. Ich werde in dem Fall mal schauen wie oft 
man den Sync machen muss, damit keine Fehler entstehen. Zeit braucht er 
ja trotzdem, dann währe es besser wenn man nur alle paar Bytes syncen 
müsste.

[Sean G. (atmega318)]

Ich habe jetzt mal den Code ohne die Synchronisation gemacht, komme aber 
nur auf 25 Updates pro Sekunde! Hat jemand von euch eine Idee wie ich da 
optimieren könnte? Hier mein Code (definitiv nicht Standardkonform, ich 
habe eigentlich direkt in Opcode programmiert, das ist nur eine 
parallelgeführte Stütze...) Zwischen lbl1 und jp nz, lbl1 ist der 
kritische code (muss 768 mal pro frame ausgeführt werden) den Rest habe 
ich der Vollständigkeit halber drin gelassen, ist aber vermutlich fast 
unverständlich.

di
(lbl3)

ld a,FF
out (00),a
ld h,FC

ld c,01
ld a,FF
out (01),a

ld a,FE
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,FD
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,FB
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,F7
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,EF
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,DF
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,BF
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a

ld a,7F
out (01),a
in(c),b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a
SRA b
SRA b
ld a,b
AND h
out (00),a





ld a,80
out (10),a

EX SP,(HL)
EX SP,(HL)

ld a, FC
out(00),a
ld e,20
(lbl2)
ld c,10
out (c),e

EX SP,(HL)
EX SP,(HL)

ld c,11  (zur optimierung wäre auch inc c möglich, weil c vorher 10 ist!)
ld b,64(dezimal)

(lbl1)
ld d,0

IN a,(00)
BIT 3,a
jr z,2
SET 7,d
BIT 2,a
jr z,2
SET 6,d
IN a,(00)
BIT 3,a
jr z,2
SET 5,d
BIT 2,a
jr z,2
SET 4,d
IN a,(00)
BIT 3,a
jr z,2
SET 3,d
BIT 2,a
jr z,2
SET 2,d
IN a,(00)
BIT 3,a
jr z,2
SET 1,d
BIT 2,a
jr z,2
SET 0,d

out(c),d

dec b
jp nz, (lbl1)

inc e
ld a,e
cp 2F
jp nz, (lbl2)
jp (lbl3)

[Uwe B. (derexponent)]

ich glaube zwar immer noch nicht das es ohne synchronisation 
funktioniert
aber hier das ganze "etwas" schneller :
(mit Angabe der Taktzyklen)

---------------------------------------

LD D,0       
LD E,12         // Maske fuer Bit2 und Bit3

IN  A,(00)   11
AND E        4
RLA          4
RLA          4 
RLA          4
RLA          4  // hier wäre ein "SWAP" schneller
LD  D,A      4  // aber ich glaube den gibts beim Z80 nicht

IN  A,(00)   11
AND E        4
RLA          4
RLA          4
OR  D        4
LD  D,A      4

IN  A,(00)   11
AND E        4
OR  D        4
LD  D,A      4

IN  A,(00)   11
AND E        4
RRA          4
RRA          4
OR  D        4
LD  D,A      4

---------------------------------------

Summe = 120 Takte

P.S. dein Code braucht 188 bis 252 Takte

also viel schneller ist es nicht


Gruss Uwe

[Sean G. (atmega318)]

WOW, danke vielmals, ich werde es gleich mal ausprobieren.

Uwe B. schrieb:
> P.S. dein Code braucht 188 bis 252 Takte
>
> also viel schneller ist es nicht

Oh doch es ist mehr als doppelt so schnell, denn in meinem Code fehlen 
noch die NOPs um alle Pfade gleich schnell zu machen (ja, ohne das wäre 
ja "asynchron" unmöglich) und mit dauert es immer 252 Takte. Die 
Synchronisation werde ich noch je nach Bedarf öfter, oder seltener 
machen deshalb ist sie nicht drin. Vielleicht ist es so schon schnell 
genug, und sonst gehe ich von 6Mhz auf 14 oder so, und dann ist es 
sicher schnell genug.
Vielen Dank, ich werde bald Bericht erstatten :) (kann dauern ohne 
Compiler :D  )

[Georg G. (df2au)]

Sean Goff schrieb:
> (kann dauern ohne
> Compiler :D  )

So etwas gibt es als Freeware, kein Grund, sich zu quälen

[Sean G. (atmega318)]

Georg G. schrieb:
> Sean Goff schrieb:
>> (kann dauern ohne
>> Compiler :D  )
>
> So etwas gibt es als Freeware, kein Grund, sich zu quälen

Ich weiss, aber ursprünglich wollte ich einen, der für den TI 82 Stats 
gemacht ist, damit ich auch ROM Funktionen direkt nutzen kann. Leider 
konnte ich den aber in der VM nicht zum laufen bekommen, und für <500 
Bytes ist von hand schreiben ja noch machbar. Ich denke ich hätte länger 
gehabt den Compiler zum laufen zu bekommen und zu verstehen.

Sean Goff schrieb:
> WOW, danke vielmals, ich werde es gleich mal ausprobieren.

Ich habe zwar noch keinen vernünftigen Code zum Senden geschweige denn 
einen Sync Mechanismus, aber so wies aussieht bin ich jetzt auf ca. 50 
FPS! Das ist schon ziemlich gut, möglicherweise Übertakte ich einfach 
noch ein bisschen, denn bis zu 15MHz ist scheinbar stabil, und im moment 
läuft er auf 6MHz.

[Uwe B. (derexponent)]

hier nochmal ein Nachtrag

damit ist der Code zwar um 4 Takte langsamer,
aber dafür sind die Stellen an denen gelesen wird
gleich lange auseinander (je 20 Takte)

das macht das synchronisieren vlt etwas einfacher
wobei ich bezweifle ob du das du auf der STM Seite
so Taktgenau hinbekommst

---------------------------------------

LD D,0       
LD E,12         // Maske fuer Bit2 und Bit3

IN  A,(00)   11
AND E        4 
RLA          4
RLA          4
LD  D,A      4
NOP          4

IN  A,(00)   11
AND E        4
OR  D        4
RLA          4
RLA          4
LD  D,A      4

IN  A,(00)   11
AND E        4
OR  D        4
LD  D,A      4
NOP          4
NOP          4

IN  A,(00)   11
AND E        4
RRA          4
RRA          4
OR  D        4
LD  D,A      4

---------------------------------------

Summe = 124 Takte

[Sean G. (atmega318)]

Uwe B. schrieb:
> hier nochmal ein Nachtrag
>
> damit ist der Code zwar um 4 Takte langsamer,
> aber dafür sind die Stellen an denen gelesen wird
> gleich lange auseinander (je 20 Takte)

Spricht irgend etwas dagegen die unteren zwei Blöcke zu vertauschen? 
Weil dann könnte ich ja die 2 NOPs weglassen, und die Daten dort aufs 
LCD übertragen.

> das macht das synchronisieren vlt etwas einfacher
> wobei ich bezweifle ob du das du auf der STM Seite
> so Taktgenau hinbekommst

Ja, das macht es sicher einfacher. Ich wollte einfach ein oder mehrere 
Sync Punkte pro Frame haben, und der STM32 zählt dazwischen mit einem 
Timer mit.
Danke nochmals, Sean

[Uwe B. (derexponent)]

Sean Goff schrieb:
> Spricht irgend etwas dagegen die unteren zwei Blöcke zu vertauschen?

dann muss es beim senden aber auch vertauscht werden

---------------------------------------

LD D,0          // D = xxxxxxxx
LD E,12         // Maske fuer Bit2 und Bit3

IN  A,(00)   11 // STM sendet Bit 7+6
AND E        4 
RLA          4
RLA          4
LD  D,A      4  // D = xx76xxxx
NOP          4

IN  A,(00)   11 // STM sendet Bit 5+4
AND E        4
OR  D        4
RLA          4
RLA          4
LD  D,A      4  // D = 7654xxxx 

IN  A,(00)   11 // STM sendet Bit 1+0
AND E        4
RRA          4
RRA          4
OR  D        4
LD  D,A      4  // D = 7654xx10

IN  A,(00)   11 // STM sendet Bit 3+2
AND E        4
OR  D        4
LD  D,A      4  // D = 76543210

---------------------------------------

Summe = 116 Takte

[Sean G. (atmega318)]

Uwe B. schrieb:
> Sean Goff schrieb:
>> Spricht irgend etwas dagegen die unteren zwei Blöcke zu vertauschen?
>
> dann muss es beim senden aber auch vertauscht werden

Ja das ist mir klar. Ich habe es jetzt mal so gestartet, und es 
scheint zu gehen, ich mach mich dann mal an den sendenden Teil.

[Sean G. (atmega318)]

DANKE an alle, speziell an derexponent! Das mit den Graustufen musste 
ich leider verwerfen, oder sagen wir mal vertagen ;), denn es flackerte 
zu fest. Dafür habe ich jetzt eine hohe Updaterate, und das mit der 
Synchronisation funktioniert auch. Ich habe jetzt alle 64 Bytes (256 
"Takte") einen Synchpuls Z80-> STM32. Genaue tests mit verschiedenen 
Rechnern (Typenstreuung) habe ich noch nicht, aber zumindest an dem 
einen Testobjekt sitzt die Synchronisation, sodass jeder Pixel perfekt 
ankommt. Bilder folgen dann später, sobald ich eine vernünftige Demo 
habe.
Und dabei auch noch ein bisschen ASM Verständnis bekommen :)
Danke nochmals, Sean
PS: Ich benutze jetzt http://clrhome.org/asm/ als Assembler, echt cool 
die Seite (man MUSS es ja nicht für TR`s verwenden, aber allgemein als 
Z80 Assembler)

[Sean G. (atmega318)]

Ich habe jetzt das mit der Synchronisation doch nochmals geändert, ich 
habe gemerkt, dass damit es mit allen Taschenrechnern ohne 
Clock-Kalibrierung funktioniert ein Synchronisieren bei jedem Byte 
sinnvoll ist. Jetzt funktioniert der Teil super, ich habe mal ein Video 
angehängt was es bis jetzt kann (LCD Ansteuern, Tasten abfragen mit 
gedrückt Erkennung, was zum Beispiel das TI-Basic ausser bei den 
Pfeiltasten nicht kann.)

[Sean G. (atmega318)]

Karl Heinz schrieb:
> Sean Goff schrieb:
>
>
>> auch möglich, dass der Z80 den Clock vom STM32 bekommt, dann können sie
>> ja nicht mer weglaufen.
>
> Wie - Du hast nicht noch mal eine seperate Clock-Leitung, sondern willst
> 780 Bytes dadurch übertragen, dass das Timing 2-er unterschiedlicher
> Prozessoren absolut synchron verläuft? Noch dazu mit einer Z80 Gurke,
> mit der du Anweisungen so anordnen musst, dass alles aufgrund der
> internen OpCode-Zyklen taktgenau rauskommt. Und das alles dann auch noch
> mit einem gewissen Speed, der den Nachteil hat, dass du dir in das
> Timing nicht sehr große Reserven einbauen kannst, die dir akkumulierte
> Zeitfehler abfangen könnten.
>
> Ich muss sagen: Du hast Gottvertrauen.
> Wenn du das zuverlässig hinkriegst, dann setze ich Himmel und Hölle in
> Bewegung, dass dich der Papst nach deinem Ableben 'heilig' spricht. Das
> wäre dann wenigstens mal ein Heiliger mit einem echten Wunder.

Wird leider doch nichts damit :(
Obwohl, auf dem einen bestimmten Z80, für den ich das eingestellt hatte 
ist es absolut zuverlässig gelaufen! Nicht einen einzigen Pixelfehler... 
Die Tatsache, dass man das aber für jeden einzeln einstellen hätte 
müssen, hat dem aber den Garaus gemacht.