Posts by 0xdeadbeef

    Also ich habe bei JLCPCB bestellt.

    Wenn ich dort das ZIP-Archiv mit den Gerber-Dateien hochlade, erkennt er die Größe automatisch. Es dauert nur ewig bei so einem großen und komplexen Board. Hängt ewig bei 96%. Da muß man etwas Geduld haben.

    Außerdem zeigt er mir dieses große Board dann am Ende nicht sofort an. Stattdessen kommt nach ein paar Minuten die Meldung "Success,this file has been saved to your File Manager". Wobei "File Manager" ein Link ist. Wenn man darauf klickt kommt man in den File Manager, wo man dann das hochgeladene Board auswählen kann. Und dann wird die Größe gleich richtig angezeigt:


    Ansonsten habe ich bei meiner Bestellung bloß die Farbe geändert, ENIG ausgwählt und "Gold Fingers" und "45°finger chamfered" ausgewählt.

    Also heute war nicht mein Tag. Eigentlich wollte ich nur kurz mein "PiggyRom" austesten, also die Platine, um originale ROMs zu benutzen, wenn man Sockel für die EEPROMs bestückt hat. Die gute Nachricht zuerst: der Adapter funktioniert sowohl für die 64kBit-ROMs als auch für das 32kBit-ROM. Durch die Adreßjumper über den Sockeln ist das Raushebeln der EEROMs allerdings sehr frickelig. Beim Character-ROM bin ich dann irgendwie mit dem Schraubenzieher abgerutscht und habe in einem unnachahmlichen Mißgeschick die Datenleitung D0 unter dem Sockel durchtrennt. Um auch nur einen Reparaturversuch zu unternehmen, mußte ich den Sockel auslöten. OK, war ungeduldig und habe ihn durchgeknipst und nur die eine Seite ausgelötet. Das lief alles andere als gut. Irgendwie war die Lötspitze meiner Entlötstation verstopft. War ein riesiges Gefrickel, den Sockel rauszubekommen und ich war sehr ungeduldig. Das Flicken der Datenleitung war eine absolute Katastrophe. Es war vielleicht ein halber Millimeter unterbrochen, aber es ist mir ums Verrecken nicht gelungen, diesen winzigen Spalt nur mit Lötzinn zu überbrücken. Es ging einfach ums Verrecken nicht. Also mußte ich ein sehr kurzes Stück Draht drauflöten. Auch das lief wie erwartet wirklich schlecht.

    Zu diesem Zeitpunkt war ich bereits völlig am Ende. Hatte nichts zu Mittag gegessen, war sauer auf mich selbst usw. Also nur ein kurzer Test, ob der Dead-Test jetzt wieder läuft. Tat er nicht. Weitere Leitungen durchgemessen: beim Auslöten des Sockels habe ich anscheinend irgendwie die Durchkontaktierung der Datenleitung für Bit3 beschädigt. Ist normal kein Thema, weil dann der Pin des Sockels die Durchkontaktierung ist. Habe alles versucht, aber auch mit eingelöteten Sockel war nichts zu machen. Also mußte ich auch hier ein Stück Leiterbahn freikratzen und mehr oder weniger mit dem Sockel verlöten. Auch das lief fast unglaublich schlecht. Irgendwie wollte das Lötzinn heute absolut nicht das das machen, was ich von ihm wollte.

    Oh, Mann. Das wäre echt nicht notwendig gewesen...


    [EDIT]

    Das PiggyROM hat jetzt auch ein eigenes Repository.

    Also passiv kann man nur "mithören", wenn intern ein kompletter Scan läuft (also alle Pins von PortA zyklisch einzeln durchgeschaltet werden). Mit dem Kernal-Scan ist das auf jeden Fall möglich. Bei Spielen und Demos halt nicht unbedingt.

    Und einen aktiven Scan würde ich grundsätzlich nur zusammen mit Restore o.ä. machen. Also Restore gedrückt halten und eine Funktionstaste drücken, um den Kernal umzuschalten o.ä. Damit stört man den internen Scan wenn überhaupt nur während dieser kurzen Phase und das sollte in aller Regel kein Drama sein.

    Wenn man die Verbindung zwischen Tastatur und CIA per Analogschalter auftrennt (entweder alle 16 Leitungen, um ganz sicher zu gehen oder zumindest die von PortA für eine >90% Abdeckung), können keine falschen Tasten vom internen Scan erkannt werden. Er kann lediglich gerade gedrückte Tasten kurz nicht mehr erkennen. Aber in dem Szenario "Restore+Taste->Umschaltung" sollten ja eh keine anderen Tasten dauerhaft gedrückt sein.

    Und selbst wenn man Leitungen von PortA selber gegen Masse zieht, sollte es möglich sein, daß Timing so anzupassen, daß das den internen Scan nicht oder zumindest so wenig wie möglich stört.

    Ich liebäugel ja auch mit so einer Replica... Dann aber ein 250469, oder ein MK2.

    Mein Board ist aber weder eine Replica noch eine komplett modernisierte Version wie das MK2. Ziel war es ja, ein optimiertes 250466 zu bauen, das alle Vorzüge des Originalboards hat (alte PLA, separates Farb-RAM usw.), aber neben der vereinfachten Versorgung über 12V halt auch den Betrieb von HMOS-VIC/SID erlaubt, die CIAs besser schützt und ein paar Erweiterungen (Dual-SID, Joystickumschalter, Kernal-Umschaltung, EEPROMs onboard) mitbringt, ohne dabei Kabelsalat im Gehäuse zu haben.

    Bei den Tiny und Atmega kann man interene Pullups setzen. Pull Down gibts da nicht.

    Das heißt wenn ich den setze kann ich ohne Probleme auf L abfragen, da ich ja ohne L ein definiertes H Signal habe.

    Ist bei der Tastaturmatrix dann ja Blödsinn, da ich über PB0 vom CIA das definierte H Signal habe. und auf L abfrage, da L vom PA0 kommt und über Taste durchgeschaltet wird. Richtig ? 🤔

    Hm. Also wie gesagt würde ich davon abraten, die Pull-Ups zu setzen, wenn Du passiv scannen willst. Vermutlich ist es schnurz, weil das üblicherweise Ströme im Bereich von 20µA oder so sind, aber es besteht auch keinerlei Notwendigkeit, weil der CIA ja interne Pull-Ups hat. Das sieht man ja daran, daß im Datenregister eines auf Eingang konfigurierter PortB immer "0xff" steht (also alles Einsen).

    Und einen Low-Pegel an PortB kann es beim Keyscan des Kernals nur geben, wenn ein Pin von PortA gerade gegen Masse geschaltet ist und gleichzeitig eine Taste in der entsprechenden Spalte die Verbindung zur einer Zeile an PortB herstellt.

    Schon Chic... aber zuviel Arbeit!

    Ich hatte ja schon erwähnt, daß der Aufbau (ohne das Besorgen der Teile oder gar das Auslöten von CIAs usw. aus anderen Boards) schon eine Menge Arbeit ist. Ich habe letzte Woche jeden Tag sicher drei Stunden oder mehr darin versenkt. Es ist ja auch nicht nur das Löten, man muß man auch die richtigen Werte raussuchen, eventuell nochmal messen (Reichelt hat mir auch wieder falsche Teile eingepackt, als ist Vorsicht besser als Nachsicht). Man kann das nicht schönreden: das macht man nicht eben mal an einem langen Winterabend.

    0xdeadbeef : Du hast ja alle Dateien hochgeladen... könnte man damit ein eigenes PCB bestellen, egal ob es funktioniert oder nicht? Oder fehlt da noch etwas ?

    Also die Gerberdateien im Archiv sind die, die ich für meine Bestellung benutzt habe. Bei meinen Tests habe ich keine katastrophalen Fehler gefunden. Aber ein paar Kleinigkeiten schon, die ich ja weiter vorne benannt habe. Wenn Du also noch etwas Zeit hast, könntest Du darauf warten, daß ich nochmal ein paar Sachen überarbeite. Aber wie erwähnt werde ich mir selber diese potentielle Version 1.1 erstmal nicht bestellen, weil die bisherige ja soweit tut. Und einen festen Termin kann ich für die V1.1 auch nicht nennen.


    Ansonsten habe ich die mechanischen Tests abgeschlossen. Dazu ein paar Bilder. Provisorische Tastatur aus meinen echten 250466er. Keycaps und so.


    Die gute Nachricht ist, daß das Board in jeder Hinsicht in ein C64C-Gehäuse paßt. Bei diesem Gehäuse ist nur die Schraube rechts oben etwas daneben. Geht aber noch. Beim Gehäuse meines originalen 250466er Board waren es eher die beiden unteren Schrauben links und rechts. Ich fürchte, da gibt es (wie ja auch schon von anderen Forenmitgliedern erwähnt) gewisse Variationen und Toleranzen.


    Das einzige echte mechanische Problem ist, daß die Metalltastaturhalter von iComp nicht perfekt passen. Auf der linken Seite ist halt in einem Longboard kein Loch an der gewünschten Stelle, also sitzt der Halter etwas wacklig und wird nur vom Board selber festgehalten. Das ist aber kein Problem speziell meines Boards. Auf der rechten Seite sind aber die Widerstände R6, R8 und R12 dem Tastaturhalter im Weg, also mußte ich da ein ordentliches Stück aus dem Halter rausdremeln. Das ging ehrlich gesagt besser als erwartet, also würde ich das nicht als ernsthaftes Problem einstufen. Man könnte sicherlich auch ein 3D-Modell entsprechend modifizieren. Das wäre aber ebenfalls ein Punkt, den ich nochmal für eine V1.1 prüfen könnte. Bin mir aber noch nicht sicher, ob da genug Platz ist.


    Mit den genannten kleineren Einschränkungen betrachte ich V1.0 also insgesamt als ziemlichen überwältigenden Erfolg. Insbesondere die Joystickumschaltung und der zweite SID im Stereo- und Dual-Mono-Modus funktionieren wie erwartet. Der Lumafix funktioniert so gut und so schlecht wie andere auch, die Bildqualität ist ziemlich gut und mechanisch paßt es auch. Die TOD-Schaltung und die 9VAC-Schaltung hatte ich ja schon vorher getestet und unverändert übernommen. Aber echte Lasten zum Testen (EPROM-Programmiergerät o.ä.) habe ich halt nicht. Ich habe zwar eine echte Datasette aufgetrieben, aber habe keine Kassetten dafür, also kann ich auch diesen Teil nicht wirklich explizit testen. Aber die Schaltung ist 1:1 aus dem Original übernommen und das Diagnosemodul testet den Kassettenanschluß ja auch, nur halt ohne echte Last. Da rechne ich jetzt eigentlich nicht mit Problemen.

    Wie wirksam die ganzen Schutzdioden sind will und kann ich nicht testen, aber gerade bei den Joystickports sollte dieses Board schon deutlich toleranter gegen ESD sein also alle originalen Boards.


    Und nur um das mal erwähnt zu haben: mit dem 1.5A-5V-Wandler sollte das Board für alle normalen Lastsituationen gut gerüstet sein, aber bei exotischen Konfigurationen (LED-Keyboard, SuperCPU, Quad-Expander) kann man nicht einfach ein dickeres Netzteil benutzen, sondern müßte sich einen dickeren DC/DC-Wandler suchen und per Adapterplatine o.ä. anstelle des Recom-Wandler einbauen. Leider kann ich den Strom auf der 5V-Schiene nicht direkt messen. Weiter oben hatte ich ja geschrieben, daß ich mit einem U2+ und zwei SIDs ungefähr 610mA und ohne U2+ ungefähr 510mA aus dem 12V-Netzteil ziehe. Ich schätze, daß davon etwa 150mA für die 9V und 12V-Schiene draufgehen, also würden mit einem U2+ 470mA aus 12V gezogen, um damit die 5V-Schiene zu speisen. Als grobe Schätzung wäre das bei einem Wirkungsgrad von 90% bereits ca. 1A (470ma*12/5*0.9 = 1015mA). Es sollten also noch 500mA Luft sein auf der 5V-Schiene bzw. vermutlich ~700mA ohne U2+.
    Und naja, mit stromsparenderen Ersatz-SIDs und/oder einer stromsparenderen Ersatz-PLA kann man noch was einsparen.

    was heißt ohne Pull Device ? 🤔

    Meinst du keine interne Pull up Widerstande setzrn ?

    Habe schon seit zwanzig Jahren nichts mit mit Atmels gemacht, aber normalerweise kann man bei den meisten Mikrocontrollers Pull-Ups oder Pull-Downs konfigurieren, die aber im engeren Sinne keine echten Widerstände sind. Üblicherweise sind das sehr schwache Stromsenken/-quellen, aber sicherheitshalber sollte man sie trotzdem deaktivieren, damit sie den internen Keyscan o.ä. nicht stören können.

    Also wenn Du die Pins am ATMega auf Eingang ohne Pull Device konfigurierst, sehe ich da eigentlich keine Probleme. Das plane ich bei meinem Projekt auch so zu machen. Also nicht mit einem Atmel, aber direkt Eingangspins eines Mikrocontrollers an die CIA-Pins anschließen.

    Ich glaube nicht, daß an dieser Stelle jemals jemand eine galvanische Trennung gemacht hat oder daß die nötig wäre. Der CIA ist ja nicht aus Zucker. Er hat halt nur wie die ganzen ICs aus dieser Zeit keine integrierten Klemmdioden und ist deshalb anfällig für elektrostatische Spannungen.


    Wie gesagt habe ich sogar vor, einen Schritt weiterzugehen und PA0 aktiv gegen Masse zu ziehen, damit ich in fast jeder Situation die Tasten in der Spalte PA0 scannen kann.

    Dir sollte aber klar sein, daß die Phasen, in denen PortA während des Scannens ein bestimmtes Bitmuster hat, nicht wahnsinnig lang sind. Habe das nicht ausgemessen, aber ich fürchte, daß das u.U. nur ein paar Dutzend (?) Mikrosekunden sind.

    wenn das in einem Interrupthandler passieren soll, müßte der schon auf der höchsten Priorität laufen und nichts machen, als die Werte wegzuschreiben.

    Also wenn Dich nur der Keyscan des Kernals interessiert und nur die Spalte PA0, wäre es vermutlich tatsächlich eine Lösung, zum Beispiel PA0 und PB4 per ODER zu verknüpfen und auf eine Null am Ausgang zu reagieren. Das mit dem Optokoppler usw. halte ich allerdings für etwas übertrieben.

    Mit einem entsprechenden Mikrocontroller könnte man sicherlich auch einen DMA-Transfer eines ganzen IO-Ports (der mit PortB verbunden ist) an einer fallenden Flanke von PA0 triggern. Aber wie gesagt: in Spielen usw. könnte es mit diesem Ansatz zu Reaktionen auf falsche Tasten kommen.

    Wie genau macht es denn das Kernal ?

    Bei PA0 die Bits nacheinander auf HIGH ?

    und bei PB0 auf 1 abfragen ?

    oder wird auf 0 abgefragt ? Also all PAO die Bits nacheinander auf 0 ?

    Ich hab irgendwo gelesen, das auf 1 abgefragt wird. Stimmt das ?

    Der Keyscan des Kernals passiert im IRQ. PortA wird auf Ausgang und PortB auf Eingang konfiguriert, dann wird eine Null durch PortA geschoben und PortB nach jedem Schritt geprüft.

    Die Ausgänge der CIAs können nur gegen Masse schalten (0). Im ausgeschalteten Zustand (1) wird der Pegel von einem Pullup hochgezogen. Wenn man eine Null auf PAx schreibt und eine Taste in dieser Spalte gedrückt ist, wird das entsprechende Bit PBx zu 0.

    Am Ende des Keyscans wird wie vorher beschrieben eine 0x7f nach PortA geschrieben. Damit ist nur PA7 low und nur Tasten in dieser Spalte können erkannt werden.


    Ich denke, das hier müßte der relevante Ausschnitt des Kernal-Keyscans sein:

    Gibt es einen Grund, warum das gemacht wird?

    Ich habe ja die Spiele ja nicht tiefgehend analysiert, sondern mit nur kurz bei einem Dutzend Spielen oder so die Werte der Port-Register zwischen zwei IRQs angeschaut. Ich vermute aber mal, daß das halt der Wert ist, der am Ende des Keyscans des Spiels im Datenregister von Port A stand und man ihn so stehen gelassen hat. Im Kernal wird die 0x7f am Ende des Keyscans explizit auf PortA geschrieben, um die Abfrage der Stop-Taste auch außerhalb des eigentlichen Keyscans zu ermöglichen oder sowas in der Art. Das ist in diesem Fall also wohl kein zufälliger Wert.


    Man könnte sich auch vorstellen, daß man mit einer 0 in PortA ohne expliziten Keyscan sehen kann, ob irgendeine Taste gedrückt wurde (PortB != 0xff). Also könnte man den Wert zyklisch abfragen und bei Bedarf (irgendeine Taste wurde gedrückt), einen expliziten Keyscan starten.

    Was genau der Grund dafür bei den Lucasfilm-Adventures ist, kann ich aber nicht sagen. Andere Spiele von Lucasfilm verhalten sich wieder etwas anders:


    The Eidolon

    Port A: df DDR: ff

    Port B: ff DDR: 00


    Koronis Rift

    Port A: ff DDR: ff

    Port B: ff DDR: 00

    Na ja, den Speicher prüft ja auch das Diagnosemodul bzw. der Dead-Test und der Sinus ist vermutlich im wesentlichen ein Tabellenzugriff, was wohl eher nicht viel zusätzliche Testtiefe bringt.

    Ich suche halt sowas wie einen Streßtest, der möglichst viel (kritisches) Zeug gleichzeitig macht und idealerweise zumindest bei einigen Fehlern irgendwelche Zähler hochzählt oder von mir aus auch abstürzt.

    Also schon so in der Art von VSPLab oder Diagnosemodul, nur halt kombiniert und eventuell noch mit Sprites usw.


    Was weitere Experimente mit anderen IC-Typen angeht: da ist meine Geduld erstmal am Ende. Ich denke, ich werde ("aus Gründen") den HTC373 wieder gegen einen LS373 tauschen. Also offiziell, de fakto habe ich da gerade eh schon wieder einen LS373 verbaut. Durch den Zeit-/Wärmefaktor ist die Testerei halt allgemein nicht so richtig spaßig. Und ehrlich gesagt hatte ich inzwischen so viele Einzelbestellungen bei Reichelt und Co, daß ich mir alleine vom Porto was Schönes hätte kaufen könnten. Von den ganzen ICs. die ich dann doch nicht benutzen konnte/wollte, fangen wir erst gar nicht an. Glücklicherweise habe ich nie Buch über die Kosten geführt.

    Tatsächlich habe ich mal irgendwo gelesen, daß ein Spiel bzw. dessen Kopierschutz mit einer emulierten 1541 angeblich nicht richtig funktioniert hat, weil dort das Herunterrampen der Drehzahl beim Abschalten des Motors nicht entsprechend nachgebildet war. Oder so. Kann mich weder an Details erinnern, noch wo ich das aufgeschnappt habe.


    So oder so sind Demos mit mehreren Disks, bei denen ich auf Grafikfehler achten soll, nicht unbedingt das, was ich zum Testen suche. Am besten sind selbstlaufende Tests/Demos/Spiele, die ich ein 1-2 Stunden nebenher laufen lassen kann um zu sehen, ob sie dabei abstürzen oder nicht.

    Nochmal zur Verdeutlichung: es gibt Spiele, bei denen der gesamte PortA die meiste Zeit (zwischen den IRQs) auf Masse gezogen ist. Zum Beispiel Zak McKracken / Maniac Mansion:

    Port A: 00 DDR: ff

    Port B: ff DDR: 00

    Zwar ist auch hier wie üblich PortA auf Ausgang konfiguriert (DDR=0xff) und PortB auf Eingang (DDR=0x00). Allerdings sind alle Datenbits von Port auf 0 gesetzt, also sind alle Leitungen von PortA auf Masse gezogen. In diesem Zustand kann man eine Taste nicht mehr eindeutig identifizieren. Wenn also PB4 in diesem Zustand ebenfalls low ist, kann das von F1 (PA0), aber auch Z, C, B, M, ".", ShiftRight oder Space kommen.