Tester für realPLA gesucht

Jetzt hab ich übrigens auch einen 8700R1 gefunden.

So, die Tests sind soweit fertig. neuRomancer, Pentagon und Fierman aus den Niederlanden waren so nett, das realPLA in jeweils mehreren Exemplaren der Platinenrevisionen KU14194HB, 250407, 250466 und 250425 getestet. Insgesamt sind fast 20 Rechner mit verschiedenen Erweiterungen wie 1541U, Nordic Replay, EasyFlash3 und Chameleon sowie KERNAL-Umschaltplatinen.

Alle Rechner bis auf einen liefen problemlos.

Unter den 4 getesteten KU-Platinen ist eine, die Probleme macht, wenn eine KERNAL-Umschaltplatine und ein Nordic Replay stecken. Dieses Board hab ich mir schicken lassen und genauer angesehen. Nach ein paar Tests ist mir auf gefallen, dass die Reset-Leitung einen Pegel von nur ca. 2,6 V hatte und das Board beim Einschalten der Floppy oft einen Reset machte. Nach dem Wechsel einer CIA war dieser Pegel wieder ok. Trotzdem läuft das Board noch immer nicht dauerhaft stabil, weder mit dem realPLA, noch mit ein paar andern Original-PLAs und Ersatz-PLAs mit den genannten Erweiterungen. Komisch.

Erstmal danke, Gerrit. Aber das war's nicht.

Der instabile Gesamteindruck, den das Board geliefert hat, konnte sich nicht bestätigen. Vielleicht war es ein Wackelkontakt beim vielen Hin- und Herstecken. Vielmehr haben sich die Beobachtungen von neuRomancer bestätigt: Das Bard funktioniert nicht mit der realPLA, wenn diese KERNAL-Umschaltplatine _und_ das Nordic Replay gleichzeitig stecken. KERNAL-Umschaltplatine und andere Module (z.B. EF3) gehen. NR mit einzelnem KERNAL geht auch.

Ich hab jetzt keine Lust mehr, das weiter zu untersuchen. Schade, aber das hat schon zu viel Zeit gekostet.

Trotzdem hat sich die realPLA in den Tests als eine der kompatibelsten (wenn nicht die kompatibelste?) Ersatz-PLAs bewiesen. Immerhin funktionierten sogar alle KU-Platinen - bis auf die eine mit den genannten Erweiterungen.

Vielleicht wollen die Tester auch Ihre Erfahrungen schildern?

An dem Artikel schreibe ich noch, das wird noch ein paar Wochen dauern... (und interessiert eh niemanden)

Auf der KERNAL-Platine steckt auch ein Original-ROM. Das Problem tritt auch auf, wenn ich den EPROM aus dem anderen Sockel entferne und nur den Original-ROM drin lasse. Der Original-ROM im Original-Sockel (ohne Umschaltplatine) lässt das Problem nicht entstehen. Daneben ist noch ein bisschen 74LSxx Umschaltgeraffel, das kann natürlich auch eine Rolle spielen. Das RR kann ich mal probieren, ja. Die SuperPLA funktioniert in dieser Konstellation übrigens. Das ist bei anderen KU-Platinen ja nicht immer der Fall (dafür geht auf denen dann die realPLA, also am besten beides im Haus haben )

Propagation Delays und Slew Rates habe ich schon zwischen Original-PLAs und der realPLA verglichen. Da stimmt alles (*). Eigentlich sogar genauer als bei der SuperPLA, aber die funktioniert ja in dem Scenario. Auch leichtes Verschieben des Timing und der Slew-Rates nach oben oder unten haben nichts gebracht. Deswegen bin ich jetzt der Meinung, dass es kein (reines) Timing-Problem ist.

Meine letzte Theorie: Irgendwelche Pegel auf den PLA-Eingängen könnten in einem Bereich liegen, der nicht ganz sauber ist. Dieser könnte dann von der realPLA anders interpretiert werden als von den Original-PLAs. Das zu untersuchen ist aber wieder ein ziemlicher Aufwand bei geringstem Nutzen (da auf keinem anderen Board ein Problem aufgetreten ist und auch bei diesem nicht mit anderer "Zusammensetzung"). Deswegen wollte ich da eigentlich keine Zeit mehr reinstecken.

Zumindest Jens und Gerrit können sicher verstehen, wie viel Zeit man in solche "sinnlosen" Dinge stecken kann. Aber manchmal will man es einfach wissen. Vielleicht (das wird sich zeigen) haben ja meine Messungen auch zur Verbesserungen an der SuperPLA geführt, dann hat sich der Zeitaufwand noch etwas mehr gelohnt (und ich hab eine neue Tasse ).

Seanser: Nein, ich hab auch nur noch ein Exemplar. Weil ein Tester eine durch falschrum Stecken gebrutzelt hat

(*) Stimmt alles == Liegt so etwa in der Mitte der anderen untersuchten Typen (7700, 8700, 82S100, Fairchild-Dingens)

Edit: Übrigens half auch eine kleine Lücke zwischen den Chipselects nichts. Ich dachte, dass vielleicht die 74LSxx-Dinger das Timing so verschieben, dass der KERNAL auf der Umschaltplatine gegen was anderes treibt.

Oh, danke für den Hinweis. Stimmt, ich erinnere mich jetzt, dass Du das geschrieben hattest. Mist, wieso hab ich das vergessen. Dann könnte ich mich also auf diese Platine und das NR konzentrieren. Den EPROM hab ich ja auch schon gezogen und den KERNAL auf der Platine gegen einen anderen ausgtauscht.

Was ich darüber denke: Sicher könnte ich mal testweise die Chips auf der KERNAL-Platine tauschen. Was mich nur wurmt ist, dass es mit den Original-PLAs funktioniert und mit meiner nicht. Wo ich doch den (zugegebenermaßen übertriebenen) Anspruch hatte, dass die realPLA total "real" ist

Inzwischen habe ich versucht, die KERNAL-Platine zu verbessern (TTL-Schaltkreise gesockelt, testweise rausgezogen und das CS-Signal mit einem Draht direkt verbunden, die fehlenden Stützkondensatoren angebracht...) - keine Veränderung. Auch das realPLA habe ich nochmal komplett durchgemessen, sogar die Schwellenspannung der Eingänge mit dem Original verglichen.

Dann habe ich (endlich mal) richtig systematisch getestet. Und das kam dabei raus (reproduzierbar):

Ohne NR und nur mit KERNAL-Platine läuft das Board mit Original-PLA und mit realPLA.

Wenn das Board total kalt ist (15 Minuten auf Raumtemperatur), startet es nicht mit dem NR. Erst nach ca. 30 Sekunden lässt ein Reset den Rechner zuverlässig starten. Dann läuft es mit Original-PLA und realPLA.

Mit KERNAL-Platine und mit NR läuft das Board sogar erst stabil, wenn man es mindestens ca. 3 bis 5 Minuten warm werden lassen hat. Auch dann läuft es mit Original-PLA und realPLA.

AFAIR erwähnte Jens mal, dass es beim RR ein Problem bei manchen Boards gab, wegen der Temperaturverschiebung von Dotclock ggü. Phi2. Vielleicht ist im NR das gleiche Design? Mit RR verhält sich der Test übrigens wie mit NR. Mit FC-III und EF3 treten die Probleme nicht auf.

Eigentlich war ich der Meinung, dass das Board gestern mal zuverlässig mit der SuperPLA gelaufen ist. Aber heute verweigert es damit den Dienst total (zwei Exemplare getestet). Trotzdem ist die SuperPLA ein guter PLA-Ersatz, sie funktioniert sonst in fast allen Boards. Jens arbeitet auch gerade an Verbesserungen für die nächste Auflage. Die hochgelobte EPROM-PLA aus dem Lemon-Forum läuft auf dem Board übrigens nichtmal ansatzweise.

Dass die Testergebnisse in den letzten Tagen so inkonsistent aussahen, liegt wahrscheinlich daran, dass ich gar nicht auf die Temperatur geachtet habe und es deswegen mal ging und mal nicht.

Nach diesen Beobachtungen kann ich wieder guten Gewissens sagen:
Das realPLA hat mit allen ca. 20 bis jetzt getesteten Boards und diversen Erweiterungen problemlos funktioniert. Darunter waren mehrere KU-Boards, die mit anderen Ersatz-PLAs oft Probleme machen. Die Arbeit hat sich also gelohnt, auch nochmal vielen Dank an die Tester.

(Ich schwanke immer zwischen "die PLA" und "das PLA" wg. "Array" - naja, egal)

Zitat von JMP$FCE2

Ich erwarte jetzt Stückzahlen und zwar Kaufbar. Am besten über den Donaldshop.

Das wird sich zeigen. Mein Teil ist getan

Zitat von gartenzwerg

Interessantes Projekt. Ich habe auch mal mit einer Implementierung angefangen:

Das Reinprügeön der PLA-Gleichungen in ein CPLD ist allerdings nur der kleinste Teil der Übung. Wenn man sich darauf beschränkt, fällt einem das bei einer ganzen Hand voll C64s und Erweiterungen auf die Füße. Der Sharp-Käfer aus den neuen C64s hat übrigens einiges an Timing-Feintuning. Das wird Dir schon auffallen, wenn Du z.B. mal die Adressleitungen und ROML/ROMH/IO1/IO2 am Expansionsport mit einem Logic-Analyzer untersuchst.
P.S.: Ah, willkommen im Forum, Frank

Das ist A13, wenn ich den Beitrag von gartenzwerg richtig verstanden habe. Wenn ja, ist das normal so, A12 bis A15 werden in Phi1-Zyklen nur mit Widerständen hochgezogen. Bei einem Vth von ca. 1,3 V bei NMOS ist das aber auch schon relativ früh ein klares "High". (gartenzwerg: Übrigens wäre es deswegen auch okay, 3,3 V auf die Leitungen zu geben. NMOS bringt auch nur ca. 3,7 V high. Die Schaltschwelle liegt noch wesentlich tiefer, wg. der TTL-Kompatibilität muss sie das auch. Ich hab den extra-Käfer nicht primär als Pegelwandler sonder wg. der Schmitt-Trigger für die RC-Delays drauf. Die 5V-toleranten CPLDs haben TTL-kompatible Ausgänge, also high ist mit mindestens 2,4 V garantiert, praktisch bringen sie fast 3,3 V.)

Wg. der Veröffentlichung: Ja, ich plane alles zu veröffentlichen, wie beim EF/EF3 auch schon. Also sowohl Hardware-Dokumente als auch das besagte Pamphlet zu allem. Allerdings erst, wenn alles rund und aufgeräumt ist. Und das wird noch ein paar Wochen dauern. Das Dokument wird sich in der ersten Version auf das 28-beinige PLA beschränken. Und selbst da sind es schon ca. 20 Seiten... Erkenntnisse über das Sharp-Viech lasse ich gern später auch mit einfließen.

Wg. des Timings: ROML/ROMH hast Du gar nicht mit dabei. Ansonsten wäre Dir vermutlich ein wesentlicher Timing-Unterschied zw. I/O und ROM aufgefallen. ROML/H werden erst viel später gezogen, wenn ich mich richtig erinnere (Mist, hab den Kram nach dem Messen damals nicht gespeichert). Vermutlich damit externe, evtl. langsame ROM-Chips aus alten Modulen erst bei einem richtig stabilen Zustand ein OE bekommen und nicht sich noch ändernde Daten auf den Bus treiben (*). Das wäre nicht schlimm, aber unschön. Also an der Stelle ist das Timing vermutlich noch nicht wirklich kritisch. Aber die Sache mit RAM-Adressen und CASRAM solltest Du Dir genau ansehen. Im Schaltplan älterer C64s sieht Du schön aufgedröselt, wie das mit dem Multiplexer funktioniert und warum CASRAM auf keinen Fall schneller sein darf als die Adress-Multiplexer. Besonders ältere RAMs (die man auf neueren C64-Boards zum Glück nicht mehr findet), werden schon zickig, wenn CAS und Spalten-Adresse etwa gleichzeitig kommen.

Übrigens: Es wäre nett, wenn Ihr diese Diskussion in einem separaten Thread fortführen könntet (evtl. verschieben?), sonst wird der hier noch konfuser

Edit: (*) Oder damit ROMH nicht nach jedem Phi1-Zyklus aktiv und sofort wieder vom Bus genommen wird. Wozu AEC und die Pull-Ups ja unweigerlich führen. Dann müsste es mit #KERNAL auch so sein.