Beiträge von Gerrit im Thema „cc65 und Speicher-Banking auf 264-Serie“


    Meiner Erfahrung nach ändert sich die Stärke der Output-Pins nicht von Charge zu Charge, denn gerade in der Chip-Herstellung kann man von sehr engen Fertigungstoleranzen ausgehen. Wenn etwas variiert, dann ist das "von Hersteller zu Hersteller". Die Option einen anderen Hersteller für die RAMs einzusetzen, hat Commodore sich mit der Verdrahtung der Multiplexer verbaut: Die funktioniert so nur mit TI-Rams. "der andere" Hersteller wäre NEC, und da ist die Verteilung der Adressbits anders - die würden schlicht und einfach nicht funktionieren.

    Es gibt diese RAMs auch noch von SHARP (wenn meine Erinnerung nicht komplett im Eimer ist), ich habe einen C128 (Flach) mit deren 16Kx4 DRAMs am VDC, ich könnte nächstes Wochenende mal ein Foto machen wenn nötig. Du hast aber insofern recht, dass ich beim C16 bzw. 116 immer nur die TMS4416 gesehen habe. Nach dem Umbau auf 64KB konnte man an 41464-DRAMs verwenden was greifbar war, diese komische Verteilung der Adressbits gabs anscheinend _nur_ bei den 4416 DRAMs.

    EDIT: Ich hab noch das MB81416 von Fujitsu gefunden, das wäre, laut Datenblatt, kompatibel zum TMS4416 im Bezug auf die Adressen. Gesehen als Chip habe ich es nie.

    Ähemm.. Änderungen an den Adressleitungen? Es werden bei 64k schlicht und einfach alle verwendet, da gibts nichts zu ändern. Die 64k-Erweiterungen sind vergleichsweise simpel, weil sie einfach den internen Speicher überbügeln. Sauberer wär's, wenn der interne Speicher ganz rausgenommen wird, aber die Option haben die meisten C16/C116-Nutzer nicht.

    Ausbauen muss man den Speicher nicht, die 4416 und 4464 haben auf Pin 1 ein _OE liegen. Pin 1 bei jedem RAM von der Platine trennen sollte reichen um den onboard-Speicher stillzulegen. Ausgänge gegeneinander arbeiten lassen ist mir jedenfalls extrem unsympatisch, vor allem wenn es sich dabei um Ausgänge schwer beschaffbarer ICs handelt. Auch kann man da böse reinfallen wenn die internen RAMs aus einer Charge stammen bei der die Ausgangstreiber etwas stärker ausgefallen sind.

    Zitat


    Ich bleibe daher bei meiner wilden Spekulation, dass es sich bei dem Transistor um eine push-Stufe handelt, die CAS=1 forciert. Es müsste sich demnach um einen PNP-Typen handeln. Und ja, das gefährdet den TED - vielleicht ist das der Grund, warum der TED als so "leicht sterblich" gilt? Waren dei 16k-Erweiterungen vielleicht sogar sehr häufig und haben dazu beigetragen, dass die Chips wie die Fliegen gestorben sind?

    Der Preis für eine 16K-Erweiterung lag damals bei 99 DM, für eine 64K (intern, Zwischensockel für TED, also wahrscheinlich sauberes Design) musste man 199DM hinlegen. Wäre also schon möglich, dass einige Leute diese Erweiterungen benutzt haben. Ich hab damals den dritten Weg genommen und die internen RAMs gegen 4464 getauscht, kam billiger, war aber mehr Arbeit. Dafür hatte ich persönlich (und die paar Leute denen ich ihre C16 erweitert hatte) nie einen toten TED oder CPU. Kühlkörper hatte ich auch montiert.

    Für deine Spekulation spricht, dass die Adressen des I/O-Bereichs viele 1-Bits enthalten und das die ideale Anwendung für das NAND mit den extra vielen Eingängen ist.


    Jetzt stell' Dir vor, dass dem TED immer vorgegaukelt wird, dass ROM selektiert ist, also CAS nicht generiert wird, dann könnte man mit externer Logik das fehlende CAS erzeugen. Der Transistor wäre dazu da, dass der interne Speicher sich regt, und lokal auf der Karte wird ein zweites CAS erzeugt. Da CAS ohnehin nur ein verzögertes MUX-Signal ist, würde das auch die RC-Elemente erklären.

    Das wäre aber ein hanebüchenes Design, ob das mit wirklich jedem C16 läuft wäre die Frage. Für eine Einzelanwendung kann ich solche Hacks verstehen, aber für ein Serienprodukt?

    Zitat


    Vielleicht kann mc71 uns erklären, was der TED macht, wenn er auf "ROM" gestellt ist? Gibt es für die CPU dann *nur* Rom? Und wo holt sich der TED dann seine Daten her?

    Wenn ich das Datenblatt zum TED korrekt verstehe (Falls du es nicht hast, google nach '7360R0') gilt die Umschaltung ROM/RAM nur für $8000-$FFFF (minus I/O-Space und TED-Register). RAM vor $8000 ist auch im ROM-Mode erreichbar und den Zugriff auf den Zeichensatz (ROM oder RAM) steuert Bit 2 in Register 18 unabhängig von der generellen Umschaltung.

    Die Umschaltung erfolgt über Schreibzugriffe auf Register 62 (ROM) und 63 (RAM), nach aussen sichtbar ist sie über aktives _CAS (RAM) bzw. aktive Chipselects (_CS0 und _CS1 für die ROMs).

    Die Ansteuerung beim 232 ist wahrscheinlich sehr straight-forward mit geteiltem CAS.

    Die offizielle Lösung würde ich trotzdem gerne mal sehen.


    Zitat

    Extern ist viel interessanter, denn die +16k Erweiterungen haben wirklich nur 16k Speicher und Logik. Die ist aber nicht klein; ich tippe darauf, dass eine Kopie von bestimmten Registern angelegt wird, und dann wird irgendein Signal "überbügelt". Hinweise darauf sind das dicke NAND-Gate (LS133), das wahrscheinlich zur Dekodierung genutzt wird, sowie ein Transistor, der wohl genug Wumms hat, um eins der Ausgangssignale "anzupassen". Klingt nach der Holzhammer-Methode: Wenn's mit Gewalt nicht klappt, dann benutzt Du nicht genug davon :smile:

    Der Transistor hängt mit einem Bein direkt an _CAS. Ich kann mir aber nicht vorstellen, dass die Schaltung _CAS damit auf HIGH zwingt. Das dürfte der TED mit der Zeit übelnehmen. Interessant sind auch die verwendeten Multiplexer. Je ein 74LS157 und ein 74LS158 (invertierte Ausgänge), gibt es dafür einen Grund?

    Die eigentliche Logik zur Unterscheidung von internem und externem RAM muss sich in den 74LS133 und 74LS00 verstecken. Wenn ich das richtig sehe ist der Ausgang des 74LS133 direkt mit einem Eingang des 74LS00 verbunden. Besonders kompliziert kann sie demit nicht sein.

    Holzhammer-Erweiterungen hatten beim C16 leider Tradition, so funktionierten auch die 64KB-Erweiterungen für den Expansionport.

    cbm-warrior,

    kannst Du mal ein Foto einer solchen +16k-Erweiterung machen? Mir würd's schon reichen, wenn ich die Chips sehe. Ich werde das Gefühl nicht los, dass die in Wirklichkeit 32K Ram beinhaltet.

    Interessant wäre auch ein Schaltplan eines 232, der hat ja 2 Bänke aus 4416 DRAMs, da würde mich die Ansteuerung interessieren.

    Mahlzeit,

    der cc65 hat auch die 264-Serie als Target. Wie allerdings Bitte melde dich an, um diesen Link zu sehen. zu lesen ist, gibt es unterschiedliche Speichermodelle für die Rechner, die mir Rätsel aufgeben: Beim Plus/4 wird "banking" benutzt, so dass der gesamte Speicher zur Verfügung steht. Für C16/C116 gibt's jedoch maximal 32k. Diese Ausbaustufe habe ich in der freien Wildbahn aber noch nie gesehen; üblicherweise findet man doch die 64K-Erweiterung an bzw. in den Teilen, oder nicht?

    Meine Frage lautet also: Wenn man einen C16 auf 64k erweitert hat, können diese 64k komplett von der cc65-runtime lib genutzt werden?

    Es gab damals für kurze Zeit eine 16K-Erweiterung für den C16 zu kaufen, steckte im Expansion-Port und brachte die Kiste auf 32KB. Kostete 99DM. Ich kenne keinen der eine hat, jeder hat die internen RAMs auf 64KB erweitert. War billiger und beim C116 auch schmerzfrei, beim C16 etwas aufwendiger wegen zu unterbrechender Leiterbahn unter einem der 74LS257.

    Meines Wissens besteht im Bezug auf Speicher zwischen C16 mit 64K und Plus/4 kein Unterschied. Die ROMs für BASIC und KERNAL sind dieselben, die Hardware zur Ansteuerung des Speichers ist dieselbe, nur die RAMs unterscheiden sich (4164 beim Plus/4 und 41464 beim C16 mit 64K) was aber irrelevant ist. Es sollte also reichen Software für den Plus/4 zu kompilieren wenn sie auf einem C16/64K laufen soll. Software die Userport oder RS232 voraussetzt wird natürlich nicht funktionieren solange beides nicht nachgerüstet ist.