Hello, Guest the thread was called744 times and contains 26 replays

last post from androSID at the

C64 ROM Signale und Timing

  • Ich hätte da mal ein paar hoffentlich nicht allzu dämliche Fragen an die Expertenrunde.


    Aus Interesse wollte ich mir das Timing der Signale am Kernal ROM des C64 genauer anschauen. Dazu habe ich im ersten Schritt den billigen Logic-Analyzer Klon rausgekramt, den ich vor einiger Zeit beschafft habe, und angeschlossen. Da das Teil nur 8 Kanäle hat, habe ich einen an den /CE Pin angeschlossen, vier an A0-A3 und die letzten 3 an D0-D2. Dann habe ich 1 Sekunde Daten aus dem "Leerlauf" des C64 mitgeschnitten und wollte mal sehen, ob das Bild für mich Sinn macht:


    Im großen und ganze würde ich sagen "ja". Aber dann sind da die vielen merkwürdigen, viel zu schmalen Spitzen auf dem /CE Signal und auf dem Datenbus. Die habe ich mir dann mit dem Oszi noch ein wenig genauer angeschaut und konnte sie auch dort leicht wiederfinden:


    Gelb ist hier /CE und Lila ein Pin des Datenbusses.


    Nun frage ich mich, sind das normale, zu erwartende "Glitches"? Oder liegen die nur an dem Ersatz-PLA auf meinem Test-Board? Lasse ich die vom Logic-Analyzer großzügig rausfiltern? Den Betrieb des Rechners scheinen sie nicht weiter zu stören.

  • 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." :-D


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

  • 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. :-D

    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.

    Danke schon mal für Deine "Interpretation".

    Und dir danke für die richtige Bezeichnung dafür. :-)

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

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

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

    Ketzer! :redcard: :D

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

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

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

    Ja klar! Bei den beiden Bilder aus dem ersten Post war ein XCPLA (DodgyPLA) auf dem Board. Ich habe nun mal eine original PLA von einem anderen Board geliehen, und das Bild sieht eigentlich nicht viel anders aus:




    Exakt das selbe Setup, nur andere PLA.

  • 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]

  • 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 ;)

  • RetroJeck Auch Dir danke für die Hinweise! Weißt Du zufällig, wieviel später der 6510 die Daten einliest? Wann der Bus also spätestens stabil sein muß in Relation zum /CE Signal am ROM? Wenn ich mir die Datenblätter einiger älterer EPROMs so anschaue, so stehen da erstaunlich große obere Schranken für die Zweit dazwischen (so in der Größenordnung von 200ns).


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

  • 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 ... :cursing:

    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]

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