Bei einem Emulator ist man froh, wenn die Software wie erwartet läuft. Man versucht nicht unbedingt, Details wie den Multiplexer in der PotX/Y-Leitungen in jedem Detail zu simulieren, zumal in einem Emulator ja keine echte Tastatur/Maus angeschlossen ist und viele dieser Details weitestgehend witzlos wären.
Beiträge von 0xdeadbeef
-
-
Man muß das nicht unbedingt an Demos usw. festmachen. So speziell wie die Abfrage einer Maus auf einem C64 funktioniert, wird das ein Simulator niemals exakt nachbilden.
Insofern ist es relativ leicht, eine Mausabfrage zu schreiben, die in einem Emulator wunderbar funktioniert und auf einem echten C64 nicht.
Auf einer FPGA-Lösung mit echten D-DUB9-Ports muß man das zeitliche Detailverhalten der PotX/Y-Pins zumindest so weit nachbilden, daß eine Maus im Prinzip funktioniert.
Ob das Verhalten wirklich in jeder Hinsicht das eines normalen C64 ist (wobei es da wegen analoger Komponenten usw. auch eine recht große Schwankungsbreite geben wird), wage ich aber auch zu bezweifeln.
Genauso wenig bilden FPGA-Lösungen die etwas kruden NMOS-Eigenschaften der C64-ICs nach. Oder den Jitter in der Takterzeugung usw.
Viele Leute haben eh falsche Vorstellungen von FPGAs. Die meisten MiSTer-Cores sind aus der MAME-Implementierung abgeleitet. Da wird nicht jeder ICs auf Gatterebene nachgebildet, sondern das im Simulator (MAME) implementierte Verhalten wurde in den FPGA übertragen. Mit all den Vereinfachungen, die damit einhergehen.
-
Die digitalen GPIOs des RP2040 haben keine 5V-Zertifizierung, in der Praxis passt das schon (Info und Tests). Clamping-Dioden gibt's nur an GPIO26-29 (wegen der ADCs), die hier aber nicht benutzt werden.
Da weint mein Ingenieursherz. Auf die Messungen eines Menschen mit fragwürdigem elektrotechnischem Hintergrund zu vertrauen statt den Angaben in den Datenblättern, erscheint mir kein nachvollziehbarer Ansatz.
Daß es an den normalen GPIO-Pins keine echten Clampingdioden (mit einem spezifizierten Maximalstrom) gibt, ist übrigens keine positive Aussage.
"The GPIO pins not connected to the ADC have a different clamping arrangement which tolerates applied voltages higher than the VDDIO voltage, but they are still ESD clamps. Permanent connection to e.g. 5V IOs is not a rated operational condition of the RP2040. The chip will likely survive accidental connection, though."
-
Nur so zwei Punkte, die mir dazu einfallen:
- Wieviel Strom zieht der RP2040 in so einer Situation (enge Schleife für Bitbanging)? Ich würde annehmen, daß eine moderne FPGA-Lösung vermutlich mit deutlich weniger Strom auskommt (20mA statt 40mA oder so).
- Soweit ich weiß, sind die GPIOs des RP2040 nicht 5V-tolerant, oder? Selbst wenn der RP2040 das eine Zeit überlebt, fließt dann ständig Strom durch die Clamping-Dioden.
-
Wurde eigentlich schon diskutiert, daß es seit zwei Wochen oder so eine 3.12a gibt?
-
Die Nutzung der 2MHz auf dem C128 ist bei SMB64 ein explizit unterstütztes Feature. Habe es mangels C128 nie getestet, aber das sollte schon gehen...
-
Wobei ich nicht 100% überzeugt bin, daß es so eine gute Idee ist, die Lüftungsschlitze beim C64C zuzupappen.
-
Wo bekommt man den halbwegs bezahlbar eine schöne schwarze Tastatur für den C64?
Die Tastatur ist ein Mechboard aus einer Sammelbestellung hier. Die Tasten sind die aus der Indigogo-Sammelbestellung hier.
Sind eigentlich "transparent black", aber das sieht man kaum.
Ob das zusammen bezahlbar war, sei mal dahingestellt
-
Natürlich ist der beige Brotkasten ikonisch, aber ich habe schon in den 80ern die Leute mit einem C64C beneidet.
Ansonsten wollte ich schon immer alles in Schwarz haben
(und natürlich ist da drin ein schwarzes 250466+
) -
Wobei ich Leaderboard eigentlich immer lieber mochte (*duck*).
-
R18 auf Masse?
Genau. Hatte beim Reinkopieren aus einem anderen Projekt ein zweites Masselayer "GND2" erzeugt, wodurch R18 auf der einen Seite nicht mit Masse verbunden war.
War im Schaltplan kaum zu sehen und im Layout habe ich zu sehr auf die automatische Prüfung gegen den Schaltplan vertraut.
Also mußte ich den Lötstopplack unter R18 wegkratzen, um die Masserverbindung durch eine Lötbrücke herzustellen.
-
War heute recht fleißig und habe einen MicroKey2 und zwei Platinen mit Dreifach-Stromquellen für eine Sensorsimulation aufgebaut (obwohl das Projekt für das ich gerade arbeite, so etwas wirklich in keiner Weise zu schätzen weiß und meine Firma meinen Arbeitsplatz eh nach China o.ä. verlagern will):
Die beiden weißen Platinen sollten eigentlich die letzte Version sein, nachdem die allererste Version überraschend gut funktioniert hatte und ein darauf basierender Prototyp mit Analogschaltern statt Dioden zur Umschalten der drei Stromquellen leider krachend gescheitert ist. Deshalb habe ich auch gleich zwei davon aufgebaut. Leider ist mir aber im Schaltplan ein peinlicher Copy&Paste-Fehler unterlaufen, wodurch das neue Feature (Erzeugung von 5V aus ~10V Versorgungsspannung mittels eines TL431 leider so überhaupt nicht funktioniert hat. Glücklicherweise konnte ich die Platinen durch einen Hack retten, der nicht brutal auffällig ist. Ich frag mich, ob ihn jemand sofort entdeckt.
-
Was im Prinzip bedeutet, daß die Tester ihre Testobjekte aus rechtlich fragwürdigen Quellen hatten.
-
Mag für Grafikprogrammierung genial sein, wenn man sich ein paar Monate eingearbeitet hat, aber ansonsten ist das halt so ziemlich die Antithese eines modernen Debuggers mit zugänglicher GUI.
-
Einen richtigen modernen Debugger für den C64 gibt es leider nicht. Es gibt halt die ganzen "Monitore" (oft auch in Freezer-Modulen usw.), die letztendlich nichts anderes sind als Kommandozeilendebugger.
Gibt es auch in Vice:
https://vice-emu.sourceforge.io/vice_12.htmlIn einer älteren WinVice-Version gab es auch mal eine minimale Debug-GUI:
-
Auf dem U64 kann man auch parallele Speeder benutzen.
-
Nicht im eigentlichen Sinne heute, aber die letzte Woche hatte ich endlich wieder an meinem "DAB+-Radiowecker"-Projekt gearbeitet, das ich ursprünglich vor sieben Jahren beginnen wollte und Anfang 2025 mit einem RasPi Zero 2 neu aufgesetzt hatte.
Nach einigen Ablenkungen durch anderen Kram, habe ich inzwischen einige wichtige Punkte erreicht:
- Ich kann das DAB+-Modul per API vom RasPi aus steuern bzw. Daten auslesen (per UART).
- Ich kann gleichzeitig einigermaßen flott (Scroll-)Text und Grafik auf dem 480x320 LCD (rechts) ausgeben. Inzwischen sogar mit Umlauten
- Ich kann die Helligkeit des LCDs über PWM dimmen.
- Ich kann Datum und Uhrzeit auf dem I2C SSD1309 OLED (links) ausgeben.
Im Vergleich zu meinen bisherigen Mikrocontrollerprojekten war das mit dem RasPi bisher ein ziemlich Krampf und alles dauert ewig.
Das Debugging ist grenzwertig, und die vielen Merkwürdigkeiten des RasPi überraschen mich stets aufs Neue..
Egal ob UART oder I2C: nichts geht auf Anhieb, alles hängt per Default am wechselnden CPU-Takt. Den I2C-Takt kann man nur in den globalen Systemeinstellungen ändern usw.
Außerdem ist die WiringPi-Library Äonen von dem entfernt, was ich mir normalerweise auf kleineren Mkrocontrollern aus dem Ärmel schüttele. Die I2C-Funktionen sind total rudimentär und unterstützen nur maximal 255 Bytes.
Statt alles in Interrupts mit verschiedenen Prioritäten zu machen, mußte ich jetzt für einigermaßen flüssigen Scrolltext auf Multithreading ausweichen. Im Prinzip läuft die Grafikausgabe auf dem LCD jetzt also auf einem eigenen Core.
Aus irgendeinem Grund gibt das DAB-Modul den Radiotext usw. als "wide char" mit 32bit aus, benutzt davon aber anscheinend nur ein Byte (letztendlich also ISO). Keine Ahnung, alles komisch.
Eigentlich war mein Plan, schon längst die Drehencoder und die beiden I2C-Sensoren in Betrieb genommen zu haben, aber irgendwie klappt nichts auf Anhieb und dauert viel länger als erwartet...
-
Ich weiß nicht wie du auf 32k Samples kommst.
Alles natürlich Zitate von der Homepage. Aber auch 380k ist mau.
Natürlich ist das kein Profi-Gerät.
Richtige Profigeräte kosten nach wie vor tausende Euros. Auch der DSLogic ist kein Profigerät. Aber er hat zumindest eine ganz brauchbare Hardware, eine offene Software und man kann eigene Protokolldecoder in Python dafür schreiben.
Wenn man an die Grenzen stößt, hat man immer noch die Option tiefer in die Tasche zu greifen.
Alles schön und gut, aber die Schubladen voll mit halbgarem Zeug zu haben, ist halt auch nicht optimal.
Und ja, ich habe ein paar solcher halbgarer LAs in meinen Schubladen...
-
Naja, ich habe eigentlich einen Intronix Logiport, das ist ein 34 Channel Logic-Analyzer
War eigentlich auch schon vor 20 Jahren veraltet. Aber Win11-Kompatibilität von LAs ist in der Tat ein Kapitel für sich.
-
Ihr seid immer so schnell begeistert, aber 32k Samples bzw. 128k im 8Bit-Modus wären schon 20 Jahren echt wenig gewesen. Man scheint den Triggerlevel nicht einstellen zu können (nur eingeschränkt über externe Vref) und ich finde keine Spezifikation der maximal zulässigen Eingangsspannung usw.
Leider sind die DSLogic Plus inzwischen auch recht teuer geworden. Früher gab's die teils für 70€ oder so mit vollem Speicher (256MBits). Habe mir vor ein paar Jahren einen U3Pro16 mit 2Gbit Speicher und USB3 gegönnt und nie bereut. Letztes Jahr oder so habe ich sogar mein ersten komplexes Decoderskript dafür (und für Sigrok, weil gleiche Codebasis) geschrieben.
