Commodore PC 10/20 und 10/20 II - RAM Aufrüstung beim zweigeteilten Board

  • So, es hat ein bissel gedauert, aber es läuft :)


    Großes Dankeschön insbesondere an Toast_r, der nicht locker gelassen hat und mittlerweile wahrscheinlich keinen GAL mehr sehen kann...


    Folgende Bestückung habe ich mit dem von ihm gebrannten GAL getestet:


    vollständig Bank 3 -> 512 kB



    vollständig Bank 3 und unvollständig Bank 4 -> Parity Error (das hatte ich einfach mal probiert, weil für 640 k theoretisch eigentliche keine volle weiter Bank notwendig ist, oder? Geht aber nicht.



    vollständige Bank 3 und vollständige Bank 4 - > 640 k



    Die Zugriffszeit schein nicht das Problem zu sein, habe auch eine Bank mit schnelleren Ram bestückt, als im Original.



    Viele Grüße und besten Dank an alle, die sich hier mit den Kopf zerbrochen haben.


    Ernst

    • Offizieller Beitrag

    Eine Bank muss immer vollständig bestückt sein, weil die Chips nur ein Bit breit sind.

    Jedes einzelne Byte wird also immer aus 8 Bits aus 8 RAM ICs zusammengesetzt. Das 9te IC enthält das Parity-Bit.


    Ich werde heute abend mal erläutern, wo die Daten für das funktionierende GAL letztendlich hergekommen sind.

    • Offizieller Beitrag

    Dann will ich euch mal teilhaben lassen an der langen Geschichte, wie es denn letztendlich gelungen ist,

    den PC-10 von efb auf 640KB Ram aufzurüsten.


    efb wollte seinen Commodore PC, der mit seiner orignalen 256KB Bestückung funktionierte, auf 640kb aufrüsten.

    axorp hatte bestätigt, daß für die Speicheraufrüstung ein anderes PAL erforderlich war. Commodore hat so das gemacht, um die Leute dazu zu bringen, bei Ihnen teure Speicher-Aufrüstsätze zu kaufen, statt einfach möglichst günstig irgendwo RAMs zu kaufen.

    Ich habe ein Commodore PC Mainboard mit 640KB Bestückung, das aufgrund der verbauten RAM-Chips des gleichen Typs aus dem gleichen Fertigungszeitraum vermutlich mit dieser Bestückung ausgeliefert wurde. Da das Board leider defekt ist, und der Defekt noch nicht diagnostiziert ist, ist die Möglichkeit gegeben, daß das PAL auf dem Board defekt ist.


    Der (in diesem Zusammenhang wichtige) Unterschied zwischen PAL und GAL ist, daß GALs mehrmals programmierbar sind, PALs aber nur einmal.Daher (und weil ich passende GALs in meinem Vorrat hatte) wollte ich natürlich ein GAL verwenden, und nicht wieder ein PAL.


    Commodore hat die PALs als eine Art Dongle verwendet, also hatte ich die Befürchtung, daß die PALs durch setzen des Security-Bits gegen Auslesen geschützt sind. Da ich aber beim Ausleseversuch nicht nur Nullen oder Einsen erhielt, sondern Daten, die ein Muster erkennen ließen, ging ich von brauchbaren Daten aus.

    Also habe ich kurzerhand die aus dem PAL ausgelesene JEDEC Datei in ein GAL gebrannt, und das GAL efb zugeschickt.

    Ergebnis: Der Rechner startete nicht mit dem GAL.

    Um festzustellen, ob das ganze denn auch tatsächlich mit einem GAL funktioniert hat efb mir sein original PAL zugeschickt.

    Zu Erinnerung: Mit dem lief der Rechner mit 256kb RAM.

    Dieses PAL habe ich dann ebenfalls augelesen, und wieder Daten erhalten, die ein Muster aufwiesen - und sie unterschieden sich von den aus meinem PAL ausgelesenen, waren aber sehr ähnlich. Das schien die Vermutung zu bestätigen, daß vernünftige Daten ausgelesen wurden.

    Diese Daten habe ich also wieder in ein GAL gebrannt, und es efb zugeschickt.

    Damit lief der Rechner auch nicht. Somit stand fest, daß das 'mal eben' kopieren vom PAL zum GAL nicht klappt.

    Im GAL Datenblatt hatte ich zwar einen Hinweis auf die Kompatiblität zu PALs gefunden, aber ganz so einfach war das ja demnach nicht.

    Ich brauchte Hilfe von jemanden, der sich im Bereich programmierbare Logik-ICs auskennt.

    Da ich im Zusammenhang mit CBM PLAs schonmal mit fhw72 (früher AndroSID) in Kontakt stand, habe ich mich an ihn gewandt.

    Von ihm habe ich erfahren, daß man nicht so einfach eine aus einem PAL ausgelesene JEDEC Datei für ein GAL verwenden kann.

    Da ein GAL zwar im Prinzip zum entsprechenden PAL kompatibel ist, aber noch einiges mehr kann, ist der Aufbau, und auch die Programmierung, anders.

    Zum Glück gibt es Programme, die die JEDEC Dateien konvertieren, und fhw72 hat mich auch direkt mit einem versorgt.

    Also ging es weiter zum nächsten Schritt: Ich habe die beiden aus den PALs ausgelesenen JEDEC Dateien konvertiert und in zwei GALs gebrannt.

    Die habe ich wieder an efb geschickt. Das (wenig?) verblüffende Ergebnis: Der Rechner lief mit keinem von beiden.

    Meine ursprüngliche Befürchtung, daß die PALs gegen Auslesen geschützt sind, schien sich zu bestätigen.

    Daß es auf diesem Weg nicht ging war jetzt jedenfalls klar, es mußte also eine andere Lösung her.

    Bei der Aktion hatte ich gelernt, daß PALs im Gegensatz zu GALs nur reine und/oder Logik abbilden können.

    Das bedeutet, daß jeder Kombination von Pegeln an den Eingängen genau eine an den Ausgängen zugeordnet ist.

    Man kann ein programmiertes PAL also auch wie ein ROM auslesen. Genau so funktioniert auch die EPROM-PLA.

    Allerdings würde ein EPROM als Ersatz für den PAL nicht funktionieren. Die Zugriffszeiten würden bei weitem nicht ausreichen.

    Aber man kann so eindeutige Daten aus dem PAL auslesen.

    Ich habe also das PAL mit meinem Eprommer ausgelesen, indem ich die PAL-Eingänge als Adressleitungen und die PAL-Ausgänge als Datenleitungen angeschlossen habe.

    An dieser Stelle kommt der nächste Helfer ins Spiel: funkenzupfer hat die so gewonnenen Daten in Logikgleichungen zurückgeführt.

    Dafür hat er eigens ein C-Programm geschrieben. Der Abgleich der so entstandenen Gleichungen mit dem Schaltplan machte keinen völlig abwegigen Eindruck.

    Als nächstes mußten die Gleichungen in eine JEDEC Datei überführt werden, mit der das GAL programmiert werden kann.

    Das ist das Stichwort für einen weiteren Helfer: for(;;) hat dankenswerter Weise nach einem geeigneten GAL-Assembler Ausschau gehalten.

    Vom gefundenen Open Source GALASM hat er dann direkt noch eine Windows-Version Compiliert, mit der dann die JEDEC-Datei erstellt werden konnte.

    Dann habe ich mal wieder einen GAL gebrannt und diesen mit dem zuvor für den PAL gebastelten Adapter auch als EPROM ausgelesen.

    Daß die dabei erhaltenen Daten Identisch mit den waren, die ich auf diese Weise aus dem PAL augelesen hatte, hat mich dann fast schon überrascht, nach all den Fehlschlägen. :mrgreen:

    Jetzt fehlte nur noch der alles entscheidende Praxistest, also habe ich (mal wieder) ein GAL an efb geschickt.

    Ergbnis: siehe Beitrag #91 (in Worten: Einundneunzig!).

    Schlußendlich hat's geklappt!


    Bei der Aktion habe ich mal wieder einiges dazugelernt. :)


    Den Dank von efb möchte ich weiterreichen an fhw72 , funkenzupfer und for(;;) , ohne deren Hilfe die Aktion so nicht gelungen wäre.


    Und hier ist sie endlich, die heiß ersehnte JEDEC-Datei, für 640 KB im Commodore PC-10 / PC-20 mit geteiltem Mainboard. :anbet:

    • Offizieller Beitrag

    Wer verstehen möchte, wie das PAL/GAL im PC-10 arbeitet, für den dürfte die PLD-Datei,

    die funkenzupfer erstellt und kommentiert hat, ziemlich interessant sein:


  • hallo christian,

    ich war wochen nicht online, ich war wieder ein paar mal krank.

    habe aber mich sehr gefreut, hier zu lesen, dass du es gelöst hast.
    pal / pla auslesen wie ein (ep)rom, erinnerte mich sehr an meinen damaligen lösungsweg.

    lg
    helmut

  • Toast_r

    vielen Dank für den umfangreichen Bericht. So etwas zu verfassen dauert bestimmt auch lange. Die ganzen Geschehnisse und wer da alles mit drin war.

    Echte Forum-Leistung das geknackt zu haben. Puhh, da wird einem ja schon beim Lesen ganz anders und das ist so eine harmlos anmutende Frage mit der Ram-Aufrüstung vom PC 10/20.:)

    ███▓▒░░♫☺Faszination der Heimcomputer☺♫░░▒▓███

  • Ich hatte das gleiche Projekt / Problem und hätte es ohne Eure Infos und Arbeit nie geschafft mein PC 10 Board auf 640k aufzurüsten.

    Danke an alle, die hier die Vorarbeit gemacht haben. :applaus:


    Das ging dann doch nicht so einfach, weil das Board erst einmal tot war, und zum Leben erweckt werden mußte ( alle RAM's ausgelötet, es war jedoch eine gebrochene Leiterbahn) . Beim PAL16V8A programmieren hatte ich bei der Auswahl des Chips das A vergessen ( also PAL16V8) , mit dem Ergebnis, daß der Rechner damit gar nicht erst hochgelaufen ist. Verify sagte aber für den Chip ok. Also Arduino UNO grogrammiert, und die 1024 möglichen Kombinationen vom PAL ausgelesen und über excel ausgewertet. Dabei bin ich dann auf die Fehlprogrammierung gestossen.




    Die Bank 3 ist ebenfalls mit 41256er bestückt. Scheint zu funktionieren, aber Checkit stürzt bei der Ermittlung der Geschwindigkeit immer ab.


    Ich würde jetzt gerne noch die Diagnose Software von Commodore einmal über den Rechner laufen lassen, konnte diese aber bisher nicht im Internet finden. Hat die noch jemand in seiner Sammlung, bzw. kennt einen Link dazu im Internet ?

    ... der Weg ist das Ziel