Hallo Besucher, der Thread wurde 136k mal aufgerufen und enthält 994 Antworten

letzter Beitrag von MiCv2 am

The Final Chesscard (Hardware)

  • ich habe ihn aufgrund der Einfachheit direkt ohne Schaltplan im Layouteditor von KiCAD gezeichnet.

    Ach, schaut ihn euch doch einfach selbst an...



    Gruß

    Thomas

  • Freak , danke dir für die Pinbelegung,

    bis auf den Widerstand habe ich den Adapter auch so aufgebaut.

    Ich habe gerade eine zweite Karte zusammen gebaut.

    Mit einem anderen RAM IS62C256AL-45TLI.

    Erste Tests sehen gut aus , Demo Mode funktioniert, und ich hab auch schon verloren :thumbdown:


    Ich werde mir die erste Karte jetzt nochmal genau anschauen. Vielleicht doch irgendwo eine nicht ganz perfekte Verbindung.

  • Freak , danke dir für die Pinbelegung,

    bis auf den Widerstand habe ich den Adapter auch so aufgebaut.

    Ist doch okay. Wie gesagt, der Widerstand ist nur zur Sicherheit. Das Flasher-Programm läuft aber stabil und setzt PB7 niemals auf Ausgang. Insofern kannst Du den Widerstand bei fliegender Verdrahtung auch weglassen...


    Ich habe gerade eine zweite Karte zusammen gebaut.

    Mit einem anderen RAM IS62C256AL-45TLI.

    Erste Tests sehen gut aus , Demo Mode funktioniert, und ich hab auch schon verloren :thumbdown:


    Ich werde mir die erste Karte jetzt nochmal genau anschauen. Vielleicht doch irgendwo eine nicht ganz perfekte Verbindung.

    Beachte bitte, dass das Battery-Management-IC TPS3613 auch die /CE-Leitung vom RAM beeinflusst. Normalerweise leitet es /RAM_SEL einfach durch, welches sich dann in /RAM_CE widerspiegelt. Wenn dieser Schaltungsteil nicht korrekt arbeitet (vielleicht wegen Unterspannung, oder wegen falscher R6/R7-Kombination), dann wird /RAM_CE auf High gehalten und das RAM nicht selektiert, was zu falschen Werten beim Lesen oder Schreiben führen kann...


    Ich habe auch keine Anhaltspunkte gefunden, warum mein gewählter Ersatztyp nicht funktionieren sollte. Zusätzlich, um meinen Kopf da mal aus der Schlinge zu ziehen:



    Man beachte den roten eingekreisten Text: "Voll kompatibel mit allen 3,3V- und 5V-Produkten der Konkurrenz."


    Gruß

    Thomas

  • Ein Copyrigth gilt auch nicht für immer

    Korrekt - aber die zur Zeit gültigen Fristen sind so lang, dass man das Ablaufen eines Copyrights eines Werks erlebt, welches während der eigenen Lebenszeit erschienen ist. Je nach genauer Situation liegt die Länge IIRC im Augenblick bei 95, 120 oder "Lebensende des Autors plus 70" Jahren. Die Rechteverwerter-Industrie argumentiert natürlich stets, dass diese Fristen zu kurz wären.


    bin mir nicht ob es mit technischen Patenten gleichzusetzen ist in diesem Fall

    Patente sind zwar auch Rechte an geistigem Eigentum, aber eine andere Art und unterliegen anderen Fristen. Software unterliegt dem Copyright, nicht dem Patentschutz - auch wenn Software verwendet werden kann, um mit einem Patent geschützte Ideen umzusetzen.


    korrigiert mich wenn ich mich irre

    [x] Done.

  • eachte bitte, dass das Battery-Management-IC TPS3613 auch die /CE-Leitung vom RAM beeinflusst. Normalerweise leitet es /RAM_SEL einfach durch, welches sich dann in /RAM_CE widerspiegelt. Wenn dieser Schaltungsteil nicht korrekt arbeitet (vielleicht wegen Unterspannung, oder wegen falscher R6/R7-Kombination), dann wird /RAM_CE auf High gehalten und das RAM nicht selektiert, was zu falschen Werten beim Lesen oder Schreiben führen kann...

    Das werde ich mal versuchen irgendwie zu messen.



    Ich habe auch keine Anhaltspunkte gefunden, warum mein gewählter Ersatztyp nicht funktionieren sollte. Zusätzlich, um meinen Kopf da mal aus der Schlinge zu ziehen:

    Ich auch nicht,

  • Hallo,


    rund vier Jahre nachdem ich einige FCC64-Module gebaut habe, will rafi sich ebenfalls ein Modul bauen, verwendet dafür aber ein anderes RAM, mit dem das Modul offensichtlich nicht arbeiten möchte... :(


    Ich habe mir daraufhin nochmal meine Schaltung genau angeschaut und bin dabei auf eine Unregelmäßigkeit gestoßen, die vielleicht als Ursache identifiziert werden könnte:


    * In einem normalen 6502-System geht der CPU-Takt zu Phi0 rein und das gesamte Timing (z.B. Schreibzugriffe beim RAM) werden auf PHI2 referenziert, welcher ein Ausgang ist.

    * Ich habe es beim FCC64-Modul ähnlich gemacht: Der CPU-Takt geht bei PHI2-In rein und ich verwende für RAM-Schreibzugriffe PHI2-Out.

    * Im Demoboard von WDC wird es aber anders gehandhabt: Dort geht der CPU-Takt ebenfalls bei PHI2-In rein, dasselbe Taktsignal wird aber auch gleichzeitig für die RAM-Schreibzugriffe verwendet.


    Die Phasenverschiebung zwischen PHI2-In und PHI2-Out sind in alten Datenblättern mit bis zu 22ns spezifiziert, was durchaus problematisch werden könnte. In neuen Datenblättern wird nichts mehr angegeben und von einer Verwendung des PHI2-Out-Signals indirekt abgeraten.


    Ich dachte nun, dass man dieses Problem leicht lösen kann, indem ich die Verbindung zu PHI2-Out löse und einfach stattdessen PHI2-In verwende. Also pflugs Leiterbahn aufgekratzt und neue Drahtbrücke verlegt.



    Aber auch wenn statt PHI2-Out jetzt PHI2-In verwendet wird, exakt so wie im WDC-Demoboard, dann funktioniert irgendwas nicht korrekt. Jedenfalls bekomme ich keinen Zugriff mehr auf das FCC-65C02-Subsystem. Stattdessen gibt es nach dem Einschalten nur einen schwarzen Bildschirm mit weißen Streifen, der anzeigt, dass die Kommunikation zwischen C64 und FCC-65C02-Subsystem nicht funktioniert.


    Für mich heißt das aber wohl: Wieder zurück an die Werkbank!


    Aber wo liegt jetzt der Fehler? Leider hat das FCC-65C02-Subsystem keine Möglichkeit zur Ausgabe eines Debug-Signals. Die einzige Schnittstelle ist das Transfer-Register, von dem ich aktuell nicht weiß, ob es korrekt arbeitet.


    Ich werde mich wohl am Wochenende nochmal vor das Scope setzen und mir Signale und deren Timing anschauen, um hoffentlich diesem Fehler auf die Schliche zu kommen. Ich habe nämlich immer noch den Anspruch, dass die Schaltung mit allen kompatiblen RAMs korrekt arbeiten muss.



    Vielleicht ist dann nach vier Jahren ein Schaltungs- und Layoutupdate fällig. Dann wäre aber auch mal Zeit für ein Monitorprogramm, damit man das FCC-65C02-Subsystem mal für andere Dinge nutzen kann. Denn dann könnte man sie auch ohne Copyrightprobleme einfach als Co-Prozessor-Modul verkaufen...


    Aber jetzt erstmal wieder mein umgelötetes FCC64-Modul zum Laufen bekommen...



    Gruß

    Thomas

  • Ich denke, das hängt mit dem Wert von T_DHW aus dem Datenblatt des WDC65C02 und T_HW aus dem Datenblatt des 6502 zusammen. Beim 6502 sind es mindestens 30ns, weil beim WDC65C02 wir über 10ns sprechen. Das bedeutet, dass nach dem Abfallen von PHI2 der Datenbus nur 10ns lang stabil bleibt. Dient ohne zweifel dazu, höhere Taktraten zu ermöglichen.


    Wenn 10ns für das SRAM zu wenig sind, dann kann es sinnvoll sein, PHI0 zu verwenden, da der Datenbus schon lange stabil ist, bevor PHI2 abfallt. Das darf man aber nur bei einer Schreibaktion machen, denn bei einer Leseaktion liest die CPU den Bus zum Zeitpunkt des Abfalls von PHI2. Der SRAM darf also erst danach seine Ausgänge abschalten.


    Dies sieht für mich nach etwas komplexeren Logik aus, die nicht nur mit einem Drahtchen erreicht werden kann?

  • Dies sieht für mich nach etwas komplexeren Logik aus, die nicht nur mit einem Drahtchen erreicht werden kann?

    Ziel war ja erstmal, PHI2-In als direkten Ersatz für PHI2-Out zu verwenden, also nur ein Signal ersetzen. Dafür reicht eine kurze Drahtbrücke durchaus aus. Die komplexere Logik für die Ansteuerung des SRAM sitzt ja im CPLD (,wo das PHI2-In-Signal hingeht).


    Gruß

    Thomas

  • ohje das hört sich für mich jetzt alles sehr kompliziert an und eigentlich versteht ich da nur Bahnhof.


    Und das alles nur weil das original RAM so nicht mehr lieferbar ist.


    Allerdings habe ich ja wie schon geschrieben mit einem anderen RAM Erfolg gehabt, habe das gleiche jetzt noch mal

    bestellt und werde eine bis dato nicht funktionierende Karte umbauen.

    Wenn es dann auch funktioniert sollte sich die Spezialisten evtl. mal die Datenblätter anschauen.

    Wo da der entscheidende Unterschied liegt.

  • Gerade den Alliance RAM gegen den ISSI getauscht.

    Demo Mode funktioniert, Spielen zumindest im 5MHz Mode funktioniert auch.

    Weitere Test hab ich bisher noch nicht gemacht.


    Also definitiv ein RAM Problem, (Timing?)


    Das ISSI hat 45ns das Alliance 55ns . Aber das müssten andere klären, da bin ich leider raus.

    jedoch werde ich den RAM für die restlichen Karten nachbestellen.

  • Ja, ich bin weitergekommen. Ich Testreihen am Laufen, wie das Programm reagiert, wenn ich die Werte direkt in die Bank 4 schreibe, wo sich der Code für die zweite CPU befindet.

    Gibt's hier irgendwelche Neuigkeiten bezüglich "Final Chesscard" mit SCPU Unterstützung, statt dem eigenen 5MHz Prozessor?

  • Nur wenn die Rechenkapazität grösser wird kommt doch kein anderer Schachzug dabei heraus, oder irre ich mich?

    Wenn man die Zeit pro Zug begrenzt könnte eine schnellere CPU in der gleichen Zeit mehr Züge durchrechnen, was vermutlich die Spielstärke erhöht. Es gab wohl für 65C02-basierte Schachcomputer eine Box namens TurboKit, welche einen diskret nachgebauten 65C02 mit bis zu 18MHz Takt enthielt, um deren Spielstärke zu erhöhen.

  • Erstens das was "Unseen" schon schrieb und ausserdem würde die Chesscard dann nicht nur im M.A.M.E., sondern auch auf denjenigen C64 Emus laufen, welche die SCPU unterstützen, also etwa im Denise und im VICE, was ja auch toll wäre.



    ja ist klar, aber dazu müsste man doch die FinalChessCard Software umprogrammieren ... was hier bestimmt keiner machen will.

    Da ist doch Stephan Scheuer schon drüber seit einiger Zeit, deshalb hatte ich ja nachgefragt. Die Idee dass das überhaupt funktioniert, stammte ja von ihm und wenn das wirklich hinhauen würde, wäre das schon eine faszinierende Sache.