PLA-Ersatz "PLA16V8" für 264er-Reihe
- OliverW.
- Thread is marked as Resolved.
-
Ja, ich hatte es schon eine Weile fertig und Testexemplare sind wieder bei Adrian Black. Ich habe die Webseite in der Tat still und leise sichtbar gemacht. Der PLA16V8 ist ein schönes Beispiel für Durchentwicklung bis das Wesentliche und dann passt der ganze PLA in einen einzigen 16V8.
Er wurde noch nicht so ausgiebig getestet wie der PLA20V8, aber ich gehe aufgrund der Kenntnis der TED-Computer davon aus, dass es auch hier keine Kompatibilitätsprobleme geben wird.
-
Adrian hat wieder einmal ein schönes Video erstellt:
[External Media: https://www.youtube.com/watch?v=S7e1MGJwGvI] -
Passt das PLA16V8 in den C116? Auf dem Board geht es ja zumindest auf einer Seite ziemlich eng zu, und ich denke mal die Ferrite-Komponenten und die Caps sind da im Wege, oder?
-
Ich pack da immer einen Zwischensockel drunter, schon weil ich die Kondensatoren nicht biegen will.
Wenn es dich interessiert, ich habe noch einige Platinen von meinem Design, siehe meine Chronik.
Mfg Jood
Edit: Ohh.. C116, ich bin raus...
-
Ja, geht um einen C116.
-
Vielleicht wäre es gut, wenn man in der Überschrift erwähnen würde, dass es sich um Platinen für 264er Geräte handelt.
Kann ein MOD das bitte korrigieren?
-
8R0TK4$T3N
Changed the title of the thread from “PLA-Ersatz "PLA16V8"” to “PLA-Ersatz "PLA16V8" für 264er-Reihe”. -
Kann ein MOD das bitte korrigieren?
Erledigt.
-
Der PLA16V8 passt in einen C116. Auf dem Foto benutze ich einen meiner Prototypen:
Inklusiv Sockel in der Hauptplatine und PLA ist die Höhe ungefähr so groß wie der Cartridgeanschluss. Das Gehäuse kann problemlos geschlossen werden:
Es gibt jedoch ein mechanischen Konflikt wenn man das originale Funkabschirmungsblech verwerdet:
Da ein C116 einen hohen Sammlerwert hat (ein Plus/4 ist viel praktischer) und zu einem hohen Preis verkauft wird, würde ich es so weit wie möglich in seinem Originalzustand belassen. Ich wäre daher geneigt, eine PLA aus einer C16 oder Plus/4 zu nehmen und die PLA16V8 darin zu verwenden und die C116 mit original PLA und Funkabschirmungsblech auszustatten.
-
Prima, danke für das Feedback. Ich will vor allem die Wärmeentwicklung im C116 reduzieren, daher möchte ich das originale PLA ersetzen. Die Änderungen, die ich am C116 vorgenommen habe (Schaltregler, Zementwiderstand raus, ggf. ROMs durch EEPROM ersetzen) sind ja rückrüstbar, wenn man das will. Ansonsten ist der C116 original, und die getauschten Chips sind ja schnell wieder zurückgesteckt. Das Wärmeleitblech schmeiße ich natürlich auch nicht weg, das hebe ich natürlich auf.
Ich werd dann mal so ein PLA über Deine Homepage bestellen; mit dem C64 PLA hat das ja damals auch prima geklappt.
-
-
Das Problem ist, dass ich keine 1551 besitze und wenig Grund sehe, mir eine zuzulegen. Auf meinem Büro steht normalerweise mein 1571 und mein C16 und Plus/4 haben beide JiffyDOS eingebaut. Diese Kombination ist viel schneller als eine 1551. Meine Motivation, einen 1551er zu kaufen, ist daher sehr gering. Aber da ich keine 1551 habe, ist es auch schwierig, eine PLA zu entwickeln.
Technisch wäre es sehr einfach, und ich würde die PLA16V8 als Basis nehmen, weil das 1551 Paddle auch einen guten Teil der PLA als UND-port verwendet. Einige Leiterbahnen müssen verschoben werden, danach ist es trivial, die Gleichungen anzupassen. Ich denke, ich könnte das Design innerhalb eines Tages erstellen. Das Testen auf der anderen Seite...
-
Technisch wäre es sehr einfach, und ich würde die PLA16V8 als Basis nehmen, weil das 1551 Paddle auch einen guten Teil der PLA als UND-port verwendet. Einige Leiterbahnen müssen verschoben werden, danach ist es trivial, die Gleichungen anzupassen. Ich denke, ich könnte das Design innerhalb eines Tages erstellen. Das Testen auf der anderen Seite...
Die Gleichungen sind ja bekannt und meines Wissens eine Untermenge des PLAs im C16 (mit einer anderen Adress-Decodierung, weil das Paddle auf einer anderen Adresse liegt).
Ich habe den Plan, ein Paddle für die 1551 zu bauen, das ohne den MOS6523T und ohne das originale PLA auskommt noch nicht ganz aufgegeben. Ein auf einem GAL16V8 basierende Lösung wäre da natürlich auch vom Platz her top. Ich würde das direkt, ohne Adaptersockel, auf das PCB draufdesignen. Bisher habe ich an ein EPROM-PLA gedacht, aber ein GAL wäre um Klassen besser.
-
Bisher habe ich an ein EPROM-PLA gedacht, aber ein GAL wäre um Klassen besser.
Kann ich dir irgendwie helfen dabei?
Mit GAL und CPLD kenne ich mich aus.
Allerdings habe ich auch keine 1551 und kein Paddle mehr, hab ich alles vor Jahren weiter gegeben.
Wenn man so ein Paddle nachbaut, könnte man auch gleich eines für den C64 machen ...
-
Kann ich dir irgendwie helfen dabei?
Ja, sicher ... die Gleichungen in ein GAL 16V8 quetschen und synthetisieren.
Irgendwo sind die Gleichungen veröffentlicht, sonst könnte androSID vielleicht helfen?
Wenn man so ein Paddle nachbaut, könnte man auch gleich eines für den C64 machen ...
Am C64 funktioniert das ohne GAL, weil man da z. B. IO1 und IO2 nutzen kann. Der C16 hat sowas nicht, daher wurde das im Paddle generiert.
-
Am C64 bräuchte man also nur ein PIA oder VIA
Oder man nimmt einfach ein Turbo Trans Modul?
Und welcher IO Baustein würde am Modul für den C16 zum Einsatz kommen?
Ein VIA?
Oder einfach TTLs?
-
Ich denke, es sollte möglich sein, dies mit reinen TTL-Bausteinen zu tun. Port A des 6525 wird bidirektional sein und kann mit einem 74x646 realisiert werden. Die beiden Leitungen von Port C sind wahrscheinlich unidirektional und können mit 74x175 zum Schreiben und 74x244 zum Lesen realisiert werden. Zugriffe auf das Datenrichtungsregister ignorieren.
-
Am C64 bräuchte man also nur ein PIA oder VIA
Da man am C64 die Software sowieso erst schrieben müsste, wird da ein VIA, PIA oder CIA reichen. Der 6523T im Paddle hat einen 8-Bit Port A (PA0..7), 2-Bit Port B (PB0..1) und 2-Bit Port C (PC6..7). Dafür reicht ein Device mit zwei vollen 8-Bit-Ports. IRQ, Schieberegister, usw. braucht man gar nicht.
Und welcher IO Baustein würde am Modul für den C16 zum Einsatz kommen?
Ein VIA?
Oder einfach TTLs?
Am C16 reicht leider ein VIA nicht, wenn man die Software nicht umstricken will, siehe oben. Es werde Port A, B, C verwendet ("Tri-Port", TIA).
Ich denke, es sollte möglich sein, dies mit reinen TTL-Bausteinen zu tun. Port A des 6525 wird bidirektional sein und kann mit einem 74x646 realisiert werden. Die beiden Leitungen von Port C sind wahrscheinlich unidirektional und können mit 74x175 zum Schreiben und 74x244 zum Lesen realisiert werden. Zugriffe auf das Datenrichtungsregister ignorieren.
Grundsätzlich sind Port A, B, C des TIA nur bidirektionale Ports ohne besondere "Magie". Es existiert hat pro Portbit ein Datenrichtungsregister (DDRA..C), sodass jedes Bit im Prinzip einzeln umgeschaltet werden kann. Ohne die Software geprüft zu haben würde ich raten, dass das bei Port A nicht genutzt wird (entweder alles Eingang oder alles Ausgang). Bei Port B und wird die Richtung WIMRE schon einzeln umgeschaltet. (Bin mir aber nicht mehr sicher.)
toms01 hat das ja bereits mit einem CPLD nachgebildet.
Mir schwebt aber eine Lösung mit "Originalbausteinen" vor, wo man nicht erst ein CPLD programmieren muss, weil das nicht jeder kann. Daher habe ich 2 x VIA, 2 TTLs für die Adress-Umcodierung von TIA auf 2 x VIA und ein EPROM (bzw. eben GAL) als PLA-Ersatz im Sinn.
-
Der C16 Expansion Port
Seltsam, dass Commodore keine IO Adressen dekodiert hat???
Also der GAL soll das tun...
Das ist simpel wenn man weiß welche Adressen.
-
Also der GAL soll das tun...
Das ist simpel wenn man weiß welche Adressen.
Wie gesagt, die Gleichungen sind bekannt.
