C64 ROM Signale und Timing

Zitat von bigby

Nun frage ich mich, sind das normale, zu erwartende "Glitches"? Oder liegen die nur an dem Ersatz-PLA auf meinem Test-Board?

Irgendein Entwickler der C64 sagte anscheinend mal sinngemäß: "Der C64 ist ein Computer, der so aussieht, als funktioniere er."

Ohne es zu wissen würde ich sagen, diese Glitches/Spikes sind normal und kommen auch mit einem normalen PLA vor - das wäre übrigens interessant, wenn du das gegentesten könntest. Dadurch, dass nicht alle Signale gleichzeitig anliegen (siehe z. B. Timing-Diagramm des 6510) und weil nicht alle Bauteile die gleichen Zugriffszeiten aufweisen (Exemplarstreuung usw.) kommt es kurzfristig zu Zuständen wie diesen. Wichtig sind die Signalzustände zu bestimmten Zeitpunkten, z. B. an den Flanken von Phi0 und AEC.

(Keine Garantie auf Richtigkeit, sondern eher wie Pipi Langstrumpf: "Ich mach mir die Welt ...")

Es wurden zwar Experten gefragt, aber ich sehe das wie kinzi Langstrumpf. Da die Spitzen offenbar nichts machen/auslösen, ist das eben ein digitales Rauschen, was nur mit diesen neumodischen hochauflösenden Messgeräten überhaupt sichtbar wird.

Interessant wäre aber schon, wer bzw. was die Spitzen verursacht. Du baust nicht zufällig gerade ein KU-Board o.ä. auf und könntest nach jedem jeweils neu hinzugekommenen Teil am Bus neu messen?

Zitat von advotax

Es wurden zwar Experten gefragt, aber ich sehe das wie kinzi Langstrumpf.

Och, ich hab mich auch ganz frech und ungefragt reingedrängt. Komm nur, ist genug Platz hier.

Zitat von advotax

Interessant wäre aber schon, wer bzw. was die Spitzen verursacht.

Unterschiedliche Signallaufzeiten im PLA (da unterschiedlich "lange" Logikterme angewendet werden) und durch die hier und dort eingestreuten TTL-Gatter (vor allem UND und Inverter) bei einzelnen Signalen.

Wenn z. B. zwei Signale verUNDet werden, das eine aber noch davor invertiert werden muss, weil seine Polarität nicht passt kann so was schon vorkommen. Macht man sich ja ab und zu sogar absichtlich zu Nutze, um ganz ganz kurze Spikes absichtlich erzeugen zu können.

Zitat von bigby

Danke schon mal für Deine "Interpretation".

Und dir danke für die richtige Bezeichnung dafür.

Zitat von kinzi

Unterschiedliche Signallaufzeiten im PLA

Du meinst, (nur) dort? Dann müsste es ja - ich hänge mich mal weit raus - deutliche, also wenigstens messbare Unterschiede zwischen original PROM, CPLD- und EPROM-Versionen geben, allein schon aufgrund der unterschiedlichen Geschwindigkeit der Bausteine. Nur mal schnell die Datenblätter nach Gatterlaufzeiten überflogen:

• 82S100: 35-80 ns
• XC9356XL (z.B. PLAnkton): max. 10ns
• 27C512: 90-150ns

Wobei ich jetzt nicht weiß, ob man den EPROM-Wert oder diese Werte überhaupt gleichsetzen kann. Eslapion hatte ja rausgefunden, dass es meist an zu schnellen EPROMs (45ns) scheitert und nur die echten 90ns OTP von ST problemlos funktionieren, weshalb er beim PLAnkton auch entsprechende Verzögerungen (softwareseitig?) eingebaut hat.

Vielleicht liegt es ja weniger (nur) an den Laufzeiten, als (auch) an derartigen Spitzen auf den Bussen, dass z.B. Super Zaxxon nicht mit EPROM-PLAs läuft?

Ich dachte aber eher an andere Busteilnehmer und eventuelle Wechselwirkungen. Daher die Idee mit dem stufenweisen Aufbau. Die INIT-Routine des 6510 läuft ja beispielsweise "ohne alles". Da könnte man immer wieder mit definiertem Start (RESET-getriggert) messen. Vielleicht muss man einfach nur konsequent µT-RAMs einsetzen und schon flutscht alles. Aber eine solche Analyse ist wohl auch einfach zuviel Aufwand bei höchstwahrscheinlich geringer Ausbeute. Dann wiederum wäre die nächsten Tage und (hoffentlich nicht) Wochen genug Zeit...

Zitat von advotax

Du meinst, (nur) dort?

"Nur" nicht, siehe meine zusätzlichen Ausführungen. Aber ich bin ziemlich sicher: Auch und gerade dort.

Fest steht: das /CE des ROMs muss lange genug anliegen, sonst kümmert es das ROM gar nichts. Also machen diese "Spitzen" nichts. Fest steht auch: Nicht alle Eingangssignale am PLA liegen exakt zeitgleich an: A15-A12 liegen z. B. sicher nicht zeitgleich mit AEC, Phi0, RAS, CAS usw. an. Die Ausgänge "zappeln" sich folglich zum definierten Zustand hin. Daher sind solche "Glitches" meiner Meinung nach gerade zu "intrinsisch".

Zitat von advotax

Vielleicht muss man einfach nur konsequent µT-RAMs einsetzen und schon flutscht alles.

Ketzer!

Zitat von bigby

Naja, zumindest die "Spitzen", von denen wir hier sprechen, sind ja auch auf dem Datenbus zu sehen. Sie sind also lang genug, um das ROM zu kümmern.

Nicht. wenn /CE nicht lange genug aktiv ist.

Wenn ich das richtig sehe, treten diese Glitches auf den Datenleitungen immer mit /CE auf - entweder bei einem kurzen /CE-Glitch oder an der Flanke, wenn /CE regulär low geht. Beides ist egal, weil im ersten Fall das ROM gar nicht selektiert wird (viel zu kurz) und im zweiten Fall viel länger braucht, bis es auf /CE reagiert.

Warum allerdings auch auf den Datenleitungen diese Spitzen daherkommen kann ich mir im Moment nicht erklären.

Zitat von kinzi

Warum allerdings auch auf den Datenleitungen diese Spitzen daherkommen kann ich mir im Moment nicht erklären.

Das können natürlich auch Einkopplungen in die Messleitungen sein. Der C64 ist ja schließlich fast so viel Radiosender wie Computer.

bigby Hast du Zeit, Lust und Möglichkeit, das Ganze auch mit Original-PLA zu testen bzw. zu vergleichen? Wenn es damit genauso glitcht, ist zumindest der PLA-Ersatz (welchen hast du überhaupt drin?) als Quelle augeschlossen und es "muss" so sein.

Ich sage ja: "It's not a bug, it's a feature!"

[EDIT]

bigby Wenn du Zeit und Lust hast, häng doch mal Phi0 statt einer der Adressleitungen dran, damit man das im zeitlichen Kontext sieht.

[/EDIT]

Ist das Phi0 oder Phi2?

Dachte ich springe mal kurz rein mit meiner Erfahrung: die pla braucht 'ne weile, bis es die richtigen signale ausgibt. Bis dahin gehen andere output signale kurz low und deren chips reagieren natürlich. Und die PLA Reaktion ist bei manchen Dingen (Adressen) 'interessanter' als wo anders, ebenfalls aus naheliegenden Gründen, wenn man mal drüber nachdenkt. Bei 'langsamer' digitaler hw der Zeit ist das weniger problematisch - die braucht eh ne Weile, aber wenn man sich das heutzutage ansieht und besonders wenn man nur auf einen trigger warten würde bei deutlich schnellerer hw ist das problematisch und man muss es verstehen und handeln.

Die Daten müssen ja erst stabil sein, wenn der 6510 später samplet, und dann müssen sich alle am Bus schlüssig sein wer gemeint ist/war..

Aber ja - wenn man denkt, das man saubere Signale sehen würde ohne richtig viel 'glitches', sollte man nicht am kernalsockel rummessen

Zitat von bigby

Weißt Du zufällig, wieviel später der 6510 die Daten einliest?

Siehe sein Datenblatt:

http://www.zimmers.net/anonftp…nts/chipdata/6510-pre.zip

[FALSCHE BILDER ENTFERNT]

Er sampelt an der steigenden Flanke, daher meine Frage ob es Phi0 oder Phi2 ist, weil mir dein Bild etwas merkwürdig vorkommt.

[EDIT]

Jetzt weiß ich auch, wieso ... ich hab' wieder mal das falsche Datenblatt erwischt. Das ist das richtige:

http://www.zimmers.net/anonftp…cuments/chipdata/6510.zip

Weil im obigen (preliminary) gibt es noch die Eingänge Phi1 und Phi2, und der 6510 hat schlussendlich Eingang Phi0 und den Ausgang Phi2 (er generiert Phi1 und Phi2 on-chip selbst). Daher sind diese richtig:

Und dann passt es auch mit deinem Timing zusammen.

[/EDIT]

[EDIT #2]

Das Forum macht mich wahnsinnig mit seiner Bilderverwaltung ...

Jetzt müsste es passen.

[/EDIT #2]

[EDIT #3]

So, nachdem ich mich vollends entblödet habe passt's. Er sampelt bei fallendem Phi0.

[/EDIT #3]

Zitat von bigby

Ach ja, aber wenn man wissen möchte, sie die Signale aussehen, die so am Kernal ROM ankommen, und keine theoretischen Werte, dann muß da schon rummessen...

Genau, und das schöne ist, dass man dann interessantes sieht wie das hier und dann 'was lernt.

Zur Frage zurück: die 'glitches' sind also normal und die Zeit, die es braucht bis das richtige CS aktiv ist hängt ab von board rev.(etwas)/pla(mehr)/adress-range. Absolute worst case den ich sah ist vergleichweise 'spät', einige dutzend ns (müsste ich nachsehen für genaue werte, aber mehr als ich erst annahm). Bis dahin war in dem

Fall der kernal angesprochen, um ihn dann zu deselektieren. Dieser schlimmste case ist reproduzierbar - aber in normalem Betrieb seltenst bis nie zu sehen.