Mich würde mal eine Anleitung interessieren wie ich den Code aus Git heraus baue.
Zur zeit bekomme ich:
~/gitfiles/Sidekick64$ make
Makefile:89: ../Rules.mk: Datei oder Verzeichnis nicht gefunden
make: *** Keine Regel, um „../Rules.mk“ zu erstellen. Schluss.
Was ist besser als ein Sidekick? Zwei Sidekicks!
Dank eines Sidekick-Wannenstecker-Mods ist jetzt endlich Platz für 264+64=328 auf den von mir gern als Tischplatte bezeichneten improvisierten Holzbrettern.
sehr geiler Anblick - BEIDE Lieblinge beglückt!!!
sehr geiler Anblick
Vielen Dank! Da ich gerade die eine Platine noch gesäubert habe von Flussmittel, mache ich gleich noch ein Familienfoto meiner derzeitigen Sidekicks. Wenn ich Zeit finde, kann ich zu jeder Platine kurz noch was schreiben, wahrscheinlich aber heute nicht mehr.
ich hab 4x Möbelgleitpads von Ikea drunter geklebt
Hah... Bei mir wurde es ein Stück"Kofferfuß", den ich noch etwas zurecht geschliffen habe. Hält mit doppelseitigen Klebeband erstaunlich gut.
MegaPatch 64/128 V3.3r7 SnapShot 2020/05/10 läuft mit Sidekick64
Ich frage mich ab und an, wie man das Selbstbasteln eines Sidekicks vereinfachen kann, so dass mehr Interessierte an diesem Projekt im Stande sind, es eigenständig nachzubauen. Als ich im Januar als Tester meine erste Sidekick v0.1-Platine bestückt habe, hat es recht lange gedauert, bis diese dann auch tatsächlich funktioniert hat (bei mir hat sehr lange das OLED kein Lebenszeichen von sich gegegeben). Sidekick hat ja kein Eigendiagnose-System, welches auf dem OLED-Screen anzeigt, wo man gerade einen Fehler beim Löten gemacht hat (und es gibt wohl kein anderes Projekt, welches sowas böte).
Seit Frenetic die Sidekick-Platine v0.3 veröffentlicht hat, ist eine Hemmschwelle weggefallen: Die drei 257er-ICs sind eine Nummer gößer geworden und wesentlich einfacher zu verarbeiten. Allerdings ist es trotzdem so, dass man erstmal alles bestückt und am Ende hofft, dass auch alles funktioniert. Wenn dann am Ende nach dem Bestücken nichts funktioniert, ist Frustpotential da (und Euphoriepotential für den Moment, wo man die letzte schlampige Lötstelle korrigiert hat).
Eine Vereinfachung wäre am leichtesten zu erreichen durch einen Ausbau von Dokumentation - das wichtigste Stück Doku (der Schaltplan) ist ja aber schon längst vorhanden. Um dies auszubauen, frage ich mich, ob man eine empfohlene Bestückungsreihenfolge für die Platine ausarbeiten könnte, die neuen Sidekick-Bestücker einen frustärmeren Weg ermöglicht. Ich habe einen Vorschlag für den Anfang der Bestückungsreihenfolge der Sidekick-Platine, aber ich bin mir nicht sicher, ob es nach dem Anfang wirklich einen roten Faden gibt für einen sinnvollen Schritt-für-Schritt-Weg zur vollständig bestückten Platine.
Mein Vorschlag versucht einzig und allein, ein visuelles Feedback durch LEDs und OLED-Display frühzeitig in den Bestückungsprozess einzubringen. Man sieht an leuchtenden LEDs / leuchtendem OLED dann schon nach nur einem IC (dem 573er), dass man zumindest am Anfang schon soviel richtig gelötet hat, dass einige Dinge leuchten. Im weiteren Bestückungsverlauf kann man sich dann immer mal wieder vergewissern, ob die LEDs / das OLED immer noch leuchten.
Ohne jetzt noch weiter ins Detail zu gehen, als Sidekick-PCB-Minimalbestückung für ein erstes visuelles Feedback würde ich folgende Bauteile ansehen, siehe Foto. Wenn Interesse besteht, kann man diese Sache hier noch weiterspinnen. Oder ihr könnt sagen, warum das ganze Eures Erachtens keine gute Idee ist.
Vorschlag für Minimalbestückung, mit der man ein erstes Mal den Raspi mit Sidekick64-SD-Karte anschließen könnte, um zu sehen, ob LED(s) und/oder OLED hell werden. Natürlich sollte man keinesfalls in diesem Stadium den Expansionport des C64 mit ins Spiel bringen.
Einhängen des Raspis in Sidekick ohne 2x20-Buchsenleiste und natürlich ohne Verlöten. Das Gewicht der Sidekick-Platine sorgt (im Idealfall) für eine kleine Verkeilung, so dass 2x20 GPIO-Pins genug Kontakt haben für einen Schnelltest der Platine im Frühstadium.
hm, also ich muss sagen, dass die Sidekick64 - Platine sehr einfach zu bestücken ist und ich gar kein Zwischenstand-Feedback erwarte. Und das sage ich als Erst-SMD-Löter, welcher ja auch nur einen Teilerfolg bisher hatte. Das liegt aber an mir.
Aber als mäßig Englisch Versteher wünschte ich mir auch eine deutsche Dokumentation, aber das ist nicht primär wichtig.
Schön wäre nur zu wissen, was beim Booten von Sidekick64 passiert (Splash-Screen, LED-Orgel) und was passieren sollte, wenn man beispielsweise einen anderen Kernal oder Freeze (hab ich noch nicht probiert) lädt.
Generell ist Sidekick64 durch seine RaspberryPi-Huckpack Lösung etwas sperrig, was vielleicht auch abschreckt. Aber wenn ich das richtig verfolgt habe, könnte das Layout ja komplett gedreht werden., so dass Raspi und Sidekick64 als Sandwich (eher Doppelwoper 
) fungieren. Bzw. über Flachbandkabel ließe sich das ja auch lösen.
Wäre es denkbar, mit Sidekick ein Modem zu emulieren, über welches man via Wifi des Raspberry Pi ins Internet kommt und z.B. ein BBS aufrufen kann? Wäre ein weiteres cooles Feature!
Wäre es denkbar, mit Sidekick ein Modem zu emulieren, über welches man via Wifi des Raspberry Pi ins Internet kommt und z.B. ein BBS aufrufen kann? Wäre ein weiteres cooles Feature!
Wie lang darf die Antwort sein?
Es gibt jemanden, der momentan damit experimentiert, wie aufwändig es wäre, Netzwerk-Anbindung in Sidekick zu ermöglichen. Netzwerk-Anbindung ist noch keine Modem-Emulation zur BBS-Nutzung, aber die elementare Voraussetzung dafür. Da Sidekick in einer Bare-Metal-Welt angesiedelt ist, bekommt man nicht alles so geschenkt, wie man es von Linux her kennt. Das Bare-Metal-Framework Circle, auf dem Sidekick basiert, bietet Netzwerk-Features über Ethernet-Kabel schon lange, aber WLAN-Zugriff ist in Circle derzeit hochgradig experimentell und erst seit sehr kurzer Zeit möglich.
Ein Reinbringen von Netzwerk über Kabel (Raspi 3B+) oder WLAN darf Sidekick nicht aus dem "Kick" äh Tritt bringen - es muss gewährleistet sein, dass die Kommunikation über den Expansionport fehlerfrei bleibt. Die derzeitigen optimistischen Praxis-Erfahrungen sind, dass Sidekick auf einem Raspi 3B+ mit Netzwerkkabel recht stabil funktioniert - bei aktiver Netzwerk-Verbindung. WLAN hat dagegen sehr viele Tücken momentan. Es läuft prinzipiell - für eine Minute - und die Hälfte der Sidekick-Features funktioniert nicht mehr wegen Treiber-Problemen bei aktivem WLAN (CRTs-Starten geht nicht, AR oder FCIII gehen nicht) - aber SID-Emu und NeoRAM und PRG-Starten dürften gehen.
Frenetic hat ja alle seine Einzel-"Features" (Kernels) unter dem Dach des Menü-Kernels zusammengebracht. Der Menü-Kernel ist das bekannte Startmenü, von dem man überall hinspringen kann. WLAN-Netzwerk würde ich aufgrund der genannten Probleme eher als eigenen Kernel sehen derzeit, den man "mal" startet (=auf der SD-Karte umbenennt), wenn man "mal" was im Netz machen will. Dann wird aus dem normalen Menü-Kernel das destabilisierende WLAN rausgehalten.
Zum Thema "Applikation": Für eine BBS-Software via Sidekick gibt es mehrere Möglichkeiten, wie man vorgehen könnte. Das beste an BBS-Kommunikation ist meines Erachtens, dass sie unverschlüsselt über's Netz geht und der Sidekick-Kernel dafür nicht HTTPS-fähig sein muss, was noch eine andere Baustelle ist.
Fazit: Lange, bevor WLAN in Circle stabil geworden sein wird, wird Netzwerk über LAN-Kabel (am Raspi 3B+) in Sidekick wesentlich zuverlässiger funktionieren.
EDIT: Alles Gesagte gilt für Sidekick64 - nicht unbedingt für Sidekick264, da gibt es noch kaum Praxiserfahrungen mit Netzwerk und andere "Timings".
Danke für die ausführliche Antwort, emulaThor! Es freut mich, dass schon "jemand" mit einer Netzwerkverbindung für Sidekick experimentiert. In einem ersten Schritt würde ja eine LAN-Verbindung ausreichen, und wenn Circle irgendwann mal eine stabile Wifi-Verbindung bietet, kann man diese zusätzlich integrieren. Alles Schritt für Schritt!
Vielleicht noch ergänzend zu emulaThor : das "Gute" am C64 ist, dass man ihn vom Expansionsport aus anhalten kann -- z.B. um Netzwerk-Kommunikation mit dem RPi durchzuführen. Es ist (leider) so, dass alles was der RPi tut, ausser mit dem C64 zu kommunizieren, ihn bei seiner Hauptaufgabe leicht aus dem Tritt bringt. Es reicht schon ein Cache Miss bei einem Zugriff und der C64 stürzt ab.
Was mich u.a. davon abgehalten hat Modem/Netzwerk Emulation anzugehen ist, dass es mir so ein Henne-Ei-Problem zu sein scheint. Die Emulation dieses alten LAN-Bausteins auf anderen Netzwerkkarten scheint mir etwas nutzlos (oder?), nachdem heute alles verschlüsselt ist/sein sollte und der C64 das nicht schafft. Mit einem Geos-Treiber könnte man die Emulation des alten Bausteins vermeiden und direkter auf's LAN zugehen, aber den kann ich nicht schreiben. Einzelne Anwendungen könnte man bestimmt modifizieren, aber so ein bisschen fehlt mit da der Use Case bei einem 1,70€ Modem mit einem ESP8266
Das (W)LAN für Sidekick-Funktionalität zu nutzen und nicht direkt durchzureichen, was "jemand" gerade macht, erscheint mir viel sinnvoller...?
Danke für die ausführliche Antwort, emulaThor! Es freut mich, dass schon "jemand" mit einer Netzwerkverbindung für Sidekick experimentiert
Danke für Dein Interesse! "Jemand" hat mal den aktuellen, unfertigen Stand für kabelbasiertes Netzwerk in einem kurzen Video festgehalten. Die Netzwerk-Features sind derzeit experimentell und kein Bestandteil des aktuell verfügbaren Sidekick-Kernels.
Es wird über LAN-Kabel eine Connection mit DHCP gemacht, die aktuelle Uhrzeit reingeholt und es werden per HTTP ein paar "Kurznachrichten" von einem HTTP-Server reingelesen.
Ich frage mich ab und an, wie man das Selbstbasteln eines Sidekicks vereinfachen kann, so dass mehr Interessierte an diesem Projekt im Stande sind, es eigenständig nachzubauen.
Ich finde das Projekt auch spannend und wäre prinzipiell auch nicht abgeneigt,
aber wie ich bereits schon einmal erwähnt habe, werden die Augen mit der Zeit
nicht besser.
Früher (tm) konnte ich einhändig eine Platine löten die auf der anderen Strassen-
seit lag, heute löte ich Standard-Bauteile mit Leuchtlupe... (Sch..ss-Alter)
Mich hält also schlicht die doch umfangreiche SMD-Bestückung davon ab.
Zudem scheint die Materialbeschaffung nicht ganz so einfach zu sein, spezielle
IC-Typen usw...
Daher kämen für mich nur, entweder ein Fertiggerät, oder ein teilbestückter
Bausatz in Frage.
Mfg Jood
"Jemand" hat mal den aktuellen, unfertigen Stand für kabelbasiertes Netzwerk in einem kurzen Video festgehalten.
Oh oh, da hat sich ja "jemand" geoutet! 
Die Frage wäre ja auch - LAN für den 64er - okay, vielleicht um Daten mit dem PC oder Amiga oder ?? auszutauschen - aber MUSS ein 64er, mit seinem vergleichsweise WINZIGEN, pixeligen Anzeigemöglichkeiten wirklich UNBEDINGT ins Internet? Welche Seiten soll er denn da noch anzeigen? Der Amiga ist ja mit deutlich mehr Ram und wesentlich leistungsfähigerem Prozessor ja schon nahezu ausgeschlossen von heutiger Web-Technologie und hoffnungslos überfordert, auch nur den amazon-Shop anzuzeigen - also was will dann der 64er in dem Umfeld?
Das es technisch möglich ist, nen 64er ins WWW zu hieven - okay, das wurde schon gezeigt - aber braucht das tatsächlich jeder dann auch praktisch zuhause, weils IRGENDWIE möglich ist? Auch wenn man nichts lesen oder erkennen kann??
Dann lieber NUR nen Netzwerkanschluss und sicheren Datenaustausch bauen und das Internet doch mit dem PC durchforsten - schont sicher auch die Nerven des Einen oder Anderen 
aber MUSS ein 64er, mit seinem vergleichsweise WINZIGEN, pixeligen Anzeigemöglichkeiten wirklich UNBEDINGT ins Internet? Welche Seiten soll er denn da noch anzeigen?
Keine Webseiten, sondern zu BBS soll er Kontakt aufnehmen können. Deren Darstellung ist für Commodore-Rechner optimiert. Und davon gibt es einige, siehe hier:
für mich wäre Netzwerk ausschliesslich zur Dateifreigabe auf dem PC intereassant, also dass man auch seinen PC nach Stuff "durchsuchen" kann. Also einfach um die SD Karte zu schonen und damit den Slot des Pi. Also z.B. cifs oder ftp (was leichter zu handhaben ist für den Pi).
Schön, dass "Jemand" sich damit beschäftigt , ich kann sowas leider nicht .
Da der Raspberry Pi 3A+ keinen LAN Anschluss hat , wäre Unterstützung für WLAN oder USB-Netzadapter nötig.
Die Emulation dieses alten LAN-Bausteins auf anderen Netzwerkkarten scheint mir etwas nutzlos (oder?), nachdem heute alles verschlüsselt ist/sein sollte und der C64 das nicht schafft.
aber MUSS ein 64er, mit seinem vergleichsweise WINZIGEN, pixeligen Anzeigemöglichkeiten wirklich UNBEDINGT ins Internet? Welche Seiten soll er denn da noch anzeigen?
Zum einen ist das Internet ja nicht nur das WWW. Ich könnte mir eine Art "App Store" für den C64 vorstellen, auf den er direkt zugreifen könnte oder aber auch eine C64-only-Kommunikations-Software.
Aber ich persönlich würde auch nicht gleich das Web ausschließen wollen. In diesem Webrowser-Thread haben wir lang und breit die Machbarkeit diskutiert und ich bin nach wie vor davon überzeugt, dass der C64 rudimentär einen Gutteil des Webs anzeigen könnte (und zwar besser als mit Contiki) – wenn man ihm mit einem Web-Proxy unter die Arme greift. Was den Proxy angeht, stelle ich mir den als allgemein erreichbaren Server im Netz vor – aber notfalls (und sicherer) geht halt auch ein "privater" im eigenen Zuhause. Der Proxy würde nicht nur die (modernen CSS/HTML-5) Seiten so weit von Ballast bereinigen, dass der dabei herauskommende, mehr oder weniger reine Text, auf einem C64 darstellbar wäre (was durchaus denkbar ist), sondern natürlich auch die Ent- und Verschlüsselung der HTTPS-Kommunikation übernehmen.
Wenn man also ohnehin über einen Raspi die (W)LAN-Schnittstelle für den C64 realisiert, könnte man den natürlich auch noch mehr machen lassen als "nur" einen TCP/IP-Stack zur Verfügung zu stellen.
Ich fände den Spaß zwar etwas geringer, wenn das "Web-Helferlein" direkt am C64 steckt als wenn es ein allgemein erreichbarer "Daten-Reduktions- und Entschlüsselungs-Server" wäre – aber man nimmt, was man kriegen kann.
