In einem Jahr hat sich viel getan und ich wurde innerhalb der 14 Stunden seit Threadstart bereits von 2 Leuten unabhängig voneinander darauf angesprochen, dass ich einen Vortrag machen sollte.
Ich werde deshalb über den aktuellen Stand des MiSTer CD-i core referieren. Bin mir noch nicht sicher, in welcher Form und wie lange so ein Vortrag dauern könnte.
Slamy Hast Du vielleicht noch einen konkreten Hinweis, wo ich nochmal schauen könnte oder müsste?
Ich empfehle an dem Pico mit einem Multimeter zu messen, um direkt erstmal die Quelle des Signals zu prüfen.
Schaue mal hier https://raw.githubusercontent.…heads/main/doc/pinout.svg
Die Pinne haben 3.3V, wenn der Button durchgedrückt wird. Auf diese Weise kannst du herausfinden, ob generell das Signal anliegt, wenn du eine Taste auf dem Pad drückst.
Vielleicht ist dort eine kalte Lötstelle irgendwo auf dem Weg zum Transistor. Das kann schonmal passieren.
Ich betreibe meinen MiSTer seit Jahren mit einem Commodore 1084 (allerdings mit Scart Anschluss) und hatte bisher keine großen Probleme. Manchmal ist das Bild horizontal an der oberen Kante leicht nach rechts gebogen. Das macht der Monitor aber auch am echten Atari ST. Ich drücke dann einmal vorne die CVBS Taste und das Bild sieht wieder besser aus. (Obwohl kein Composite Signal anliegt... hmm)
Warum ich eigentlich schreibe... ein MiSTer unterliegt in seiner Gesamtheit keiner Hardware-Qualitätskontrolle. Ich habe den Fehler gemacht, mein Analog IO Board bei diesem Laden hier zu bestellen.
Die Bestückung der Boards war nicht korrekt, weshalb das analoge Bild Nichtlinearitäten in der Farbwiedergabe aufwies. Der DAC wird beim Analog IO v6.1 über eine R2R Ladder erzeugt. Es gibt mehrere Versionen dieser Analog I/O Boards.
Alternativ kann man auch den DirectVideo Mode nutzen. Das geht aber nur mit gewissen HDMI zu VGA Adaptern, die so dämlich sind, dass sie sich als DAC missbrauchen lassen. Damit hast du dann aber kein Bild über HDMI mehr für deinen LCD Fernseher, brauchst aber auch kein Analog I/O Board mehr. DirectVideo lässt sich mit etwas Fingerspitzengefühl durch eine Tastenkombi aktivieren. Ist aber eher advanced das Thema.
Was ich damit sagen will, lasse eine Testsoftware nach Anschaffung laufen, um Testbilder anzuzeigen. Eventuell die 240p test suite von Kordamp auf dem SNES Core.
Dass Arcade boards alle 60 Hz haben, stimmt glaube ich nicht. R-Type müsste 55 Hz haben und auch das läuft ohne Probleme am 1084.
Der C64 Core des MiSTer ist übrigens nicht so der Brüller. Er erfüllt seinen Zweck, das Bild ist aber viel zu sauber.
Ich habe mich zu sehr an die Eigenheiten des VIC gewöhnt.
Hallo, ihr lieben. Frohes neues kann man noch wünschen, denke ich. Das Jahr ist noch frisch.
Nach etwas Gebastel zwischen den Jahren, ist die Version 0.2 freigegeben. Verglichen mit dem Release Kandidaten v0.1-12-g0a045cd gibt es noch ein paar weitere Änderungen:
Die letzten beiden Punkte mögen etwas verwirrend sein. Das liegt einfach in der Natur dieses Projektes, gleichzeitig 4 Eingabegeräte auf 2 Ports zu mappen. Für den C64 mag das alles unwichtig sein, für den Amiga ist es aber meiner Meinung nach schön, um nicht immer hinter den Rechner zu kriechen zu müssen, um zu stöpseln.
Vielleicht einmal ein Update, weil es wirkt, als würde dieser Thread einen Cliffhanger haben. Wir hatten versucht zusammen eine Lösung zu finden. Es gab auch die Idee, dass ich auf seinem Rechner über Remote Access weiter entwickle. Das entpuppte sich dann aber als technische Herausforderung, weshalb wir es erstmal gelassen haben. Bei dem "Xbox 360 Wireless Receiver" handelt es sich nicht um ein "Human Interface Device", welches einfach die Reports erbricht. Es entspricht der "Vendor Class". Das ist genauso ekelhaft wie bei den XBox One Controllern, aber anders, weil der Receiver 4 Controller gleichzeitig unterstützt.
Ich müsste also ein wenig Liebe anwenden. Bisher hatte ich noch nicht auf der Arbeit die Kollegen angesprochen, ob die derartige Geräte zuhause haben. Das werde ich die Woche über mal nachholen.
............. das Teil sollte in Serie gehen, mitsamt einem/dem schönen gedruckten Gehäuse
Das sagt mein Nachbar auch. Der denkt aber nur in Business Cases. Aber ich vermute, dass dann gewisse Gesetze eingehalten werden müssten. Kein Blei-Lötzinn und Gewährleistung. Und wenn dann ein CIA weg brutzelt... oi oi...
Aktuell habe ich keine Pflichten damit. Das letzte Mal, dass man mich ein wenig dazu gedrängt hat, Geld damit zu verdienen war mit meinem Amiga Spiel. Und da hatte ich dann auch ein wenig den Support am Hals, weil irgendwas nicht ging, wenn man Steckkarte X, Betriebssystem Y oder eine dreckige CD32 Linse hat.
Ich bastle und wurschtle eigentlich nur gerne. Nur ist mir das irgendwann zu doof geworden, einfach nur so vor mich hin zu wurschteln. So haben wenigstens noch andere Leute was davon.
Anbei gibt es eine etwas korrigierte Software. Ich war am Montag ein wenig zu flott unterwegs und da klappte so einiges nicht. Hiermit sollte die Final Cart. III auch nach dem Power up direkt laufen.
Es ist auch noch eine weitere kleine Funktion dazu gekommen. Wenn man ein Gerät rauszieht, rückt dieses in den leeren Port vor. Es gab vorher einen Spezialfall, wenn man mehrere Gamepads hatte und genau den rausgezogen hat, der nicht mit dem Mausport verbunden war. Dann war ein Port leer und der andere war geteilt zwischen Maus und Gamepad.
Das sind so doofe Spezialfälle. Es gibt bestimmt noch mehr davon 
Ich würde jetzt noch auf das Github Issue und auf die XBox 360 Analyze warten und dann wäre das erstmal die Version 0.2 wenn sich nichts anderes größeres findet.
- mein XBOX360 Controller über den Microsoft Wireless Receiver funktioniert weiterhin nicht. Hier ist es übrigens so, dass die LED des Wireless Receivers auch nicht aufleuchtet, ein Zeichen, dass hier irgend ein Init nicht läuft. Diese LED geht nur an, wenn die Kommunikation steht, nicht alleine wenn die Betriebsspannung anliegt.
Ich habe leider aktuell keinen Xbox360 Controller in Reichweite. Ohne den wird es sehr schwierig sein, das Ding tatsächlich einzupflegen. Wenn dir das wirklich wichtig ist, müsstest du mir den entweder einmal auf dem Postweg zukommen lassen oder wir machen das bei der nächsten DoReCo. Eine weitere Möglichkeit wäre noch, dass ich mich im Verwandtenkreis einmal umschaue. Das werde ich in den nächsten Tagen versuchen und dir dann bescheid geben.
- mit der neuen Firmware können jetzt im FC3 beide Stecker in Port 1 und 2 eingesteckt sein. Die Mouse funktioniert nach 2 klicks auf die Taste im C64 Mode. Was mir auffällt: die Mouse funktioniert manchmal nicht sofort nach 2 Klicks, manchmal muss man das FC3 nochmals bei eingeschaltetem 64er reseten, danach funzt die Mouse.
Das ist ein richtig gutes Finding. Das tritt ein, wenn der C64 einen power cycle erfährt. Der Yaumataca startete bisher mit Joysticks auf beiden Ports, wenn noch kein Ereignis erfolgte. Die Firmware, die ich angehangen habe erweitert den Release Kandidaten von oben um ein weiteres Verhalten. Control Port 1 startet ab sofort immer im Maus-Modus, auch wenn noch kein USB initialisiert wurde. Das führt dazu, dass FC3 nicht im Joystick Modus startet. Denn genau das passiert. Du müsstest dann einmal Ports Swappen und würdest dann feststellen, dass ein eventuell eingesteckes Gamepad den Mauszeiger manipuliert.
Je länger ich drüber nachdenke.... das wird niemals das Problem fixen, wenn man versehentlich mit dem Amiga oder Atari ST Modus aufstartet. Denn dann wäre der C1351 Modus ja verkehrt....
Aber wenn man den Adapter nur am C64 benutzt, so wäre die FC3 damit wieder gelöst.
Die Micromys erkennt den angeschlossenen Rechner glaube ich automatisch. Ich weiß aber nicht, wie die das macht.
Ziemlich viele Variablen in dem ganzen!
wir haben also bis zu 0,4V Spannungsabfall an der Drossel, und das schon mit recht wenig Belastung. Falls da Gamepads angrschlossen werden die auch noch einen Akku laden wird es sicherlich knapp...
Das ist echt ein Ärgernis. Vor allem auch sehr abhängig von der Drossel... Tatsächlich war die Drossel eines der letzten Dinge, die ich an der Hardware geändert hatte. Und auch nur, weil man die Logitech m100 durch den SID hören konnte... Das sollte den Sound rausfiltern, weil der C64 da sehr empfindlich war. In meinem Fall hat die Drossel einen Widerstand von 2Ohm. Das ist eigentlich nicht allzu viel.
Viel gruseliger ist das beim Amiga, weil da einfach mal 4Ohm im Rechner permanent verbaut sind.
Es kann sein, dass eine mögliche Lösung ist, dass man die Drossel anders dimensioniert. Ich bin jedoch was Analog-Technik angeht ein absoluter Noob.
EDIT: Ich muss die Software zurücknehmen. Das war gerade vorm Sport mit einer zu heißen Nadel gestrickt. Die Software bekommt dadurch richtige Probleme. Das mache ich die Tage nochmal mit Ruhe.
Ja, das war gestern ein kleines Abenteuer. Ich ärgere ich auch ein wenig, dass ich nicht auch hier am Anfang des Threads ausgesagt habe, dass es Probleme gibt, wenn man mit beliebigen USB Gamepads dran geht.
Ende vom Lied war, dass zumindest ein weiteres Gamepad eingepflegt wurde. Ich habe tatsächlich erst gerade vom mouSTer erfahren. Das Ding kann angeblich alle Gamepads, die es gibt. Ich frage mich nur wie. Zumindest der Quellcode scheint nicht offen zu sein.
Wie bereits angekündigt - und weil mir der Wildwuchs aus verschiedenen Firmwares hier nicht gefällt -, gibt es für euch den Release Kandidaten für die Version 0.2.
Hier die Änderungen verglichen mit v0.1:
Ich hoffe, ich habe nichts vergessen. Generell gab es viele Kritikpunkte. Ich kann leider nicht alle davon lösen. Wenn ich irgendwas wichtiges vergessen habe, so schreibt mir das bitte.
Was mich gerade noch gestört hatte, war die Vielseitigkeit der Wheel-Mäuse auf dem Amiga. Es gibt mindestens 3 konkurrierende Systeme, die ich gefunden habe:
Ich habe den Yaumataca bisher nicht auf dem a1k beworben, weil ich befürchtete, dass dann noch mehr Wünsche sich auf dieses Projekt projezieren würde. Ich merke aber, dass ich das tun müsste, um zu erfahren, welchen Wheel Betriebsmodus sich die Leute dort eigentlich wünschen würden. Da ich ursprünglich aus der Amiga-Schiene komme, ist es schon fast Blasphemie, dass der C64 Modus sich jetzt etwas weiter entwickelt hat, aber der Amiga Modus nicht.
Ich schätze das liegt daran, weil ich dieses Projekt bisher vor allem auf der DoReCo und eben hier im Forum beworben habe.
Der offizielle Release mit Versionsnummer wird durchgeführt, sobald ich eine Rückmeldung bezüglich eines github Issues erhalten habe.
Was aber gar nicht sein Ziel war denke ich ...
Es gibt Dinge, die tatsächlich nicht mein Ziel waren. Es war bisher nicht mein Ziel, dass der Yaumataca einfach auf magische Weise mit jedem USB Eingabegerät funktioniert. Ausnahme sind Mäuse. USB Mäuse halten sich alle an Standards. Und wenn nicht, wäre der Hersteller, der dahinter steht relativ schnell pleite. Das gleiche gilt für Tastaturen. USB Mäuse und USB Tastaturen starten stets in einem Kompatibilitätsmodus auf und werden durch die spezifischen Treiber erst nachträglich in einen Modus gebracht, in welchem die Spezialitäten zum Ausdruck gebracht werden.
Die Sache mit den Gamepads ist fürchterlich und die Komplexität kann ich alleine nicht handeln. Das ist wahrscheinlich auch der Grund, warum bisher kein kommerzielles Gerät auf dem Markt verfügbar ist, welches das probiert, was der Yaumataca als Ziel hat. Oder es gibt eines und ich kenne es noch nicht.
So sieht das hier jetzt aus:
Viel zu viele Kabel. 4 Stück, wenn die 5V nicht aus dem C64 kommen. 3 Stück, wenn das Teil am C64 hängt. Dann braucht man nur noch SWDIO, SWCLK und GND.
Mehr wird für die Entwicklung der Yaumataca Firmware nicht benötigt, inklusive der Debugging-Ausgaben.
Nur muss ich diese jetzt erst einmal im Code zu den "Bytes" zuordnen - das bleibt eine Ratespiel: "Now - by observing the change - I know the bit position of this specific button!" - bleibt eine Kunst beim Erfinder - Mir zumindest erschliesst sich der direkte Zusammenhang noch nicht, zumal die Bytes in den Kommentaren und in den Outputs abweichen - "Be creative" bedeutet hier Such, Struppi, such bis in die Nacht...
Wie im letzten Post davor erwähnt ist diese Anleitung ein "lebendiges" Dokument. Ich bin mir noch unsicher, welche Informationen genau notwendig sind. Mit "Be creative" ist gemeint, dass jedes USB Gamepad einen anderen Report sendet.
Ich bin mir noch nicht sicher, ob generell klar ist, wie USB hier an dieser Stelle funktioniert. Deswegen eine Zusammenfassung.
Der USB Standard sieht das "Human Interface Device" (kurz HID) vor. Das ist eine Kategorie von Geräten, die mit Menschen interagieren. Dazu gehören unter anderem Maus, Tastatur und Gamepad.
Jedes HID verfügt über einen oder mehrere "Human Interface Device Report Descriptors". Das ist ein Binärklumpen, welcher die Struktur des "Human Interface Device Reports" dokumentiert, damit sich das Betriebssystem darauf einstellen kann.
Dieser Report Descriptor wurde bisher durch den Yaumataca nicht analysiert. Das ist auch das Problem, welches dazu führte, dass einige Mäuse einfach nicht richtig funktionieren. Das kriege ich aber gerade in den Griff und wird in naher Zukunft hier als Release bereitstehen.
Potentiell kann man damit auch das Gamepad Problem lösen. In der Praxis gibt es damit aber so viele Probleme, dass ich das aktuell nur mit Strahlenschutz-Anzug anfassen würde. Alleine, weil einige Gamepads (Nintendo Switch, ick hör dir trapsen) einfach den falschen übertragen.
TLDR: Mit Kreativität ist gemeint, dass man sich überlegen muss, wie man die Bits des Gamepads auf die interne Datenstruktur des Yaumataca mappt. Die Software erwartet einen Report als Ausgabe des HID Handlers, in welchem die Buttons drin stehen. Das ist bei jedem Gamepad unterschiedlich.
Das Github Repo wurde heute von mir erweitert. Mäuse sollten damit nun ohne Probleme funzen. Wer sich den Schmerz antun mag, darf den Report Descriptor Parser auch für Gamepads einsetzen. Es wird jedoch der Weg des Schmerzes sein.
spacepilot3000 Warum RTT bei dir nicht geht, weiß ich noch nicht. Aber das kriegen wir bestimmt noch raus.
gibt es evtl auch eine Liste im git in der die eingebauten controller mit den HID und VID nummern stehen?
Eine Liste davon gibt ist direkt in dem Readme. Es stehen zwar keine VID:PID Kombinationen dort, es ist jedoch klar kommuniziert, dass nicht jeder Controller out of the box gehen wird. Da jedes USB Gamepad eine eigene Sprache spricht, ist es nur sehr schwer die alle auf einen Nenner zu bringen. Der professionelle Ansatz wäre ein Parsing des HID Report Descriptors. So würde es ein Linux machen oder auch ein Windows. Das klappt für die meisten Gamepads vor 2005, versagt aber bei hochwertigen aus den Konsolengenerationen danach, die leider vom Standard abweichen. Das PS4 Gamepad ist eine Ausnahme....
Selbst wenn ich den HID Report Descriptor analysieren würde, verbleibt aber dann noch das Problem mit dem Button Mapping. Es müsste dann ein Tool zum Yaumataca beigelegt werden, welches es gestattet eben jenes möglichst angenehm einzustellen.
Das wäre alles ziemlich schön, müsste dann aber wieder gewartet werden, weil dieses dann auch wieder unter Linux, Windows und Mac (und für manche auch auf dem C64 selbst) laufen müsste, damit alle happy hippo sind.
Ich bin deshalb mit dem Ansatz gefahren, dass ich versuchen wollte die bekanntesten Gamepads mit einer möglichlist sinnvollen Buttonbelegung umzusetzen. Am besten auch welche, die man immer noch käuflich im neuwertigen Zustand erwerben kann.
Klar wäre es besser, wenn Slamy eine Möglichkeit hätte, diese Daten direkt über das Github zu sammeln
Im Fall von Github gibt es mehrere Möglichkeiten. Da es eine dezentrale Versionsverwaltung ist, kann jeder das Projekt forken und bei Änderung einen Pull-Request stellen. Ich kann das dann in den Hauptstand einfließen lassen.
Alternativ kann ich auch Rechte geben. Das tue ich jedoch nur sehr ungerne und nur bei Leuten, denen ich wirklich vertraue. Deswegen wäre mir der Pull-Request Ansatz erstmal lieber.
Traditionell verwendet Github das Markdown Format für die Textdokumente. Man kann aber auch wohl ein Wiki anlegen. Damit habe ich bisher keine Erfahrungen gemacht.
Generell ist die Idee jedoch sehr gut, dass es eine genaue Kompatibilitätsliste gibt.
Ich habe mir jetzt ein paar Tage vorgenommen mich wieder dem Yaumataca zu widmen. Die Leute im MiSTer Forum wissen bescheid. Das Timing war jetzt etwas doof, weil der Yaumataca einfach gerade durch die Decke geht und scheinbar doch etwas Liebe notwendig ist, um ein paar Probleme zu lösen.
Ich werde deshalb in den nächsten Tagen den develop-Branch auf dem Github Projekt aufräumen und mal schauen, ob ich 1 oder 2 Probleme lösen kann.
Speziell die Sache mit den Mäusen (darum kümmere ich mich die nächsten Tage) und die Sache mit der Final Cart III sind mir irgendwie noch ein Dorn im Auge.
Sobald du uns schreibst wie es geht werd ich versuchen, ob ich das hinbekomme
Sooo, liebe Gemeinde.
Ich habe mich mal ein wenig hingesetzt. Auf dem develop Branch gibt es nun eine erste Version der Anleitung.
https://github.com/Slamy/Yauma…op/doc/adding_gamepads.md
Es handelt sich dabei um ein lebendiges Dokument. Es wandert in die Mainline, sobald mindestens eine Person damit einen neuen Controller hinzugefügt hat. Wenn etwas fehlt, so kann entweder derjenige einpflegen, was er glaubt, was fehlen würde und einen Pull-Request stellen oder, wenn derjenige die Antwort nicht weiß, so ist klar geworden, dass etwas fehlt und ich trage es nach. Ziel ist, dass klar wird, wie man Controller hinzufügt.
Oder - allerdings eine theoretische Laienidee - könntest Du Slamy statt Joypad Anpassungen selbst zu machen, dokumentieren was / wie Du die Anpassungen machst, so dass Dir findige User aus der Community das Hinzufügen von weiteren Pads abnehmen würden? Keine Ahnung ob das möglich wäre, aber wenn, würde es Dir mittelfristig die Arbeit abnehmen und sicher käme da noch etwas Dynamik in die Kompatibilitätsliste - also nur gesetzt den Fall, dass das noch jemand anders beherrschen würde ... und kein Chaos bei der FW erzeugt ... und ... so.
Kann natürlich ein komplett quarkige Idee sein, kann das nicht abschätzen.
Nein, die Idee ist super. Es gibt einfach zu viele Gamepads, als das ich sie selbst einpflegen könnte. Am angenehmsten ist es auch einfach, wenn die Geräte selbst vor Ort sind. Ich nehme mir mal die nächsten Tage vor, die Firmware ein wenig aufzuräumen. Es gibt da ja mindestens ein Issue auf dem Github Repo... die Sache mit den Mäusen.... das werde ich fixen und dann müssen wir wieder zu vernünftigen Versionsnummern zurück. Es kursieren zu viele verschiedene Firmware Versionen. Und dann schreibe ich eine Anleitung mit einem Exemplar, mit genau den Schritten die notwendig sind, um ein neues Gamepad hinzuzufügen.
Als Vorbereitung: Derjenige, der für den Yaumataca entwickeln möchte benötigt noch einen 2. RP Pico, der mit einer Programmer Firmware geflasht werden muss. Die müsste Picoprobe heißen. Ohne die macht das keinen Spaß, weil man sonst die Debugausgaben nicht sieht.
Programmcode immer größer werden und irgendwann laggen oder sich wiederholen, wenn jeder fleißig IDs sammelt und einträgt.
Die Software hat eine relativ strukturierte Architektur. Der Lag wird nicht größer, wenn man mehr IDs einträgt.
Die Sache mit der Hardware ist etwas, was ich befürchtet hatte. Mein Design wurde leider nicht in Frage gestellt, weshalb mindestens 2 bekannte Probleme bei der Hardware vorliegen:
Ich hoffe, dass mein Platinendesign nicht das große Problem ist. Bei 2 PS3 Controllern frisst die Drossel bereits 0.29V. Das kann auch Probleme begünstigen. Da mein C64 bereits nur 4.90V am JoyPort bereitstellt, bleiben am Ende - so messe ich - 4.62V am USB Port übrig. Die Drossel und der Elko waren ursprünglich dafür gedacht, damit man die Spannungsschwankungen einer optischen Maus nicht aus dem SID hören kann. Das war leider ein gewisses Problem, welches ich mit diesem LC Filter lösen wollte. Es kann sein, dass das jetzt beißt.
Vielleicht mag Slamy noch mal über seinen Code schauen, da ich da leider keine Ahnug von soetwas habe
Also das wäre jetzt in der Tat etwas ganz neues. Ich habe das Gerät schon häufiger mit verschiedenen Gamepads getestet. Probleme hatte ich eher gesehen, wenn die Gamepads ordentlich Ladestrom gezogen haben. Tatsächlich habe ich das Ding noch nie mit 2 identischen Gamepads betrieben. Meine Erfahrung basiert also genau auf dem Gegenteil. Gibt es jemand anderes hier, der ähnliche Erfahrungen hatte? Ich habe den Yaumataca gerade mit einem PS3 Dual Shock zusammen mit einem Switch Pro Controller getestet und konnte keine Probleme feststellen. Getestet am C64c mit Joyride. Ich habe dann auch mal den Switch Pro rausgezogen und durch einen 2. PS3 Dual Shock ersetzt und hatte tatsächlich selbst auch kurz Probleme. Ich bin mir aktuell nicht sicher, ob es daran liegt, dass kurz mehr Strom gezogen wird als sonst. Ich empfehle die Controller vorher einmal aufzuladen, damit die nicht zu viel Strom aus dem C64 ziehen.
Heute kam der OTG-Adapter und ich habe mal ein wenig probiert. Meine normale PC Maus funktioniert soweit, ist aber viel zu schnell . Das Kalibrierungstool ist speziell für die 1351 Maus? Oder kann man damit jede Maus kalibrieren
.
Oha, an so etwas habe ich noch gar nicht gedacht. Stimmt, Mäuse sind ja unterschiedlich schnell. Boah, da muss ich mir was überlegen. Das ganze Projekt hatte bisher kein wirkliches Konfigurations-Interface. Ich bin mir bezüglich der Natur dessen noch nicht ganz sicher. Am Ende möchte man ja eigentlich nicht, dass dafür ein PC notwendig ist. Hmmm. Ich bin auch natürlich für Vorschläge offen.
Bezüglich des Kalibriertools. Ich bin eine "Pingelfutt" und ich wollte, dass der analoge Werte-Bereich der 1351 am SID exakt eingehalten wird, auch wenn es gar nicht unbedingt notwendig ist. Das Kalbriertool hat den Zweck die Widerstands-Toleranzen rauszurechnen. Die meisten Leute würden es wahrscheinlich nicht mal merken, weil die meiste C64 Software das ebenfalls rausfiltert. Das Tool ist nur für den 1351 Modus.
Wenn man das Scrollrad dreht, blinken im Drehrhytmus am anderen Port der Left- und Up- Port. Gehört das so? Keine Ahnung
Hallo, Jau, das muss so. Hier bitte: https://aminet.net/package/util/mouse/WheelBusMouse
Du verwendest aktuell die eigentlich vorgesehene Version der Yaumataca Firmware. Das ist die, die auch im github aktuell als master/main deklariert wird. Hier im Forum kursieren aktuell einige Varianten davon, weil ich mit der heißen Nadel gewisse Dinge gefixt habe.
Es hat sich herausgestellt, dass der Report Modus von mir falsch implementiert wurde und nur bei manchen Mäusen funktioniert. Leider ist dieser erforderlich für die Wheel-Funktion. Wenn dich das stört, so kannst du eine der kursierenden Versionen hier verwenden. Die lassen die Maus im Boot-Mode und der ist immer gleich. Sollte er zumindest.
quadflyer8 Ich bin generell froh, dass das Projekt eine Eigendynamik entwickelt hat. So muss das bei Open Source sein. Die Existenz dieser Testpunkte hatte ich nicht auf dem Schirm. Das würde bedeuten, dass man eine Platine "Huckepack" nehmen kann. Und da könte ein USB Hub drauf. Das würde dann je nach Umsetzung die Idee der einfachen Aufbaubarkeit kaputt machen. Es wäre dann aber wirklich aufgeräumter....
Ich bin leider kein guter Elektronik-Bastler, weshalb mir die Lösung mit dem "Gehänge" bisher ausreichte. Ich war schon froh, dass die Platine nicht nackelig herumhängt.
Eine Sache noch. Wenn es geht, nimmt bitte die Metall-Schirmung von den DSUB9 Steckern ab. Die können Kurzschlüsse verursachen. Ich habe Angst, dass sich jemand den C64 schrottet. Ferner wäre es besser, wenn ihr den Yaumataca nicht während des Betriebes in den C64 steckt. So lange einer der beiden Ports drin ist, kann man ohne Probleme einen der beiden rausziehen. Nur von 0 auf 100 ist ein bissle gefährlich. Dadurch, dass da einiges USB mäßiges dran hängt, kann es passieren, dass der Strom am Anfang sehr hoch ist und die Spannung einsackt. Gleiches gilt für den Schutz der CIAs. Durch die Beschaffenheit der DSUB9 Stecker, wird GND nicht als erstes kontaktiert. Es ist ein bissle Glück.
Der hat Amiga für beide genannten Probleme einen Hardware-Schutz, weshalb er davon nicht betroffen ist. Beim C64 fehlt das alles oder ich finde es im Schaltplan nicht.
Warum heissen die Modi eigentlich S ( ... ) , R ( .-. ) und M ( - - )?
Dafür gibt es keinen Grund. Das war purer Zufall. Es hätte auch jede andere Blinkfolge sein können. Wichtig war mir nur, dass es überhaupt ein Feedback gibt.
Wenn Slamy mag kann er gern beide STLs hinzufügen (auch da bin ich ne GITHUB-Null)
Also zunächst einmal finde ich das Design wirklich schön.
<Kunst-Schwurbel>Es hat etwas uriges und drolliges in dieser beigen Farbe. Ich kann das gerne dem github Repo hinzufügen. Nur eine Frage vielleicht. Wie druckt man das überhaupt? Ich kenne STL bisher nur als Format für "Form" aber nicht für "Material". Aber vielleicht kannst du mich eines besseren belehren. Den Modus Schriftzug würde ich vielleicht nur etwas kleiner machen oder weg lassen. Der Morse Code ist ein netter Touch und scheint sowohl funktional, als auch Teil des Designs zu sein. </Kunst-Schwurbel>
Ich find den/die/das Yaumataca ja ziemlich cool, denke nur über eine optisch aufgeräumtere Variante mit weniger Kabelsalat nach, das erinnert ja schon fast an die Kabel/Adapter-Orgien an MacBooks mit nur 2 USB-C Buchsen.
Das Ideal wäre, wenn der USB Hub auf dem gleichen Platinchen untergebracht wäre, wie der RP2040. Nur kann das wahrscheinlich kaum einer noch mit der Hand löten.
Der Hub, der von dir genannt wurde hat leider das Problem, dass er eine USB Mini Buchse hat. Du musst ja dann zuerst vom Micro USB OTG zu USB A, um von dort zu USB B Mini zu kommen. Das wäre noch mehr Kabelsalat.
Theoretisch könnte man aber wahrscheinlich bei den Distanzen auch einfach den USB Hub an den Pico löten. Dafür braucht man aber eine ruhige Hand. Generell stimme ich aber zu, dass es dann aufgeräumter wäre.
