SID nachbauen

Es gibt 233 Antworten in diesem Thema, welches 54.704 mal aufgerufen wurde. Der letzte Beitrag (10. Juli 2017 um 13:55) ist von MGR3SA.


  • Habe mir den Source Code nicht angeschaut, aber müsste man da viel mehr machen, als diesen mit GCC für den ARM zu übersetzen und die Audioausgabe an den DA-Ausgang eines passenden Microcontrollers schicken?


    Ja, man müsste beispielsweise schauen wie man resid die Verwendung von double precision-Fliesskommazahlen abgewöhnt, weil Cortex M4-Mikrocontroller typischerweise nur eine Single-Precision-FPU haben. Blindes Ersetzen von double durch float wird vermutlich nicht direkt zum Ziel führen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Wir können ja mal die Mülldeponien rund um Norristown umgraben, vielleicht finden sich da ja die Masken und die Fertiungsanlagen.
    :weg:


  • Ja, man müsste beispielsweise schauen wie man resid die Verwendung von double precision-Fliesskommazahlen abgewöhnt, weil Cortex M4-Mikrocontroller typischerweise nur eine Single-Precision-FPU haben. Blindes Ersetzen von double durch float wird vermutlich nicht direkt zum Ziel führen.

    Zumindest ist die pure Anzahl von double-Arithmetik immer noch halbwegs überschaubar (siehe Anhang). Da sieht erstmal durch die naive (!) Brille nichts irre numerisch instabil aus, so dass das unbedingt doppelte Präzision bräuchte (die kriegt man aber auf PCs praktisch gratis, also warum nicht verwenden). Aber im Anhang sind ja auch nur die double-Deklarationen mit Initialwerten enthalten ;)

    Ich frage mich dennoch, ob die pure Rechenkraft eines ARM-Mikrocontrollers reicht, um die reSID-Synthese in Echtzeit hinzukriegen - echt keine Ahnung.

  • u-he Diva ist derzeit die beste Echtzeit-Simulation analoger Klangerzeugung. Das verlangt aber sehr viel Rechenpower, da ein ähnlicher Algorithmus wie bei der Bitte melde dich an, um diesen Link zu sehen.in Echtzeit genutzt wird.
    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

  • Zumindest ist die pure Anzahl von double-Arithmetik immer noch halbwegs überschaubar (siehe Anhang). Da sieht erstmal durch die naive (!) Brille nichts irre numerisch instabil aus, so dass das unbedingt doppelte Präzision bräuchte (die kriegt man aber auf PCs praktisch gratis, also warum nicht verwenden). Aber im Anhang sind ja auch nur die double-Deklarationen mit Initialwerten enthalten ;)

    Ich frage mich dennoch, ob die pure Rechenkraft eines ARM-Mikrocontrollers reicht, um die reSID-Synthese in Echtzeit hinzukriegen - echt keine Ahnung.

    Ich habe im Laufe des letzten Jahres den resid code gruendlich durchgeackert. Die eigentliche resid Engine laeuft zur Emulationszeit ausschliesslich mit integer Berechnungen, genauer gesagt mit fixedpoint arithmetik. Dazu werden aber umfangreiche Tabellen angelegt, in dem die Ergebnisse der komplizierteren Rechnungen abgelegt sind. Diese Tabellen werden in double berechnet und dann entsprechend skaliert und auf integer gerundet. Diese TAbellen werden beim initialisieren der Software erzeugt und spaeter nicht mehr veraendert.
    Deine Fundstellen in resid-double.txt beziehen sich im uebrigen (zumindest auf den ersten Blick) auf den rate converter, der aus dem Ausgangssignal mit 1MHz Samplerate dann die von der Soundkarte gewuenschte Frequenz erzeugt. Der resid-fp code liegt in einem eigenen Verzeichnis (resid) und duerfte auch noch mal doubles enthalten, welche aber nur in der Initialisiserungsphase benoetigt werden.
    Klar ist auf jeden Fall, dass dieser Ansatz recht viel Speicher benoetigt, da die vorberechneten Tabellen nicht gerade klein sind. Aber in 1 MB duerfte locker alles reinpassen. Nur eben nicht in 8kBytes oder was der ATMEGA beimSwinSID hat.

  • wenns hart auf hart kommt und auch mein letzter SID verbraucht ist, werde ich meine kleine Nichte mit ihrer Blockflöte neber mein 64er setzen. Der hört sich z.Zt auch so an :drunk:

  • Der resid-fp code


    resid-fp ist veraltet.

    Zitat

    Klar ist auf jeden Fall, dass dieser Ansatz recht viel Speicher benoetigt, da die vorberechneten Tabellen nicht gerade klein sind. Aber in 1 MB duerfte locker alles reinpassen.


    Nope:

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ein anderes Problem bei der Verwendung eines modernen Microcontrollers als Ersatz für den SID ist die Signalspannung im C64. Viele aktuelle Controller vertragen keine 5V an den I/O-Leitungen.

  • Ich denke mit einem FPGA ist man besser bedient als mit einem uController, einfach weil man das in Hardware schneller "rechnen" kann. Außerdem könnte man so die Filter noch dazuschalten via zusätzlicher Hardware.

    Hier ein Projekt, das den SID in vhdl nachgebildet hat:
    Bitte melde dich an, um dieses Medienelement zu sehen.

    EDIT: ok scheinbar wurde ein neueres video dazu schon gepostet (inklusive Filtern)

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Nun, die STM32-Familie ist 5 Volt-tolerant was I/O angeht. Vom Bus lesen dürfte also einfach gehen - auf den Bus schreiben braucht wohl noch Pegelwandler (?).

  • Ein anderes Problem bei der Verwendung eines modernen Microcontrollers als Ersatz für den SID ist die Signalspannung im C64. Viele aktuelle Controller vertragen keine 5V an den I/O-Leitungen.


    Das dürfte eines der kleinsten Probleme bei so einem Projekt sein - aktuelle Controller mit 5V-toleranten Pins und bidirektionale Pegelwandlerchips existieren.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Zum Thema FPGA Implementierung hat sich Dag bereits Ende letztes Jahr schonmal geäußert:

    Um das zu erreichen bräuchte "man" SIDs, die mit ausreichender Anzahl Probes
    direkt auf dem DIE ausgestattet sind, um die Messungen zu machen und ggf.
    auch festzustellen in welchen Parametern sich verschiedene SIDs nun ganz genau
    unterscheiden....

  • Der kennt die Parameter für die FETs auch nicht - sonst wäre es sicher schon realisiert worden!

    Die waren auch nicht konstant. Seit den Die-Shots ist schließlich bekannt, daß sich die Revisions zum Teil einzig vom Material unterscheiden und ansonsten identisch aufgebaut sind. Das reicht aber mit unter schon für deutliche Klangunterschiede aus.

    Außerdem könnte man so die Filter noch dazuschalten via zusätzlicher Hardware.

    Die Filter tatsächlich analog nach zu bauen, hat noch keiner versucht, oder? Da man ziemlich viele Parameter verändern kann, und nach Möglichkeit noch zwischen 6581 und 8580 wählen möchte, dürfte der Aufwand recht groß sein.

  • Ich habe mir mal ein paar Posts durch gelesen (nicht alle) und wollte nur mal anmerken, dass die PSoC 5LP Serie von Cypress einige sehr nützliche Eigenschaften für Audio-Zeug mit bringt:
    1. CPLD on Chip vergleichbar mit einem Bitte melde dich an, um diesen Link zu sehen. aber zusätzlich voll DMA fähig (in Verilog programmierbar)
    2. 64k ram +256k flash + 2k eeprom (max)
    3. 80mhz (max) Cortex M3
    4. 2 Kanal digitaler Filter mit 24bit Auflösung (DSP on Chip)
    5. Analoger "CPLD" ... Verschiedene programmierbare analoge Blöcke (OPAMPs, DACs usw.)
    6. Dynamische Pin-Zuweisung ... fast alle Ausgänge sind beliebig schaltbar (analog, digital usw.)
    7. 0,8-5V VCC (Voltage Booster on Chip), 5V TTL ohne levelshifter. zusätzlich können Ports mit eigenen Logikleveln definiert werden (1,8-5V)

    Leider muss man für die Entwicklungsumgebung Windows benutzen (kein Linux oder mac OS)

    Falls jemand Interesse an den ICs hat, kann ich noch 2-3 Bitte melde dich an, um diesen Link zu sehen. anbieten . (12€/Kit inkl Versand)

  • In der Bitte melde dich an, um diesen Link zu sehen." ist der SID drin.
    Weiß von Euch jemand worauf dieser basiert, bzw. ob die Filter da auch gehen?

    Update:
    Im Bitte melde dich an, um diesen Link zu sehen. sind die Filter drin.

  • Dieses Ding hätte eine gute Spezifikation für einen SID Ersatz:
    Bitte melde dich an, um diesen Link zu sehen.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Soweit ich weiss gibt es fuer den Propeller auch bereits eine SID-Implementierung

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Bitte melde dich an, um dieses Medienelement zu sehen.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.