C64 Reloaded / Bugs / Auffälligkeiten

Es gibt 393 Antworten in diesem Thema, welches 96.839 mal aufgerufen wurde. Der letzte Beitrag (5. Oktober 2023 um 10:38) ist von tulan.

  • 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 Bitte melde dich an, um diesen Link zu sehen. 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:
    Bitte melde dich an, um diesen Anhang zu sehen.

    Das "C64 Reloaded"-Board
    Bitte melde dich an, um diesen Anhang zu sehen.

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

    Bitte melde dich an, um diesen Anhang zu sehen.


    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

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Irgendwelche Fehler meinerseits? Vielleicht gibt es einen Aspekt, den ich nicht bedacht habe?

    Nein, deine Analyse ist IMHO richtig.

    Zitat

    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?

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Danke freak für die mehr als interessante analyse. Ich kenne mich damit nicht aus aber finde es überaus interessant. Bin gespannt was wiesel dazu sagt. Ich denke er wird das sicherlich auch genau analysiert haben.

  • 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

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Ich hätte noch eine andere Frage. Der Reloaded hat doch einen VSP Fix. Dann sollte doch dieses Tool fehlerfrei durchlaufen? Bitte melde dich an, um diesen Link zu sehen.
    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.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • @VSP: HOPPLA!

    Man beachte die Zeiten...

    Dachte erst, so what
    Bitte melde dich an, um diesen Anhang zu sehen.


    ... aber tatsächlich

    Bitte melde dich an, um diesen Anhang zu sehen.

    ... und dann sogar noch

    Bitte melde dich an, um diesen Anhang zu sehen.


    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.

    2 Mal editiert, zuletzt von TheRyk (24. August 2016 um 01:51)

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Wird es nochmal C64R zu kaufen geben oder war das jetzt eine einmalige Sache ?

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

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

  • Ein C64 Reloaded Reloaded wäre in der Tat super! :)

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

    Auch wenn man dran gebastelt hat *duck* ?

    Jedenfalls danke für die Info, gelegentlich mach ich mal n Test mit old VIC

  • 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 :smile:

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

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

    - WiC64 - The Commodore 64 Wireless Interface -> Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    - CHECK64 - The C64/C128(D) Diagnostic Set -> zum Beitrag: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    - Anfertigung von Kühlkörperklammern -> zum Beitrag: Bitte melde dich an, um diesen Link zu sehen. Info: Kein lästiges Kleben mehr
    - Veranstaltung Kölner-Retrotreff -> zur Homepage: Bitte melde dich an, um diesen Link zu sehen.

  • Bitte melde dich an, um diesen Link zu sehen.
    Wird die Info bei Fertigstellung des "drop-in replacement für das GAL", auf deiner Homepage veröffentlich?

  • 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

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von Freak (24. August 2016 um 14:14)

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

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────