Rekonstruierter Quellcode SwinSID Nano

Hallo,

Obwohl wir heute mehrere Optionen haben, ist das SwinSID Nano nach wie vor eine sehr beliebte SID-Alternative. Wir verwenden immer noch die Firmware "Lazy Jones fix" von 2014. Swinkels ist vollständig aus der Gemeinschaft verschwunden, und seine Website ist jetzt auch offline. SwinSID scheint also tot zu sein. Die SwinSID bleibt also beliebt, aber niemand kann in den Quellcode schauen, um zu sehen, ob es etwas zu verbessern gibt. Ich möchte dieser Situation ein Ende setzen und habe den Quellcode rekonstruiert.

Zu diesem Zweck habe ich die Firmware zerlegt und ausgiebig studiert. Danach habe ich allen Variablen wieder einen sinnvollen Namen gegeben und eine Menge Kommentare hinzugefügt. Wiederholender Code wird mit Makros dedupliziert.

Den Quellcode ist hier auf Github verfügbar:

https://github.com/dmantione/swinsid/blob/main/README.md

Zur Frage, ob es etwas zu verbessern gibt: Wenn du meine Kommentare leset, werdet du feststellen, dass die Firmware einige merkwürdige Probleme enthält, und einige davon sind niedrig hängende Früchte.

I don't think so. What do you mean by old and new? I do plan to take a look at Swinkel's final firmware and compare that with the Lazy Jones fix firmware.

Ich habe die allerletzte Firmware von Swinkels analysiert und hinzugefügt. Beide befinden sich jetzt im Build.

Ich habe das sicherlich gelesen, aber die Sache ist dass Codekiller auch aufgehört hat und nie einige Quellcode veröffentlicht hat. Ich fürchte, dass seine Arbeit als verloren betrachtet muss werden.

Übrigens, wenn jemand Firmware für den SwinSID HC oder SwinSID Ultimate hat, dann halte ich mir empfohlen.

Stimmt, der Thread gibt einen guten Einblick in die Hardware-Operation des SwinSID Ultimate; es ist mir klar, wie er die Schieberegister in Kombination mit SPI verwendet, um das Lesen aus dem SwinSID zu ermöglichen.

Für mich wäre dieser Ansatz nicht akzeptabel: Die 4 Schieberegister + CPLD + zusätzlicher Mikrocontroller machen das SwinSID so viel komplexer, dass die Verwendung eines schwereren ARM-basierten Mikrocontrollers sinnvoller ist. Daher würde ich für Verbesserungen bei einem einzigen Mikrocontroller bleiben, aber das muss nicht unbedingt der Atmega88 sein, es gibt inzwischen auch neuere AVR-Mikrocontroller auf dem Markt.

Swinkels hat nie etwas von einer Lizenz gesagt, ich habe ihn nicht um Erlaubnis gebeten, also könnte ich theoretisch gesehen einen Drohbrief von einem Anwalt erhalten. Da jeder die SwinSID-Firmware frei verwendet und Swinkels vollständig verschwunden ist, betrachte ich es als Abandonware, der Autor ist nicht mehr an seiner Kreation interessiert.

Es ist möglich, einen Atmega mit einer Fuse-Einstellung gegen Auslesen zu schützen, aber würde Codekiller so weit gehen? Wenn das Fuse-Bit nicht gesetzt ist, kann ich die Firmware einfach aus der SSU auslesen und sie dort analysieren. Ich denke, das wird bei der Entwicklung neuer Firmwares, auch für den Nano, sicherlich nützlich sein, da viele der Verbesserungen (wie ein besserer ADSR-Algorithmus) nicht spezifisch für die SSU-Hardware sind.

Ich denke das es sich lohnt, weil die SwinSID weiterhin beliebt ist. Das bedeutet notwendigerweise, dass ein Teil der Community SID-Musik über ein SwinSID hört. Sie ist vielleicht nicht der aktivste Teil der Gemeinschaft, aber das macht es nicht anders.

Wenn die Firmware des bestehenden SwinSID verbessert werden kann, wäre das ein Plus. Übrigens glaube ich nicht, dass die Verwendung eines 8-Bit-AVRs grundsätzlich falsch ist: Es können sicherlich situationen entstehen bei denen die Rechenleistung der begrenzende Faktor ist, aber nach dem, was ich jetzt gesehen habe (lies meine Kommentare), gibt es ganz viel sachen wobei es um Bugs oder Vereinfachungen handelt wobei mehr Rechenleistung kein Vorteile gibt.

Ich selbst habe übrigens ein ARM2Sid in meinem C128.