Dietrich hat geschrieben:Das geht ja im 10-Minuten-Takt hier weiter

Bernd hat geschrieben:Falls erforderlich ist bei dem verwendeten Baustein ja noch etwas frei um für dein CF Adapter den Impuls auf die richtige Länge zu bringen. Damit sollte es doch möglich sein.

Ähh, bin kein Gal- oder Lötexperte. Aber wir haben ja in der HAR genug Hardware-Experten, die Sache mit dem CF müssen wir unbedingt sauber hinkriegen. (Sonst wäre mein neues OS ja umsonst )

10 Minuten sind zu viel
Die Hardware kann leicht so verändern werden daß es zu den 280ns reicht. Zur Kontrolle gibt es ja noch ein Oszi.

Bernd

Aha,

das Atari-PHI0 weicht also auch von der 6502-Doku ab. Hatte ich mir schon gedacht... Ich werde nochmal das Sandisk-Datenblatt und die ATA/IDE-Spec studieren (habe ich bisher nur überflogen). Vielleicht habe ich irgendwas übersehen und die Breite des PHI2-Signals kann auch kürzer als 280ns sein *hoff*. Ansonsten könnte es recht kompliziert werden.

Melde mich wieder, wenn ich was habe. Dann sollten wir versuchen (evtl. zusammen mit Hardwaredoc) eine geeignete Schaltung aufzubauen. Wie wär's ?

Gruß Dietrich

Bernd hat geschrieben:Die Hardware kann leicht so verändern werden daß es zu den 280ns reicht. Zur Kontrolle gibt es ja noch ein Oszi.

Super! Endlich ist ein stabiler CF-Betrieb in Sicht. Müssen wir unbedingt probieren!

Soviele Postings an einem Tag habe ich noch nie geschrieben

Dietrich hat geschrieben:Aha,

das Atari-PHI0 weicht also auch von der 6502-Doku ab. Hatte ich mir schon gedacht... Ich werde nochmal das Sandisk-Datenblatt und die ATA/IDE-Spec studieren (habe ich bisher nur überflogen). Vielleicht habe ich irgendwas übersehen und die Breite des PHI2-Signals kann auch kürzer als 280ns sein *hoff*. Ansonsten könnte es recht kompliziert werden.

Melde mich wieder, wenn ich was habe. Dann sollten wir versuchen (evtl. zusammen mit Hardwaredoc) eine geeignete Schaltung aufzubauen. Wie wär's ?

Gruß Dietrich

Geht klar. Es geht doch nichts über ein verändertes Atari Betriebssystem dass eine CF direkt unterstützt.
Da sollte die Hardware keine Fehler mehr machen.

Bis dann,
Bernd

Dietrich hat geschrieben:Ich habe nämlich aufgrund meiner Erfahrungen mit dem CF den Verdacht, dass die CPU (in einigen Ataris) die Adressleitungen kurz vor der fallenden Flanke von PHI2 verändert (was eigentlich nicht sein darf).

Diesen Verdacht kann ich definitiv bestätigen. Genau dieses Problem hat uns alle auch einige graue Haare bei der Freezer-Entwicklung gekostet... Wahrscheinlich sind nicht nur die Adressleitungen sondern auch die Datenleitungen (bei Schreibzugriffen) betroffen, die fallende Flanke von PHI2 kommt einfach zu spät (ich hab leider immer noch kein Oszi).

Abhilfe wie folgt: Beim Lesen wie gewohnt PHI2 nehmen, beim Schreiben PHI2 AND PHI0. Nimmt man beim Lesen auch PHI0 so _könnte_ möglicherweise der Datenbus zu früh auf Tristate sein und die CPU liest Müll. Beim Schreiben (zu normalen RAMs etc.) ist PHI2 AND PHI0 völlig OK: Der Datenbus ist lange vor der fallenden Flanke von PHI0 stabil und alle RAMs etc. übernehmen die Daten mit der steigenden Flanke von /WE (entsprechend der fallenden Flanke von PHIx). Der Zustand des Datenbusses bei der steigenden Flanke von PHIx ist egal (siehe auch Timing-Diagramm der 6502 CPU: Dx ist erst einige Zeit nach der steigenden Flanke von PHI2 gültig).

Manchmal ist es nötig, irgendwelche State-Transitions erst bei der fallenden Flanke von PHI2 zu machen (zB auch im Freezer). Das habe ich im Freezer folgendermaßen gelöst:

Alle modernen CPLDs unterstützen transparente Latches an den Eingängen. Ins Freezer-CPLD gehen nur Adressleitungen rein (mit Datenleitungen wird's ein wenig schwieriger, die sind ja bidirektional und bei Schreibzugriffen erst deutlich später gültig). Hier genügt es, einfach die Eingänge mit PHI2=high zu latchen. Intern sind dann alle Leitungen bis zur fallenden Flanke von PHI2 stabil.

Wie gesagt, bei den Datenleitungen ist's nicht so leicht, die einfachste Lösung ist hier, die fallende Flanke von PHIx etwas vorzuziehen.

so long,

Hias

Hallo Dietrich,

ich habe da einige Veränderungen an der Schaltung durchgeführt. Das Ergebnis ist ein Signalamplitude von 5V und ein stabiles Reckecksignal mit einer Länge von ca. 260us. Beim Versuch den Impuls zu verlängern gabt es Probleme mit dem Antic. 260us ist das Maximum.

Was du gestern von mir bekommen hast ist nicht mehr aktuell. Ich arbeite daran. Nach Abschluss sende ich es dir wieder zu.

Bernd

Danke Hias,

jetzt verstehe ich auch Bernds PHI2-Signal. Es geht hier weniger um die Stabilisierung von PHI2, sondern darum, die fallende Flanke von PHI2 etwas vorzuziehen, so dass bei Schreibzugriffen (auf ein SRAM) die CPU den Datenbus noch belegt, wenn das SRAM darauf zugreift. Beim getakteten Lesen ist es besser, PHI2 etwas zu verzögern, damit das SRAM den Datenbus noch belegt, wenn die CPU den Datenbus ausliest.

Damit ist mir auch der Ausgang von Bernds Experimenten klar: BPHI2 (PHI2 an der PIA) funktioniert nicht, weil die Flanke am SRAM für Schreibzugriffe zu spät kommt (für Lesezugriffe kein Problem). PHI0 funktioniert nicht weil die Flanke am SRAM für Lesezugriffe zu früh kommt (für Schreibzugriffe kein Problem).

Eins verstehe ich noch nicht ganz: Wenn jetzt beim Schreiben PHI0 AND PHI2 benutzt wird, wird damit die fallende Flanke um ca. 50ns (?) vorgezogen. Dann könnte man doch auf Latches an den Adressleitungen verzichten, oder? Oder sollten die Adressleitungen auch während PHI0 AND PHI2 = High nicht stabil sein? (Ich würde gern auf Latches verzichten, um die Schaltung einfach zu halten.)

Gruß Dietrich

Hallo Hias,

ich habe da noch eine einfache Idee um das PHI2 Signal stabiler zu bekommen. Beim 800XL und 130XE liegt hinter dem PHI2 Ausgang ein 74LS08. Den werde ich mal gegen einen HCT Typen austauschen.

Die SRam Erweiterung hatte ich bislang am PHI2 Eingang des PIA angeschlossen mit dem Resultat dass es zu Speicherfehlern kam. Die Vermutung von dir mit dem zu langen PHI2 Signal ist richtig und liegt an dem 74LS08. Durch den Alterungsprozess kommt es zu einer Laufzeitverzögerung. Mal sehen ob ein HCT Baustein nicht wunder wirkt.

Bernd

Dietrich hat geschrieben:Danke Hias,

jetzt verstehe ich auch Bernds PHI2-Signal. Es geht hier weniger um die Stabilisierung von PHI2, sondern darum, die fallende Flanke von PHI2 etwas vorzuziehen, so dass bei Schreibzugriffen (auf ein SRAM) die CPU den Datenbus noch belegt, wenn das SRAM darauf zugreift. Beim getakteten Lesen ist es besser, PHI2 etwas zu verzögern, damit das SRAM den Datenbus noch belegt, wenn die CPU den Datenbus ausliest.

Damit ist mir auch der Ausgang von Bernds Experimenten klar: BPHI2 (PHI2 an der PIA) funktioniert nicht, weil die Flanke am SRAM für Schreibzugriffe zu spät kommt (für Lesezugriffe kein Problem). PHI0 funktioniert nicht weil die Flanke am SRAM für Lesezugriffe zu früh kommt (für Schreibzugriffe kein Problem).

Eins verstehe ich noch nicht ganz: Wenn jetzt beim Schreiben PHI0 AND PHI2 benutzt wird, wird damit die fallende Flanke um ca. 50ns (?) vorgezogen. Dann könnte man doch auf Latches an den Adressleitungen verzichten, oder? Oder sollten die Adressleitungen auch während PHI0 AND PHI2 = High nicht stabil sein? (Ich würde gern auf Latches verzichten, um die Schaltung einfach zu halten.)

Gruß Dietrich

Beim schreiben wird der Zyklus um ca. 50ns früher beendet . Wenn PHI2 zu spät abfällt kommt es zu Speicherfehlern. Um dies zu verhindern wird der Zyklus einfach etwas gekürzt. Geniale Idee .....

Bernd

Hi Bernd,

bin gespannt, wie du das Signal verlängert hast. Ich habe jetzt nochmal die ATA-1 und ATA-2-Spec und die Datenblätter zu Sandisk- und Toshiba-CFs gewälzt - mit einem überraschenden Ergebnis:

Die erforderlich Breite des RD- und WR-Signals (und damit die Breite des Taktsignals) ist übereinstimmend in allen Unterlagen so definiert (man muss nur das kleingedruckte lesen ):

Code: Alles auswählen

 PIO-Mode         0    1    2    3    4
 8-Bit-Betrieb   290  290  290   80   70 (in ns)
16-Bit-Betrieb   165  125  100   80   70 (in ns)


Zum PIO-Mode: Bei den Sansdisk-Standard-CFs wird PIO-Mode 1 benutzt, Ultra-Karten haben PIO-Mode 2, Ultra-II Karten daher vermutlich Mode 3.

Wenn wir also auf den 8-Bit-Betrieb verzichten, haben wir keine Timing-Probleme mehr. Nachteil ist natürlich, dass damit die Hälfte des CF ungenutzt ist. Trotzdem würde bei meinem OS noch immer das Doppelte bis Vierfache an Images auf das CF passen als bei MyIDE

Was hältst Du von Hias Vorschlag zum Timing (beim Schreiben PHI2 AND PHI0 benutzen, beim Lesen PHI2 benutzen) ? Das müsste meiner Meinung nach einwandfrei funktionieren. Ich werde mal eine einfache Gatterlogik dazu entwerfen.

Gruß Dietrich

Dietrich hat geschrieben:Hi Bernd,

bin gespannt, wie du das Signal verlängert hast. Ich habe jetzt nochmal die ATA-1 und ATA-2-Spec und die Datenblätter zu Sandisk- und Toshiba-CFs gewälzt - mit einem überraschenden Ergebnis:

Die erforderlich Breite des RD- und WR-Signals (und damit die Breite des Taktsignals) ist übereinstimmend in allen Unterlagen so definiert (man muss nur das kleingedruckte lesen ):

Code: Alles auswählen

 PIO-Mode         0    1    2    3    4
 8-Bit-Betrieb   290  290  290   80   70 (in ns)
16-Bit-Betrieb   165  125  100   80   70 (in ns)


Zum PIO-Mode: Bei den Sansdisk-Standard-CFs wird PIO-Mode 1 benutzt, Ultra-Karten haben PIO-Mode 2, Ultra-II Karten daher vermutlich Mode 3.

Wenn wir also auf den 8-Bit-Betrieb verzichten, haben wir keine Timing-Probleme mehr. Nachteil ist natürlich, dass damit die Hälfte des CF ungenutzt ist. Trotzdem würde bei meinem OS noch immer das Doppelte bis Vierfache an Images auf das CF passen als bei MyIDE

Was hältst Du von Hias Vorschlag zum Timing (beim Schreiben PHI2 AND PHI0 benutzen, beim Lesen PHI2 benutzen) ? Das müsste meiner Meinung nach einwandfrei funktionieren. Ich werde mal eine einfache Gatterlogik dazu entwerfen.

Gruß Dietrich

Die Signaldauer der CF-Karten im 8bit Mode ist zu lang. Wenn du im 16bit Modus arbeitest bist du zu allen anderen Kartenlesern inkompatibel, das wäre schade. Ich denke mit nur 2 TTLs ist der 8bit Mode machbar. Auch Noname CF-Karten können dann eingesetzt werden.

Bernd

Bernd hat geschrieben:Wenn du im 16bit Modus arbeitest bist du zu allen anderen Kartenlesern inkompatibel, das wäre schade.

? Ich hatte nicht vor, auf dem CF ATR-Images als FAT-Dateien zu speichern. Das ist wegen des 16-Byte-ATR-Headers ausgeschlossen, weil die Atari-Sektoren deswegen auf 2 CF-Sektoren verteilt sein können. Dafür bräuchte ich einen 1KB Puffer im RAM, den ich nicht habe.

Falls es mit dem Timing nicht klappen sollte, bleibt der 16bit-Betrieb noch als Notlösung.

Dietrich hat geschrieben:Eins verstehe ich noch nicht ganz: Wenn jetzt beim Schreiben PHI0 AND PHI2 benutzt wird, wird damit die fallende Flanke um ca. 50ns (?) vorgezogen.

Ja, genau.

Dann könnte man doch auf Latches an den Adressleitungen verzichten, oder?

Für normales I/O ja. Die Latches brauchst Du nur dann, wenn Du zB eine State-Machine hast und die State-Transitions am Ende des Clock-Cycles (fallende Flanke von PHI2) machen willst/musst. Letzteres ist beim Freezer der Fall, die State-Machine zur Aktivierung des Freezers muß synchron mit dem Atari-Takt laufen.

Oder sollten die Adressleitungen auch während PHI0 AND PHI2 = High nicht stabil sein?

In dieser Zeit (genauer: bei der fallenden Flanke von PHI0 AND PHI2) müssen die Signale stabil sein. Ansonsten ist die CPU way out of spec (oder einfach gesagt komplett hinüber).

so long,

Hias

Dietrich hat geschrieben:

Code: Alles auswählen

 PIO-Mode         0    1    2    3    4
 8-Bit-Betrieb   290  290  290   80   70 (in ns)
16-Bit-Betrieb   165  125  100   80   70 (in ns)


Zum PIO-Mode: Bei den Sansdisk-Standard-CFs wird PIO-Mode 1 benutzt, Ultra-Karten haben PIO-Mode 2, Ultra-II Karten daher vermutlich Mode 3.

Wenn wir also auf den 8-Bit-Betrieb verzichten, haben wir keine Timing-Probleme mehr.

So einfach ist das alles leider nicht (es gibt noch mehr Kleingedrucktes in der ATA Spec).

Geräte, die PIO 3 und höher unterstützen, sollen beim Einschalten im PIO Mode 0, 1, oder 2 sein. Danach kann man die unterstützten PIO Modi abfragen und das Gerät manuell in einen höheren PIO Mode setzen. Und nun beisst sich die Katze in den Schwanz:

Register Transfers sind immer im 8-Bit Modus. Und dieser Modus verlangt nun 290ns Pulse Width. Der 16-Bit Modus bezieht sich nur auf den Daten-Transfer. Um nun ein Gerät in PIO Mode 3 zu bringen, muß man erst mal die Register richtig beschreiben können...

Siehe ATA/ATAPI-8 Parallel Transport Rev 0b http://t13.org/docs2005/d1698r0b-ATA8-APT.pdf Seite 141ff.

Bei den Compact-Flash Karten gibt es einen Modus, sodaß Daten-Transfers auch in 8bit möglich sind (über das Set Features Kommando, $EF, Feature $01). Ich hatte das mal ausprobiert, aber es hat nicht so richtig geklappt. Hattest Du in dieser Richtung schon Erfolg?

Achja, beim Lesen der CompactFlash Card Spec fällt mir gerade auf, daß bei PIO Mode 3 und höher das Auswerten von IORDY verpflichtend vorgeschrieben ist...

so long,

Hias

HiassofT hat geschrieben:

Dietrich hat geschrieben:

Code: Alles auswählen

 PIO-Mode         0    1    2    3    4
 8-Bit-Betrieb   290  290  290   80   70 (in ns)
16-Bit-Betrieb   165  125  100   80   70 (in ns)


Zum PIO-Mode: Bei den Sansdisk-Standard-CFs wird PIO-Mode 1 benutzt, Ultra-Karten haben PIO-Mode 2, Ultra-II Karten daher vermutlich Mode 3.

Wenn wir also auf den 8-Bit-Betrieb verzichten, haben wir keine Timing-Probleme mehr.

So einfach ist das alles leider nicht (es gibt noch mehr Kleingedrucktes in der ATA Spec).

Geräte, die PIO 3 und höher unterstützen, sollen beim Einschalten im PIO Mode 0, 1, oder 2 sein. Danach kann man die unterstützten PIO Modi abfragen und das Gerät manuell in einen höheren PIO Mode setzen. Und nun beisst sich die Katze in den Schwanz:

Register Transfers sind immer im 8-Bit Modus. Und dieser Modus verlangt nun 290ns Pulse Width. Der 16-Bit Modus bezieht sich nur auf den Daten-Transfer. Um nun ein Gerät in PIO Mode 3 zu bringen, muß man erst mal die Register richtig beschreiben können...

Siehe ATA/ATAPI-8 Parallel Transport Rev 0b http://t13.org/docs2005/d1698r0b-ATA8-APT.pdf Seite 141ff.

Bei den Compact-Flash Karten gibt es einen Modus, sodaß Daten-Transfers auch in 8bit möglich sind (über das Set Features Kommando, $EF, Feature $01). Ich hatte das mal ausprobiert, aber es hat nicht so richtig geklappt. Hattest Du in dieser Richtung schon Erfolg?

Achja, beim Lesen der CompactFlash Card Spec fällt mir gerade auf, daß bei PIO Mode 3 und höher das Auswerten von IORDY verpflichtend vorgeschrieben ist...

so long,

Hias

Hallo Hias,

in der ATA/ATAPI-8 Parallel Transport Rev 0b Anleitung findet man das Timing Diagramm auf Seite 142 und die Zeiten dazu auf Seite 143.
Wo wir sicherlich in der Spezifikation sind ist das maximale Zeitfenster zwischen zwei Schreibzyklen von 600ns. Nun habe ich da eine Frage: Muß der Impuls von 290us nur beim schreiben oder auch beim lesen eingehalten werden?

Bernd

Bernd hat geschrieben:in der ATA/ATAPI-8 Parallel Transport Rev 0b Anleitung findet man das Timing Diagramm auf Seite 142 und die Zeiten dazu auf Seite 143.
Wo wir sicherlich in der Spezifikation sind ist das maximale Zeitfenster zwischen zwei Schreibzyklen von 600ns. Nun habe ich da eine Frage: Muß der Impuls von 290us nur beim schreiben oder auch beim lesen eingehalten werden?

Bei beidem. Siehe Table 47 auf Seite 143. t2: DIOR/DIOW pulse width

so long,

Hias

HiassofT hat geschrieben:

Bernd hat geschrieben:in der ATA/ATAPI-8 Parallel Transport Rev 0b Anleitung findet man das Timing Diagramm auf Seite 142 und die Zeiten dazu auf Seite 143.
Wo wir sicherlich in der Spezifikation sind ist das maximale Zeitfenster zwischen zwei Schreibzyklen von 600ns. Nun habe ich da eine Frage: Muß der Impuls von 290us nur beim schreiben oder auch beim lesen eingehalten werden?

Bei beidem. Siehe Table 47 auf Seite 143. t2: DIOR/DIOW pulse width

so long,

Hias

Danke Hias,
jetzt ist der Grund auch klar warum das MyIDE Interface Probleme mit den CF Adaptern hat. Scheinbar kommen die Sandisk CF Karten mit kürzeren Zugriffszeiten aus. Die maximale von mir ermittelte PHI2 Impulslänge liegt bei 250us. Wird diese Zeit überschritten gibt es vom Antic fehlerhafte Bilddarstellungen. Die kleinste Impulslänge liegt bei 150us.

Bernd

Bernd hat geschrieben:Die maximale von mir ermittelte PHI2 Impulslänge liegt bei 250us. Wird diese Zeit überschritten gibt es vom Antic fehlerhafte Bilddarstellungen. Die kleinste Impulslänge liegt bei 150us.

Wie hast Du die kürzeren bzw. längeren PHI2 Impulse generiert und wie ist die Phasenlage im Vergleich zum originalen PHI2 bzw zu PHI0?

so long,

Hias

Jetzt wird's langsam kompliziert:

Hias hat geschrieben:Register Transfers sind immer im 8-Bit Modus. Und dieser Modus verlangt nun 290ns Pulse Width.

Stimmt, hatte ich übersehen. Wir kommen also nicht um die 290ns herum! Damit fällt die direkte Verwendung von PHI2 (High-Dauer etwa 245ns) und PHI0 AND PHI2 (High-Dauer etwa 210ns) wohl aus, wenns mit allen CFs laufen soll. (Die Sandisk-CFs schaffen das aber).

Da bleibt wohl nur folgende Idee:
Beim Schreiben wird als Takt nur (!) für das CF PHI0 genommen, das eine Pulsbreite von 280ns haben sollte. Die Flanke am CF liegt dann etwa 35ns vor der fallenden Flanke von PHI2. Alternativ könnte man die steigende Flanke von PHI0 in ein Monoflop mit einer Haltezeit von 290ns leiten. Damit würde die Flanke am CF etwa 25ns vor der fallenden Flanke von PHI2 liegen. Fürs Lesen (nur für das CF) könnte man PHI0 OR BPHI2 nehmen. Die Impulsbreite ist damit etwa 315ns und die Flanke am CF liegt etwa 20ns hinter der fallenden Flanke von PHI2. Es stellt sich nur die Frage, ob die Adressleitungen bei der steigenden Flanke von PHI0 (70ns vor PHI2) schon gültig sind. Theoretisch ja, notfalls könnten man PHI0 noch etwas verzögern (1 Gatter oder so).
Mit "Flanke am CF" meine ich natürlich die steigenden Flanken der /IORD und /IORW-Signale am CF - gemäß den Gleichungen /IORD = NOT( R/W AND Takt) und /IORW = NOT( NOT(R/W) AND Takt).

Um das genau zu berechnen, brauchen wir ein Oszi-Diagramm, dass PHI2 (an der CPU), BPHI2 (an der PIA) und PHI0 im Verhältnis zueinander anzeigt. Hallo Bernd!

Hias hat geschrieben:Bei den Compact-Flash Karten gibt es einen Modus, sodaß Daten-Transfers auch in 8bit möglich sind (über das Set Features Kommando, $EF, Feature $01). Ich hatte das mal ausprobiert, aber es hat nicht so richtig geklappt. Hattest Du in dieser Richtung schon Erfolg?

Jo, genau das klappt bei mir. Ich habe ein Basic-Pgm (mit etwas 6502-Code) geschrieben, das den Atari auf eingebaute CF-Karten untersucht, dann mit "Set Feature" in den 8bit-Modus geht und anschließend einen "Identify Device" ausführt. Auch beim Schreiben und Lesen von 512 Byte-Sektoren gabs im 8bit-Betrieb keine Probleme. Im 8bit-Betrieb kriege ich 4- bis 8mal soviele Images auf ein CF wie bei MyIDE

Bernd hat geschrieben:Die maximale von mir ermittelte PHI2 Impulslänge liegt bei 250us.

Ja, aber das gilt doch nur, wenn du das modifizierte PHI2 auch für die ATARI-ICs benutzt. Es spricht nichts dagegen ein separates Taktsignal nur fürs SRAM und das CF zu generieren, siehe oben

Hias hat geschrieben:

Dietrich hat geschrieben:Dann könnte man doch auf Latches an den Adressleitungen verzichten, oder?

Für normales I/O ja. Die Latches brauchst Du nur dann, wenn Du zB eine State-Machine hast und die State-Transitions am Ende des Clock-Cycles (fallende Flanke von PHI2) machen willst/musst.

Hmm, beim Schreiben wirds wohl keine Probleme geben, aber beim Lesen evtl. doch: Die Flanke am SRAM bzw. CF muss ja beim Lesen hinter PHI2 liegen (sonst würde das SRAM seinen Datenbus dekativieren bevor die CPU die Daten lesen konnte). Damit könnte die CPU die Adressleitungen doch zu früh ändern. Ergo wären die Latches doch erforderlich, wenn das modifizierte Taktsignal das Problem nicht abstellt.

Hallo Dietrich,

hier kommen die Oszi Bilder.


___________________________________________________________________________________
PHI0 zu PHI2 abgenommen an der CPU
gelb=PHI0



___________________________________________________________________________________
PHI0 zu PHI2 abgenommen an der PIA
gelb=PHI0





___________________________________________________________________________________
PHI2 CPU zu PHI2 PIA
gelb=PIA




___________________________________________________________________________________

Ich habe da eine Idee. Um auf die Impulslänge zu kommen fehlt nicht mehr viel. Einige Zeit geht beim Impulsanstieg vom Sägezahn PHI2 der CPU verloren. Wenn ich die Schaltung an PHI0 setze kommt das Signal früher und kann somit länger gehalten werden.

Auf einen neuen Versuch,
Bernd