Beiträge von Freak

Zitat von 2ee

Dennoch, falls irgend jemand einen Hinweis hat, was das Problem sein könnte, soll er sich bitte melden.

Ich hätte da so eine Vermutung:

Du zeigst in dem Schaltplanausschnitt zwar deine drei benutzten Gatter des 4050, aber auf dem gesamten Schaltplan finde ich nichts zu den unbenutzten Gattern.

Laut einem Datenblatt zum 4050 und auch im Allgemeinen sind unbenutzte Eingänge auf jeden Fall mit einem definiertem Pegel zu belegen. Außer vielleicht bei 74LS-ICs, die haben interne Pull-Ups...

Versuch doch einfach mal, die Pins der unbenutzten Gatter (Pin 9, Pin 11 und Pin 14) auf GND zu legen...

Gruß

Thomas

Hallo,

nachdem die Kat-Ce 68070 inzwischen von Martin Hepperle zu mir gezogen ist, hatte ich in den letzten Tagen mal Zeit, mich dem System zu widmen und habe versucht mit der Kat-Ce 68070 zu kommunizieren.

Dabei stand allerdings nur ein relativ neuer Linux-PC ohne RS232 zur Verfügung, so dass ich ein wenig basteln musste.

Als erstes wurde der MAX232 entfernt und ein gedrehter Sockel mit ein paar Drahtbrücken derart präpariert, damit TxD und RxD vom 68070 an die Messerleiste geführt werden. Dort habe ich dann einen USB/TTL-Serialadapter drangeklöppelt und damit die Verbindung vom PC zum 68070 hergestellt. Allerdings ohne Hardware-Flusskontrolle...

Um mit der Kat-Ce 68070 zu kommunizieren ist ja auf der PC-Seite ein entsprechendes Programm notwendig. Martin hatte im Post 7 eine C-Implementation gefunden, die mir ganz geeignet erschien. Die ließ sich auch übersetzen, allerdings habe ich vorher im Source die Datenflusssteuerung entfernt, ich denke in der heutigen Zeit gehen bei 19200 Bits/s keine Zeichen verloren...

Und siehe da: Die Kat-Ce 68070 meldet sich und wartet auf Eingaben...

Mir ist bis jetzt nur aufgefallen, dass die verlinkte C-Implementierung des Kommunikationsprogramms nicht fehlerfrei ist und beispielsweise nicht scrollt. Der Bildschirm wird nach unten hin gefüllt, aber dann passiert alles weitere nur in der unteren Zeile. Aber so ein paar Programmierkenntnisse habe ich, so dass ich dieses Problem noch am Wochenende beheben konnte.

Mal schauen, ob ich auf das System auch Binär-Dateien übertragen und starten kann, die ich auf dem PC assembliert habe. Macht zumindest Spaß, sich mit dem alten System zu beschäftigen...

Gruß

Thomas

Zitat von mister-freeze

Ich hätte sogar einen Timer im System zur Verfügung.

Rein aus Interesse: Was für ein System ist denn das?

Okay, damit hast du eine geschachtelte Verzögerungsschleife realisiert, die eine gewisse Anzahl von Taktzyklen verbrät.

ABER:

Es gibt zwei weitere Faktoren, die du hier nicht beachtest und die die verstrichene Zeit negativ beeinflussen können:

1) Der Videochip: Es gibt Rechner, deren Videochip für die Videoausgabe auf den ROM/RAM-Inhalt zugreifen müssen und dabei den Prozessor für ein paar Taktzyklen anhalten. Wenn ich mir dein Bild im vorigen Post angucke, dann trifft dieser Faktor hier aber wohl nicht auf dich zu. Beim C64 und seinen Verwandten aber schon. Deswegen wäre in einer derartigen Konstellation eine Verzögerung mittels eines Timers die bessere Wahl.

2) Interrupts: Falls Interrupts auftreten (IRQs können gesperrt werden, NMIs sind nicht unterdrückbar), dann unterbricht der Prozessor für eine für dich undefinierte Zeit dein Programm und kehrt erst nach Beendigung des Interrupts zurück, um dein Programm weiter auszuführen. Dies führt ebenfalls zu einer weiteren Verzögerung, so dass deine Verzögerungsroutine nur einwandfrei arbeitet, wenn die Interrupts im Status-Register gesperrt sind und extern keine NMIs auftreten.

Beide Probleme lassen sich durch die Verwendung eines Timers umgehen. Denn der läuft unabhängig von der CPU und würde der CPU den Zeitablauf mittels Interrupt melden.

Gruß

Thomas

Zitat von klaly

Aber so ganz erschließt sich mir nicht was das xlink Zeug so macht.

XLink ist eine komfortable Möglichkeit, vom PC aus auf den Speicher eines 6502-Systems zuzugreifen, um z.B. Programme zu übertragen, welche auf dem PC assembliert wurden. Oder auch um einzelne Speicherstellen zu beschreiben oder auszulesen.

Wurde ursprünglich vom Forum64-User "henning" vor einigen Jahren entwickelt und sehr gut dokumentiert: Klick mich an!

Ich war damals davon echt begeistert und benutze es heute noch. Und finde, dass es sich auch gut für andere Systeme eignet...

Ich verlinke nochmal mein Video, das ich im August gemacht habe: Youtube-Video

Zitat von klaly

Interessant ist, dass der CH552 ein 8051 Chip ist, ich dache immer das wäre "einfach nur ein USB/UART Chip" .

Da ist ein vollwertiger 8051 mit drin, der sich über USB programmiren lässt. Außerdem braucht der Chip keinen externen Quarz um über USB zu kommunizieren. Das finde ich schon sehr attraktiv! Letztlich spielt der CH552 Schnittstelle zwischen dem über USB angeschlossenem PC und dem Parallelport des Zielsystems...

Gruß

Thomas

Hallo zusammen,

lange hat es gedauert, aber nach einigen Monaten des Lötens und Programmierens ist jetzt die erste vorzeigbare Version des XLink-Adapters für den Junior-Computer 2 fertig!

Die Features sind exakt dieselben, wie schon vor einigen Monaten vorgestellt. Es wird jedoch wie geplant anstelle der AVR-CPU die China-CPU CH552 von WCH verwendet. Dies macht den Adapter wesentlich preiswerter, wenn auch etwas schwieriger nachzubauen, da es den CH552 nur als SMD gibt und ich hier sogar auf die kleinste Version im TSSOP20-Gehäuse angewiesen bin, da nur diese Version zwei zwingend benötigte Port-Pins rausführt.

Ich habe mir vor einigen Wochen ein paar Adapter gebaut, um diese dann direkt an der Erweiterungsplatine für den Junior Computer 2 zu testen.

Ich brauchte im Quelltext meines JC2-Kernals nur die Basisadresse des VIAs auf $0800 anpassen und schon funktionierte alles wie schon zuvor mit meinem eigenen VIA-Adapter und dem originalen XLink-Adapter für den C64. Die Funktionalität ist sogar derart kompatibel, dass ich inzwischen den eingebauten Benchmark laufen lassen kann:

Der "-M C128"-Parameter ist notwendig, um die Menge an Daten auf 8kByte zu begrenzen. Der Standard-Benchmark für den C64 überträgt wesentlich mehr Daten. (u.a. auch an Stellen, an denen der Junior Computer 2 kein RAM hat. Da funktioniert dann das Vergleichen zwischen gesendeten und empfangenen Daten nicht mehr...)

Mal schauen, wie es in den nächsten Monaten weitergeht. Jetzt steht erstmal Weihnachten vor der Tür, da wird sich zum Basteln nicht so viel Zeit finden. Ich habe aber schonmal eine ganze Menge Infos auf meinen Github-Account abgelegt, den ich hier und hier verlinke.

Falls ich im neuen Jahr mit diesem Projekt fortfahre, möchte ich die Software (sowohl die Firmware als auch den Kernal) nochmal ein wenig überarbeiten. Sie läuft zwar störungsfrei, aber vielleicht kann ich ja beispielsweise noch eine Watchdog-Funktionalität integrieren, damit sich der Adapter bei gegebenenfalls auftretenden Übertragungsstörungen selbst zurücksetzt. Die Adapterhardware halte ich für ausgereift. Man könnte zwar noch das ein oder andere Bauteil weglassen, aber die jetzige Version ist für mich absolut vorzeigbar und wird so bleiben...

Vor ein paar Tagen habe ich auch noch ein wenig mit KiCAD gespielt und den Adapter auf ein kleines Panel gesetzt. Damit könnte man die Platinenkosten noch ein wenig reduzieren.

So, das war es erstmal von mir.

Gruß

Thomas

Zitat von 2ee

Passt jetzt der Einschalter bei dir bündig zum Rand, oder steht der noch leicht über?

Edit: Vieleicht sollte man noch für die STEP LED zusätzlich eine SMD LED vorsehen.

Der Einschalter passt jetzt sehr gut. Der Rand der Platine steht ganz leicht (so 0,5 mm) über. Ich denke, das ist in Ordnung...

Für die STEP-LED noch zusätzlich Pads dazu basteln? Ich glaube, da ist nicht mehr so viel Platz. Oder man lötet einfach eine SMD-LED im Format 0603 auf die Pads der 3 mm-LED. Oder vielleicht eine 1,8 mm-LED statt der 3 mm-LED... Aber auch die jetzt verlötete 3 mm-LED passt gut zu den Tastern.

Ich habe übrigens auf der Unterseite einen 3,3 k-SMD-Widerstand zwischen Pin 1 und Pin 2 von JP1 gelötet. So spare ich mir den Jumper, der normalerweise auf JP1 1-2 sitzt...

Gruß

Thomas

Zitat von 2ee

Poste doch bitte mal ein Vollbild von deinem Junior mit den SMD Tastern. Bin gespannt wie das aussieht.

Bitte sehr:

Gruß

Thomas

Hallo zusammen,

nach ein paar Wochen Abstinenz im Computer-Basteln habe ich in der letzten Woche mir einen zweiten Junior 2 auf der aktuellen PCB-Version gebaut, diesmal mit kleinen SMD-Tastern. Nach dem ersten Einschalten leuchtete zwar wie erwartet das Display und zeigte plausible Hex-Werte an, jedoch nahm der Junior 2 keinerlei Tastenbefehle entgegen.

Spoiler: Wie sich herausstellte, lag der Fehler im Platinendesign! Ich bin damit wohl der erste, bzw. der einzige, der SMD-Taster verwendet hat. Ansonsten wären hier bestimmt schon mehr Fehlermeldungen. Aber der Reihe nach...

Fehlersuche war also angesagt...

Die beiden Tasten, die zum 556 gehen, funktionierten. Die NMI-Taste ließ die CPU (ohne initialisierten NMI-Vektor) abstürzen und beendete das Multiplexen des Displays, die RST-Taste holte den Rechner wieder ins Leben zurück und das Display sah wieder normal aus. Weitere Tasten funktionierten jedoch zu keinem Zeitpunkt.

Als ersten Schritt habe ich erstmal alle ICs von meinem ersten Junior 2 eingesetzt, in der Hoffnung, dass ein Chip auf der neuen Platine vielleicht fehlerhaft sei. Mit den neuen Chips eingeschaltet: Gleiches Resultat, keine Tasteneingaben möglich...

Hmmm, erstmal rausbekommen, auf welcher Seite des RIOT denn der Fehler liegt. Ist es die Display- und Tastaturmatrix mit dem 74145 und dem ULN2003 oder arbeitet der CPU-Teil vielleicht nicht korrekt? Vielleicht arbeitet das RAM auch fehlerhaft und erzeugt dieses Fehlerbild...

Um einen Fehler im CPU-Teil auszuschließen, habe ich eine halbfertige Version meines XLink-Adapters angeschlossen und den Junior 2 wieder gestartet. Und mit dem Adapter war ein Beschreiben und Lesen des JC2-Speichers problemlos möglich. Ich konnte auch die gerade im Display angezeigte RAM-Adresse mit neuen Werten befüllen und das Ändern des RAM-Inhalts im Display verfolgen. Für mich war also klar: Der CPU-Teil ist in Ordnung und ich verlagerte die Suche auf die Port-Seite des RIOT in den Tastatur-Teil.

Ich habe daraufhin die Leitungen der Tastaturmatrix ohmsch durchgeklingelt und festgestellt, dass die Taste 5 dauerhaft Durchgang hat. Oha, sollte eine fehlerhafte SMD-Taste den Fehler verursachen? Also fix die Taste ausgelötet und nochmal im ausgebauten Zustand durchgemessen: Diesmal alles okay, Taste arbeitet einwandfrei. Nanu? Den Junior 2 ohne die Taste 5 eingeschaltet und getestet: Auch hier war jetzt alles okay soweit...

Aber wieso hatte die Taste dann im eingelöteten Zustand Durchgang? Ein Blick auf die Platine bringt Klarheit:

Dazu zuerst ein paar Hinweise zum Aufbau der SMD-Taster: Diese haben vier Anschlüsse, von denen jeweils zwei immer miteinander verbunden sind. Im Bild wären das jeweils die beiden Anschlüsse auf der rechten und linken Seite. Ein Tastendruck verbindet nun diese beiden Seiten miteinander.

Wenn man sich die Platine nun genau anschaut, dann geht die Leiterbahn von rechts oben kommend zwar auf den Anschluss links unten, aber auch der Anschluss rechts oben wird durchfahren und verbindet die Anschlüsse rechts oben mit links unten!

Wird jetzt ein Taster eingelötet, dann besteht folgende Verbindung: Linke Seite, Anschluss links unten, über die Leiterbahn auf den Anschluss rechts oben, von dort intern im Taster auf den Anschluss rechts unten. Damit sieht es dann für den Junior 2 so aus, als wenn die Taste dauernd gedrückt wäre...

Wieso geht die Leiterbahn überhaupt durch das Pad oben rechts? Wurden nicht alle Pads des Taster-Footprints mit Namen versehen? Wurde kein Design Rule Check gemacht, welcher die Abstände bemängelt hätte?

Wie kommt man nun am schnellsten raus aus der Misere?

Ich habe einfach den Anschluss oben rechts vom Taster abgeschnitten und den neuen Taster (ich bin beim Auslöten nicht zimperlich gewesen...) mit nur drei Anschlüssen befestigt.

Nicht schön, aber funktionell...

In einer überarbeiteten Version der Platine sollte mindestens bei dieser Leiterbahn auf ausreichend Abstand geachtet werden. Nein, bei jeder Leiterbahn sollte auf ausreichend Abstand geachtet werden. Aber dafür ist der DRC im Layout-Programm da, den man gerne mit etwas größeren Werten (so ab 0,4 mm aufwärts) versehen kann und darf...

Ansonsten sind diese Tasten eine ganz nette Alternative, wie ich finde.

Randnotiz: Im Hintergrund des ersten Bildes kann man auch die LED-Anzeigen sehen. Reichelt hat mir diesmal für den Typ 'SC 52-11 RT' zwei unterschiedliche Typen mit unterschiedlichen Helligkeiten geliefert. Normalerweise wird der Typ "SC52-11SRWA" geliefert, diesmal waren im Beutel aber ein paar "SC52-11SURKWA" (und ich habe es bei Einlöten nicht gemerkt). Die noch eingelötete SURKWA-Anzeige ist so dermaßen verdammt hell, ideal wenn man Filterscheiben verwenden will. Die kommt zwar hier auf dieser Platine wieder raus, aber ich glaube das wird mein neuer Vorzugstyp...

Gruß

Thomas

Zitat von 286Micha

3. meine WDC W65C02 (Fake?)

Zitat von 286Micha

Dann habe ich eine W65C02 (von WDC) getestet.. -> die klappt GARNICHT..

Die CPU ist bestimmt kein Fake und es wundert mich auch nicht, dass ein einfaches Ersetzen der CPU nicht funktioniert.

Ich meine mich zu erinnern, dass A) ein paar Pins (leicht) unterschiedlich verwendet wurden und B) das Timing der Phi-Signale leicht anders ist. Deswegen hatte ich auf meiner Forum64-FinalChessCard mit gewissen RAMs Probleme bei der Ansteuerung gehabt.

Hier sind ein paar Änderungen beschrieben: Klick mich...

Gruß

Thomas

Zitat von 2ee

Ich wüsste gerne, ob Freak auch solche Probleme beim Laden des Basics hat. Er hat ja auch eine Rev. 3B Platine wie Michael.

Auch wenn ich etwas spät dran bin und der Fehler schon gefunden wurde:

Ich habe das Basic noch nicht ein einziges Mal geladen, sorry.

Aber ich bin so mit meinem Projekt beschäftigt und dann habe ich ja jetzt auch noch zwei weitere Platinen, die bestückt werden wollen, dass ich da einfach noch nicht zu kam...

Gruß

Thomas

Falls Du ein digitales Zweikanal-Scope verwendest, kannst Du ja mal folgendes ausprobieren:

Kanal 1 wird mit der Reset-Leitung verbunden,

Kanal 2 wird mit der A0-Adressleitung verbunden.

Getriggert wird auf eine High-Flanke von Kanal 1, also wenn Reset wieder High wird. Und zwar dann im Single-Shot-Mode.

Dann sollten eigentlich auf der Adressleitung ein paar Pulse zu sehen sein. Nämlich wenn der 6502 sich den Reset-Vektor holt und wenn er dann ab der Reset-Adresse mit dem Lesen der Op-Codes beginnt...

Gruß

Thomas

Zitat von ralf02

An Pins 9-25 der 6502 haben die Signale nur ca. 100mV - mit "Spikes" ca. 200mV. Ist das normal ?

Nein. Das sind die Adressleitungen, die sollten fleißig vor sich hinflackern. Mindestens die mit den kleinen Pin-Nummern (in Richtung A0).

Vielleicht klappt die Adressdekodierung mit den TTL-Bausteinen nicht und die CPU stürzt unmittelbar nach Lesen des Reset-Vektors ab, da durch falsche Adress-Dekodierung nichts Sinnvolles gelesen wird.

ThoralfAsmussen Erst einmal vielen Dank für die konstruktive Kritik!

Zitat von ThoralfAsmussen

Das Video ist für sowas doch auch OK geworden. Mein einziger "Kritikpunkt" wäre, daß man, wenn man eine Videobearbeitung nutzt oder wenigstens was Überlagern kann, evtl. noch ein großer grüner Pfeil auf den Wechsel von F5 auf 4C im Display hinweisen könnte, indem er von z.B. min 4:00 bis 4:10 auf das DATA Display zeigt. (Das ist sowas, was nur jemand sieht, der erwartet und weiß, wo er jetzt eine Veränderung sehen müßte. Viele andere Leute werden da gar keine Veränderung sehen, weil sie rechts im Bild schauen. Das angesprochenes Publikum sollte aber eigentlich wissen, was gemeint ist. Es ist halt nur, wenn Du z.B. willst, daß Zufallsgucker nicht sofort abgeschreckt werden.)

Ja, das ist mir später auch aufgefallen. Allerdings eher auf der rechten Seite, bei den Rückmeldungen, die das Client-Programm ausgibt (z.B. bei PEEK). Da wäre ein kleiner grüner/gelber/roter Kreis/Pfeil bestimmt hilfreich gewesen. Aber dann nochmal neu hochladen wollte ich das Video dann auch nicht.

"Viele andere Leute" wie du schreibst schauen sich das ja gar nicht erst an. Es ist halt etwas zu speziell für eine breite Masse... Und dann kam dazu, dass ich es an diesem Wochenende auch "unbedingt" abgearbeitet haben wollte, weil ich es schon ein paar Wochen vor mir hergeschoben hatte.

Falls aber wieder was von mir in dieser Richtung kommt (was ich nicht ausschließen möchte), dann werde ich auf Änderungen optisch hinweisen...

Zitat von ThoralfAsmussen

Das Tempo ist sicherlich ein wichtiger Punkt - 10 kByte/Sekunde (min 9:20) ist natürlich erschreckend nach heutigen Maßstäben.

Vielleicht geht da ja noch was. 6 Sekunden für einen Volltransfer ist für reines Laden sicher OK, für andere Sachen aber vielleicht noch optimierbar (s.u.).

Kurzer technischer Exkurs: Die Datenübertragung über USB passiert in den Control-Transfers. Von denen gibt es 1000 Stück pro Sekunde (jede Millisekunde ein Transfer). Und in jedem Transfer werden 64 Bytes übertragen. Also "eigentlich" sollten 64KByte innerhalb einer Sekunde drüben sein...

Warum das nicht so ist? Das weiß ich nicht genau. Ich schiebe die Langsamkeit auf die USB-Library, die Henning damals bei der Entwicklung verwendet hat...

Zitat von ThoralfAsmussen

Beim "jump" Befehl könnte amn evtl. über die Namensgebung nachdenken. "run" oder "go" z.B.

Bei "peek" und "poke" werden die Adressen direkt hinter dem Befehl angenommen, was schön so ist (wie man es allgemein erwarten würde (müßte ja nicht so sein)). Allerdings ist es dann ein wenig inkonsequent / inkonsistent, daß man bei "load" die Adresse explizit mit "-a" einleiten muß. Vielleicht wäre es hier auch schöner, wenn da die Adresse einfach als zweiter Parameter erwartet wird. Alle anderen Sachen, etwa load Befehle mit fixer Ladeadresse, lassen sich dann daraus einfach ableiten, prinzipiell sogar als Shell Kommando, aber natürlich auch Programmintern, indem der Fixpunkt dann mit dazu gesetzt wird - etwa als "loadfix" = "load 0x4000")

Generell könnte man darüber sinnieren, ob es evtl. Sinn machen könnte, die Adressen generell als Hexadressen zu erwarten. Da müßte man evtl. mal eine Umfrage starten, was wahrscheinlich erst mit echten Usern brauchbare Ergebnisse bringt. "poke 4000 23" macht sich besser als "poke 0x4000 0x23" zu tippen - auch wenn es aus Programmierersicht wahrscheinlich sehr gut und definiert aussieht. Evtl. ist auch besser, daß so wie hier zu lassen, also dezimal als Standard und 0x für Hex, dafür aber noch "heek" und "hoke" für Hex als Extrakommandos einzuführen.

Weiteres interessantes Extrakommando wäre evtl. "poke+" und "peek+", was einen Counter beginnend vom letzten "poke" / "peek" Befehl benutzt und diesen jeweils um einen Wert hochzählt. Analog dazu "poke-" und "peek-".

Was ich als sehr interessant erachten würde, wäre sowas wie ein "Block-poke", z.B. als "poke256". Analog dazu ein "peek256". Die sollten genauso wie die normalen poke/peek funktionieren, aber gleich an einem Stück 256 Byte auf einmal holen/schicken.

Ich weiß nicht, ob jemand dann sowas nutzt, aber es würde sehr einfach die Möglichkeit eröffnen den RAM "seitenweise" ein/auszulesen. Damit ließen sich so Sachen machen, wie Stacks auslagern etc. - das ist dann aber schon der Punkt, wo der Speed auch bißchen höher sein muß.

Alles anzeigen

In deinem Kommentar sind ein paar interessante Ideen drin. Bei der Eingabe von Adressen oder Werten stimme ich allerdings nicht mit dir überein, immer Hexwerte zu verwenden. Ich persönlich vermisse beispielsweise ein $-Zeichen für Hexwerte, Binärwerte wären neben Dezimalwerten auch ganz nett.

Aber da kommen wir schon zum Hauptproblem:

Ich bin ein Hardware-Mensch. Und Assemblerprogrammierung kenne ich auch. Wenn es allerdings darum geht, den Quelltext des Konsolen-Programms zu erweitern oder anzupassen, dann muss ich leider passen. Das können andere bestimmt wesentlich besser als ich. Da kenne ich meine Grenzen...

Es gäbe beim Konsolen-Programm nämlich weitaus mehr anzupassen: Das ganze Projekt war ursprünglich nur für den C64 und C128 von Commodore gedacht und das Konsolen-Programm (und der zugehörige 6502-Kernal) können auch nur zwischen diesen beiden Rechnern unterscheiden (Es gibt auch nur ein Bit, welches den Rechner-Typ überträgt). Ich habe XLink aber inzwischen auch auf einem VC20 laufen und jetzt kommt der Junior Computer II dazu. Eine Byte-Variable wäre da durchaus hilfreicher. Auch gibt es noch eine Reihe weiterer Befehle, die ich im Video gar nicht erwähnt habe: Z.B einen Benchmark-Befehl. Dieser holt sich aus der "Rechner-Typ"-Variablen die Info, welchen Bereich vom Ziel-System es für den Benchmark-Test beschreiben darf. So direkt ist dieser Befehl also nach jetzigem Stand gar nicht lauffähig. Oder der Identify-Befehl, der den Typ des Ziel-Systems ausgibt. Bis jetzt steht dort nur immer C64 oder C128...

Mit der Erweiterung des Konsolen-Programms könnte man sich also gut beschäftigen und das Projekt etwas nach vorne bringen. Henning selbst ist hierfür wohl nicht mehr zu gewinnen. Drüben im Forum64 war er schon fast ein Jahr nicht mehr online... Aber die Quellen sind ja alle verfügbar...

Ich lebe also mit dem Konsolen-Programm, so wie es ist. Und ich versuche trotzdem, die Hardware anzupassen. Auch wenn ich schon im Vorwege weiß, dass man auf der Software-Seite noch einiges mehr machen könnte und es nicht perfekt wird. Aber es ist nutzbar und es hilft beim Cross-Development...

Gruß

Thomas

Zitat von ralf02

ich habe mir jetzt auch einen Junior Computer ][ (Rev. 3b/2022) zusammengelötet, aber das einzige was bei dem Rechner leuchtet, ist die rote LED in der GO-Taste, wenn STEP=ON. Sollten die 7-Segment-Anzeigen nicht etwas anzeigen, wenn man RS drückt ? Bei mir bleiben sie leider dunkel (Display-Schalter natürlich ON). Hier mein Aufbau:

Die LED in der GO-Taste ist einfach über einen Widerstand und den STEP-Schalter an die Spannungsversorgung angeschlossen. Das ist keine große Kunst die leuchten zu lassen...

Und ja, nach Drücken von RS sollten die 7-Segment-Anzeigen ein paar Ziffern darstellen.

Für mich sieht der Aufbau erst einmal okay aus. Deshalb kann ich da nur durch ein paar Fragen weiterhelfen:

A) Die Reset-Leitung prüfen (Pin 40 der CPU). Beim Drücken der RS-Taste soll der Pin auf Low gehen, nach Loslassen der Taste auf High wechseln...

B) Das EProm. Man kann leider den Typ nicht erkennen, aber falls du hier ein 27C512 verwendest, dann sollte (da bei dir der Lötjumper JP3 gebrückt ist) das Kernal-Image in der oberen Hälfte liegen.

Gruß

Thomas

Ohne (programmiertes) Eprom wird sich da nicht viel tun...

Hallo,

ich hatte vor einiger Zeit hier im Thread ja schon einmal angedeutet, dass ich einen eigenen Weg zur Datenübertragung vom PC zum Junior Computer II gehe, indem ich ein XLink-Modul mit dem Junior Computer II verbinde.

Ich bin inzwischen soweit, dass meine Anpassung (bzw. meine ca. 500 Bytes lange Erweiterung) des Monitor-Programms vom Junior Computer II stabil läuft und ich Daten zuverlässig zwischen PC und Junior Computer II austauschen kann.

Allerdings lässt sich das mit einfachen Bildern hier im Thread nicht wirklich gut zeigen. Deswegen habe ich mir in den letzten Tagen eine kleine Präsentation ausgedacht und diese mit meinen begrenzten Möglichkeiten (sowohl von der Technik als auch von meinen Präsentationsfähigkeiten her) am PC aufgenommen. Das Material habe ich heute geschnitten und auf Youtube hochgeladen. Ich denke, mittels des Videos lassen sich die Möglichkeiten der XLink-Anbindung an den Junior Computer II wesentlich besser darstellen.

Die Präsentation findet ihr hier: Klick mich... (Seid aber bitte etwas nachsichtig. Ich bin absolut kein Profi-Youtuber oder Profi-Sprecher...)

Was haltet ihr davon? Kommentare sind willkommen...

Gruß

Thomas

Zitat von NorbertJ

Anm: Vielleicht ein Relais-Problem?

Bleibt vielleicht das Reed-Relais im eingeschaltetem Zustand kleben, vielleicht durch einen zu hohen Strom vom Motor?

Ich würde mal die Spannung am Motor-Pin mit angesteckter Datasette messen und danach mal ohne angestecktem Gerät. Beides Mal sollten ja (wenn die LED aus ist) die 6V wieder weg sein...

Gruß

Thomas

Zitat von 286Micha

daher finde ich Version1 besser,.. da man auch ohne "Vor-Ahnung", JC II erkennen kann

Dem schließe ich mich an...

Dann ist das evtl. die Paste auf den Pads, die du siehst... (wegen SMD-Bauteil). Schau mal, ob der Pasten-Layer an ist...

Achso, dieses "Problem"...

Gucke dir mal den Footprint an und nehme bei den Pads bei den verwendeten "Technischen Lagen" den Silkscreen-Layer "F.SilkS" raus, Der ist wahrscheinlich aktiv...

Zitat von 2ee

Muss ich bei den SMD Bauteilen noch irgendwas einstellen, bzgl. der Lötstoppmaske? Irgendwie sieht das im PCB Editor so aus, als ob die Lötflächen garnicht frei gestellt sind, oder scheint das nur so? Werd das mal recherchieren.

Kann ich dir ohne weitere Infos so nicht beantworten. Du könntest ja aber mal mit "Alt-3" dir die 3D-Ansicht anschauen (in der man auch die Bauteile ausblenden kann). Dann kann man schon relativ sicher sehen, ob die Pads mit Stopplack bedeckt sind. Ansonsten sieht man es auch sicher im Gerber-Viewer...

Nebenbei: In der 3D-Ansicht kann man auch vorhandene oder fehlende Durchkontaktierungen erkennen...

Gruß

Thomas

Zitat von 2ee

Da Thomas alias DL8EBD mich jetzt nach einer Junior Platine gefragt hat, musste ich dann doch mal die von Freak angeregten Änderungen am Platinenlayout vornehmen.

Ich hab jetzt zunächst mal die Schraubbohrungen ebenfalls auf 4,2mm reduziert und auch hier bei der Mittelbohrung alle Leiterbahnen großzügiger drum herum geführt.

Der Ein-/Ausschalter ist jetzt ein wenig weiter vom Platinenrand weggerutscht.

Das ROM hat jetzt einen zusätzlichen Jumper Namens ROM_BANK_SEL, mit dem bei eingesetzten 32K (E)EPROM A14 auf Masse gezogen werden kann. Somit sind dann, für jeden der es haben möchte, zwei wählbare ROM Versionen möglich.

Klasse! Da kribbelt es mir in den Finger, ja direkt die nächste Version zu bauen... (Obwohl ich gerade die Marquardt-Taster eingelötet habe und sie wieder auslöten würde...)

Zitat von 2ee

Ebenfalls noch nicht drin (eventuell hab ich ja heute Nacht noch Zeit und Lust), sind die vorgeschlagenen, alternativen SMD Schalter. Die werden aber sicherlich in nächster Zeit von mir implementiert, da ich die Idee doch recht gut finde.

Oh, dann warte ich doch noch...

Zitat von 2ee

Ausserdem sind die Bohrungen der beiden Kippschalter immer noch als durchkontaktierte Bohrung gestaltet. Hintergrund: Ich hatte die Footprints für die Schalter selber gemacht, und im Footprint Editor gibt es irgendwie nur Pads, welche dann halt durchkontaktiert sind. Wie man das in KiCAD ändern kann weiß ich jetzt leider nicht. Das es gehen muss ist klar, schließlich gibt es ja auch den Footprint "Mounting_Hole". Vielleicht bekomme ich da ja noch rechtzeitig von Freak oder jemand anderen einen Tipp, ansonsten landen die neuen Gerber Files dann ab morgen bei mir im Download Ordner.

Du arbeitest mit KiCAD 5.irgendwas? Dann versuche mal folgendes: (Pad anklicken und dann "e" für "Editieren" drücken)

Die Bohrlochgröße natürlich entsprechend anpassen (beide Felder "Größe X" und "Lochgröße X" sollten den gleichen Wert haben).

Gruß

Thomas

Die Platine gefällt mir sehr gut!

Zitat von 2ee

Es sieht zwar immer ganz schick aus, ist aber bei den Masse Pins schwerer zu löten und wahrscheinlich für Lötanfänger eine Herausforderung.

Wenn man in KiCAD die "thermische Anbindung" wählt, dann werden die Pins mittels vier (in der Breite und Länge) definierbare Leiterbahnstücke angebunden. Wenn man es nicht gerade mit einem 15W Lötkolben versucht, dann ist das auch nicht schwerer zu löten...

Zitat von 2ee

Die VIAs haben jetzt eine Bohrung von 0,5mm bei einem Durchmesser von 0,8mm. Das ist meines Erachtens nach das Maximum dessen, was ich bei der Leiterbahndicke nehmen sollte. Aber vielleicht hat Thomas da ja doch einen besseren Vorschlag.

Ich denke, das geht schon in Ordnung. Ich habe vor ein paar Tagen eine kleine Adapterplatine (*) in Auftrag gegeben, da habe ich auch 0,8mm Durchmesser gewählt, allerdings mit einer 0,4mm Bohrung. So habe ich einen Restring von 0,2mm Stärke. Aber deine 0,15mm Restring finde ich auch okay. Das hängt auch immer vom Fertiger ab, wie genau die Bohrung in der Mitte des VIAs liegt. Bei einem zu kleinen Restring kann dann die Bohrung schon mal "halb außerhalb" des VIAs liegen...

(*) Apropos "Kleine Adapterplatine": Ich bin nicht nur ein stiller Mitleser. Insgeheim bastel ich auch ein wenig...

Eine kleine Platine mit einem 6522, simuliert in etwa einen C64/VC20-Userport, damit ich mein XLink-Modul einfach anschließen kann und dann die Firmware des Juniors anpassen kann. Wahrscheinlich wegen Platzproblemen unter Entfernung des eingebauten Editors und Assemblers. Nutzt das irgendwer? Ich denke nicht... Soll aber nur eine Übergangslösung sein, später sollte das eine "Plug'n'Play"-Lösung werden... Aber erstmal reicht diese Variante...

Funktioniert bloss nicht mehr, wenn man den Junior II später mit deinem Expansion-Board verbindet, denn dann kann ich mein Modul nicht mehr anschließen. Ideal wäre ja die Verwendung von Port B des 6522 auf deiner Platine, allerdings brauche ich für die Kommunikation neben PB0 bis PB7 auch CB1, CB2 und die Reset-Leitung (sowie GND und 5V). Dann könnte man später ggf. ein kleines Modul mittels Flachbandkabel an Port B anklemmen...

Naja, noch sind die Platinen nicht einmal angekommen und Reichelt hat meine vor Wochen bestellten Marquardt-Taster immer noch nicht geliefert...

Gruß

Thomas

PS: Ach was, einfach frech mal was wünschen: Ich wünsche mir auf J4 einen Pin 15 mit /Reset (und Pin 16 frei). Das könnte man ja nur auf der Platine ausführen und könnte das Bauteil J4 weiterhin 14-polig lassen... Ich würde dann einen 16-poligen Pin-Header einlöten und würde mir einen Draht zum Anklemmen an die Reset-Leitung sparen...

Zitat von 2ee

Eventuell kann mir Thomas da ja eine Alternative aufzeigen.

Leider nein. Ich route ausschließlich selbst, ohne Autorouter.

Und noch einen Nachtrag zu meinen Verbesserungsvorschlägen:

Von dem 74LS01 werden bei dir 3 Gatter verwendet, beim Original Junior werden zwei Gatter verwendet. Das Layout des Original-Junior hat die Eingänge der unbenutzten Gatter mit GND verbunden. Das ist merkwürdigerweise nicht im Schaltplan zu erkennen, nur beim Verfolgen der Leiterbahnen auf der Platine.

Schaltungstechnisch gesehen ist das auch richtig so. Zwar bei LS-Schaltkreisen nicht zwingend notwendig (da sie mittels internem Pullup auf log. 1 gezogen werden), aber guter Stil...

Du hast bei deinem Junior II drei Gatter vom 74LS01 verwendet. Das vierte Gatter hängt jedoch vollständig in der Luft.

Es wäre guter Stil, das vierte Gatter (sofern nicht verwendet) bei der nächsten Revision ebenfalls eingangsseitig auf GND (oder 5V) zu legen...

Gruß

Thomas

Zitat von 2ee

Z.B. bekommt bei diesem Schaltplan das Laufwerk über Anschluss 3 (BLUE) nicht den Motorstrom (also die 6V Spannungsversorgung) vom Rechner, sondern offensichtlich Masse geliefert. Die liegt dann über den Schalter SW2 am Motor und an Anschluss 6 (Cass Sense). Der Motor selber wird über die 5V Leitung (Anschluss 2) versorgt. Hier hatte man wohl bemerkt, dass der Motor auch mit 5V gut läuft.

Aber in der original Datasette für den C64 war Cass Sense wohl einfach auf Masse geschaltet, wenn SW2 geschlossen wurde. Im C64 hing die Leitung dann noch mit einem Pull Up Widerstand über +5V eben am CPU Port 4.

Nee, nee, nicht ganz so schnell...

Der Anschluss 3 vom Datasetten-Schaltplan geht auf die geschaltete Seite vom "PLAY SW" (die anderen Seite ist fest auf GND). Daraus folgt, dass dieser Anschluss auf den Sense-Eingang am Computer (und damit auf einen Eingang) geht.

Der Anschluss 2 vom Datasetten-Schaltplan ist die positive Motorseite (andere Seite ist fest mit GND verbunden) und bekommt vom Computer IMMER ca. 6V, egal ob C64, C16, Plus4 oder VC20. Ich habe mir gerade nochmal die Schaltpläne der einzelnen Rechner angesehen, da gibt keiner nur 5V raus. Das war Commodore wohl zu unsicher...

Zitat von 2ee

Du siehst also, vieles war einfach das Werk von Unwissenheit (KiCAD) und schlichter Faulheit. Daher Danke für die vielen Vorschläge, die ich beim nächsten mal sicherlich beherzige. Aber ich weiss ja jetzt, an wen ich mich da für ein Review wenden kann.

Die Unwissenheit sei verziehen, die zweite erstellte Platine in KiCAD kann nicht perfekt sein... Ich habe vor einigen Jahren von Eagle zu KiCAD gewechselt, weil ich für eine große Platine die notwendige Lizenz nicht bezahlen wollte (irgendwas vierstelliges wollten die damals dafür haben). Ich habe mir gesagt, das investiere ich lieber in Elektronikbauteile... Ich habe dann mich wirklich intensiv mehrere Monate mit KiCAD beschäftigt. Zuerst ist der Workflow noch gewöhnungsbedürftig, aber wenn man dann auch ein paar Tricks kennt, kann man super mit dem Programm arbeiten...

Du kannst dich gerne für ein Review an mich wenden, das Angebot steht. Ich könnte auch die eine oder andere kleinere Aufgabe hier übernehmen. Beispielsweise würde ich für eine Bestückungsmöglichkeit mit alternativen Tastern nicht nochmal 23 Taster in den Schaltplan zeichnen, sondern den einfach so lassen, wie er ist. Man könnte dann relativ einfach den Footprint des Tasters mit den zusätzlichen Pads versehen. So wird der Schaltplan dann nicht so unübersichtlich...

Zitat von 2ee

Was ich auf der nächsten Revision noch drauf machen würde, wäre ein 2 zu 1 Decoder, um bei Anschluss des ESP32 Terminals automatisch den Max232 von TxD und RxD zu "entkoppeln". Den muss man nämlich zur Zeit dann immer rausziehen, um einen Kurzschluss zu vermeiden.

Das ESP32-Terminal ist bis jetzt noch an mir vorbeigegangen, das werde ich mir mal anschauen...

Ich denke aber nebenbei auch über eine Möglichkeit nach, den Junior "automatisiert" mit Programmen zu beschicken, um Softwareentwicklung zu vereinfachen. Ich habe da eine USB-Transfer-Lösung für den C64 im Hinterkopf: XLink von Henning Liebenau. Geänderte Firmware für dem Junior (deswegen einen Jumper für die Kernal-Auswahl) und ein Kommandozeilenprogramm auf dem PC. Quelltext auf dem PC schreiben, assemblieren und dann mit einem Befehl zum Junior schicken und automatisch dort starten. Ich finde die Idee ganz sexy, da sie sehr schnelle Turnaround-Zeiten zulässt. Assemblieren und Übertragen zusammen in unter zwei Sekunden (je nach PC)...

Wie bekommt ihr ansonsten Programme auf den Junior? Nur über den PM mittels XModem?

Gruß

Thomas

Zitat von 2ee

Kurz: Ja! Vorschläge erwünscht. Immer! Und beim Board Layout kann man immer was verbessern.

Okay, dann lege ich mal mit meinen Vorschlägen los. Bitte verstehe sie nicht als Kritik!

Folgende Verbesserungen für eine Überarbeitung des Layouts möchte ich vorschlagen:

Vorschlag A) Befestigungslöcher von 5,3 mm auch 4,2 mm reduzieren.

Begründung: Abstandshalter für M5 sind sehr schwer zu bekommen. Abstandshalter für M4 gibt es z.B. bei Reichelt für kleines Geld (DI4 20MM) und derart massiv müssen die Abstandshalter meiner Meinung nach gar nicht sein.

Vorschlag B) Mittleres Befestigungsloch: Leiterbahnen in einer größeren Entfernung zum mittleren Befestigungsloch verlegen.

Begründung: Auf beiden Seiten der Platine gehen Leiterbahnen derart dicht am mittleren Befestigungsloch vorbei, so dass ein Schraubenkopf (auf der Oberseite) oder der Abstandshalter (auf der Unterseite) bei beschädigtem Lötstopplack leicht eine Verbindung zu diesen Leiterbahnen haben kann. Deshalb wäre mein Vorschlag, um alle Befestigungslöcher eine "Restricted"-Zone zu haben, in der keine Leiterbahnen verlaufen (von der Größe eines Schraubenkopfes oder etwas größer...).

Vorschlag C) Die Löcher für die Schalter "Display" und "Step" auf "nicht durchkontaktiert" ändern.

Begründung: Die Löcher sind zur Zeit als großes Lötpad ausgeführt, inklusive einer Metallisierung der Bohrung zwecks Durchkontaktierung. Dies ist hier jedoch nicht notwendig. Deshalb könnten diese Löcher als "Non-Plated-Through-Holes" ausgeführt werden.

Vorschlag D) Copper-Pouring auf der Unterseite.

Begründung: Nicht zwingend notwendig, jedoch muss dann nicht so viel Kupfer weggeätzt werden. Neben leichten elektrischen Vorteilen also eher ein kleiner positiver Umweltaspekt...

Vorschlag E) Den Hauptschalter etwas von Rand wegrücken.

Begründung: Wenn man für den Hauptschalter die zweipolige Version mit 5,08 mm Pinabstand einsetzen möchte, dann steht dieser derzeit leicht über die Platine über. Wenn man den Schalter leicht vom Rand wegrückt, dann befindet sich der Schalter vollständig auf der Platine.

Vorschlag F) Den 25-poligen SubD-Stecker etwas von Rand wegrücken.

Begründung: Auch wenn man die schon etwas kürzere EU-Version verwendet (wie in deiner Anleitung vorgeschlagen), so steht der SubD-Stecker derzeit noch ca. 1 mm über den Rand raus und schließt nicht bündig mit der Platine ab. Ein leichtes Verrücken weg vom Platinenrand würde dazu führen, dass der SubD-Stecker vollständig auf der Platine aufliegt. Die genauen Abstände stehen meiner Meinung nach im Datenblatt.

Vorschlag G) Jumper für die oberen beiden Adressleitungen des ROMs

Begründung: Zur Zeit sind beide Adressleitungen fest mit 5V verbunden und lassen so 3/4 des ROMs ungenutzt. Mit Jumpern (und zwei Pullup-Widerständen) hätte man die Möglichkeit, verschiedene ROMs manuell einblenden zu können, falls man z.B. selbst an der Firmware was ändern möchte.

Vorschlag H) Eigentlich nur eine fixe Idee: Zusätzliche Lötpads für kleine SMD-Taster als Ersatz/Provisorium zu den Marquardt-Tastern.

Begründung: Zur Zeit sind die vorgesehenen Marquardt-Taster nicht überall zu bekommen. Mein Vorschlag wären Lötpads (oder vielleicht zusätzliche Bohrungen, müsste man mal ausprobieren) auf den Tasterflächen, auf denen sich kleine billige 6mm-SMD-Taster (Reichelt: TASTER 9315) löten lassen. Diese kann man dann leicht wieder entfernen, sobald man über die Marquardt-Taster verfügt. Und auch wenn dann ein paar Lötreste auf der Platine verbleiben, sieht man diese später nicht, da sie dann durch die großen Taster verdeckt werden. Mit kleinen Tastern hätten die Beschriftungen auf der Platine dann auch eine Verwendung...

Vorschlag J) Das Routing generell überarbeiten.

Begründung: Ich glaube, du hast teilweise beim Routing die Leiterbahnführung KiCAD überlassen. So sind viele Stellen vorhanden, wo Leiterbahnen nicht direkt von einem IC weggehen, sondern erst nochmal ein Stück in Richtung des benachbarten Pins. Da könnte man das Layout verbessern. Ebenso würde ich das Routing bei den Kondensatoren beispielsweise nahe U5, U6, U7 und U8 so ändern, dass diese Kondensatoren im Pfad zu den VCC-Pins der einzelnen ICs liegen. Im Moment sind alle VCC-Pins der ICs miteinander verbunden und die Kondensatoren nur "in der Nähe" angeschlossen. Das Routing sollte aber so aussehen: VCC-Pfad -> Pluspol einzelner Elko -> direkt zum VCC-Pin eines einzelnen ICs. Das sind nur zwei Beispiele, wo ich beim Routing Potenzial zur Verbesserung sehe. Generell sollten meiner Meinung nach auch die VIAs etwas größer sein und die Leiterbahnen nicht so viele Knicks haben. Ich glaube aber, das liegt an der KiCAD-Unterstützung im manuellen Routing-Modus...

Ich verstehe, das du den Schaltplan 1:1 vom Original übernommen hast. Dort waren an vielen Stellen die 1 µF-Elkos als Abblockkondensatoren vorgesehen. Das war damals auch aufgrund der damaligen Stromversorgung okay. Damals hatte man einfach eine Vollgleichrichtung mit Ladeelko und Linearregler. Da waren die Störungen im "niederfrequenten" Bereich. Heutzutage sind überall Schaltnetzteile, die ein größeres Störspektrum aussenden und weswegen man für die höheren Frequenzen dann kleinere Kapazitäten verwendet. Ich habe in meinen Nachbau - dort wo es möglich war - gedrehte Fassungen mit eingebautem 100 nF-C eingesetzt. Nicht falsch verstehen. Das Design ist so rubust, dass es natürlich auch ohne geht. Aber konsequenterweise müsste man den Junior II auch mit dem entsprechenden Retro-Netzteil versorgen...

Bitte obiges nicht als Kritik verstehen. Wie ich im vorherigen Posting schon schrieb, würde ich da gerne unterstützen, falls bei dem einen oder anderen Punkt Konsens besteht.

Gruß

Thomas

Zitat von ThoralfAsmussen

Ich wollte ja auch nochmal nachschauen, wo genau das mit den 6V für die Datasette überhaupt herkommt ??

Ich hab's direkt aus einem C64-Schaltplan...

Ausgangsspannung an Pin "C,3" ist hierbei die 6,8V der Zenerdiode abzüglich der Spannung, die über der Basis-Emitter-Diode von Q1 abfällt. Also so überschlagsmäßig sind das denn 6V.

Ich hätte hier auf die Schnelle einen kleinen Verbesserungsvorschlag für die IO-ROM-CARD:

Der Jumper JP4 (Language Select) sollte besser nur zweipolig ausgeführt werden. Und zwar folgendermaßen: Pin 1 von U8 über ein 10k-Widerstand gegen Vcc, Pin 1 über einen Jumper gegen GND. Bei der jetzigen Ausführung besteht nämlich die Gefahr, dass (wenn kein Jumper gesteckt ist) Pin 1 offen in der Luft hängt. Und unbeschaltete Eingänge sollte man bei CMOS-ICs vermeiden...

2ee : Wie denkst du generell über Anmerkungen und Verbesserungsvorschläge zu der Hauptplatine? Ist die Entwicklung für dich mit dieser Version "3b" beendet oder bestünde die Möglichkeit, Verbesserungen am Layout vorzuschlagen (keine neuen Funktionalitäten)? Ich könnte da auch gerne unterstützen...

Gruß

Thomas

Zitat von 2ee

Da ich hier noch eine Datasette rumfahren habe, dachte ich, ich könnte ja auch eventuell das Verfahren des C64 nutzen (daher auch der vorgesehene, schöne 6-pol. Platinenstecker). Deshalb hatte ich weiter oben ja bereits gefragt, ob jemand weiss, ob die Datasettenlaufwerke schon ein digital aufbereitetes Signal ausgeben, dann spart man sich nämlich etliches an analoger Elektronik. Jedenfalls bin ich diesbezüglich für Ideen und Hinweise dankbar.

Die C64-Datasette gibt am Stecker digitale Signale raus, die (so ziemlich) direkt auf Ein-/Ausgänge der I/O-Portbausteine oder auch auf den I/O-Port der CPU gehen. Von dieser Sichtweise aus gäbe es keine Probleme.

Nicht so gut sieht es mit der Versorgung der C64-Datasette aus. Neben den üblichen 5V für den Analog- und Logikteil wird das Laufwerk mit geschalteten ca. 6V für den Motor versorgt, die im C64 aus einer ungeregelten 9V-Spannung generiert werden.

Keine Ahnung, ob a) 5V für den Motor ausreichend wären und b) wie groß die Stromaufnahme des Motors ist...

Gruß

Thomas