Wobei ich in der V1.2 ja wie erwähnt extra die SMD-Diodennetzwerke auf die Rückseite geklatscht habe, damit man das nicht mehr braucht.
Posts by 0xdeadbeef
-
-
Die bipolaren("SU") Elkos kann man durch die Bank mit "normalen" Elkos ersetzen. Besondere Anforderungen gibt es eigentlich nirgends außer bei den Spannungen - die sind mehr oder weniger ernst gemeint.
1%-Widerstände braucht man eigentlich nur in der Überspannungsschaltung:
QuoteUse 1% resistors for the critical resistors in the voltage protection circuit (R6, R8, R9, R10, R12).
Da ist allerdings mit R12 ein 1k-Widerstand dabei. Im Zweifelsfall halt selektieren.
-
Über bloßes Herumraten sind wir eigentlich längst hinaus. Die Funktionalität des Moduls ist relativ klar. Für was es exakt eingesetzt wurde, werden wir vermutlich nie genau wissen.
Aber es wird was wohl eine Art Steuerung/Regelung für irgendwas gewesen sein (Analogwert rein, Frequenzsignal raus).
-
Kann gut sein. War zu faul und müde, um darüber nachzudenken
-
Den Opamp hätte ich andersherum gezeichnet. Aber auf den ersten Blick bestätigt das meine Einschätzung, daß das zwei getrennte Schaltungsteile sind.
Der Eingang geht über den Opamp auf den ADC und dessen BCD-Ausgänge usw. gehen auf den Userport. Also eine AD-Wandlung, deren Wert am Userport eingelesen wird.
Der SID geht als Eingang auf die PLL. Der Zähler ist nur Teil der PLL-Schaltung (teilt den rauskommenden Takt durch irgendwas um ihn als Referenz zur Synchronisierung mit dem Eingangssignal zu benutzen).
Das Relais dient dazu, entweder das Eingangssignal der PLL (also den Takt? vom SID-Ausgang) oder den Ausgang der PLL auf das NAND-Gatter zu schalten, das als Ausgangstreiber mißbraucht wird.
Das Relais wird vom Userport aus geschaltet, das Poti dient nur zur Abschwächung des Ausgangs.
Ich kann da jetzt aber trotzdem keinen tiefere Sinn drin erkennen. Man kann einen Analogwert in den C64 einlesen und über den SID ein Rechtecksignal ausgeben, das entweder direkt aus dem SID-Signal abgeleitet ist oder über eine PLL auf eine höhere Frequenz hochgesetzt wird.
Der Entwickler hatte wohl eine Anwendung dafür, aber so richtig spannend kann die irgendwie nicht gewesen sein. Eventuell war das so eine Art Regelungseinheit. Also ein Kennwert wurde als Analogwert in den C64 eingelesen, daraus eine Ansteuerfrequenz berechnet, die dann über den SID und die PLL-Umschaltung ausgegeben wurde, um den Kennwert in eine Richtung zu bewegen. Oder so.
-
Eine Trennung in Sender und Empfänger würde zwar die separaten (?) Schaltungsteile für In und Out erklären, aber ansonsten paßt IMHO nichts zu SST wie es im Artikel beschrieben ist.
Und wie gesagt: der ADC sollte eigentlich nur mit 96Hz wandeln, was OK für ein Multimeter oder so ist, aber sonst für so ziemlich gar nichts.
Und solange nicht jemand mit einem kompletten Schaltplan ums Eck kommt und sich zeigt, daß die PLL und der Zähler für etwas komplett Unerwartetes eingesetzt werden, denke ich nach wie vor, daß damit aus einem SID-Signal eine Frequenz generiert und als Rechtecksignal auf Out ausgegeben wird.
-
Also ohne mit das jetzt noch einmal im Detail angesehen zu haben: ich denke nach wie vor nicht, daß das was mit Audio zu tun hat.
Vermutlich wurde der SID benutzt, um ein Rechtecksignal (o.ä.) einer bestimmten Frequenz zu erzeugen, das dann in die PLL geht.
Was ich jetzt auch erst richtig wahrgenommen habe: der CA3162 hat eine eigene Samplingfrequenz, die entweder 4Hz oder 96Hz beträgt.
Weil Pin6 auf 5V liegt, wandelt er mit 96Hz. Eigentlich scheint es ausgeschlossen zu sein, daß dieser ADC für irgendeine höhere Abtastfrequenz benutzt werden könnte.
Das Relais scheint ja nur zwei verschiedene Frequenzabgriffe von PLL/Zähler auf das NAND-Gatter zu schalten, daß aber anscheinend eher als Treiber misbraucht wird.
IN1A/IN1B sind kurzgeschlossen. OUT1/IN2A/IN2B sind kurzgeschlossen. Also doppelte Invertierung. Der Ausgang OUT2 geht dann aufs Poti, das wahrscheinlich nur benutzt wird, um das Frequenzsignal abzuschwächen.
Der Schaltungsteil "SID -> PLL/Zähler -> NAND -> Poti -> Out" sieht also wie ein Rechtecksignalgenerator mit einstellbarem Pegel aus.
Der Schaltungsteil "In -> Opamp -> ADC -> Userport" sieht nach einer davon weitestgehend unabhängigen 96Hz-Abtastung des Signals an "In" aus, die dann vom C64 am Userport eingelesen wird.
Auf den ersten Blick sehe ich die Verbindung zwischen diesen beiden Funktionalitäten nicht.
-
Aber ich finde es als Laie total faszinierend, dass man trotz Bestimmung der verwendeten Bauteile, Aufbau und dem Fachwissen hier nicht, oder zumindest nicht so einfach darauf schließen kann um was es sich handelt und für was es da ist. Magical
Hat sich halt noch niemand die Mühe gemacht, einen Schaltplan zu erstellen und nur mit den Fotos wäre das auch ziemlich anstrengend/fehlerträchtig. Zumindest ich kann auch bei dem 74xx die genaue Beschreibung nicht lesen.
Insofern raten wir herum, weil uns Informationen fehlen. Ich halte es aber auch für möglich, daß man selbst mit vollem Schaltplan nicht genau wissen wird, für was das Ding genau gedacht war.
Was genau mit den ADC-Werten gemacht wird, würde sich erst durch die unbekannte Software erschließen. Und wir wissen ja nicht einmal, ob das Teil jemals funktioniert hat oder nur eine Testrakete von jemandem war.
Ich halte Stimmverzerrer oder andere Audioanwendungen aber auf den ersten Blick für unwahrscheinlich. BNC benutzt man eigentlich nicht für Audio sondern eher für Meßtechnik oder Funktechnik.
-
Die Bauteile (PLL, ADC mit BCD-Ausgang, Zähler) verweisen auf die Abtastung eines Analogsignals mit einer einstellbaren Frequenz.
Die BCD-Ausgänge des ADCs CA3162 gehen definitiv auf den Userport, also wird auf jeden Fall ein Analogwert digitalisiert und digital am Userport ausgelesen.
Soweit ich das sehen kann, ist der Hold/Bypass-Pin mit der PLL verbunden. Ich würde nach wie vor vermuten, daß mit der PLL und dem Zähler die Abtastfrequenz eingestellt wird.
Ein Relais könnte in diesem Kontext z.B. zur Bereichsumschaltung oder Umschaltung der Impedanz dienen. Aber die Pins 1/12 scheinen eher mit Zähler und PLL verbunden zu sein.
Also sieht es eher so aus, als könnte man damit zwischen zwei Frequenzen umschalten oder so!? -
Vielleicht auch die Hardware für ein einfaches Oszi?
-
HCF4046 ist eine PLL, HCF4518BEY ist ein 4Bit-BCD-Zähler. CA3162E ist ein ADC, der ein dreistelliges BCD-Display ansteuern kann. CA3140E ist ein Opamp.
-> Irgendeine Art von ADC, wobei die BCD-Ansteuerung vermutlich an die Userport-Pins geht, um den Wert digital einzulesen.
Vermutlich kann man mit dem Drehschalter die Abtastfrequenz einstellen.
Oder so.
-
Nicht konkret. Das war mehr so eine Sache von wegen "besser haben als brauchen".
-
Ich will in einem RasPI-Projekt Text und Grafiken auf einem LCD ausgeben, aber nicht notwendigerweise im Sinne einer Desktopanwendung.
Ich habe mir dafür ein Waveshare 3.5" LCD (B V2 version , IPS, 480×320) besorgt. Hauptgründe für dieses Display waren das IPS-Display und die Steuerung der Hintergrundbeleuchtung über PWM.
https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(B)
Eigentlich hatte ich ursprünglich nicht vor, das Display zur Anzeige der Konsole und/oder des Desktops zu verwenden, aber um es mal auszuprobieren, habe ich auch mal versucht, es laut Anleitung zu installieren.
Weil ich meinen Pi Zero 2 W erst gerade eben aufgesetzt habe, wurde mir BookWorm 64bit empfohlen, also habe ich das installiert.
Neben anderen Problemen führt das leider dazu, daß die einfache Installation des Treibers nicht funktioniert.
Ich habe mich dann durch diese etwas verworrene manuelle Konfiguration gekämpft, bei der auch so einiges nicht auf Anhieb geklappt hat:
https://www.waveshare.com/wiki…_(B)_Manual_Configuration
Aber am Ende wurde mir eine Konsole angezeigt. Hatte zu diesem Zeitpunkt auch "Boot to CLI (o.ä.)" ausgewählt. Umschalten auf den Desktop hat nicht funktioniert. Teils bin ich dann auch nicht mehr per SSH auf den RasPi gekommen.
Also habe ich wieder auf "Boot to CLI" umgestellt und mal spaßeshalber versucht, mit "cp /dev/random /dev/fb1" in den Frame Buffer zu schreiben. Das hat im Prinzip funktioniert, aber ein Zeichen wurde wieder von der Konsole überschrieben.
Vor allem aber hat in dieser Kombination der Login über SSH extrem lange gedauert (10 Sekunden oder so statt sofort). Ich vermute, daß es irgendwie daran liegt, daß der Treiber nur mit X11 funktionieren würde, aber die Umstellung auf X11 unter den neuesten Bookwork-Versionen nicht mehr funktioniert. Oder was auch immer.
Nun war Bookwork 64bit anscheinend auch Anfang 2025 noch eine schlechte Wahl, wenn man damit eigentlich überall nur Probleme bekommt, aber eigentlich wollte ich das Display ja eh nur "direkt" ansteuern. Schreiben in den Framebuffer klang zwar irgendwie verlockend, aber direkte Kontrolle über die zu schickenden Daten ist vermutlich eh besser. Nun benutzt mein Display anscheinend einen ILI9486 und keinen IlI9341, den ich schon bei diversen Mikrocontrollerprojekten benutzt hatte, aber irgendwie bin ich davon ausgegangen, daß es da auch diverse Bibliotheken für den RasPi geben müßte. Gibt es aber anscheinend nicht. Schon gar nicht als Teil von WiringPi (will ja in C programmieren).
Was mich zum meiner eigentlichen Frage bringt: was ist der beste/einfachste Weg, ein SPI-LCD auf dem RasPi als Ausgabe für ein einziges Programm zu benutzen (am Ende wird nur dieses Programm direkt beim Booten gestartet)? Speziell wenn man in C programmieren will.
Anscheinend scheinen 99.9% der Leute über einen Treiber und den Framebuffer zu gehen. Gibt es dafür einen speziellen Grund? Es erscheint mir irgendwie bizarr, ein winziges Display mit niedriger Auflösung zur Darstellung der Konsole oder des Desktops zu verwenden.
Und auf einem "nackten" Mikrocontroller ohne Linux würde man natürlich direkt per SPI Befehle schicken.
-
Streng genommen habe ich noch nicht wirklich was programmiert, aber die letzten Tage habe ich rumgebastelt, um auf dem Raspberry Pi Zero 2 W von meinem PC aus zu entwickeln.
Dank der Extension "Remote SSH" von Visual Studio Code kann man tatsächlich am PC entwickeln, kompilieren und debuggen, obwohl alles auf dem RaspPi läuft.
Sprich: der Quelltext liegt nur auf dem RasPi, der Compiler und der Debugger laufen auf dem RasPi. Trotzdem sieht es (fast) so aus, als wäre das ein lokales Projekt auf dem PC mit lokalen Tools:Leider ist Visual Studio Code halt speziell beim Einrichten eines Projekts etwas "sperrig" und das ganze ist leider eine ziemliche Übung in Geduld.
Geschätzt braucht es eine Minute, bis man nach dem Start von Visual Studio Code so richtig loslegen kann. Und wenn man eine Debug-Session startet, dauert es 15-30s bis man auf dem ersten Breakpoint steht.
Bin mir nicht sicher, ob das am langsamen WLAN liegt oder am Zero 2, aber es ist trotzdem toll, daß so etwas überhaupt funktioniert...
-
Habe oben noch rumeditiert. Das dritte Spiel is "Lester"
-
Wer kennt die Spiele, die da in dem Video in Post #34 gespielt werden. Das in dem Tower, wo sich das Sprite immer nur in horizontalen und vertikalen Linien bewegen kann, kenne ich. Wenngleich ich auch gerade nicht auf den Namen kommen.
Old Tower
https://retrosouls.itch.io/old-tower-commodore-64
Lester
https://knifegrinder.itch.io/lester
Nixy The Glade Sprite
-
Ich bin damals bei meinem 250407-Blackscreen u.a. nach den Hinweisen in diesem Buch hier vorgegangen:
https://github.com/petersieg/R…/Buch-Retro-Computing.pdf
War aber irgendwie nicht so hilfreich wie erhofft. Meine Scope-Messungen haben eigentlich nur gezeigt, daß der SID funktioniert und sich irgendwas auf der CPU tut, aber am Schluß habe ich doch mehr oder weniger alles gesockelt und getauscht, nur um am Ende festzustellen, daß es (entgegen der allgemeinen Meinung) doch die CPU war.
-
Sind "LLC_V2.zip" aus dem ersten Beitrag und "Modulatorhalter Jood SLC.stl aus #4 für ein Longboard (250466+) die aktuellste Versionen?
Irgendwas zu beachten?
-
-
Leider nicht