Sorry, war ein paar Tage nicht hier drin. Ich habe mehr so gebastelt. Aber es scheint ja, dass es jetzt klappt.
Beiträge von svenpetersen1965
-
-
Alles anzeigenDas mit der niedrigen Reaktionszeit hatte ich verstanden, sage ja: Cooles Teil!
Meine Version hat (wird haben, hatte die falschen Schalter gekauft) einen Schalter,
der quasi 2 Eingänge hat, die er jeweils auf einen von drei Ausgängen schaltet.
Also zwei Ebenen, jeweils 1 auf 3. Damit schalte ich einen Oszillator (China-Teil für 1,50),
dahinter ein Inverter, weil das China-Ding am Ausgang high rausgibt, aber der C64 ja low braucht.
Keine Ahnung, ob bei Deiner Schaltung auch so ein Umschalter funktionieren würde,
aber ich als Atmega-DAU könnte mir das vorstellen.
Mein Ding hat einen Eingang und zwei Ausgänge
Alles andere ist ein anderes Ding. Ich habe noch ein paar I/O-Pins auf MicroMatch-Steckverbinder. Einen zweiten Eingang gibt das aber nicht her, weil es nur drei zusätzliche I/Os sind. Die hatte ich eher für Drehgeber oder ähnliche Gadgets gedacht. -
Was bei Spielen, wie R-Type oder Katakis leider keine gute Lösung ist, denn bei beiden muss man den Feuerknopf gedrückt halten, um den Beam aufzuladen.
Wenn ich nicht ein Layout-Programm-DAU (Eagle & Co.) wäre und mehr Zeit hätte,
würde ich mir das Projekt auf github ja ansehen und schauen, ob ich das modifizieren könnte.
Aber das wird dann genauso fertig wie meine anderen Projekte (Morsen lernen, Braille lernen,
Arduino programmieren, NAS mit OMV aufsetzen, ...).
Da gibt es auch ein auführliches PDF
Mit Stromlauf und allem Kram. Viele kommentierte Bilder vom Aufbau, Stückliste etc. -
Der Feuerknopf wird natürlich abgefragt und es wird nicht Dauerfeuer geschossen, sondern nur, wenn der Feuerknopf gedrückt wird.
Was bei Spielen, wie R-Type oder Katakis leider keine gute Lösung ist, denn bei beiden muss man den Feuerknopf gedrückt halten, um den Beam aufzuladen.
Da kann man Rapid-Fire abschalten. Dazu dient der rote Knopf
-
Alles anzeigen
So, mein Control Port Switch ist jetzt auf Github......
Du warst zu schnell.
Ich bastel auch gerade an einer Dauerfeuer-Schaltung (zwei separate, eine für jeden Port).
Bei meiner Lösung gibt es aber
-Nie Dauerfeuer
-Dauerfeuer, wenn Knopf gedrückt (wie bei Deiner Lösung)
-Immer Dauerfeuer, kann aber durch Halten des Feuerknopfes "umgangen werden". Gibt doch sicher Spiele, wo man durch langes
Drücken eine Waffe "auflädt" - jedenfalls habe ich sowas in Erinnerung.
Letzteres geht leider mit Deiner Schaltung nicht.
Da der Rest obercool ist (alleine die geile Anzeige! Ich habe nur eine LED zur Anzeige der Feuerrate)
und Du auch noch einen Port-Umschalter drin hast, wäre meine Anregung:
Meine Funktion (Halten des Feuerknopfes umgeht Dauerfeuer) und
Dauerfeuer für BEIDE Ports (wenn zwei Leute gegen-/miteinander spielen) integrieren.
DAS wäre dann das ultimative Dauerfeuer!
Und ich bräuchte meins nicht weiterbasteln.
Also, das Ding liegt bei mir seit ungefähr einem Jahr rum. Es hat immer für mich selber gereicht, und ich hatte keine Lust das Ding Github-fertig zu machen. Das Display habe ich vorgesehen, habe es aber erst in den letzten Tagen drangebastelt.
Der Feuerknopf wird natürlich abgefragt und es wird nicht Dauerfeuer geschossen, sondern nur, wenn der Feuerknopf gedrückt wird. Dann aber unmittelbar, der erste Schuss ist nicht vom zufälligen Zustand eines Oszillators abhängig, er wird mit dem Feuerknopf synchronisiert. Das hält die Verzögerung eigentlich bei weniger als einem Schleifendurchlauf (1ms). Es sei denn, dass der Schalter ungünstig prellt. Der C64 macht es aber auch nicht anders, da muss der Knopf auch abgefragt werden und ich denke, dass der Abfragezyklus meistens über einer ms liegt.
Ich habe darüber nachgedacht, so etwas Ähnliches in meinen Joystick einzubauen. Da würde ich einen Drehgeber einbauen, mit dem man es ein und ausstellen kann. Wahrscheinlich muss ich das gehäuse dafür etwas länger machen, damit drehgeber und Display reinpassen. Controller wird dan wahrscheinlich direkt ein Atmega328.
Gruß
Sven
-
Das ist ganz schön viel Aufwand für eine Sache die mit 3x4066 und nen 555 ohne progammieren hätte getan werden können .
OK, die ultimative Anzeige wär dann nicht dabei.
Das habe ich mir schon überlegt. Allerdings ballert der 555 irgendwann. Zyklisch eben. Der Pro Mikro wartet, bis der Feuerknopf gedrückt ist und ballert genau dann los. Die Zykluszeit der Hauptschleife ist 1ms. Die Verzögerung beträgt also maximal 1ms.
Die Anzeige ist natürlich auch wichtig. Jedes Programm hat seine optimale Feuergeschwindigkeit.
außerdem ist Autofeuer Schummeln :-)))) -
Wie geil!
Und... hm... ich habe hier bereits von Jim ein WiModem liegen (leider ist das Display defekt) und ein selbst gebautes Wifi-Modem inkl. selbst designtem Case... und wenn ich so etwas sehe, will ich auch das hier nachbauen! Nicht dass ich die alle bräuchte, aber ich finde solche Projekte halt extrem cool!
Ich halte die Modems für zweifelhaft. Der Grund: der C64 hat TTL (5V) Level. Der NodeMCU hat 3.3V Level. Die Eingänge sind sehr wahrscheinlich mit Dioden geschützt. D.h. wenn ein H-Level aus dem C64 auf einen NodeMCU Eingang trifft, dann wird der Pegel runtergebügelt. Das funktioniert nur, weil der CIA ziemlich schwach auf der Brust ist. Mir liegt nun keine Innenschaltung der IO-Pins vor. Aber es ist nicht unwahrscheinlich, dass es sich um eine Push-Pull-Schaltung handelt. Wenigstens sollte man dies annehmen. In diesem Fall würde das Modem den CIA stressen. Darum sinD in meinem Modem Level-Shifter eingebaut. Vielleicht völlig umsonst, aber besser ist das.
-
Wie steuert man die Led's an?
Die LEDs zeigen den Status der seriellen Signale bzw. der Handshake-Leitungen an. Die Handshake-Leitungen steuern die LEDs über einen Inverter an. Die RxD und TxD Leitungen habe ich über eine R/C Kombination an die Basis eines Transistors gelegt. Dieser schaltet die jeweilige LED. Der Grund: diese Leitungen ändern sehr oft den Zustand, daher wären sie nicht besonders hell, das würde doof aussehen zusammen mit den anderen.
Die Firmware auf dem NodeMCU hat noch eine Status LED. Das ist die sechste im Bunde. -
Hallo auch,
wenn es von Interesse ist, ich habe gerade mein WiFi Modem Rev. 2 auf Github gestellt.
Dieses funktioniert auch mit der NodeMCU in der breiteren Form, bisher hatte passte nur die originale NodeMCU hinein. Das Board ist dadrurch ein wenig länger gewprden, daher war auch ein neues Gehäuse fällig. Auch dies ist komplett im Github Repository.
Beide Bauformen der NodeMCU
Im Gehäuse Unterteil (breite NodeMCU)
Komplettes Gehäuse
-
So, mein Control Port Switch ist jetzt auf Github: https://github.com/svenpeterse…l-Port-Switch-Rapid-Fire-
Falls es von interesse ist.
Das Ding kann einen Joystick zwischen beiden Controlports umschalten. Man spart sich also das Umstecken. Weiterhin macht das Ding Rapid Fire. Das bedeutet, dass nicht wie bei autofire die ganze Zeit geballert wird, sondern nur, wenn man auf's Knöpchen drückt. Das macht auch kein blöder Oszillator, sondern ein Mikroprozessor (genauer gesagt ein Arduino Pro Micro Modul), damit gleich losgeballert wird, wenn der Knopf gedrückt ist. Die Verzögerung ist maximal 1ms. Das ist relativ wenig, verglichen mit der normalen Reaktionszeit von ca. 300ms.
Und weil der Arduino sonst nichts zu tun hat, wird die eingestellte Feuerrate auf einem OLED-Display angezeigt. Damit kann man schnell die für das jeweilige Spiel optimale Feuerrate einstellen.
-
Ist das auch transparent? Kann ich auf den Bildern nicht so erkennen.
Milchglas würde besser passen als Transparent, das Filament ist Transparent aber besser bekommst das gedruckt nicht hin.
Also ich zumindest nicht
Lg
Transparent ist eher "so durchscheinend". Man erkennt eine LED im Inneren blinken, weiß aber nicht, welche es ist. Ich habe einen Transparentdruck als Diffusor für ein beleuchtetes Logo verwendet. Es geht nur mit 100% Infill. Für "klar" braucht man wohl eher einen Resin-
Drucker.Gruß,
Sven
-
Habe ich das richtig verstanden - wenn ich den Keyboard-Dongle weglasse und das separat teste, ist auch mit der alten Revision alles O.K.?
ja, einmal mit und einmal ohne keyboard dongle testen. Mit „ohne“ gibt es beim keyboard ein open. Das wird nicht als Fehler gewertet. Es hat nur niemand so gemacht. Im C64 Diagnostic Manual von Commodore steht darüber auch nichts drin. Im C128 Diagnostic Manual aber schon.
Mit dem neuen Harness ist das nicht mehr nötig. Hier werden die Keyboard Feedbacks, die mit den Control Ports gemeinsam sind (ROW 0..4 und COL 0..4 ) für den Control Port Test geöffnet.
Gruß
Sven
-
Heute habe ich die Rev. 1 meines Diagnostic Harnesses auf Github gestellt. Es behebt das "False OK" Problem aller bisheringen, auf den Original Commodore Harness basierenden Diagnostic Harnesses. Dies betrifft also meine Rev. 0 und alle anderen Harnesses.
Falls bestehende Harnesses renoviert werden sollen (also alle anderen auch!), gibt es einen Extended Keyboard Dongle. Der wird mit einem Kabel an das WRITE Signal am Cassette Port (Dongle) angeschlossen.
Gruß,
Sven
-
Ha ha ... da testen wir jahrelang Blödsinn und keiner merkt es. Wie bist du darauf gekommen? Ich musste erst kräftig nachdenken, um überhaupt das Problem zu verstehen.
Man könnte jetzt noch argumentieren, dass wenn man den Keybaord-Dongle nicht aufsteckt die Control Ports sehr wohl getestet werden und man das Stecken des Keyboard-Dongles normalerweise unterlässt, wenn man die Kiste nicht aufschraubt.
Aber das ist ein sehr guter Punkt, den muss ich mir merken!
Ich habe auf meiner Website ein bisschen darüber geschrieben.
http://tech.guitarsite.de/c64_diag_harness.html
Gruß,Sven
-
Vielleicht kannst du in deinem Layout diese Funktion mit aufnehmen. Die LED an PIN 4 hast du ja bereits drauf, dann soll wohl die LED an PIN 1 ein Klacks für dich sein. Blöd nur das ich noch bestimmt 70 Platinen der aktuellen Revision von dir habe.
Thema durch. Ich habe den Cassette Port Dongle mit der SENSE LED versehen. Damit die Strombelastung gering bleibt, habe ich einen Transistor mit 10k an der Basis. Außerdem habe ich einen Datasettenanschluss hinzugefügt. Der Dongle kann so als Breakout Board genutzt werden, wenn man mal an der Datasette herum messen möchte.
Wenn in den nächsten Tagen Dei Doku fertig ist, geht das Ganze auf Github.Gruß,
Sven
-
so, jetzt gibt es die Revision 1 des Diagnostic Harness. Beim Original schließt des Keyboard Dongle die Analogschalter für den Control Port Test kurz. D.h. der Test läuft komplett ohne Analogschalter (die 4066 auf dem Userport), die Leiterbahnen zu den Controlports, die EMI-Filter und die Steckverbinder werden so nicht getestet.
Ich habe das Problem gelöst, indem ich die Keyboard Feedback Signale, die mit den Controlports schaltbar gemacht. Die (Keyboard) Verbindungen werden für den Control Port Test geöffnet. Damit wird korrekt getestet.
Die zusätzlichen Analogschalter befinden sich in Gestalt eines zusätzlichen 4066 auf dem Userport Dongle. Der hat einen (zusätzlichen) an dem der (neue) Keyboard Dongle via Flachbandkabel angeschlossen ist.Für bestehende Harnesses gibt es einen erweiterten Keyboard Dongle. Dieser hat einen Anschluss für das WRITE Signal vom Cassette Port Dongle. Damit läuft er mit meiner Rev. 0 und eigentlich allen anderen Harnesses.
Außerdem wünschte sich jemand, dass es auf dem Cassette Dongle eine LED für die Sense-Leitung gibt. Um die Stromentnahme gering zu halten, habe ich einen Transistor als Verstärker benutzt. Weiterhin hat der Dongle jetzt einen Anschluss für Datasette und kann so auch als Breakout Board verwendet werden.Heute habe ich die Leiterplatten aus China bekommen und zusammengebaut. Die Tests liefen zufriedenstellend. Nun muss ich die Doku abschließen, dann geht das Zeug auf Github.
neuer TestharnessUser port Dongle
Alternativer Keyboarddongle für bestehende HarnesseCassette Port Dongle
Im Gehäuse
Gruß,Sven
-
Vielleicht kannst du in deinem Layout diese Funktion mit aufnehmen. Die LED an PIN 4 hast du ja bereits drauf, dann soll wohl die LED an PIN 1 ein Klacks für dich sein. Blöd nur das ich noch bestimmt 70 Platinen der aktuellen Revision von dir habe.
Schon passiert. Und ich glaube, es macht ja nicht viel aus, wenn die SENSE LED nicht drauf ist. Aber in der Rev. 1, die ich gestern angefangen habe, ist die LED mit drin.
Ich habe ohnehin eine Erweiterung des Harness gerade in Arbeit. Wie gesagt, das Design ist wohl an die 37 Jahre alt und alle waren glücklich ohne meine Trickschaltung und die Sense LED.
Im neuen Design kann der Keyboard Dongle die Verbindungen unterbrechen, wenn die Controlports gerade gemessen werden. Es ist noch nicht wirklich aufgefallen, dass man beide 4066 abmontieren kann, wenn der Keyboard Dongle steckt. Auf dem sind nämlich die Verbindungen fest drauf, die die 4066 schalten. D.h. mit gestecktem Keyboard dongle werden die Controlports nicht richtig gemessen. Man muss also einmal mit und einmal ohne Keyboadr dongle messen, damit man wirklich alles geprüft hat.
Daher gibt es eine Erweiterung für bestehende Harnesses. Das ist ein Keyboard dongle, auf dem zwei 4066 drauf sind. Zusätzlich kommt ein Kabel (DuPont) zum Cassette Dongle, welches das Signal zum Abschalten führt. Software ist die Selbe, da muss nichts geändert werden.
Wenn mabn alle neu macht, dann kommt auf den Userport Dongle noch ein 4066 drauf und ein Flachbandkabel zum Keyboard dongle.
-
Alles anzeigen
Nachtrag:
Wer den "Dead Test im Selbstbau" noch etwas aufwerten will, kann sich einen einfachen Adapter mit zwei LEDs an den Tape-Port schnallen:
Ist in fünf Minuten fertig gelötet. Damit sieht man auch ohne funktionierende Bildausgabe, ob der Rechner anläuft (dann beginnen die LEDs zu blinken).
Bitte mindestens 2k2 für R1 verwenden, dieser samt LED1 hängen direkt am I/O-Port der CPU, und die kann nicht viel mehr als ca. 1,6 mA ableiten ("sinken"). R2 ist weniger dramatisch, da ist noch ein Schalttransistor dazwischen auf dem Board.
[EDIT]
Geht es jetzt?
[/EDIT]
Ich sitze ohnehin gerade am Test Harness. Ich habe einen Transistor zur Verstärkung spendiert. Dann funzelt die SENSE-LED nicht so.
-
Es wurde einmal wieder ein C64 Netzteil. Irgendwie habe ich mittlerweile viele davon. Diesmal war der Weg der Fertigstellung steinig. Zweimal musste ich ein Teil nachbestellen, das ich glaubte zu Duzenden zu haben :-))) Hoffentlich ist die Doku bald fertig, damit es auf github kann.
-
heute auf Arbeit...
Ein Brandherd
