Beiträge von 0xdeadbeef

  • Kennt Jemand dieses Modul?

    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.

  • Kennt Jemand dieses Modul?

    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.

  • Kennt Jemand dieses Modul?

    Zitat von Miyagi1980

    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.

  • Kennt Jemand dieses Modul?

    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!?

  • Kennt Jemand dieses Modul?

    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.

  • SPI-LCDs mit dem RasPi (Zero 2 W) "Best Practice"

    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.

  • Heute so gecodet...

    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...

  • Bobbel kämpft mit Blackscreen ASSY 250407

    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.

  • C64 Game Maker

    Irgendwie habe ich erst jetzt so richtig realisiert, daß der Game Maker zwar letztendlich einen C-Compiler benutzt, aber wohl innerhalb der IDE nur den eigenen Basic-Dialekt unterstützt, der dann nach C übersetzt wird.

    Das finde ich schade, denn was ich mir eigentlich wünschen würde, wäre eine Art C-IDE in einem Rundum-sorglos-Paket (mit Sprite/Char-Editoren usw.).

  • Heute so gecodet...

    Echt? Bin mir relativ sicher, daß wir vor 10 Jahren oder so in der Firma ein Excel mit >28000 Zeilen hatten, um alle möglichen Kombinationen einer "Invalid Operation" einer Float-Einheit zu erfassen.