RasPi 2/3 als In-Place SID Emulator (Vorsicht: sinnfreies Spaßprojekt)

Hallo,

ich warte noch auf die Levelshifter (die vermutlich nicht mehr vor dem Urlaub aus China kommen könnte also demnächst etwas ruhiger werden). Dementsprechend kann ich noch keine Fortschritte beim Lesen der SID-Register vermelden.

Aber ich konnte es nicht lassen Stereo-SID-Support zu implementieren…

https://www.dropbox.com/s/oc0xwr100d3qecg/dualux.mp4?dl=0

(Stereo hört man beim Smartphone-Video natürlich nicht, aber die 6-Voices. Zum Vergleichen, das Demo gibt’s hier: https://csdb.dk/release/?id=108397)

SID-Bastler: Source kommt!

Kleine Updates...

1) das Lesen der SID-Register funktioniert jetzt fast stabil (mit einem Linux Realtime Kernel sollte es dann passen).

Als "Demo" hier ein Fake-Paddle (siehe schwingendes Ding unten in der Mitte) in Monster Buster:
https://www.dropbox.com/s/3ee5…rbhms/fakepaddle.mp4?dl=0

Das Lesen der Oszillator-Register macht noch etwas Arbeit: es wird zwar von reSID unterstützt, aber die SID-Emulation läuft ja asynchron. Nichts was man nicht lösen könnte, je nachdem, wie genau man es möchte.

Der Grund warum es vorher nicht funktioniert hat, war schlicht und ergreifend ein Missverständis meinerseits, wie der direkte GPIO Zugriff auf ganze Bänke funktioniert

2) testweise habe ich reSID-fp kompiliert/getestet... ich habe noch keine Beispiele, wo man einen deutlichen Unterschied hört (gibt's aber, muss ich mal raussuchen). Die CPU Last ist aber deutlich höher.

3) @SID-Bastler schaut sich die Hardware-Seite an, in der Hoffnung dem RPi die Timing-kritischen Aufgaben abzunehmen, dann könnte man auch RPi Zero u.ä. testen

RasPi-SID hatte Urlaub, aber dafür kann jetzt auch gleich ein Sound Expander (siehe FM YAM) mitemuliert werden. Das Video hier zeigt FM-Sound (YM3812) und SID simultan (ist etwas leise geworden):

https://www.dropbox.com/s/muzfkmm0pvmplrf/sidfm.mp4?dl=0

Das Demo gibt’s auch hier:

http://c64.xentax.com/index.php/fm-yam

https://youtu.be/dTyGnh0IOtU

Der OPL2-Emulator ist der, den auch Vice nutzt – eigentlich wollte ich einen (gefühlt) besseren aus MAME nehmen, aber da scheint es Unterschiede zu geben.

… als nächstes muss ich mal an der Robustheit, was das Interface (Level Shifter, AD-Wandler) und die Software (ALSA und Co) angeht, arbeiten…

Und wieder ein ungefragtes, geltungssüchtiges Update

Heute habe ich Player mit etwas anspruchsvolleren Timings getestet.

Mahoney’s Kapla läuft gut:

https://www.dropbox.com/s/2dzl…7z/kapla_mahoney.mp4?dl=0

LMAN’s Tunes sind ziemlich anspruchsvoll, aber das verbleibende Problem ist wohl meine (Noch-)Unwissenheit was Raspian und Soundstreaming angeht und eine evtl. nötige Umstellung des Emulations-/Mixingthreads – ist alles etwas Tricky in diesem Setting (daher insb. das Knistern und die Glitches; das laute Knacken hin und wieder kommt allerdings vom Smartphone

https://www.dropbox.com/s/v6kv…l94py/lman_rasta.mp4?dl=0

https://www.dropbox.com/s/d3dp2c87flxmj4p/lman_sky.mp4?dl=0

Für einen Proof of Concept bin ich eigentlich ganz zufrieden...

Ein Raspian-Realtime Kernal bringt laut schnellem Test übrigens erstmal wenig – aber die Zuverlässigkeit der Schnittstelle mit Spannungsteilern und ungeeigneten Level Shiftern (die TXB0108 gehen gar nicht – weiss jemand warum?) zu testen ist auch nicht sehr aussagekräftig.

Hier eine kleine Auswahl an Hörbeispielen (Dump des Ausgabe des RasPi in eine Datei) mit reSIDfp (mono&dual-sid) und SID+FM – noch nicht ganz perfekt (LMAN Rasta), aber für einen RasPi und nichts ausser Spannungsteilern/Level Shifter doch überraschend finde ich:

https://www.dropbox.com/s/bhx4…osn8s/giana2.wav.mp3?dl=0

https://www.dropbox.com/s/5awb…k9hb/dualux5.wav.mp3?dl=0

https://www.dropbox.com/s/bz9as0l4ywk763k/fmyam.wav.mp3?dl=0

https://www.dropbox.com/s/d9wudqiwtxfgg8a/sky.wav.mp3?dl=0

https://www.dropbox.com/s/zw2a5fjnu9kfflp/rasta.wav.mp3?dl=0

(Quellen siehe oben im Thread, zusätzlich Giana Sisters)

Ganz frei von Glitches ist die Wiedergabe noch nicht – fühlt sich jemand berufen, mir mit dem Interfacing und Signalqualität (am SID-Sockel zum RasPi) zu helfen? Hilfe kann ich bei der Beschaltung, Analyse der Signale etc. gut gebrauchen!

Schon viel zu lange nichts mehr passiert... ich wollte mal sehen, ob ich eine USB-Maus am RasPi für den Cevi nutzen kann. Resultat siehe hier:
https://www.dropbox.com/s/9hlxqnt6ixysqmq/c64mouse.mp4?dl=0

(Maus-Click ist nicht implementiert, das mache ich gerade per Joystick)

... das eröffnet natürlich eine ganze Reihe weiterer Möglichkeiten mit Controllern ...

Zitat von kinzi

Wahnsinn!
In jeder Hinsicht ... einerseits deine Programmierleistung - Hut ab!
Und andererseits eine Maschine mit schießmichtot MIPS als I/O-Controller für Paddles für eine 1 MHz-Maschine. GEIL!
(Ja, und natürlich Sounddevice. )

Es ist ja vor allem eine Maschine die dafür so gar nicht gemacht ist... daher ist es ein bisschen Knobeln (und wundern, dass es eigentlich überhaupt geht)

Das größte Problem ist -- wenn man keine externe HW verwendet -- die Geschwindigkeit der GPIOs, daher ist ein OrangePi etc. keine Option.

Zitat von WalkThatWay

Ob das auch mit einem Raspberry Zero läuft?

Gibt ja auch Kameras, Touchscreens etc. pp. für den Raspberry. Man, man, man ...

Am Ende noch W-Lan? Oder Gigabit Ethernet?

Auf jeden Fall eine interessante Schnittstelle zum C-64 mit Potential.

Alles anzeigen

Also im Prinzip kann ich "beliebig" zwischen den RPi und dem C64 kommunizieren (ich nutze für die FM Emulation ja auch zusätzlich schon den mit IO2 adressierten Bereich). Aber gerade die Leseoperationen sind heikel, was das Timing angeht. Mein letzter Test (ich sollte das protokollieren...) war, meine ich, so, dass ca. 0.1 Promille der Reads zu spät auf den Bus schreiben (da bin ich gerade am Optimieren und Fehlerquellen suchen -- z.B. ist der uS-Timer auf dem RPi unglaublich lahm und exakter/schneller wäre es den CPU-Cycle Count zu nutzen und die Taktfrequenz manuell festzunageln). Ansonsten bäuchte ich ein fehlererkennendes Transferprotokoll, was sich aber natürlich implementieren ließe für neue/custom Anwendungen.

Noch besser wäre es natürlich die hiesigen Elektronikexperten helfen mir mal mit dem Interface (Spannungswandler etc. -- ist zum Beispiel schon die Kabellänge ein Problem bei den Signalen? Was machen die Levelshifter damit...? ...?)

Das bringt mich zum RPi Zero: ich denke er würde Emulation (eines SIDs mit reSIDfp, vl. 2 mit reSID, + FM) und Kommunikation schaffen, _wenn_ er von außen Hilfe bekommt. Ein CPLD (hab ich aber keine Ahnung von) oder ein Mikrokontroller der die zeitkritischen Dinge übernimmt. Für letzteres wollte ich mit mal einen STM32 anschauen. Mein "Ziel" ist ja den RPi so anzuschließen, wie es jeder nachmachen kann. Derzeit sind's Komponenten für ~2€ auf einem Steckbrett... der STM würde noch 1,5€ zusätzlich ausmachen (befindet sich derzeit auf einem Containerschiff). Das wäre fur DualSID+FM nicht so verkehrt

Im Prinzip kann man alles mögliche an Peripherie verwenden, die Software auf C64-Seite muss im Zweifel angepasst werden (die Frage ist, ob man das dann will?).

An was ich noch so gedacht habe (aber die Zeit...):
- Bluetooth Controller (PS3/4)
- .PRG laden (dann muss ich nicht immer die Demos manuell laden, "Bootloader" auf ein EPROM und laden von RPi)
- zum Testen erstmal ein Video streamen, aber mein Assemblerprogrammieren auf dem Cevi ist 30 Jahre her

Nach langer Zeit mal wieder ein Update, falls Interesse besteht…

Zuletzt hatte ich mit Level Shiftern experimentiert (Danke an die Helfenden hier: Bustreiber 74x245 und Oszi) und alles mal auf Lochraster aufgebaut. Nachdem klar war, dass die „Signalqualität“ stimmt, war also angesagt, die Software-Seite -- GPIO Bit Banging auf der RPi3 und Raspbian -- genauer unter die Lupe zu nehmen.

Mittel der Wahl: Echtzeit-Kernel, Interrupts deaktivieren, Assembler, … optional Overclocking. Ende der Geschichte: der Kernel verteilt immer Interrupts auf alle Kerne, das kann einen Kern mal für ein paar Mikrosekunden beschäftigen und prompt verpasst man einen SID-Zugriff. Ich habe nichts gefunden außer, dass ich den Kernel mit einem eigenen Scheduler hätte kompilieren könnte... In Zahlen ausgedrückt: wenn man unentwegt in SID-Register schreibt, dann verpasst man etwa 0.5 Promille der Befehle. Bei normalen SID-Playern hört man das eigentlich nicht, hat mir aber trotzdem nicht gefallen. IRQs unter Raspbian/Linux sind, nach allem was ich gelesen habe, auch zu langsam.

Ich hatte überlegt einen STM32-uC als Interface zwischen C64 und RPi3 zu nehmen, aber nachdem mir der USB-STLink noch gefehlt hat und ich nicht loslegen konnte, habe ich eben RPi3 Bare Metal (also ohne OS) programmiert (Circle++ ist hier hervorragend!)

Hier kann ich einen FIQ-Handler verwenden und verpasse keine Zugriffe. Momentan löse ich jeden Takt aus – für SIDs alleine würde CS reichen, wenn ich SFX Sound Expander möchte brauche ich aber noch IO2 (also extern verknüpfen, oder PHI2 abfangen und CS und IO2 testen). Ich habe noch nicht alles portiert, derzeit spielt nur 1x SID (reSID 1.0 -- wie in WinVice) und alles auf einem Core: https://www.dropbox.com/s/5456…sPiSID_BareMetal.mp4?dl=0

Ich denke mal, dass ich beides erstmal weiterführe (über andere Plattförmchen denke ich noch nach): Entwicklung/Debugging mit Raspbian ist einfach angenehmer (aber einiges werde ich nicht dort testen und übernehmen können, da Circle und Baremetal oft ein wenig anders ist). Bei Baremetal muss ich zum testen immer den Kernel auf SD kopieren und in den RPi stecken...

So oder so, wenn am Ende etwas herauskommt, was mehrere SIDs, Sound Expander etc. abdeckt und so einfach ist, dass es sich jeder zuhause zusammenstecken kann, dann bin ich zufrieden. Alles weitere (Peripherie nutzen etc.) ist dann i-Tüpfelchen

Ihr habt beide (teils ;-)) richtig gelesen

Es gibt eine Variante, die unter Raspbian läuft (mit o.g. Schwierigkeiten) und eine Bare Metal, die ich gerade auf den Feature-Stand der erstgenannten bringe (wird aber noch ein bisschen dauern).

Im Prinzip sind beide dann, was das "Interface" zum C64 angeht erstmal kompatibel/austauschbar -- könnte man also bequem ausprobieren...

So, Bare Metal ist auf dem Stand der Raspbian-Version, also Dual SID + SFX Sound Expander (die 3 Oszis in den Bildern sind SID 1+2 und SFX). Gerade läuft alles auf nur einem Core, es besteht also noch Hoffnung für einen PRi Zero.

Jetzt baue ich vielleicht noch Unterstützung für den SFX Sound Sampler ein, auch wenn ich von dem selbst erst vor kurzem gelesen habe... was fehlt dann noch an C64 Sound Ausgabe?

Wie man sieht ist die Konstruktion gerade noch recht wild und ich überlege, wie man den abschreckenden Formfaktor gleich bekommt. Eine Option wäre eine kleine Platine im SID-Sockel und ein Flachbandkabel nach außen (brauche 21 Drähte). Wie in einem anderen Thread gefragt/diskutiert wird es wohl nicht vollständig extern am Expansionsport gehen :-/ (SID Chipselect am Expansionsport?) Ich bin für Ideen/Vorschläge dankbar!

Heute etwas aus dem Kuriositätenladen…mit sinnvollem Hintergrund: ich wollte mal testen, wie verlässlich mein Schreiben auf dem C64-Bus vom RPi aus ist und dabei konnte ich ausprobieren, was ich schon immer mal testen wollte. SID macht Sachen und spielt ein Video ab

https://www.dropbox.com/s/l51b…ax/RasPiSIDVideo.avi?dl=0

Der Code zum Abspielen auf dem C64 ist folgender (nicht gezeigt: Einschalten Hires-Mode und Initialisieren des Farbrams, transferriert werden stupide 8192 Bytes pro Frame):