Also zumindest in den früheren Versionen des Emulators hatte ich sogar mit dem Pi400 einige Performance-Probleme, ich weiß nicht ob man sich mit einem Pi Zero hier einen Gefallen tut
Ich hab im Discord mal den Xemu Entwickler befragt - der sagt auch ein Pi 5 sollte es schon sein. Er meint die Genauigkeit der Emulation ist dafür verantwortlich dass das nicht schneller geht.
Wobei diese nicht das "Problem" der unpassenden Tastatur Belegung lösen. Mich irritiert das am Emulator zumindest ungemein.
Ja wenn man so enien "billig" Emulations Tastaturcomputer angeht, benötigt der natürlich schon eine angepasste Tastaturbelegung. Die Tastenanordnung wäre immer noch nicht ideal, aber besser wäre es auf jeden Fall.
Eine andere Möglichkeit wäre noch, ein leicht modifiziertes FPGA-Entwickler-Board (z.B. mit ausgewählten Schnittstellen wie Joystickports schon dabei) als "Kit" anzubieten, also komplett mit vorinstalliertem Mega65-Core und der Möglichkeit eine beliebige USB-Tastatur zu verwenden.
Ja das würde dann auch die Core-Entwickliung ermöglichen. Aber leider ist der FPGA das mit Abstand teuerste Bauteil von allen. Für den, der im Mega65 steckt finde ich Preise von knapp oder rund um 300 Euro - for den Chip alleine! Die kleinere 100T Version würde es für den Mega65 (nicht alle alternativen Cores) ebenso tun. Aber die ist immer noch teuer. Mit FPGA wird es leider nicht billig - außer vielleicht in 10 Jahren wenn die als Einstiegschips vertrieben werden.
Es fällt mir noch ein - es gibt sogar ein FPGA Entwicklungs Board auf dem der Mega65 Core läuft - wurde für Prototypenentwickling verwendet und funktioniert meines Wissens nach immer noch. Da lehne ich mich aber ein wenig aus dem Fenster - hier können sicher andere besser Weiterhelfen!
Also zumindest in den früheren Versionen des Emulators hatte ich sogar mit dem Pi400 einige Performance-Probleme, ich weiß nicht ob man sich mit einem Pi Zero hier einen Gefallen tut
Tatsächlich? Das wundert mich nun doch, weil "soo" anspruchsvoll ist ein Mega65 nun auch nicht. Aber gut - man könnte immer noch einen Pi 500 hernehmen - nur mit unter 100 Euro kommt man halt nicht mehr hin. Dafür aber schon mit Gehäuse und es würde mich nicht wundern wenn schon jemand Commodore Style Aufkleber dafür entworfen hätte.
Gehäuse und Tastatur sind sehr hochwertig und das eingebaute Diskettenlaufwerk schlägt sich auch auf den Preis nieder, ist aber ebenfalls ein Alleinstellungsmerkmal.
Vielleicht sollte man irgendwann doch über eine kostengünstigere Variante nachdenken, um mehr Leute zu erreichen.
Die Idee kommt immer wieder auf, aber gerade das Diskettenlaufwerkt macht den geringsten Teil der Kosten aus. Dafür müsste man aber die Gussformen für das Gehäuse erneuern/nacharbeiten was zu noch mehr Extrakosten auf der Produktionsseite führen würde. Der hohe Preis ist halt ein Zusammenspiel vieler Dinge - gute Tastatur, Kleinseriengehäuse, Produktion in Europa...
Zum Ausprobieren kann man ja immer den Emulator heranziehen - der kostet erstmal garnichts. Und schön langsam kommt in mir die Idee hoch, ob man nicht eine günstige, gerne auch mechanische, Tastatur mit einem Raspi Zero verheiraten könnte, so dass er gleich in den Mega65 "bootet". Ein schönes Gehäuse dazu ausdrucken und man landet bei ca. 100 Euro. Mag sich jemand an so ein Projekt machen? 
Achja, Commodore Style Tastenkappen brauchts dann noch, da gibt es ja meines Wissens nach mittlerweile auch Lösungen.
Noch ein Nachtrag - eine kurze Websuche ergibt - da gibt es zuhauf Projekte an denen man sich orientieren könnte. Das (für mich) schwierigste scheint mir ein Setup das direkt in den Mega65 Emulator bootet, mit möglichst wenig Linux dazwischen. Um der realistischeren Bedienung wegen.
Ich nutze es gerne. Die Haptik der Disketten gehört einfach dazu, und alles was ich selber herumbastle kommt auch auf Disketten.
Auch war faktisch immer ein nervender Screenreader Speech nach dem Login eingeschaltet. Den konnte ich mit CAPS LOCK halten und S ausschalten.
Das ist interessant, denn das hatte ich auch einmal. Und als ich versuchen wollte der Sache auf den Grund zu gehen hat es sich, vermutlich bei einem Update, von selber behoben. Ich habs auf meine recht spezielle Konfiguration auf dem Gerät zurückgeführt, aber wenn du das auch hattest...
Gewünschtes DE aktivieren mit:
sudo update-alternatives --config x-session-manager
Eigentlich sollte man das auch nach dem Start im grafischen Login Manager auswählen können. Darum heißts ja auch "Login Manager" - aber so gehts natürlich ebenfalls.
Der Weg über eine saubere Raspberry OS LITE Installation ist wohl besser für Produktivzwecke auf der SSD.
Sehe ich auch so - ausprobieren und dann das fix installieren das einem am meisten zusagt.
Danke, das war wohl ein PEBKAC meinerseits, hatte das nicht richtig gelesen u.a. Please login to see this link..
Ja, aber wie gesagt - hat hier eh keine Auswirkung.
Ich habe die Schritte bei der SSD Installation so wie beschrieben gemacht und da war kein grafisches Login verfügbar nach der Cinnamon Installation und Reboot und auch nach dem Raspi-Config.
Ob das sudo apt install cinnamon (bei Euch) vs sudo apt install cinnamon-desktop-environment (bei mir) den Unterschied macht?Oder vielleicht dass ich einen 43" Dell (3840 x 2160 px) via HDMI angehängt habe?
Nein, ich habe ja eben genau deine Anleitung befolgt und cinnamon-desktop-environment installiert. Die Auflösung vom HDMI Monitor ist es sicher auch nicht. Darum wäre ich dankbar wenn das noch jemand testen könnte.
All das sollte garnicht notwendig sein! - ein einfaches "apt install cinnamon" reicht auch und genau darum geht es. (bzw. darum warum es möglicherweise doch nicht immer reicht)
Hier also die ganze Anleitung Schritt für Schritt für DAUs like the rest of us:
So. Ich habe mich jetzt hingesetzt und deine Anleitung Schritt für Schritt nachvollzogen. Und was soll ich sagen?
Ich installiere also:
sudo apt install cinnamon-desktop-environment
Danach neu gestartet - es kommt wieder die Kommandozeile. So weit, so wie erwartet.
Jetzt noch "raspi-config" und auf grafischen Boot umstellen.
Nochmaliger Neustart und es kommt ein grafischer Login Manager!!
Das ist zwar das was ich eigentlich erwartet hätte, aber nicht das das du beschrieben hast. Für eine Problemlösung ist das jetzt natürlich nicht optimal. Meine ursprüngliche Vermutung war, dass cinnamon-desktop-environment aus irgend einem Grund keinen Loginmanager mitinstalliert und das Paket von gldriver-test einen solchen über eine Abhängigkeit nachholt. Darum habe ich auch noch "gldriver-test" nachinstalliert - das hat jedoch in meinem Fall keine unerfüllten Abhängigkeiten.
Auch meine Frage ob dasselbe Problem bei der Installation von xfce auftritt bezog sich darauf. Bei KDE weiß ich dass ein Loginmanager mitkommt.
Eines ist mir jedoch noch aufgefallen:
sudo apt install cinnamon-desktop-environment -y
ODER sudo apt install cinnamon-desktop-environment #minimal -y (weniger Apps & co)
ODER sudo apt install cinnamon-desktop-environment Please login to see this link. -y (noch weniger Ramsch)
Das ist nicht korrekt. Zuerst glaubte ich, du hast eine neue apt Syntax gefunden die ich noch nicht kannte, aber die Raute ist nur ein Kommentar das ignoriert wird. Korrekt wäre folgendes:
sudo apt install cinnamon-desktop-environment
sudo apt install cinnamon
sudo apt install cinnamon-coreAuf den Test hat das aber keine Auswirkung. Bei der von dir angegebenen Variante wird einfach auf jeden Fall immer der volle Desktop installiert.
Insgesamt ist das leider kein befriedigendes Erlebnis. Schön wäre wenn das noch jemand testen könnte! Ich bin im Moment ohne Ideen.
Danke Dir, Saiki. Das werde ich mit meinem auch mal testen, dann mit XFCE. Das mag ich mehr als Cinnamon.
Wenn du das machst, versuche mal ob xfce ohne die zusätzliche Installation von gldriver-test startet.
Ich habe da so eine Vermutung die ich aber erst am Abend selber probieren kann.
Cool, Rechner mit Parallelport, ich habe mich nämlich gewundert wie man heute auf PCs zu GPIOs kommt.
Aber die Sache ist die. Da hat sich jemand die Arbeit gemacht, all die komplexen Installationsroutinen in eine Setupdatei zu packen um es dir möglichst einfach zu machen - großartig.
Hätte ich das gebaut (kann ich nicht, aber mal angenommen), gäbe es dafür ein .deb Paket dass du am Raspi mit Doppelklick, oder einem einzelnen Befehl in der Kommandozeile installieren könntest. Für Windows müsstest du dann allerdings einen Developer Account anlegen, Visual Studio installieren und dich in die Hardware APIs für den Parallelport einarbeiten. Also sehr wohl die oben erwähnten DLLs selber zusammenfrickeln.
Nur gut das ich das nicht kann - das gäbe erst Beschwerden
Ja, gerne Auslagern, wenn die anderen Beteiligten auch interessiert sind, wüsste ich das wirklich gerne.
Hier melde ich mich dann, wenn ich das mit dem alternativen Desktop am Raspi vom Lite Image ausprobiert habe.
Ahja, letzteres hat sich wohl erledigt, auch schön
Wede es aber trotzdem nochmal nachstellen
Wie gesagt, evtl mein festgefahrenes Hirn. Und Bequemlichkeit. Wenn ohne machbar, sollten solche Installorgien nicht mehr nötig werden. Ja ja ja: Paketmanager...aber auch für DB9?!
Mal so aus ehrlichem Interesse, wie würde man dieses Problem unter Windows lösen?
Beide Varianten sollten zu dem gleichen Ergebnis führen, genauso würde ich es auch machen. Das Einzige das mir noch einfällt, vielleicht schert sich das Raspberry Pi OS nicht ums "default graphicl target". Das sollte es zwar, aber wer weiß was genau die daran gemacht haben.
In raspi-config kann man einstwllen ob er in die Kommandozeile oder ins GUI starten soll. Vielleicht hilft das.
Heut Abend kann ich das mal auf einem Pi ausprobieren, falls du noch keine Lösung gefunden hast.
Tu dir nichts an, auch nach 25 Jahren Linux sitze ich auch noch öfters lange an einem Problem. Das hat nichts mit dem Erfahrungslevel zu tun, nur die Sachen an denen man hängt werden komplizierter - und man lernt dabei.
Versuch mal bei Windows oder Mac OS die graphische Oberfläche zu tauschen. Wie lange würdest du wohl daran sitzen?
Die Fehler haben nichts mit xfce4 oder einem Desktop zu tun, sondern mit Kernel Modulen die nicht direkt beim Linux Kernel mitgelifert sondern manuell (beziehungsweise über externe Quellen) installiert wurden. (Please login to see this link.)
In deinem Fall sieht das, dem Namen nach, nach Gamepad sowie DB9 Treibern für die Raspi GPIO Pins aus. Eine kurze Suche lässt mich auf RetroPi als Quelle schließen. Diese konnten nicht installiert werden, entweder weil nicht vorhanden, oder weil ein Problem vorliegt oder warum auch immer. Wie fireball schrieb, ist das nur ein Problem wenn du entsprechende Geräte (alte Orginalhardware) an den Pins des Raspi anschließen willst.
Ganz allgemein ist es so, sobald man bei Linux Distributionen beginnt, Dinge an der Paketverwaltung vorbei zu installieren, beginnen auch die Probleme. Willst du dir ein schönes Retro-Emulations Setup basteln, kommst du aber vermutlich nicht darum herum. In dem Fall würde ich tatsächlich eine eigene SD-Karte nur für diesen Zweck erstellen. Alles installieren und dann nie wieder updaten. Für andere Arbeiten, dann die interne Disk.
Nachtrag - der Fehler wird vermutlich bei jedem Update wieder angezeigt. Wenn dich das stört, im Please login to see this link. habe ich was gefunden, dass nach einer Lösung aussieht. Aber natürlich wieder Drittquellen... naja.
Gibt es auch XFCE?
"sudo apt install xfce4 xfce4-goodies"
Das kann schon etwas mehr als der Standard LXDE Desktop vom Raspberry Pi und garantiert auch dass du nicht versehentlich Wayland verwendest - weil XFce derzeit (noch) nur X11 unterstützt. Das war lange Zeit mein Standard Desktop für Menschen die nicht so verrückt wie ich sind ums sich "Tiling Window Manager" anzutun.
die Erklärung ist wahrscheinlich länger als das eigentliche doing.
Und das ist die Geschichte, die mich am Linux so ankotzt. Jeder meint, da irgendwas rumfrickeln zu müssen. Da kommt dieses "Superhirn" mit seinem chaissendreck systemd. xzig verschiedene Konfigs, nichts ist einheitlich. Jeder Honk meint, an der guten alten funktionierenden Syntax von einigen daemons irgendeinen Mist dranfrickeln zu müssen.
Gegen diesen Schoaß ist ein klassisches SysVR4 á la Irix oder ein 4.4 BSD eine reine Wohltat. Da läuft alles wie gewohnt, und man braucht keine xzig Schrauben, um z.B. diese vollends schwachsinnige Farbgebung beim Editor oder ls anzudrehen.
z.B. Ubuntu 22 - wir ziehen erst mal irgendwelche Patches, crashen den Software-Installer, lassen locks liegen und verhindern das Update permanent crashender applikationen, weil, das graphische blurps ja so scheiße bunt und toll aussieht. RHEL hat wenigstens dnf oder yum und ist halbwegs erträglich (damit meine ich NICHT gut ...)
Insbesondere die ganzen dependencies plus der Chaiss, der automatisch installiert wird, blos weil jemand meint, möglichst viel Müll (solitaire ? wtf) mit auf die Platte hauen zu müssen, geht mir massivst auf den Keks.
Und weil ich mir solche Aufregung ersparen will, verwende ich schon seit vielen Jahren ganz einfach Debian und das läuft. Früher hab ich mich auch mit Gentoo, Arch und anderen Distris herumgespielt und dabei viel gelernt(!!) - aber wer auf wenig Veränderung steht, für den ist Debian grade richtig. Ich habe Systeme die ich seit 2012 nie neu installiert, sondern immer nur aktualisiert habe. Das will schon was heißen.
Schön wenn KDE gut funktioniert - zu einem kompletten Wechsel wollte ich da angesichts der eingeschränkten Leistung der Pis erstmal nicht raten, aber KDE Ost natürlich die deutlich modernere DE
Vergiss die Leistungsangst. Meine derzeitigen Hauptrechner sind ein Pi 5 und ein Intel N150 - die sind in einem ähnlichen Leistungsbereich (der Intel nur wenig schneller) und man spürt KDE überhaupt nicht. Alles was schneller als ein Pi 4 ist schafft das aus meiner eigenen Erfahrung locker.
Dazu muss ich noch anmerken, dass ich vor einem Jahr noch ausschließlich mit wirklich schlanken Desktops wie i3 und Sway unterwegs war und so wie du über KDE gedacht habe. Die Erfahrung hat mich mittlerweile eines Besseren belehrt.
