C64 Reloaded / Bugs / Auffälligkeiten


    • Pentagon
    • 39697 Aufrufe 385 Antworten

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Pentagon schrieb:

      Das ist ein reiner, sachlicher Fachthread indem man gemeinsam die gefundenen Dinge berichten kann. So dass ein anderer sagen kann: "Das ist bei mir und meinem Board auch genauso".
      Ich glaube auch was gefunden zu haben: C64R: Falsche Logikfamilie für die diskrete Logik verwendet?

      Moin!

      Ich bin durch die Arbeit an meiner eigenen C64-Reinkarnation C64xs vor ein paar Wochen an einem Punkt angelangt, an dem ich mich entscheiden musste, welche Logikfamilie ich für die auf dem Board verteilen diskreten Logikelemente verwende.

      Beispielsweise habe ich (wie der C64R auch) auf der Platine nur ein einziges EProm, auf dem Kernal, Basic und CharSet gemeinsam gespeichert werden. Damit die Ansteuerung (lies: Auswahl des richtigen Bereiches) klappt, bedient man sich ein paar logischer Gatter, die zwischen den Select- und Adressleitungen, sowie dem anzusteuernden EProm geschaltet werden.

      Siehe diese Ausschnitte aus den Schaltplänen:

      Mein "C64xs"-Board:
      A.jpg

      Das "C64 Reloaded"-Board
      B.jpg

      Für das Problem, welches ich unten beschreibe, dient die Adressleitung A12 als Beispiel. Es betrifft jedoch weite Teile des C64R.

      So sind meiner Meinung nach im C64R folgende ICs in der HCT-Logikfamilie anstatt in der HC-Logikfamilie auszuführen:

      U8 (aufgrund der Ausgänge der CIA U2)
      U14 (aufgrund der Signale vom VIC-II)
      U15 (aufgrund Adressleitungen A10, A11 der CPU)
      U16 (aufgrund der Datenleitungen)
      U20 (aufgrund der Signale der PLA)
      U26 (aufgrund AEC und RAS vom VIC-II)
      U27 (aufgrund der Signale A12 und BA)
      U28 (aufgrund COL6 und COL7 (Ausgänge der CIA U1))

      U13 und U25 sind im Schaltplan zwar meiner Meinung nach fehlerhaft als HC-Logik gezeichnet, eingebaut wurde jedoch zumindest bei mir (meiner Ansicht nach richtigerweise) HCT-Logik (wegen den Adressleitungen der CPU am Eingang):

      C.jpg


      Welcher Logikfamilie müssen dieses zwischengeschalteten ICs angehören?
      Die benötigten ICs hatte ich für mein Projekt in HC-Logik und HCT-Logik verfügbar. Aber welche Logikfamilie ist die richtige? Muss ich HC verwenden oder HCT, oder ist es vielleicht sogar egal?

      Ich beschreibe im Folgenden den nur wirklich relevanten Teil meiner Untersuchungen. Das Thema könnte man auch wesentlich detailierter wiedergeben, mit noch viel mehr Theorie. Das würde aber niemand bis zum Schluss lesen.


      Basics
      Fangen wir also an: Wo ist denn überhaupt der Unterschied zwischen HC und HCT?

      HC und HCT beschreiben im Grunde nur eine Logikfamilie, nämlich "High-Speed-CMOS", wobei die HCT-Familie an ihren Eingängen eine im Vergleich zur HC-Familie andere "Empfindlichkeit für Low- und High-Pegel" besitzt.

      Die Werte für die HC-Logikfamilie (Folgende Eingangswerte sind für Vcc=4,5V. Werte sind nicht fest: Bei Vcc=5,0V sind die Werte leicht höher.):
      High-Pegel: 3,15V - Vcc
      Low-Pegel: GND - 1,35V

      Die Werte für die HCT-Logikfamilie (Eingangswerte für Vcc=5,0V. Werte sind fest definiert.):
      High-Pegel: 2,0V - Vcc
      Low-Pegel: GND - 0,8V

      Die zu stellende Frage lautet demnach: Welche Logikfamilie erkennt an ihren Eingängen die Signale des 6510 (oder der anderen ansteuernden ICs) in jedem Fall (d.h. zu 100%) korrekt?

      Eingänge bei HC und HCT
      Betrachtet man nur den High-Pegel, dann lässt sich folgendes sagen: Der HCT erkennt einen Pegel von beispielsweise 2,5V zu 100% sicher als logisch 1 (da er laut Datenblatt eine logische 1 garantiert ab 2,0V erkennt), während das bei dem HC erst 100% sicher bei 3,15V passiert. Das Datenblatt für einen HC-Typ gibt zwar auch den Wert 2,4V an. Dieser Wert ist aber nur ein typischer Wert, der nicht garantiert ist, sondern nur in den allermeisten Fällen zutrifft, also eben nur typisch. Wenn ich also 2,5V an den HC-Eingang lege, wird das IC dies ziemlich sicher als logisch 1 erkennen. Wenn die Chip-Fabrik aber einen schlechten Tag hatte und das IC nicht typisch reagiert, dann könnte bei 2,5V aber auch schon mal eine logische 0 erkannt werden und z.B. erst ab 2,8V oder vielleicht 3,0V eine logische 1. Das IC wäre aber immer noch innerhalb der Spezifikation (da erst ab 3,15V zu 100% eine logische 1 erkannt werden muss) und kein Ausschuss.

      Ausgänge beim 6510, 6525 und beim 6569
      Das Datenblatt der ICs sagt über die Ausgangspegel an den Pins folgendes aus:

      Low-Pegel: kleiner 0,4V
      High-Pegel: größer 2,4V

      Dies besagt, dass bei den ICs der High-Pegel einer Leitung zwischen 2,4V und 5,0V sein kann. Meistens liegt er im Bereich um 4,0V, er kann und darf(!) aber auch beispielsweise nur 2,5V betragen.

      Wenn ich jetzt so einen "grenzwertigen" 6510 mit nur 2,5V an einem Adress-Pin mit einem "grenzwertigen" HC-Baustein (der vielleicht 2,8V für logisch 1 erwartet) verbinde? Was lässt sich dann über die Funktion sagen? Erkennt diese Kombination eine logische 1? Beide ICs wären ja noch innerhalb ihrer Spezifikationen.

      Und wenn ich diesen "grenzwertigen" 6510 mit nur 2,5V High-Pegel an einem Adress-Pin mit einem HCT-Baustein (der garantiert 2,0V für logisch 1 erwartet) verbinde? Was ist wohl besser?

      Bemerkung am Rande: Die Ausgänge der CMOS-Version des 6510 haben als Highpegel mindesten 3,5V. Da könnte man den HC-Typ ohne Probleme einsetzen...

      Gegenprobe mit EProm
      Wenn man sich das Datenblatt des eingesetzten EProms für die ROM-Inhalte (Kernal, Basic, CharSet) anschaut (dabei ist der Hersteller völlig egal, oder der Typ (27C256 oder 27C512)), dann stellt man hier fest, dass das EProm für seine Eingangssignale am Adressbus für Low und High folgende Eigenschaften erwartet:

      Low: Pegel kleiner 0,8V
      High: Pegel größer 2,0V

      Dies entspricht exakt den Werten für die Eingangssignale bei der HCT-Familie. Und das macht auch Sinn, da es einen Einsatz eines CMOS-Eproms in einer TTL-Umgebung ermöglicht.

      Fazit
      Die obige Untersuchung ist bei meiner kleinen C64xs-Platine die Entscheidungsgrundlage für die Verwendung der HCT-Familie für diskrete Interface-Logik gewesen.

      Warum im C64R nun nahezu durchgängig die HC-Familie für Interface-Logik verwendet wurde, obwohl bei dieser Familie die Erkennung einer logischen 1 zu 100% erst bei höheren Pegeln spezifiziert ist, kann ich nicht sagen. Aufgrund obiger Untersuchung halte ich dies jedoch für nicht richtig.

      Bitte versteht mich nicht falsch: Die Pegel des 6510, 6526 und 6569 sind in über 99% der Fälle weit über den Mindestwerten und von daher wird der C64R auch funktionieren. Jedoch können ja auch externe Module den 6510 abschalten und von externer Seite den aktiven Part übernehmen und wenn diese sich am Rande der Spezifikation befinden, dann kann es auch zu Stabilitätsproblemen kommen. Oder Du hast einen 6510 in den Nullkraftsockel eingesetzt, der selbst nahe an den im Datenblatt genannten Mindestwerten arbeitet. Auch dann würde ich mich über mangelnde Stabilität nicht wundern.


      Jetzt seit ihr dran:
      Kramt die Datenblätter raus und versucht meine Beschreibungen zu verifizieren. Irgendwelche Fehler meinerseits? Vielleicht gibt es einen Aspekt, den ich nicht bedacht habe? Gibt es einen Grund, warum HC hier die bessere Wahl sein sollte? Ich würde mir wirklich wünschen, wenn jemand meine Feststellungen hier fundiert widerlegt!

      Bis dahin bleibe ich bei meiner Meinung: "Für diskrete Logik im C64xs ist die HC-Logikfamilie NICHT die richtige Wahl!"

      Gruß,
      Thomas
    • Freak schrieb:

      Irgendwelche Fehler meinerseits? Vielleicht gibt es einen Aspekt, den ich nicht bedacht habe?
      Nein, deine Analyse ist IMHO richtig.

      Gibt es einen Grund, warum HC hier die bessere Wahl sein sollte?
      Vielleicht war gerade ein grösserer Stapel HC-Chips der beötigten Typen im Lager, während HCT erst beschafft werden müsste?

      Quellcode

      1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
      2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
      3. 30 printint(rnd(1)*328)-217

      sd2iec Homepage
    • C64 Reloaded / Bugs / Auffälligkeiten

      Ich denke das ganze macht dynamisch einen größerern Unterschied als rein statisch. Ob das aber ins Gewicht fällt, weiß ich auch nicht. Der high-nach-low Wechsel geht bei NMOS Ausgängen recht fix, da aktiv nach low getrieben wird. Da wird der Unterschied in der Schaltschwelle wahrscheinlich keinen großen timingtechnischen Unterschied machen. Das kann beim langsameren low-nach-high Übergang schon anders aussehen. Ob das aber eine Auswirkung auf die Funktion hat, kann ich nicht sagen. Das müsste man mal messen, wieviele Nanosekunden das dann ausmacht.

      Als ich bei der Entwicklung des XA1541 Kabels mal solche Schaltflanken untersucht habe, konnte ich beim Durchschalten des Eingangstreibers sogar einen kleinen Spike im Signal entdecken :) Auf das entsprechende Equipment habe ich aber keinen Zugriff mehr.

      Gruß x1541
      Zuletzt repariert:
      21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
      19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
      27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!
    • Ich hätte noch eine andere Frage. Der Reloaded hat doch einen VSP Fix. Dann sollte doch dieses Tool fehlerfrei durchlaufen? csdb.dk/release/?id=120810
      Also ich habe meinen Reloaded nur einmal kurz aktiviert und jetzt wieder im Karton. Aber der Test lief bei mir damals nicht fehlerfrei durch.
      Hatte eine 6510 CPU, 8565R2 VIC-II und 8580R5 SID zum Testen. Mit original PLA.
    • @VSP: HOPPLA!

      Man beachte die Zeiten...

      Dachte erst, so what
      DSC_1854.jpg


      ... aber tatsächlich

      DSC_1845_foo_2.jpg

      ... und dann sogar noch

      DSC_1846_foo_2.jpg


      OK, is bei mir natürlich auch modded-beyond-repair, Stereo-in-SID, Super-PLA, ansonsten auch 6510 und 8565R2, 8701-Ersatz rausgeschmissen und wieder durch 8701 ersetzt.

      Gerade knapp vor 60:00 kamen auch 2 weitere (Line 3/6 und Line 6/7)


      Vorhin mal aus Jux Demo mit Safe "Channel" <- hätte er echt mal erklären können /o\ 1 keine Probleme... Ich lass es mal laufen, mal sehen, ob dann morgen noch n Channel safe is ^^

      PS: Natürlich VIC 10 Minuten warm werden lassen vorher, wie von lft befohlen
      PPS: Nach 90 Min nur noch 3 "safe channels"
      Es sind keine anzeigbaren Aktivitäten vorhanden.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von TheRyk ()

    • katarakt schrieb:

      Bin gespannt was wiesel dazu sagt. Ich denke er wird das sicherlich auch genau analysiert haben.
      Da gibt es nichts "genau" zu analysieren, denn die Schaltflanken im C64 haben extrem hohes Rauschen. Dieses Rauschen hat zur Folge, dass sich die Flanken temperaturanhängig um mehr als 40ns verschieben.

      Die Verschiebung durch Verwendung einer anderen Logikfamilie beläuft sich auf wenige Nanosekunden. Solange das Rauschen größer ist als die Verschiebung durch eine andere Schaltschwelle, gibt es weder messbare, noch spürbare Änderungen.

      Aus akademischer Sicht ist es zwar richtig, HCT zu wählen, aber in der Praxis ist es genau so sinnlos wie der Kauf eines 900-EUR-Digitalkabels, das angeblich "luftiger" klingen soll.

      Jens
      forum.icomp.de/ - Das offizielle iComp Supportforum ist online.
    • TheRyk schrieb:

      @VSP: HOPPLA!
      Das ist mit 8565R2 VIC bekannt, und ich bin mit einigen C64R-Kunden deswegen in Kontakt. Zwar kann ich "in Kürze" keine andere Lösung anbieten als einen 6569-VIC einzusetzen, aber ich denke, dass ich mit einer kleinen Zusatzplatine, welche in den GAL-Sockel gesteckt wird, ein so verändertes Timing erzeugen kann, dass auch der 8565R2 keine VSP-Probleme mehr verursacht.

      Der Fix wird auch dann kostenlos, wenn der C64R außerhalb der Garantiezeit ist.

      Jens
      forum.icomp.de/ - Das offizielle iComp Supportforum ist online.
    • Ace von Heisenberg schrieb:

      Wird es nochmal C64R zu kaufen geben oder war das jetzt eine einmalige Sache ?
      Ich werde das Design ein wenig überarbeiten, und ein komplett neues Design machen (sprich: Es wird zwei getrennte Produkte geben). Details dafür müssen aber noch geklärt werden - da sind noch ein paar Meetings angesetzt, Verträge zu unterzeichnen und andere Projekte "wegzuarbeiten". Ich denke, dass ich Genaueres im September veröffentlichen kann.

      Jens
      forum.icomp.de/ - Das offizielle iComp Supportforum ist online.
    • Wiesel schrieb:

      Ace von Heisenberg schrieb:

      Wird es nochmal C64R zu kaufen geben oder war das jetzt eine einmalige Sache ?
      Ich werde das Design ein wenig überarbeiten, und ein komplett neues Design machen (sprich: Es wird zwei getrennte Produkte geben). Details dafür müssen aber noch geklärt werden - da sind noch ein paar Meetings angesetzt, Verträge zu unterzeichnen und andere Projekte "wegzuarbeiten". Ich denke, dass ich Genaueres im September veröffentlichen kann.
      Jens

      Ja... dann werden wohl bald "veraltete" C64R zu gutem Preis in der Bucht verfügbar sein!
      PLAdvanced+ - The all in one PLA replacement!
      PLAdvancedA1060 - Amiga Sidecar A1060 replacement!
    • TheRyk schrieb:

      Auch wenn man dran gebastelt hat *duck* ?
      Es wird ein drop-in replacement für das GAL, also nichts mit "Board zurück schicken", sondern Fix-Platine anfordern, Paket erhalten, einbauen, fertig. Wenn man etwas kaputt macht, dann an der Fix-Platine, und höchst wahrscheinlich mechanisch. So ein Fall geht ohnehin nicht auf meine Kosten :)

      Jens
      forum.icomp.de/ - Das offizielle iComp Supportforum ist online.
    • Wiesel schrieb:

      Ace von Heisenberg schrieb:

      Wird es nochmal C64R zu kaufen geben oder war das jetzt eine einmalige Sache ?
      Ich werde das Design ein wenig überarbeiten, und ein komplett neues Design machen (sprich: Es wird zwei getrennte Produkte geben). Details dafür müssen aber noch geklärt werden - da sind noch ein paar Meetings angesetzt, Verträge zu unterzeichnen und andere Projekte "wegzuarbeiten". Ich denke, dass ich Genaueres im September veröffentlichen kann.
      Jens
      "Nur" neue Gehäuse, wäre doch langweilig. :)
      Schön zu hören.
      - CHECK64 - The C64/C128(D) Diagnostic Set -> zum Beitrag: CHECK64 | Manuals
      - Anfertigung von Kühlkörperklammern -> zum Beitrag: Kühlkörperklammern Info: Kein lästiges Kleben mehr
      - Veranstaltung Kölner-Retrotreff -> zur Homepage:
      koelner-retrotreff.de
    • Wiesel schrieb:

      Aus akademischer Sicht ist es zwar richtig, HCT zu wählen, aber in der Praxis ist es genau so sinnlos wie der Kauf eines 900-EUR-Digitalkabels, das angeblich "luftiger" klingen soll.
      Dass ein 900-EUR-Digitalkabel sinnlos ist bestreitet hier niemand.

      Dass man Vorgaben für korrektes elektrotechnisches Design wider besseren Wissens ignoriert, irritiert mich jedoch sehr. Hast Du meinen Text vollständig gelesen? Die von Dir beschriebene "Sinnlosigkeit" des Einsetzens von HCT-Bauteilen erspart "in der Praxis" Dir und jedem Käufer gegebenfalls auftretende sporadische Fehlfunktionen und sichert uns allen eine 100%ige Funktion der Schaltung. Ich lese aber mit Verwunderung aus obiger Antwort, dass Du kein Interesse daran hast ...

      Wobei Du Dir selbst wohl nicht ganz sicher scheinst: U13 und U25 sind ja bereits von Dir selbst als HCT ausgeführt worden. Die Logikfamilie ändert man gegenüber der Schaltplanvorgabe nicht grundlos. Lief vielleicht ein Prototyp mit Adressmultiplexern in HCT stabiler als in HC? Das würde zumindest diese Änderung erklären. Kostentechnisch kann es ja bei einer so geringen Stückzahl von Geräten kein relevanter Faktor sein.

      Vielen Dank für den Einblick in Deine Entwicklungsprinzipien.

      Gruß,
      Thomas

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Freak ()

    • Freak schrieb:

      Dass man Vorgaben für korrektes elektrotechnisches Design wider besseren Wissens ignoriert, irritiert mich jedoch sehr.
      Nana, jetzt haut Euch mal nicht die Köppe ein. Was ich aus Wiesels Post lese ist, dass er Dir zustimmt, aber seiner Ansicht nach das Rauschen auf den Signalen größer ist als die Auswirkung von HC vs HCT. Hört sich jetzt gar nicht so konträr an.

      Der Vergleich mit dem Digitalkabel hinkt allerdings m.E., weil er die Argumentation (ungewollt?) in eine unwissenschaftliche Ecke stellt.
      ────────────────────────────────────────────────────────────
      Time of Silence - Time of Silence 2 Development Blog
      ────────────────────────────────────────────────────────────
    • Benutzer online 1

      1 Besucher