Forum: Mikrocontroller und Digitale Elektronik SID-Player ARM/FPGA?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

hab gegoogelt und bin über mehrere Projekte/Libs gestolpert, die den SID 
emulieren.

- resid
- resid_fp
- siduino
- fastsid aus dem Emulator Vice

Resid scheint für einen ARM viel zu aufwändig zu sein (Zyklengenaue 
Emulation).  Siduino ist sehr minimalistisch, aber vom Ergebnis wohl 
garnicht so übel. Über FastSID weiß ich nicht viel, muss ich 
ausprobieren.

Dann gibt es wohl noch SwinSID als Drop-In-Replacement für den 6581er 
... Die verwenden einen ATMega8 und der scheint wohl gut genug zu sein, 
aber kein Source-Code dafür.

Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine 
ARM-Portierung eignen würden?

VG
Mampf

: Bearbeitet durch Moderator
von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SID Sourcen für die Atmega gibt es einige, auch für einen Arduino Uno.

Wird es ein Open-Source Projekt?

von Mampf unterwegs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> SID Sourcen für die Atmega gibt es einige, auch für einen Arduino
> Uno.
>
> Wird es ein Open-Source Projekt?

Jup klar, ich halte nichts von closed source :)

Und natürlich nicht-kommerziell

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ah das Problem ist ja noch interessanter und geht über eine 
SID-Emulation hinaus ...

Man benötigt zum Abspielen der .sid-Files wohl auch noch eine 
6502-Emulation ... Kranker Scheiß xD

von Cyblord -. (cyblord)


Bewertung
-5 lesenswert
nicht lesenswert
Was zum Geier ist SID?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Was zum Geier ist SID?

Der Sound-Generator vom C64 ...^^

Hmm, es gibt eine synthetisierbare Version des SIDs in VHDL ... 
6502-CPUs gibt es auch genügend ... Dazu noch einen Soft-Cortex-M0 und 
voila ...^^

Glaub ich hab mein nächstes Bastelprojekt ;-)

von Besucher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ah das Problem ist ja noch interessanter und geht über eine
> SID-Emulation hinaus ...
>
> Man benötigt zum Abspielen der .sid-Files wohl auch noch eine
> 6502-Emulation ... Kranker Scheiß xD

Wenn du mehr als nur die 08/15 SIDs abspielen möchtest (also z.B. auch 
x-fach Speed Tunes oder Digis) wirst du womöglich auch noch Teile des 
VICs (für Rasterinterrupts), Teile der CIAs (für Timerinterrupts) und 
die MMU emulieren müssen. An sich alles kein großes Problem, aber es 
kostet halt ordentlich Resourcen. Da möchte ich mal zu einem ARM mit 
wenigstens 150 MIPS raten. Zuzüglich einem separaten SID. ^^

PS: Wenn du das Projekt tatsächlich angehst dann halte uns bitte auf dem 
Laufenden! Ich wollte auch schon immer einen SID-Player für die 
Stereoanlage haben, bin die Sache aber irgendwie nie tatsächlich 
angegangen...

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> Kennst das schon?
>
> http://www.fpgasid.de/project-definition

Nice, allerdings gibt es da keine Sourcen dazu :'(

Besucher schrieb:
> wirst du womöglich auch noch Teile des
> VICs (für Rasterinterrupts), Teile der CIAs (für Timerinterrupts) und
> die MMU emulieren müssen.

Puh, also einen ganzen C64 quasi ... Und das nur um Sid-Files 
abzuspielen xD

Hmm, da würde ich mich eher an sidplay(fp) orientieren ... Das scheint 
ein recht guter Player zu sein und es würde mich fast wundern, wenn der 
auch noch eine VIC, CIA und MMU-Emulation hat :)

 ... Ich hab zufällig gerade ein Board mit STMF4 designed. Der läuft auf 
168MHz und hat 32MB RAM, µSD-Slot, I2S Stereo DAC - und als Display eine 
Wortuhr xD Ah und ist 80x40mm groß in etwa.

Aber ich geh fest davon aus, dass der wahrscheinlich zu langsam sein 
wird. Insbesondere sidplay mit der Zyklus-genauen Emulation. Irgendwie 
müssen die Zyklen@9,irgendwas-MHz ja durchgerechnet werden ...

Danach kuck ich mal weiter ... Wahrscheinlich macht eine FPGA-Version 
eher Sinn :)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ahja der absolute Wahnsinn!

Die libsidplay hat tatsächlich eine VIC, CIA, ... Emulation!

Auszug aus dem Code:
/ Set the ICs environment variable to point to
// this player
Player::Player (void)
// Set default settings for system
:CoUnknown<ISidplay2>("SIDPlay 2"),
 CoAggregate<ISidTimer>(*iaggregate()),
 c64env  (&m_scheduler),
 m_scheduler ("SIDPlay 2"),
 cpu     (&m_scheduler),
 xsid    (this),
 cia     (this),
 cia2    (this),
 sid6526 (this),
 vic     (this),


Zwar alles abgespeckt - ist irgendwie klar, eine grafische Ausgabe zB 
braucht man nicht - aber trotzdem vorhanden.

Erwähnte ich schon mal? Kranker Scheiß xD

: Bearbeitet durch User
von Besucher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ahja der absolute Wahnsinn!
> Die libsidplay hat tatsächlich eine VIC, CIA, ... Emulation!

Dürfte wohl daran liegen das bisher noch niemand ein hinreichend 
flexibles Dateiformat (auf dem PC) für SIDs erfunden hat. :)  Deswegen 
werden Besonderheiten von Tunes noch immer mit Hilfe von C64-nativem 
Wrapper-code gelöst. Und dieser ist zumeist einfach gehalten (nutzt 
bspw. Raster- oder Timer-Interrutpts), schon allein um sowohl auf PAL- 
als auch auf NTSC- Geräten zu laufen. Und natürlich sollen die SIDS ja 
auch nicht nur auf PC-Playern laufen sondern vor allem auch auf einem 
normalen C64.
Die Jungs von der HVSC geben sich zwar redlich Mühe die Sammlung 
möglichst "Emulations-kompatibel" zu halten (haben ja z.B. auf PSIDv2NG 
umgestellt), aber da dies bisweilen Handarbeit für jedes einzelne 
Musikstück erfordert darf man da auch nicht zu viel erwarten.

Jetzt wäre es freilich interessant zu wissen wieviele der Tunes denn 
nun welche Features von VIC/CIA/MMU benötigen um abgespielt zu werden. 
Ich weiss noch, ich hatte mal angefangen einen Emulator zu schreiben nur 
um genau diese Informationen herauszubekommen (und um anschließend 
selber einen Standalone-Sidplayer zu bauen). Aber irgendwie ist das 
Projekt im Sande verlaufen... Muss mal nachschauen wie weit ich da 
gekommen war.
Auf VIC/CIA/MMU verzichten wollen würde ich allerdings nicht, denn 
dadurch würde ein großer Teil hervorragender Musikstücke wegfallen. 
Soviel Luxus muss schon sein. :)

Hmm, ich habe schon mehrere - mehr oder weniger rudimentäre - 
c64-Emulatoren für verschiedene Zwecke geschrieben und mich auch schon 
mehr als einmal mit dem Projekt eines Standalone-Sidplayers befasst. Aus 
der groben Erinnerung weiss ich noch das ich den Resourcenbedarf einer 
MCU dafür beim ersten Mal mit 180 MIPS abschätzte, beim zweiten Mal mit 
150 MIPS (jeweils mit separatem SID-Chip, also ohne Emulation dieses 
Chips (was für die Goldohren unter uns ja ohnehin untragbar wäre...)). 
Ich kann mich allerdings nicht mehr daran erinnern wie diese 
Abschätzungen zustande kamen. xD  (mit/ohne Ansteuerung von 
SD-Card/LCD/XMEM/etc. ?)


PS: Ach, ich schicke dir nachher mal einfach 'ne PM.

von Besucher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Man benötigt zum Abspielen der .sid-Files wohl auch noch eine
> 6502-Emulation ... Kranker Scheiß xD

Beside: Genau genommen muß eine 6510-CPU emuliert werden. Diese hat ggü. 
einer 6502 noch einen zusätzlichen Port (8 Bit) über den u.a. auch die 
MMU gesteuert wird. Und da der c64 normalerweise in ca. 90% aller 
Taktzyklen über die CPU (und somit auch über die MMU) auf den Speicher 
zugreift wird eine exakte Emulation der CPU+MMU in Software richtig 
teuer...
Eine 100%ig exakte Emulation (welche ja auch Halbzyklen, Badlines und 
ähnliche Späße berücksichtigen müsste) würde für einen SID-Player imho 
allerdings nicht benötigt, da reicht es aus in maximal ca. 25% aller 
Taktzyklen die MMU zu berücksichtigen. Dadurch wird die Sache schon 
wesentlich billiger. :)
Und wenn man mal davon ausgeht das nicht mal die Goldohren unter uns 
eine Verzögerung von wenigen µS heraushören können dann kann man damit 
durchaus arbeiten. :D

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Discovery Board wäre gut für einen Player geeignet, weil es schon 
einen Codec hat:
http://www.st.com/en/evaluation-tools/stm32f4discovery.html

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Das Discovery Board wäre gut für einen Player geeignet, weil es
> schon
> einen Codec hat:
> http://www.st.com/en/evaluation-tools/stm32f4discovery.html

Aber kein SDRAM und kein SD-Slot ... Zufällig hab ich gestern erst ein 
Board fertig gebastelt, das zufällig perfekt dafür wäre xD

Ein STM32F429 @ 168MHz mit 32MB SDRAM, µSD-Slot und einem Audio-Codec - 
auf ca 80*40mm :D

Auf dem Ding werde ich das Sid-Zeugs ausprobieren :)

(Eigentlich war das Ding dazu gedacht, den Cris-Dynamic-Compressor 
(ursprünglich ein Audacity Plugin in lisp) drauf laufen zu lassen ... 
Der macht aber einen wahnsinnigen Lookahead von bis zu 17 Sekunden, 
weshalb man da viel RAM braucht zum Buffern)

SDRAM funktioniert wunderbar, heute muss ich noch µSD und Audio testen 
... Auf die SD könnte man die ROMs für Kernal, Chargen und Basic 
auslagern und dann in den SDRAM laden :)

(Und als Display gibt es eine zweite Platine mit einer Wortuhr xD )

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Aber kein SDRAM und kein SD-Slot ...
Ja, das ist ein echter Nachteil an dem Board.

Eine alternative wäre das
Beitrag "STM32F407 Black und Arduino"
das ist günstig und hat einen SD-Kartenslot.
Es gibt ja dort auch eine Variante für zusätzliches RAM.

Dazu dann noch den Adafruit I2S Verstärker
https://www.adafruit.com/product/3006

oder das STM32F7 Dicovery. Das hat alles inclusive Display

http://www.st.com/en/evaluation-tools/32f746gdiscovery.html

ist aber ein wenig kostenintensiv.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Puh, kleiner Zwischenstatus ... SDRAM, µSD und USB (MSC) funktioniert 
... Hab die C64-Kernel jetzt auf die SD-Karte gepackt ... Mal schauen, 
ob ich morgen zum Portieren der libsidplay komme :D

Wahrscheinlich ist der ARM sowiso viel zu langsam, aber mal kucken ;)

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Was sich ideal dazu eigen sind die Xmos µP es gab sogar mal ein Projekt 
hierzu.

Youtube-Video "XMOS SID Synth test"

Ein ähnliches Board bekommt man für 14-50€ :).

http://www.pollin.de/shop/dt/NzIzNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Entwicklerboard_XMOS_XK_STK_A8DEV_XCORE_XS1_A.html

Die 500MIPS sollten reichen ;)

: Bearbeitet durch User
von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Puh, kleiner Zwischenstatus ... SDRAM, µSD und USB (MSC) funktioniert
> ... Hab die C64-Kernel jetzt auf die SD-Karte gepackt ... Mal schauen,
> ob ich morgen zum Portieren der libsidplay komme :D
>
> Wahrscheinlich ist der ARM sowiso viel zu langsam, aber mal kucken ;)

PM hatte wegen der Captchas leider nicht geklappt... Also falls die 
Rechenpower für libsidplay nicht reicht und du dich dazu entschließen 
solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid. 
Daran könnte ich mich glaube ich gut (und würde das auch gerne) 
beteiligen. :)

Marco H. schrieb:
> 
http://www.pollin.de/shop/dt/NzIzNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Entwicklerboard_XMOS_XK_STK_A8DEV_XCORE_XS1_A.html
>
> Die 500MIPS sollten reichen ;)
Schickes Board! Und immer noch billiger als ein richtiger SID bei ebay. 
xD

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Das Stimmt ich habe auch noch welche im Schrank ;) Es gab mal jemanden 
der hat die Dinger Stangenweise geerbt. Auch noch andere Sachen aus der 
Zeit.

Da sie bei einigen Musikern recht beliebt sind ist der Preis zur 
Innovation recht hoch.  Bei solchen Geschichten geht es er darum 
legendäre Dinge mit heutiger Technik nach zubauen.

Es gibt heute noch Software für den C64, man mag es kaum glauben :)

Die Xmos µP sind für alle Zeitkritischen Sachen recht interessant.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Hatte der Amiga500 den gleichen Chip? In meiner Wunderkiste waren auch 
ein paar Stangen "Amiga500 SID" dabei, muss gleich mal suchen gehen, was 
das genau war. Vielleicht Goldstaub :-)

von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> Hatte der Amiga500 den gleichen Chip?
Leider nicht. Der Amiga hatte afaik einen Chip namens Paula welcher 
PCM-Samples per DMA abspielte.
Aber falls du da tatsächlich noch eine Kiste mit SIDs im Keller hast 
dann sag Bescheid!! :D

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja 
PLCC.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> und du dich dazu entschließen
> solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid.

Interessant wäre es schon, ich tu mich aber meistens recht schwer damit, 
mit irgendetwas länger als 2 Wochen beschäftigt zu sein^^

Wenn die Rechenpower nicht reicht, würde ich gleich Richtung FPGAs gehen 
:)

Aber danke für dein Angebot! :)

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Die Weiterentwicklung des SID findet man wohl hier:

http://mega65.org/

(mit Stereo und so)

von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Michael H. schrieb:
>> und du dich dazu entschließen
>> solltest selber eine Emulation zu schreiben dann sag doch mal Bescheid.
>
> Interessant wäre es schon, ich tu mich aber meistens recht schwer damit,
> mit irgendetwas länger als 2 Wochen beschäftigt zu sein^^

Ach, das kenne ich... Ist aber kein Problem, bei deinem Tempo würde ein 
c64-Emulator ja locker in einer Woche fertig sein. ^^

> Wenn die Rechenpower nicht reicht, würde ich gleich Richtung FPGAs gehen
> :)
Mit FPGAs kenne ich mich leider zu wenig aus um dabei mithalten zu 
können. :/  Für etwaige Detailfragen zu einer Emulation stünde ich 
jedoch zur Verfügung.
Und wenn der SID-Player steht dann baue bitte auch gleich noch einen 
MOD-Player mit ein! xD

H.Joachim Seifert schrieb
>Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja
>PLCC.

Ich harre gespannt deines nächsten Postings. :D

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> Die Weiterentwicklung des SID findet man wohl hier:

Sehr cool! Der C65 😍 Leider kenn ich den nur von Bilder, war aber 
damals, als man zum ersten mal was davon las, aber schon sehr fasziniert 
:)

Aaaah, die haben eine quelloffene VHDL-Implementierung u.a. vom SID!

Dann gibt es wohl schon zwei ... Muss ich mal vergleichen :)

https://github.com/MEGA65/mega65-core/blob/master/src/vhdl/sid_6581.vhd


Michael H. schrieb:
> Für etwaige Detailfragen zu einer Emulation stünde ich
> jedoch zur Verfügung.

Darauf komme ich sicher zurück!

z.B. hatte ich einen Quelloffenen SID-Core gesehen und in einem Thread 
meinte jemand, es würde irgendeine Synchronisierung fehlen ... Evtl 
würde ich daran noch was weiterbasteln.

Was man dann auch brauchen könnte sind anspruchsvolle SID-Files, die den 
SID auch richtig nutzen und die Features kombinieren. Hatte da mal ein 
Youtube-Video mit so einem SID-Sound gesehen, muss ich nochmal suchen :)

Michael H. schrieb:
> Und wenn der SID-Player steht dann baue bitte auch gleich noch einen
> MOD-Player mit ein! xD

OMG, die MOD-Files hatte ich ja total vergessen! Vielen Dank für die 
Erinnerung!

: Bearbeitet durch User
von Mampf unterwegs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit 
klappen.... Hab die libsidplay und resid auf dem arm laufen und für 
10sek abspielzeit braucht er in etwa 6sek... Leider konnte ich noch 
nicht reinhören, aber daten sind zumindest vorhanden... Spannend xD

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit
>klappen....

Das klappt mit Sicherheit in Echtzeit. Ein Atmeg16 schafft des SID schon 
in C ohne besondere Assemblertricks. Und der 6502 Simulator läuft mit 
Sicherheit auch.

von Besucher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das sind ja schonmal gute Neuigkeiten! :)
War es denn ein Standard-Tune (der um die 5%-10% der Rechenzeit des c64 
nutzt) oder schon etwas "anspruchsvolleres"?

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Frag doch mal im forum64.de

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Besucher schrieb:
> Das sind ja schonmal gute Neuigkeiten! :)

hah, ich hab gestern rein gehört ... total kaputt alles xD

Ich probier es nochmal, hab mit den Defines möglicherweise was kaputt 
gemacht ... Lass die Lib jetzt erstmal für arm-linux cross-compilen und 
übertrage dann die Defines :)

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf
>Nur ganz kurz... Ich glaube das mit dem. Stm32 könnte in echtzeit
>klappen....

Du könntest den Code so kapseln, dass man ihn auf unterschiedlichen 
Frameworks laufen lassen kann.

1. Audiobuffer mit Funktion update(&AudoBuffer[0]) füllen
2. Schnittstellen zu Speicherkarten mit Call-Backs kapseln.

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sooo, es geht doch ...

Bin mir noch nicht 100% sicher ... Aber für 60sek@22.05kHz hat er 40sek 
benötigt, für 44.1kHz könnte es gerade nicht ausreichen ... Aber ich hab 
noch Möglichkeiten ... SDRAM-Initialisierung tweaken, Timings anpassen, 
Sektionen ins SRAM auslagern - zB die 6502/10-Emulation ...

Hmm, ob man MP3s hier überhaupt hochladen kann ... Mal ausprobieren :)

Hat jemand ein anspruchsvolles SID-File?

Kenn mich da leider zu wenig aus^^

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Du könntest den Code so kapseln, dass man ihn auf unterschiedlichen
> Frameworks laufen lassen kann.
>
> 1. Audiobuffer mit Funktion update(&AudoBuffer[0]) füllen
> 2. Schnittstellen zu Speicherkarten mit Call-Backs kapseln.

Der sidplayer ist erstaunlich pflegeleicht ...

Das hier ist alles, was man im Prinzip braucht, um Files abzuspielen:
// einfach irgendwie ein SID in das RAM laden (FsFAT)
    f_open(&MyFile, "MEGA.SID", FA_READ);
    uint32_t size = f_size(&MyFile);
    uint8_t *sidfile = (uint8_t*) malloc(size);
    f_read(&MyFile, sidfile, size, (UINT*)&bytesread);
    f_close(&MyFile);

// hier gehts mit dem SID los
    sidplay2 Sidplay2;

    SidTune Tune(sidfile, size);
    ReSIDBuilder ReSID("");
    Tune.selectSong(1);
  
    Sidplay2.load(&Tune);
    sid2_config_t sid2config;
    ReSID.create(1);
    sid2config.frequency = 22050;
    sid2config.emulateStereo = true;
    sid2config.leftVolume = 255;
    sid2config.rightVolume = 255;
    sid2config.clockSpeed = SID2_CLOCK_PAL;
    sid2config.optimisation = 1;
    sid2config.sampleFormat = SID2_BIG_UNSIGNED;
    sid2config.sidModel = SID2_MOS6581;
    sid2config.forceDualSids = false;
    sid2config.sidSamples = true;
    sid2config.playback = sid2_stereo;
    sid2config.environment = sid2_envPS;
    sid2config.precision = 16;
    sid2config.sidEmulation = &ReSID;
    Sidplay2.config(sid2config);

    uint8_t *output = (uint8_t*) malloc(22050*2*2);

// abspielen und mit dem output dann irgendwas machen
    for (int i=0;i<60;i++) {
      Sidplay2.play(output, 22050*2*2);
    }


D.h. man braucht kein wahnsinniges Framework ... :)

Was auf jedenfall dazu kommt - ohne macht es keinen Sinn ist ein 
Buffering und DMA, um die Daten aus den Speicher auf die I2S zu 
schaufeln :) Mal kucken, vlt krieg ich das Montag schon hin ;-)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hah, DMA und I2S funktioniert auch ... Sogar angenehme 
Kopfhörerlautstärke ;-)

Somit ist mein Board vollständig getestet und funktioniert :)

Jetzt muss ich mal anspruchsvolle SIDs suchen ... Ich mach nachher noch 
eine Aufnahme :)

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So noch ein Sample ... Über den Audio In meines PCs aufgenommen ... So 
ein Mist wieder, das hat unter Linux nicht gescheit funktioniert ... der 
PC hat zu leise, in der falschen Samplerate und einer der beiden Kanäle 
hatte eine Dauerhochfrequenzstörung mit Amplitude maximal ... Das lag 
aber nicht am ARM, das hatte der auch, wenn ich ihn abgesteckt hatte xD 
Hoffe, die Qualität geht nach Normalisieren und Resamplen ;)

Das hat der STM32 in Echtzeit abgespielt :)

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Welches Framework hast du denn jetzt genommen ?

von Michael H. (dowjones)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Das hat der STM32 in Echtzeit abgespielt :)
Das klingt ja schon topfit! :D

Probier mal die angehängten SIDs, die sollten überdurchschnittliche 
Rechenzeit benötigen. Wenn die auch laufen wie sie sollen - dann 
Respekt!!

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Welches Framework hast du denn jetzt genommen ?

Mein Projekt hab ich per CubeMX von ST erstellen lassen, also HAL. CMSIS 
alleine wär zwar schöner gewesen, aber da ist die ST-Peripherie ziemlich 
frickelig und aufwändig - USB zB.

Hoffe, ich hab deine Frage richtig verstanden.

Michael H. schrieb:
> Probier mal die angehängten SIDs, die sollten überdurchschnittliche
> Rechenzeit benötigen. Wenn die auch laufen wie sie sollen - dann
> Respekt!!

Probier ich gleich mal aus :)

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Hoffe, ich hab deine Frage richtig verstanden.

Ähm, ich meinte eher, welchen SID-Player hast Du genommen? Hast Du 
vielleicht einen Link zum Source?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
>>Hoffe, ich hab deine Frage richtig verstanden.
>
> Ähm, ich meinte eher, welchen SID-Player hast Du genommen? Hast Du
> vielleicht einen Link zum Source?

Aaaah, ich hab sidplay2 verwendet ... Bei dem ist der resid gleich dabei 
(ich glaube, eine der akkuratesten Sid-Emulationen überhaupt).

https://sourceforge.net/projects/sidplay2/

(ausprobieren kann man den zB unter Linux über den sidplay ... Der ist 
glaub ich direkt im Repository)

So, die SIDs getestet ... Also für 44kHz wäre die 4fache 
Prozessorleistung hilfreich - und die anspruchsvollen Sids laufen bei 
22kHz nicht mal in Echtzeit.

Aaaaber, ich hab noch nicht zum optimieren angefangen ... Ein Bottleneck 
könnte mein SDRAM sein ... resid hat ein paar Arrays, die meinen ganzen 
internen RAM auffressen und so musste quasi fast alles andere ins SDRAM 
... Und den Code kann ich deshalb auch nicht im SRAM auslagern, Muss mal 
schauen, wieso die Wave-Tables nicht als "const" deklariert sind ... Ob 
man die ändern kann?

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind 
ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist 
zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist 
aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Die Wave-Tables müssen im internen RAM liegen, sonst wird das Ganze 
nochmal deutlich langsamer. Aber dann ist nicht mehr genügend RAM 
übrig,um Code in den RAM auszulagern. Und die restlichen Variablen, die 
resid und libsidplay anlegen sprengen diesen auch.

Aus dem SDRAM ist es zu langsam.

Also alles in allem ein netter Test, aber nicht wirklich tauglich ...

War aber keine Zeitverschwendung - hab die Gelegenheit genutzt, mein 
Board fertig zu testen und die Peripherie wie DMA und I2S in Gang zu 
bekommen.

Ich orientier mich jetzt neu und werde das demnächst nochmal als 
FPGA-Cores testen. Hab im Prinzip alles zusammengesammelt, was ich dafür 
brauche (leider gibt es keinen GPL-Core für den VIC, d.h. ich müsste 
einen verwenden, den man nicht redistributen darf - egal ob mit oder 
ohne Änderungen daran).

Ich könnte vmtl einen selbst bauen, aber da müsste ich mich erstmal 
einarbeiten, was die sid-music überhaupt vom VIC benötigt und das auf 
das allernötigste Reduzieren, da ich ja keine Grafikausgabe brauche - 
oder kucken, was die libsidplay mit dem VIC und der CIA macht und den 
C-Code nach VHDL portieren ... Da ist mir der Schwierigkeitsgrad aber 
noch nicht klar ... Muss ich mir mal anschauen :)

Eine GPL-Version der CIA hab ich auch nicht gefunden.

6510, SID und der PLA scheinen kein Problem zu sein, wobei man den SID 
vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine 
kleinere Finger-Übung.

Frustrierend ist aber, dass jegliche komplett-Projekte eines C64igers 
als Core im FPGA nicht frei sind ... Da sitzen irgendwelche 
kommerzgeilen Leute auf ihren Cores und veröffentlichen den Bitstream 
für den FPGA. Oder eben eine Version, die Quellcode hat, aber mit dem 
man nichts machen darf. ("The source-code (VHDL) of FPGA-64 is made 
available strictly for personal educational purposes. It is not allowed 
to copy, upload or redistribute this work in any way, neither in 
original form nor with additional files or changes. Contact the author 
if you want a commercial license for (part of) FPGA-64.")

Schade ... Aber gut, wie kompliziert kann so eine uralt-Kiste schon 
sein, das Wissen ist verfügbar, man muss nur kucken wo ... Ansonsten ist 
es ja straight forward ... Ich denke, die CPU, SID, PAL und Speicher 
kriegt man recht schnell hin ... VIC und CIA wird interessant. (*edit*: 
Oh, die Minimal-VIC-Implementierung ist ja wirklich sehr kurz ... Und 
die Event-Loop ist als State-Machine implementiert ... Dann glaub ich 
ist das kein Problem mit VHDL).

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
>ungenügend

Sehr schade. Hast Du Lust das Projekt hier zu posten, dann könnte man 
mal einen Blick darauf werfen.

von Markus K. (markus-)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
> ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist
> zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist
> aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Die F7 gibts mit bis zu 512KB internem RAM, sie sind deutlich schneller 
als die F4 und sie haben Caches, was den Zugriff aufs SDRAM (je nach 
Anwendung) auch beschleunigen kann. Außerdem sind sie natürlich 
lieferbar.

Beim H7 sollte man beachten, dass nur der Core und das tightly coupled 
memory mit 400MHz laufen, die SRAM1..3 dagegen nur mit 200MHz.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
RPI mit bare metal, wäre auch noch möglich.

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Sehr schade. Hast Du Lust das Projekt hier zu posten, dann könnte man
> mal einen Blick darauf werfen.

In der "unpolished" Version sicherlich :)

Marco H. schrieb:
> RPI mit bare metal, wäre auch noch möglich.

Hmm, ja, der hätte sicherlich genügend Resourcen :)

Persönliches Problem ist allerdings, ich mag nicht sonderlich gerne 
kauf-Module^^ Ich weiß, ist nicht wirtschaftlich, aber ... naja^^

Ich hab mich mit dem FPGA-Thema mal beschäftigt ... Wenn man den VIC 
wirklich auf das Minimum reduziert wie in der libsidplay, wird alles 
extrem vereinfacht.

Das, was mir nicht so in bestehenden Projekten gefallen hat, ist das 
Einbetten der ROMs direkt in VHDL als - ähm - ROM^^

Hab da ein uraltes damaliges Projekt gefunden, das evtl gut geeignet 
wäre ... Das hat 1MB SRAM (als 512k*16) und da könnte man das 
Memory-Mapping und das Bank-Switching des C64 gut umsetzen ... Der VIC 
muss ja vom RAM nicht lesen können, weshalb sich da vieles vereinfacht 
und man die Wahnsinns-PLA in der Form auch nicht braucht.

Mal schauen, wie weit ich mit einem uralt Spartan 2 komme xD

Falls der nicht reicht, hätte ich noch Alternativen wie das Altera DE1 
(hat auch 512kB SRAM)

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>In der "unpolished" Version sicherlich :)
Da ist jetzt aber nur das Bild von Deinem FPGA-Board ;-)

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
>>In der "unpolished" Version sicherlich :)
> Da ist jetzt aber nur das Bild von Deinem FPGA-Board ;-)

Here you are ... Lass dich nicht von "mp3" irritieren, das man in 
einigen Filenamen findet ;-)

Da ist auch das cubemx-File dabei, dann sieht man, wo welche Peripherie 
dran hängt.

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Here you are ...

Dankeschön :-)
Stecken da zwei SID-Emulatoren drinn? resid und libsidplay?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
>>Here you are ...
>
> Dankeschön :-)
> Stecken da zwei SID-Emulatoren drinn? resid und libsidplay?

Nope, ReSid ist die Sid-Emulation, Libsidplay macht die 6510, die CIA, 
die VIC und quasi die "Glue-Logic" dazwischen - und das ganze 
File-Handling (SID-Files laden, in den RAM an die richtige Stelle 
kopieren für die 6510 CPU usw ):) Der "SidBuilder" (bei libsidplay 
dabei) wrappt den ReSid so, dass das zu den anderen Emulierten Chips 
dazu passt.

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke.

>Die Wave-Tables müssen im internen RAM liegen, sonst wird das Ganze
>nochmal deutlich langsamer.

Was meinst Du mit Wave-Tables? Sollte der SID nicht den Sound 
produzieren?

Mich wundert, dass viele Dateien die Endung *.cc haben, das scheint mir 
heute ziemlich unüblich.

>wobei man den SID
>vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine
>kleinere Finger-Übung.

Für was den FIR Filter?

Im Verzeichnis gibt es auch viele *.dat Datein. Für was sind die gut?

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Soooo, also ... Fazit meines kleinen Tests ... Die 168MHz sind
>ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist
>zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist
>aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!)

Was mir jetzt auch noch nicht ganz klar ist: Wie passt Dein Fazit zu dem 
mp3-File, welches Du gepostet hast?:
Beitrag "Re: [ARM] SID-Emulator-Library?"

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ich hab mich mit dem FPGA-Thema mal beschäftigt ... Wenn man den VIC
> wirklich auf das Minimum reduziert wie in der libsidplay, wird alles
> extrem vereinfacht.

Ja, das wäre aus meiner Sicht echt cool. Das liegt aber nur daran, 
dass ich ein cp/m Fan bin und mir ein VIC, der zum alten R3 kompatibel 
ist, echt helfen würde (die sind rar und eher teuer). Damit würde 
nämlich das z80 Modul bei mir wieder laufen (mein R3 ist kaputt 
gegangen).

Ebenso fänd ich es cool gleich eine 80-Zeichen Option und nen 
aktuelleren Ausgang (VGA wohl) zu implementieren. Dafür könnte ich wohl 
sogar etwas verilog beisteuern.

Aber: ich kann Dir sagen, dass bei so einem Projekt sich ungefähr 1000 
Leute melden würden, bei denen irgendeine Demo nicht läuft. Diese 
Demo-Coder haben ja leider diese Angewohnheit, in die VIC-Register 
irgendwelche 'illegalen' Werte reinzuschreiben, mit denen der VIC dann 
irgendwas macht, was von den Entwicklern so nie geplant war.

U.a. hier kannst Dir bisserl was zum Thema anhören:

Youtube-Video "28c3: Behind the scenes of a C64 demo"

Aber trotz allem sollte sich mal jemand trauen, sowas zu starten.
Echter Team-Geist halt (TEAM = toll, ein anderer machts).

:-)

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Was meinst Du mit Wave-Tables? Sollte der SID nicht den Sound
> produzieren?

ReSid hat für die 4 verschiedenen Kurvenformen Tabellen, um diese zu 
generieren.

Markus schrieb:
> Mich wundert, dass viele Dateien die Endung *.cc haben, das scheint mir
> heute ziemlich unüblich.

Hmm ja, k.A. :)

Markus schrieb:
>>wobei man den SID
>>vmtl noch mit FIR-Filter aufbohren müsste ... Das wäre aber vmtl eine
>>kleinere Finger-Übung.
>
> Für was den FIR Filter?

Die VHDL-Implementierung des SIDs hat keine Filter ... Man kann dem SID 
ein paar Analog-Filter zuschalten (oder so ähnlich) und man müsste das 
in VHDL als digitalen Filter implementieren. FIR-Filter sind solche 
digitalen Filter, die sich leicht implmentieren lassen (wenn man die 
Filter-Koeffizienten hat). Das geht aber richtung digitale 
Signalverarbeitung und wurde deshalb vmtl nicht umgesetzt, weil das 
Thema ansich ziemlich komplex ist (und viele FPGA-Resourcen benötigt).

> Im Verzeichnis gibt es auch viele *.dat Datein. Für was sind die gut?

Ich vermute, das sind die binären Files, bevor sie in C-Code umgewandelt 
wurden.

Markus schrieb:
> Was mir jetzt auch noch nicht ganz klar ist: Wie passt Dein Fazit zu dem
> mp3-File, welches Du gepostet hast?:

Ja also mit meinem Fazit wollte ich nicht sagen, dass es garnicht 
funktioniert ... Aber es funktioniert nicht gut genug, dass man damit 
alle SID-Files abspielen könnte, die man wollen würde. Fast so wie ein 
MP3-Player, der nur bis 128kBit abspielen kann ... Den würde auch 
niemand wirklich haben wollen xD

Andreas R. schrieb:
> Ebenso fänd ich es cool gleich eine 80-Zeichen Option und nen
> aktuelleren Ausgang (VGA wohl) zu implementieren. Dafür könnte ich wohl
> sogar etwas verilog beisteuern.

Oh, da hast du mich falsch verstanden :)

Die Minimal-VIC-Implementierung soll vollständig ohne Grafik 
auskommen, d.h. hat nur die Register, die Raster-Counter, die 
Bad-Line-Erzeugung usw, aber keinerlei Grafikausgabe.

Die Bad-Lines sind beim C64 wichtig (alle 8 Zeilen muss der VIC die CPU 
anhalten, um Daten für die Textdarstellung aus dem RAM zu holen, das 
dauert so ca 40 Taktzyklen), da sich viel C64-Code auf das Timing 
verlässt und die Music vmtl timingtechnisch kaputt wäre, wenn man die 
Badlines nicht implementieren würde :)

Das FPGA64-Projekt hat eine komplette VIC-Implementierung:

http://www.syntiac.com/fpga64.html

Ist halt lizenztechnisch ein Albtraum, weshalb ich von dem Projekt 
nichts verwenden wollte - aber für deinen persönlichen VIC, könntest du 
da bestimmt was verwenden :)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ah nice, hab noch ein Projekt gefunden, das OpenSource ist ...

Das hat noch eine CIA-Implementierung in VHDL :)

Dann hab ich alle Komponenten zusammen, die ich brauche und muss nur den 
Minimal-VIC basteln ...

https://github.com/gardners/c65gs

*edit*: Hab alle Cores - bis auf den Mini-Vic - mal synthetisieren 
lassen ... Vom Resourcen-Verbrauch wird das easy mit einem Cyclon 2 mit 
20k-LE ... 7% SID, 20% CPU, 2% CIA ... Der mini-VIC wird nicht viel 
brauchen ... Kriegt man locker unter - und gegen einen zweiten SID 
spricht nichts :D

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Mampf,

>Schade ... Aber gut, wie kompliziert kann so eine uralt-Kiste schon
>sein, das Wissen ist verfügbar, man muss nur kucken wo ...

die Formulierung liegt mir etwas schwer auf dem Magen. Ich habe da immer 
das Gefühl, dass die Leistungen der früheren Entwickler nicht richtig 
gewürdigt werden. Dabei waren das damals die Besten der Besten und sie 
haben Mannjahre mit der Entwicklung dieser Computer verbracht. Ich würde 
sagen:
"Diese uralt-Kisten sind sehr kompliziert"
Nehmen wir z.B. dein SID-Projekt für den STM32F4. Du hast SID-tunes 
Software , die für PCs mit mehreren Gigahertz und beliebig viel RAM 
geschrieben sind, auf einen STM32F4 mit 168MHz und begrenztem Speicher 
übertragen und dann heraus gefunden, dass die Leistung nicht ausreicht.

>Aber gut, wie kompliziert kann so eine uralt-Kiste schon sein
Und da genau kommt die Kompliziertheit ins Spiel: Man müsste nämlich die 
Komponente jetzt selber schreiben und auf den STM optimieren.

Ich schätze der SID-Code selbst kann mindestens um den Faktor 4 in der 
Laufzeit beschleunigt werden.

Die 6510 Simulation ist auch nicht Laufzeit-optimiert. Was möglich ist, 
wenn man einen Simulator wirklich optimiert, kann man hier im Projekt 
Beitrag "CP/M auf ATmega88" sehen.

Gut, es ist die Frage, ob man wirklich so viel Aufwand betreiben will um 
einen SID-Tune-Player auf dem STM zum laufen zu bekommen.

Nimmt man fertige Routinen, vereinfacht sich das Ganze natürlich 
ziemlich und da fällt mir das fälschlich Isaac Newton zugeschriebene 
Zitat ein:

"Wir alle stehen auf den Schultern von Riesen"

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> "Diese uralt-Kisten sind sehr kompliziert"

Kommt auf das Abstaktions-Level an, wie man sie betrachtet ...

Wenn man sich den VIC anschaut, dann ist das Ding furchtbar kompliziert.

Wenn man sich ansieht, wie die Komponenten verschaltet sind und die 
Chips nur als Blackboxen ansieht, vereinfacht sich das extrem.

Bei deiner Argumentation hast du eins nicht bedacht ... Die damaligen 
Entwickler waren alle genial und haben unglaubliche Leistungen 
vollbracht ... Trotzdem ist etwas bestehendes nachzuvollziehen oder gar 
nachzubauen wesentlich einfacher.

Meine Aussage schmälerte in keiner Weise die Leistung, die damals 
vollbracht wurden - vor alter Computer-Technik hab ich den höchsten 
Respekt (oder auch vor so Sachen wie dem Fernseher und der 
abwärtskompatiblen Erweiterung für die Farbe und die technische 
Umsetzung nur mit analogen Komponenten!)

Aber es ist nunmal so, dass vollbrachte Leistungen leichter repliziert 
werden können als etwas von Grund auf neu zu erfinden ... :)

> Gut, es ist die Frage, ob man wirklich so viel Aufwand betreiben will
> um einen SID-Tune-Player auf dem STM zum laufen zu bekommen.

Genau das ist der Punkt ... Evtl gibt es jemand, der den Ehrgeiz hat, 
das zu machen ... Ich gehöre da sicher nicht dazu - wenn etwas länger 
als 2 Wochen dauert, suche ich mir ein neues Projekt^^

> Nimmt man fertige Routinen, vereinfacht sich das Ganze natürlich
> ziemlich.

Genau, darauf wollte ich hinaus und meine Aussage war auf eine 
FPGA-Implementierung bezogen.

Ich hab fertige VHDL-Cores für 6502, CIA, SID und VIC (den ich 
allerdings so nicht verwenden werde) gefunden und die anzupassen und in 
ein VHDL-Projekt zu integrieren ist nicht besonders schwierig, da ich 
das meiste nur als Black-Boxen verwenden werde und sie nicht von Scratch 
neu bauen muss :)

Die PLA zB brauch ich so überhaupt nicht, wie sie im C64 war ... Mit 
VHDL ist man unabhängig vom Rest des C64, d.h. man muss auf vieles 
garnicht eingehen und es muss nicht kompatibel bleiben. Bisschen 
Adressdekodierung (wahrscheinlich sogar weniger, weil ich mit einem 
haufen SRAM verschwenderisch umgehen werde und so gut wie keine 
Adress-Dekodierung brauche, da ich keine zig verschiedenen Speicher habe 
sondern nur einen einzigen und dynamisches RAM hab ich auch nicht, das 
refresht werden müsste) und das war es dann im Prinzip, solange das 
Timing von CPU und VIC dann passt.

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vor einiger Zeit habe ich mir diesen Video-Vortrag von einem der 
Entwickler bei Commodore angeschaut.
Die Inhalte des Vortrags sind wirklich gut:
Man bekommt einen guten Eindruck unter welchen Bedingungen ( sowohl 
technisch wie auch wirtschaftlich ) damals diese Home-Computer 
entwickelt wurden.

http://hackaday.com/2016/12/13/computers-for-the-masses-not-the-classes/

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Vor einiger Zeit habe ich mir diesen Video-Vortrag von einem der
> Entwickler bei Commodore angeschaut.
> Die Inhalte des Vortrags sind wirklich gut:
> Man bekommt einen guten Eindruck unter welchen Bedingungen ( sowohl
> technisch wie auch wirtschaftlich ) damals diese Home-Computer
> entwickelt wurden.

Vielen Dank für das Video, das schau ich mir morgen gleich mal an!

Sowas finde ich hochinteressant! :)

Ah kleiner Zwischenstand zum FPGA-Dingens ... Ich bau gerade am Mini-VIC 
... Hab ein geniales Dokument gefunden, in dem das Timing steht und die 
"Hold"-Zeiten, in denen der 6510er nicht auf den Bus zugreifen darf.

http://unusedino.de/ec64/technical/misc/vic656x/vic656x-german.html

: Bearbeitet durch User
von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Dieser Artikel über den VIC ist in c64-Kreisen zwar bislang der 
Standart-Report schlechthin, allerdings dürfte der VIC bei einem 
SIDplayer nur eine sehr untergeordnete Rolle spielen. Es sollte reichen 
die aktuelle Rasterzeile in 0xd012/0xd011 sowie die zugehörigen 
Interrupts zu emulieren. Über etwaige Verzögerungen durch Badlines oder 
Sprites würde ich mir da überhaupt keine Gedanken machen*.

Die Emulation des 6510 wird wesentlich relevanter sein, und dafür kann 
ich - neben den alten Schinken von Synertek** - vor allem auch die 
Seite:
http://web.archive.org/web/20160315002735/http://homepage.ntlworld.com/cyborgsystems/CS_Main/6502/6502.htm
empfehlen!

Wünsche dir - auch aus eigenem Interesse xD - weiterhin viel Erfolg bei 
deinem Projekt! :D


* ich möchte mal behaupten das es Coder, damals wie heute, einen 
feuchten Kehrricht interessiert ob der Player ab und an mal für ein paar 
µS unterbrochen wird. xD
Solange man nicht weiss welchen Tracker der Musiker damals genutzt hat, 
und an welchen Taktzyklen der zugehörige Player dort vom VIC 
unterbrochen wurde, braucht man glaube ich gar nicht erst zu versuchen 
das Ganze auf µs exakt abspielen zu wollen. Das hört sowieso niemand 
heraus. Die Toleranzen des Analogteils vom SID (und seiner externen 
Beschaltung) sind schon alleine groß genug als das es hier wirklich 
nicht auf ein paar µS ankommt.

** http://archive.6502.org/datasheets/synertek_programming_manual.pdf
http://archive.6502.org/datasheets/synertek_hardware_manual.pdf

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> ch möchte mal behaupten das es Coder, damals wie heute, einen
> feuchten Kehrricht interessiert ob der Player ab und an mal für ein paar
> µS unterbrochen wird. xD

Naja, das ist schon einiges an Holz, was da abfällt ... Jede 8te Zeile 
um die 40 Taktzyklen + extra noch etwas, wenn Sprites aktiv sind :)

Ich kann mal testen, was passiert, wenn man in libsidplay das 
"BA"-Signal einfach deaktiviert :) Danke für die Idee!

Michael H. schrieb:
> Die Emulation des 6510 wird wesentlich relevanter sein

Für den hab ich mir bei OpenCores einen Core gesucht, der von sich 
selbst behauptet, er wäre zyklengenau :)

Also eigentlich war es 6502, den ich um den 6-Bit-Port, der über die 
Zeropage angesprochen wird, erweitern musste :)

Michael H. schrieb:
> Wünsche dir - auch aus eigenem Interesse xD - weiterhin viel Erfolg bei
> deinem Projekt! :D

Danke danke :)

Bin auch gut weitergekommen ... Den Minimal-VIC von libsidplay hab ich 
gestern nach VHDL portiert und quasi alles zusammen gebaut.

Synthese-Report anbei ... Passt locker (Mini-VIC, 6510, CIA1+2, inkl 2 
SIDs) in den FPGA des Altera DE1-Boards xD

Mit etwas Glück schaffe ich es heute noch, das Ganze zu testen :)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Heute auf Heise über den Monster-6502 :D

Sehr geiles Ding :)

https://www.heise.de/newsticker/meldung/Mehr-LEDs-MOnSter-6502-blinkt-wieder-3715460.html

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, das Teil finde ich auch super. Am liebsten hätte ich eins.

Hier wurde ein Thread dazu angefangen:
Beitrag "6502 selfmade CPU"

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Kennt jemand zufällig einen guten 6502 Disassembler für Linux?

Meine CPU läuft um Kreis ... Sie hat den Reset-Vector richtig aus dem 
RAM gelesen und ist an die richtige Stelle gesprungen, hat noch ein paar 
Befehle ausgeführt und hängt nun an einer Stelle:

$1f8e: jmp $1f8e

Ist wohl eine Art Fehler-Handler für irgendwas ... Nur mir ist nicht 
klar, weshalb sie dort hin kommt :)

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Kleiner Zwischenstand ... Mein Problem von letztens war falsche 
Interrupts vom MiniVIC ... Hab einige Fehler in meiner Implementierung 
gefunden, dann kam zumindest schonmal Sound und ein Rythmus war 
erkennbar.

Jetzt hab ich festgestellt, der r6502_tc Core funktionierte nicht 
richtig, mit dem T65-Core hab ich zumindest Music, die noch (extrem) 
übersteuert ist, ansonsten funktionierts.

Dürfte nur noch eine Kleinigkeit sein, dann läuft es xD

von Mampf F. (mampf) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an, aaaber 
hab da noch ein merkwürdiges Problem, das mit einige Zeit kosten wird, 
zu beheben ...

Die ersten 14 Sekunden oder so läuft die Musik viel zu schnell, bis sie 
dann plötzlich in der richtigen Geschwindigkeit läuft ... Keine Ahnung, 
wie das möglich ist. Evtl irgendeine Interrupt-Geschichte, aber so viele 
Interrupts gibt es da nicht und die CIA kann ich ausschließen (2 
unterschiedliche getestet, gleiches Ergebnis).

14 Sekunden sind halt echt seltsam ...

Kann jetzt noch versuchen, den MiniVIC durch einen anderen testhalber zu 
ersetzen, aber bei dem sollten die Interrupts korrekt sein ... Naja, mal 
schauen

: Bearbeitet durch User
von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an,
:D

> Die ersten 14 Sekunden oder so läuft die Musik viel zu schnell, bis sie
> dann plötzlich in der richtigen Geschwindigkeit läuft ... Keine Ahnung,
> wie das möglich ist. Evtl irgendeine Interrupt-Geschichte, aber so viele
> Interrupts gibt es da nicht und die CIA kann ich ausschließen (2
> unterschiedliche getestet, gleiches Ergebnis).
Hmmmstimmt, es werden wohl nur die wenigsten SID-Files implizit 
Interrupts verwenden.
Wie werden die aus der Emulation herauskommenden Daten denn 
schlußendlich ausgegeben? Werden PCM-Samples errechnet und in einem 
Ringbuffer abgelegt, welcher dann per ISR abgespielt wird? Falls ja, 
vielleicht stimmt dort die Synchronisation erst dann wenn der Buffer 
vollgelaufen ist? Klingt etwas an den Haaren herbeigezogen, ich weiss, 
aber an irgendetwas muss es ja liegen. Und wenn es etwas naheliegendes 
wäre hättest du's ja wahrscheinlich schon längst gefunden... ;-)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> Wie werden die aus der Emulation herauskommenden Daten denn
> schlußendlich ausgegeben?

Direkt als PCM-Audio-Samples :) Die werden direkt an den Audio-CODEC 
geschick.

Michael H. schrieb:
> Falls ja,
> vielleicht stimmt dort die Synchronisation erst dann wenn der Buffer
> vollgelaufen ist?

Hmm ... Irgendein Timing-Problem muss es sein ... Wenn ich meine 
Bus-Decoder-Logik ändere - zB auf Taktsynchron umstelle - dann bleibt 
das Phänomen nicht nur 14 Sekunden, sondern quasi für immer.

Also scheint es irgendwas mit der Buslogik zu tun zu haben, aber die 
Effekte sind mir völlig unverständlich.

Und soviele Möglichkeiten gibt es eigentlich nicht ... CIA1 und 2 hab 
ich von den Interrupts totgelegt, das Phänomen bleibt. Und der MiniVIC 
macht zumindest in der Simulation, was er soll. Und der VIC von FPGA64 
macht genau das gleiche (=Phänomen bleibt).

Interessanterweise macht es der andere CPU-Core auch nicht richtig, aber 
da ist die Geschwindigkeit nicht zu hoch, sondern viel zu langsam ... Da 
wird der SID nur kA alle halbe Sekunde mal mit neuen Werten gefüttert.

Also irgendwas ist grundlegend falsch und ich bin bisher noch nicht 
dahinter gekommen, was es ist.

Ich schau nochmal in das FPGA64-Projekt rein, evtl fällt mir da etwas 
auf, was dort anders als in meiner Implementierung gemacht wird :)

Und in der Arbeit hab ich ein Oszi, dann kann ich mir mal wirklich die 
Interrupts auf irgendwelche Pins ausgeben lassen und kucken :)

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an,

Bezieht sich das jetzt auf die Microcontroller- oder die FPGA-Version?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Bezieht sich das jetzt auf die Microcontroller- oder die FPGA-Version?

Die FPGA-Version :)

Ah hmm, mist ... Mit der CPU vom FPGA64 Projekt läuft es einwandfrei 
(zumindest das eine Lied, hab noch kein anderes getestet). D.h. ich muss 
weiter Cores testen, bis ich einen finde, der funktioniert und der 
lizenztechnisch kein solcher Albtraum ist wie der von FPGA64 :)

Falls ich Wizball in Stereo zum Laufen bekomme, dann nehm ich es auf und 
lade es hoch^^

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Zlorfix ... hab mir ein schönes Stereo-SID-File herausgesucht und jetzt 
ist die libsidplay zu alt, um es zu laden.

D.h. ich darf die libsidplayfp nochmal für den ARM kompilieren ...

Die Lib brauch ich, um den RAM und ROM Inhalt als quasi eine Art 
Memory-Image zu bauen, das ich dann in den FPGA lade ... Ohne 
libsidplay(fp) wäre das nahezu unmöglich selbst zu implementieren ... 
Krasser Scheiß, was die da alles in der Lib machen ... Installieren 
selber noch irgendwelche Treiber (mit Hardware-Initialisierung), 
relokieren C64-Code usw^^

von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Stereo-SID (der zweite Kanal beginnt erst nach 30 
Sekunden!), abgespielt auf dem FPGA :)

Man hört noch ein leichtes Knacken öfters ... Mal kucken, was das wieder 
ist ;-)

*edit*: Ah, mir fällt ein ... Womöglich könnte man das FPGA64-Projekt 
doch nutzen, wenn man nicht den Code redistributed, sondern ein 
Patch-File anbietet, womit die Projekt-Files gepatcht werden können :)

Vielleicht mach ich das ... Glaube, das könnte ein ziemlicher Aufwand 
sein, bis alle SID-Files auf dem FPGA laufen - und soviel Motivation und 
Zeit hab ich nicht ;-)

edit2 *UND* ich hab herausgefunden, weshalb der t6502_rc-CPU-Core 
nicht vernünftig funktioniert hat.

Der hat eine Kleinigkeit vom echten 6502 nicht implementiert ... Wenn 
der VIC die CPU per BA-Signal unterbricht, dann schreibt dieser noch 
schnell Daten weg, bevor sie dann auf den VIC wartet, bis dieser 
wiederrum die CPU wieder frei gibt.

Das dauert 3 Taktzyklen, aber die t6502_rc-Implementierung hatte mit dem 
BA-Signal sofort die Arbeit eingestellt und das ging in die Hose.

Der (rettende) Trick war, das BA mit einem CPU_WR zu verodern, d.h. die 
CPU läuft weiter, solange sie schreibt und jetzt geht auch dieser Core 
richtig :)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Könnte ein Moderator bitte den Thread-Titel in "SID-Player ARM/FPGA?" 
ändern? :) Danke!

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gratulation Mampf, Du bist ziemlich schnell.

Was mir beim MP3 auffällt: Die Musik klingt, als wenn Hall darin wäre.
Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram 
laufen?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram
> laufen?

Puh ehrlich gesagt, keine Ahnung! :D

Die Files haben noch einiges an Header-Zeugs vorne dran ... u.A. wohin 
sie ins RAM geladen werden, die I/O-Adresse des 2ten SIDs, ob PAL oder 
NTSC usw usf ...

Die werden von der Lib aber so aufbereitet, dass sie auf "echter" C64 
Hardware quasi laufen. Die Lib emuliert alles bis zu den Portpins des 
6510ers, mit denen die Speicherbereiche umgeschaltet werden.

Deshalb laufen die Files auch auf meinem FPGA-C64-Nachbau scheinbar 
problemlos.

Nachdem die lib den emulierten C64 initialisiert hat, dumpe ich die 
Speicherbereiche und lade sie in den FPGA und starte dann die CPU - und 
das funktioniert :)

Libsidplayfp kann mittlerweile auch PRG-files laden. Die wären dann 
direkt ohne irgendwas auf dem C64 abspielbar.

: Bearbeitet durch User
von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Markus schrieb:
>> Würde dieses SID-File noch auf einem echten C64 laufen mit 64K-Ram
>> laufen?
>Mampf
>Puh ehrlich gesagt, keine Ahnung! :D

Ich frage nur deshalb, weil mir der Klang so erscheint, als wenn die 
allerlei Tricks verwenden.
Normalerweise erzeugt man die Klänge des SID mit seinen internen 3 
Oszillatoren. Es gibt auch Programme, die einfach alle 20-50ms die 
Registerwerte für den SID mitschreiben. Damit kann man später den SID 
offline ( also ohne 6510 Emulation ) spielen, indem man einfach die 
Registerwerte mit der Rate an den SID schickt.
Aus der Akkustik Deines MP3-Files würde ich vermuten, dass sie die 
Oszillatoren des SID aber umgehen und den SID teilweise irgendwie als 
reinen DAC benutzen und mehr oder weniger Wav-Tables abspielen.
Dafür würde man aber mehr Speicher als die 64K benötigen, die der C64 
zur Verfügung hat.

Vielleicht gibt es hier ja jemand, der sich mit den Tricks für den SID 
auskennt.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Aus der Akkustik Deines MP3-Files würde ich vermuten, dass sie die
> Oszillatoren des SID aber umgehen und den SID teilweise irgendwie als
> reinen DAC benutzen und mehr oder weniger Wav-Tables abspielen.
> Dafür würde man aber mehr Speicher als die 64K benötigen, die der C64
> zur Verfügung hat.

Das täuscht :)

Ich hab Stereo-SID-Files in den Player geladen ... Der hat dann 3 
Stimmen pro links und rechts ... Die Implementierung selbst ist ein 
standard-SID, der nicht mehr kann.

Es gab einige MODs, mit denen man einen zweiten SID nachrüsten konnte.

Der C-One (für den ist FPGA64) ist standardmäßig mit 2 SID-Sockeln 
ausgestattet :)

Aber zu C64-Zeiten waren die Programmierer schon sehr trickreich :)

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das hier hat zB nur 7,3kB :)

von Jobst M. (jobstens-de)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> Leider nicht. Der Amiga hatte afaik einen Chip namens Paula welcher
> PCM-Samples per DMA abspielte.

Korrekt. 4 Audiospuren, 2 davon links, 2 rechts. 8 Bit, fs bis knapp 
über 50kHz, wenn ich mich recht erinnere.

> Aber falls du da tatsächlich noch eine Kiste mit SIDs im Keller hast
> dann sag Bescheid!! :D

Also ein paar habe ich noch ... ;-)
Von den 8580 könnte ich mir vorstellen, ein paar loszuwerden.
Sind unbenutzt.


H.Joachim S. schrieb:
> Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja
> PLCC.

Nein, Paula ist DIL. Agnus ist PLCC.


Gruß
Jobst

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Also ein paar habe ich noch ... ;-)

Gold in Chipform ....

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Was zum Geier ist SID?

Das Vieh aus Ice Age. Grundwissen.
;-)


Markus schrieb:
> Gold in Chipform ....

Also wieder zurück in's Bankschließfach ...


Gruß
Jobst

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jetzt muss ich mir mal Gedanken darüber machen, wie ich den SID-Player 
hardware-technisch bauen wollen würde :)

Gäbe es Interesse, das ganze Dingens tragbar mit kleinem Display zu 
haben?

Ist halt schon nerdiger Scheiß^^

Wahrscheinlich läuft sidplayfp sowiso auf Android problemlos ;-)

Also irgendwie nett der Kram, aber wofür sollte man ihn denn jetzt 
wirklich verwenden?

: Bearbeitet durch User
von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Jetzt muss ich mir mal Gedanken darüber machen, wie ich den SID-Player
> hardware-technisch bauen wollen würde :)
>
> Gäbe es Interesse, das ganze Dingens tragbar mit kleinem Display zu
> haben?

Hi Mampf,
mal aus Neugierde: Hast Du Dein Projekt mittlerweile erfolgreich 
abschließen können? Und gibt es eine Dokumentation dazu, mit deren Hilfe 
man es nachbauen kann? :D
Ich selber wäre noch immer sowohl an einem tragbaren Dingsie als auch an 
einer 19"-Variante interessiert.

PS: Und falls Du daran gedacht auch das Apspielen von MODs zu 
implementieren wäre das der absolute Hammer!! =D

von Mampf F. (mampf) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Michael H. schrieb:
> mal aus Neugierde: Hast Du Dein Projekt mittlerweile erfolgreich
> abschließen können? Und gibt es eine Dokumentation dazu, mit deren Hilfe
> man es nachbauen kann? :D

Nah, hatte instantan damit aufgehört und mein DIY-STM32-Board der 
ursprünglich geplanten Verwendung zugeführt xD

Ein dedizierter SID-Player wär zwar nett ... Aber für was? :)

Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also 
schon erschlagen.

Allerdings hätte ich wirklich noch mein zusammengetragenes Zeugs auf 
irgendeiner Webseite zum Download anbieten sollen, damit die Arbeit 
nicht ganz umsonst war.

Evtl migriere ich noch die Software vom DIY-STM32-Board auf einen 
Maple-Mini. Den SID-File-Loader würde ich auf den PC auslagern und per 
USB über das Discovery die Daten ins Altera DE1 schaufeln. (oder den 
auch noch weglassen und RS232 mit einem USB-RS232-Dongel verwenden? 😍 )

Das wäre kein großer Aufwand,eventuell Interessierte bräuchten keine 
Custom-Hardware und es könnte an einem Tag erledigt sein.

Dann den ganzen kram ins Netz werfen und sich selbst überlassen, so zu 
sagen ;)

Werde ich im Hinterkopf behalten ...^^

: Bearbeitet durch User
von das Rad neu erfinden (Gast)


Bewertung
0 lesenswert
nicht lesenswert
http://www.staringlizard.com/2015/12/03/memwa-ii/

wer nicht bei null anfangen will.

von Michael H. (dowjones)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Nah, hatte instantan damit aufgehört und mein DIY-STM32-Board der
> ursprünglich geplanten Verwendung zugeführt xD

Hach, ein Jammer...

Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist
> also schon erschlagen.
Jaaaaa, aber das ist halt nicht dasselbe. Ich persönlich möchte die 
Musik von damals halt nicht nur auf einem seelenlosen Smartphone hören 
sondern auch "fühlen"; von daher käme für mich nur eine C64-Emulation in 
Frage die einen realen SID ansteuert. Hatte gehofft ich könnte mich bei 
der Realisierung dessen z.T. bei deinem Projekt bedienen. 8)

> Allerdings hätte ich wirklich noch mein zusammengetragenes Zeugs auf
> irgendeiner Webseite zum Download anbieten sollen, damit die Arbeit
> nicht ganz umsonst war.
Ja, mach mal! Jedes bisschen hilft bestimmt schon irgendjemandem weiter. 
:)

das Rad neu erfinden schrieb:
> http://www.staringlizard.com/2015/12/03/memwa-ii/
>
> wer nicht bei null anfangen will.
Ach das Teil ist ja putzig! xD

: Bearbeitet durch User
von Ordner (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Was zum Geier ist SID?

Ich glaube, diese Rückfrage, sagt alles über den selbsternannten "Lord 
des Cyberspace" aus. Wie abgehoben und verquert kann man im Kopf sein, 
dass man in 30 Jahren nicht einmal das Wort mitbekommen hat und auch 
nicht in der Lage war, es zu googlen. Ich bin sicher, das Wort SID ist 
auch heute noch den meisten normalen Computernutzern eher inhaltlich 
bekannt, als solche Begriffe wie DDR, COM, DAO, was sie täglich nutzen.

Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also
> schon erschlagen.

von Ordner (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Jedes Smartphone kann die Dinger abspielen, das Thema tragbar ist also
> schon erschlagen.

Die Frage ist nur wie es klingt. Nach echtem SID sicher nicht.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nur mal so am Rande ...

Hab das damalige Projekt - mittlerweile ja über 1 Jahr her, auf einem 
Cyclone 10LP "recycled" :)

https://www.youtube.com/watch?v=yl28o-LobGM

Dummerweise hab ich immer noch keine GPL/MIT-Variante eines 6502/6510 
gefunden, der da funktioniert.

T65 hatte ich ausprobiert und der 6502_tc von OpenCores auch ... 
Letzterer ging zumindest auf dem Altera DE1 letzten Jahr (ist wohl ein 
Timing-Problem, weil der lief mit externem SRAM - das aktuelle Board hat 
nur BlockRAM).

Falls noch jemand Ideen hat ... :)

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Hast mal im f64 Lilith gefragt? Der hat doch auch nen 6510 geschrieben?

von Johnny B. (johnnyb)


Bewertung
1 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine
> ARM-Portierung eignen würden?

Fürs Raspberry Pi, welches ja ARM basiert ist, gibt es komplette C64 
Emulatoren (VICE). Der Vorteil ist noch, dass Du die originalen 
Applikationen vom C64 verwenden kannst.
https://github.com/retropie/retropie-setup/wiki/Commodore-64-VIC-20-PET

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Mampf F. schrieb:
>> Kennt jemand noch andere SID-Emulator-Projekte, die sich für eine
>> ARM-Portierung eignen würden?
>
> Fürs Raspberry Pi, welches ja ARM basiert ist, gibt es komplette C64
> Emulatoren (VICE). Der Vorteil ist noch, dass Du die originalen
> Applikationen vom C64 verwenden kannst.
> https://github.com/retropie/retropie-setup/wiki/Co...

Danke für den Tipp, aber um einen Emulator auf einem ARM ging es mir 
eigentlich nicht - mein Projekt spielt SID-Musik auf einem 
synthetisierten C64 im FPGA ab quasi.

Ich hatte allerdings den VIC der libsidplayfp (Sid-Player für Linux) 
nach VHDL portiert (Mini-VIC ohne Video). (Die Komponente sollte ich mal 
frei geben ... Ist eigentlich eine der wenigen Neuerungen die auf meine 
Arbeit zurück gehen ... Der Rest ist mehr oder weniger nur Glue-Logic - 
ah für libsidplayfp-angepasstes internes RAM ... Der Cyclone 10LP hat 
davon zu wenig und das gesamte ROM (nachdem libsidplayfp alles 
installiert hat) lässt sich auf weniger als 32Byte kürzen^^).

Libsidplayfp macht intern noch viele andere Dinge... Für SID-Musik 
abspielen braucht man im Prinzip weder Kernel noch Basic und möchte 
keine Benutzer-Interaktion ´ala load "$",8.

Es bereitet ROM und RAM quasi so vor (neue Reset-Vektoren, Basic-Trap, 
SID-File in den RAM - und installiert sogar einen SID-Player im RAM, der 
nach dem Reset direkt ausgeführt wird!), dass nach dem Start des 
C64-Cores direkt das SID-File abgespielt wird.

Geniale Library!

Ich glaub ich teste mal den ag_6502 ... Da muss ich aber bisserl was 
umbauen, weil der die Signale Phi1 und Phi2 selbst erzeugt.

von Christian F. (feuerwerk)


Bewertung
1 lesenswert
nicht lesenswert
Hi Mampf

Ich weiss nicht ob es dir hilft, aber wenn du eine freie 
6502-Implementierung suchst, kann ich dir meine anbieten, vielleicht 
funktioniert sie für deinen Einsatzzweck. Ja, ich weiss, ist nicht die 
schönste Implementierung, aber nachdem diverse Test-Roms erfolgreich 
darauf laufen gehe ich davon aus, dass meine Implementierung ein 
akkurates Timing besitzt. Einzige Einschränkung derzeit: Nur die 
offiziellen Opcodes und es gibt keinen Dezimal-Modus

https://github.com/Feuerwerk/fpgaNES

Die relevanten Dateien sind cpu.vhd, common.vhd sequencer.vhd

Viel Erfolg mit deinem Projekt
Christian

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christian F. schrieb:
> Ich weiss nicht ob es dir hilft, aber wenn du eine freie
> 6502-Implementierung suchst, kann ich dir meine anbieten, vielleicht
> funktioniert sie für deinen Einsatzzweck.

Wow, ein NES! 😍😍😍

Wieso ist mir denn das entgangen! :)

Vielen Dank für den Link!

Deine CPU probier ich demnächst mal aus :)

von SIDO (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Danke für den Tipp, aber um einen Emulator auf einem ARM ging es mir
> eigentlich nicht - mein Projekt spielt SID-Musik auf einem
> synthetisierten C64 im FPGA ab quasi.

Ich habe es immer noch nicht voll kapiert. Läuft nun der C64 auf dem 
FPGA und darauf oder dem ARM eine Software die SID macht oder ist der 
SID in Hardware abgebildet?

Im Fall1 empfehle ich, Dich mal mit denen hier kurz zu schließen:
https://hackaday.com/2015/02/06/a-raspberry-pi-sid-player/
https://www.arduinolibraries.info/libraries/stereo-sid

Der trötet bei mir erfolgreich!

Im Fall2, kämen die hier in Betracht:

http://www.swinkels.tvtom.pl/swinsid/
http://www.96khz.org/htm/sidemulation2.htm
http://www.fpgasid.de/project-definition

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Der trötet bei mir erfolgreich!

Welcher jetzt?

von Marcus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hier gibt es eine Kollektion von SID-Stücken:
Youtube-Video "The Epic Commodore C64 SID Collection - 11 hours of C64 Music"
Die meisten um 1988. Wie wohl modernere Stücke klingen würden?

von Sepp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
War der SID nicht teilweise analog auf dem DIE ? Ich hatte einen C64 an 
einer analog Glotze und es klang gut... R-Type zB. hatte da einen 
ohrgasmischen Level.

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Ja, der SID teilweise analog. Deshalb kann man ihn heute auch nicht mehr 
nachfertigen, weil es keine Fabriken für die damaligen 
Fertigungsverfahren mehr gibt... ;-(

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas R. schrieb:
> Ja, der SID teilweise analog. Deshalb kann man ihn heute auch nicht mehr
> nachfertigen, weil es keine Fabriken für die damaligen
> Fertigungsverfahren mehr gibt... ;-(

Naja, dann muss es eben nach-analogisieren, sollte doch anhand der 
scopebilder möglich sein:

Youtube-Video "Chris Huelsbeck - "R-Type (C64) - Loader/Title Theme" [Oscilloscope View]"

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Naja, dann muss es eben nach-analogisieren, sollte doch anhand der
> scopebilder möglich sein:

Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang 
nachzustellen. Sie können vlt Hinweise geben, wohin man denken muss. 
Wenn man das richtig machen möchte, ist da einiges zu tun. Beim SID 
wirkt u.a. auch die Versorgungsspannung und der analoge Ausgang. Vom 
Sound über den TCV-Modulator ganz zu schweigen.

von C. A. Rotwang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Naja, dann muss es eben nach-analogisieren, sollte doch anhand der
>> scopebilder möglich sein:
>
> Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang
> nachzustellen.

Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden 
sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte 
elektrische Signal und wenn man einen signalgenerator baut der den 
selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher 
auch keine andere Chance als die selben mechanischen Schwingungen zu 
fabrizieren.
Von Audio-Esotorik wie monokristalinen Kupfer und bei Vollmand 
gestreckte Kabel halte ich nix.
Was am Ausgangstreiber am FPGA hinsichtlich Lastverhalten anders ist, 
muss man halt mit einer NF-Stufe nachbilden. C64 Schaltpläne liegen 
beispielsweise dort: 
http://personalpages.tds.net/~rcarlsen/cbm/c64/SCHEMATICS/250469/252312.jpg
 ein 2SC1815 sollte heute noch kaufbar sein.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden
> sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte
> elektrische Signal und wenn man einen signalgenerator baut der den
> selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher
> auch keine andere Chance als die selben mechanischen Schwingungen zu
> fabrizieren.

Schon klar, nur ist eben jener Mixed Signal chip für sich schon sehr 
stark mit Effekten behaftet, die über die rein mathematische 
SRDN-Synthese hinaus geht. Ich habe ja Original-Aufnahmen vom SID und im 
Vergleich dazu das Emulatoren (und anderem dem Meinen) und das 
unterscheidet sich deutlich.

von Andi (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Wenn ich so ein SID-Tune höre, wie im Video 4 Beiträge früher, dann 
frage ich mich:
Kommt es wirklich drauf an, ob die Musik nun original schrecklich 
klingt, oder leicht anders schrecklich ;-)

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Kommt es wirklich drauf an, ob die Musik nun original schrecklich
>klingt, oder leicht anders schrecklich ;-

Na, so schlecht klingt das nun auch wieder nicht.
Youtube-Video "Chris Huelsbeck - "R-Type (C64) - Loader/Title Theme" [Oscilloscope View]"

Und Du musst bedenken: Es ist wirklich exorbitant, was mit den damals 
beschränkten Techniken erreicht werden konnte. Die niedrige 
Rechenleistung war nämlich kaum wirklich für die Sounderzeugung 
geeignet.

Aber klar, ein paar Jahrzehnte später ist man immer Besseres gewohnt und 
belächelt das Vergangene.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Nja es soll ja nicht ein Lautsprecher im FPGA nachmoduliert werden
>> sondern lediglich ein Mixed signal IC resp. das von ihm erzeugte
>> elektrische Signal und wenn man einen signalgenerator baut der den
>> selben y(t)-Verlauf fabriziert dann hat der E-Magnet im Lautsprecher
>> auch keine andere Chance als die selben mechanischen Schwingungen zu
>> fabrizieren.
>
> Schon klar, nur ist eben jener Mixed Signal chip für sich schon sehr
> stark mit Effekten behaftet, die über die rein mathematische
> SRDN-Synthese hinaus geht. Ich habe ja Original-Aufnahmen vom SID und im
> Vergleich dazu das Emulatoren (und anderem dem Meinen) und das
> unterscheidet sich deutlich.

Diese Unterschiede zwischen Originalsample und Emugebläse sollten aber 
deutlich im Oszilloscop oder Spectrumanalyser sichtbar sein. Das ist 
doch der Kernpunkt der Nebendiskussion, Zitat:
"Ich denke nicht, dass ScopeBilder wirklich genau genug sind, den Klang
nachzustellen."

Diese meinung teile ich nicht im geringsten, ich dachte die leidigen 
Wettbewerbe "Wer hört den Unterschied zwischen CD und Kasette" oder gar 
MP3 wie sie noch in den neunzigern gängig wären gehören, endgültig der 
Vergangenheit an.

Damit es gleich klingt, sollte man schon die selbe Endstufe benutzen, 
also aus dem C64 Schaltplan den Transistor raussuchen und dem Eigenbau 
Emulator dranstöpseln. Dazwischen macht sich sicherlich noch ein OPV 
o.ä. gut um das Last-Strom Verhalten aka Ausgangswiderstand des 
SID-Nachbaus an den Originalen anzupassen. Das machen sicherlich die 
wenigsten Nachbauer. Klar könnte man dessen Kennlinie auch in den 
Digitalbau einrechnen, aber das macht wohl auch keiner sondern begnügt 
sich mit Gefasel über verlorengangenen Herstellertechnologien.
Wem Auswirkungen von Schwankungen der Betriebsspannung wichtig sind, 
ermittelt diese eben (bspw. durch eine FT über eine Aufzeichnung vom 
Original-Chip) und stellt sie nach, beispielsweise über eine AM geringer 
Frequenz oder TP mit variabler fg oder oder.
Für den Bereich bis 12 kHz für den es für den SID geht, sollte das ein 
FPGA oder DSP locker schaffen, den mit heutigen FPGA's kann man 
Funksignale im MHz-Bereich (SDR) synthetisieren, ich glaube daher nicht 
daß dies für Audiosamples geringer Frequenz, Qantisierung und Länge 
nicht möglich sein sollte. Das Problem liegt eher in der "Mühe" sich das 
Wissen zu erarbeiten oder einfach ein bißchen mit dem Parametern zu 
spielen um einen SID-Nachäffer so zu tunen, das ein menschliches Ohr 
keinen Unterschied hört.

Hier mal "mein Lieblingsvideo" zur Signalanalyse ;-)
Youtube-Video "Contact berlin games"

Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID, 
die Trommelfelle freiblasen:
Youtube-Video "Amiga Longplay  R-Type"
Youtube-Video "Chris Huelsbeck - Turrican Main theme (Amiga 500)"
Obwohl dieses Sample klingt, als ob da jemand vergessen hat, den 7kHz 
Analogfilter das A500 abzuschalten.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Also einmal bezog ich mich auf deine Beispiel mit den Scope-Bildern auf 
YT. Die sind definitiv nicht genau genug, um was en detail zu 
beurteilen. Des weiteren ist zu sagen, dass Scope generell oft nur 8 Bit 
aufweisen und darstellen, von daher ...

Es ist auch schwierig, anhand einer Amplitudenabbildung den Klang und 
den Unterschied zu ersehen und gedanklich in Änderungen von Algorithmen 
zu übertragen. Wenn überhaupt, kommt man da mit einem Spektrumanalyzer 
und den Ohren weiter.

Beides habe ich getan. Ich kenne die einschlägigen Emulationen und habe 
hier auch Audiotechnik im Studio, die es mir gestattet, mehr zu hören 
und zu sehen, als es der Durchschnittsanwender kann.

Von daher bleibe ich bei der Haltung, dass eine authentische Nachbildung 
des SID oder anderer mixed-Signal-Audio-Chips schwierig bis unmöglich 
ist, auch wenn die Technologie durch DSPS und FPGAs es theoretisch 
leicht zuließe.

Es ist ja nicht so, dass ich keine Erfahrung in der Emulation in 
Analogtechnik hätte :-)

Bei der Bemerkung:

> ich dachte die leidigen Wettbewerbe "Wer hört den Unterschied
> zwischen CD und Kasette" oder gar MP3 wie sie noch in den neunzigern
> gängig wären gehören, endgültig der Vergangenheit an.
sehe ich noch nicht den Bezug zum Thema, stelle aber auch hier meine 
Haltung entgegen, dass diejenigen mit intakten Ohren selbstredend 
Unterschiede von Kassetten, CD und mp3 hören, zumal sich sich technisch 
quantifizieren lassen. Dass einige infolge ihrer Hörgewohnheiten nichts 
mehr hören, weil ihr Gehör verarmt ist, ist inzwischen bewiesenes Fakt, 
da öfters Gegenstand von wissenschaftlichen Untersuchungen. Frequenzen, 
die ein Hirn nicht mehr angeboten bekommt, weil das Ohr sie nicht 
transportiert, kann es nach einer Weile auch dann nicht mehr hören, wenn 
derjenige ein Hörgerät bekommt. Das Gehirn verlernt das Hören! Dieselben 
Effekte, die dazu führen, dass das Gehirn sich verändernde Ohrgeräusche 
durch Blutströmung und Ohrwachstum ausblenden kann und Bässe wahrnehmen 
kann, die nur durch Oberwellen skizziert werden sind auch dafür 
verantwortlich, Raumgrößen und Tiefen abzuschätzen und es ist ein Fakt, 
dass der Einheitsbrei, der den Ohren heute zugeführt wird, zu einem 
verarmen und letztlicher Nicherkennbarkeit führen.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christian F. schrieb:
> https://github.com/Feuerwerk/fpgaNES

Das schaut interessant aus! Kann der auch schwarze OP-Codes?

von Christian F. (feuerwerk)


Bewertung
0 lesenswert
nicht lesenswert
Schwarze Opcodes? Du meinst die illegalen Opcodes?
Nein, derzeit noch nicht, genau wie meiner Implementierung noch der 
Decimal-Mode fehlt. Beides brauche ich für einen NES nicht, da keines 
der offiziellen Spiele illegale Opcodes verwendet. Nintendo hat da 
meines Wissens damals drauf geachtet. Nichts desto trotz will ich aber 
die CPU nochmal redesignen, sauberer programmieren und im Zuge dessen 
auch die sinnvollen illegalen Opcodes mit aufnehmen.

von Thomas Kindler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab' auch einen SID für FPGA geschrieben:

  https://github.com/thomask77/verilog-sid-mos6581

Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen. Läuft 
inkl. Filter usw. auf 20 MHz ATmegas

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christian F. schrieb:
> Schwarze Opcodes? Du meinst die illegalen Opcodes?
Solche Sachen wie LAX und n-Byte NOP.

Thomas Kindler schrieb:
> Ich hab' auch einen SID für FPGA geschrieben:
Demosounds verfügbar?

von Analoger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas Kindler schrieb:
> Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen
Hallo Thomas, ich wäre an dem Projekt interessiert. Wieviel Resourcen 
belegt der? Ich hätte Bedarf, für etwas Kompaktes. Der beste SID ist 
angeblich der resid_fp von Dag Lem, mit dem Verzerrer von Antti Lankila. 
Leider verschluckt der ziemlich Rechenleistung.

> Ich hab' auch einen SID für FPGA geschrieben:
> https://github.com/thomask77/verilog-sid-mos6581
Ich habe jetzt das Projekt von Andreas Beermann ins Auge gefasst, nur 
gibt es das noch nicht und wenn nur als fertigen Chip. Dein Projekt wäre 
mir schon symphatisch, allerdings ist es offenbar Verilog?

Das Projekt von Jürgen Schuhmacher läuft offenbar nur auf seiner 
speziellen Hardware.

C. A. Rotwang schrieb:
> Klar könnte man dessen Kennlinie auch in den
> Digitalbau einrechnen, aber das macht wohl auch keiner sondern begnügt
> sich mit Gefasel über verlorengangenen Herstellertechnologien.
Antti Lankila scheint das gemacht zu haben.

von Let the Muic Play (Gast)


Bewertung
1 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID,
> die Trommelfelle freiblasen:
Der war aber doch gar kein SoundChip sondern nur ein 8BIT-Wandler.

> Youtube-Video "Amiga Longplay  R-Type"
Nee Danke!

von Thomas Kindler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Analoger schrieb:
> Thomas Kindler schrieb:
>> Bei Bedarf kann ich auch noch mein SiD4AVR-Projekt rauskramen
> Hallo Thomas, ich wäre an dem Projekt interessiert.

Hier, bitte:

  https://gist.github.com/thomask77/9b87389fe6e69f733d525be96f2f96a0

Der Code ist im wesentlichen ein Port von TinySID (kb^farbrausch).

Phasenakku ist 16 statt 24 Bit. Nur ein 15-Bit LFSR als Rauschgenerator 
für alle 3 Kanäle. Auflösung 8 statt 12 Bit. Multimode-Filter ist 
ebenfalls ein wenig abgespeckt, klingt aber super!

> Wieviel Resourcen belegt der?

Auf einem ATmega168 @ 20 MHz und 31250 Hz Abtastrate ca. 90% CPU-Zeit.

Soundausgabe am einfachsten über PWM-Pin und RC-Tiefpass.

Die SID-Registerzugriffe hatte ich per UART von einem PC-SID-Player 
übertragen.

Wenn man auf 15625 Hz runter geht, ist sogar genug Zeit für 
6510-Emulation übrig. Allerdings nur mit Tricks - man braucht z.B. eine 
Virtual-Memory-Tabelle mit Copy-on-Write, weil der ATmega nur 16k 
Speicher hat. Viele Sid-Tunes schreiben aber nur auf die Zero-Page + 
einige wenige weitere 256-Byte-Seiten.

Kann ich bei Interesse ebenfalls raussuchen.

Mit AVR-Assembler kann man bestimmt noch was rausholen.


Jürgen S. schrieb:
>> Ich hab' auch einen SID für FPGA geschrieben:
> Demosounds verfügbar?

Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h. 
knackiger, aber nicht unbedingt Originalgetreuer Sound.

Bei SiD4AVR ging's mir um die Machbarkeit, weil alle anderen AVR-SIDs 
eher nicht so toll waren (z.B. fehlten fast immer die Filter). Die 
FPGA-Variante war ein Lernprojekt, weil ich mal was mit Verilog machen 
wollte. Kein Anspruch auf 100% Emulation oder so.

Viele Grüße,
Thomas

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Let the Muic Play schrieb:
> C. A. Rotwang schrieb:
>> Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID,
>> die Trommelfelle freiblasen:
> Der war aber doch gar kein SoundChip sondern nur ein 8BIT-Wandler.

Klar ist das ein Soundchip, wie auch eine Wavetable-Soundcard bspw. 
Gravis Ultrasound wie eine AdLib-Sound-Blaster Soundcards sind, auch 
wenn die Tonerzeugung eine komplett andere ist.

Du meinst wahrscheinlich das der SID im Gegensatz zur PAULA ein 
(analoger) Synthesizer ist. Damit hast natürlich recht, und 
wahrscheinlich ist das das Problem bei der Emulation.
Da muss man schauen wie weit das konzept der wertdiskreten Zeitreihe mit 
nachgeschaltetenen Bandbreitenbegrenzenden Filter fester 
Grenzfreqquenzcharakteristik (AD-Antialaising(Glättungs)-filter) 
überhaupt trägt. Vielleicht wäre es ja sinnvoll die Audio-quellen im 
Frequenzbereich also als Spektrallinien zu geneieren und erst nach dem 
Mischen über eine inverse Fouriertransformation in den Zeitbereich zu 
wechseln? Oder wenn schon Zeitbereich dann mit hoher Auflösung (i.e. 16 
statt 8 bit)?

Ob es dann auch so klar klingt wie Orchester aus 16 sinus-genratoren?
Youtube-Video "Jeroen Tel - "Stranglehold" (XM) [Oscilloscope View]"

von Thomas Kindler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Du meinst wahrscheinlich das der SID im Gegensatz zur PAULA ein
> (analoger) Synthesizer ist. Damit hast natürlich recht, und
> wahrscheinlich ist das das Problem bei der Emulation.

Bis auf Filter und DAC ist der SID ein (für die damalige Zeit) recht 
moderner, digitaler Synthesizer.

Dreieck/Sägezahn/Square werden mit 12 Bit Auflösung direkt aus einem 24 
Bit Phasenakku erzeugt, Noise per LFSR.

Nur bei gleichzeitiger Auswahl von mehreren Wellenformen gibt es auch im 
Digitalteil ein paar Quasi-Analoge Dreckeffekte durch ein billig 
designtes Wired-AND.

Siehe auch:

  http://sid.kubarth.com/articles/interview_bob_yannes.html

C. A. Rotwang schrieb:
> Da muss man schauen wie weit das konzept der wertdiskreten Zeitreihe mit
> nachgeschaltetenen Bandbreitenbegrenzenden Filter fester
> Grenzfreqquenzcharakteri[.....]

Das sind alles gelöste Probleme: Digitalteil ist durch Chipfotos bis auf 
Gatterebene bekannt, und der Filter wird von resid_fp exzellent 
nachgebildet.

Das ist halt eher was für'n PC oder Raspi, weil Rechenaufwand. Der 
einfache TinySID-Filter "klingt" auch sehr gut.

von Soul E. (souleye)


Bewertung
1 lesenswert
nicht lesenswert
Mit dem SwinSID gibt es eine ganz passable SID-Emulation auf Basis eines 
Atmel AVR. Das Ding kann man direkt in den Sockel eines C64 setzen.

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Kindler schrieb:
> Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h.
> knackiger, aber nicht unbedingt Originalgetreuer Sound.

Ich hätte gerne mal ein Beispiel gehört, vor allem wegen des Filters.

Analoger schrieb:
> Das Projekt von Jürgen Schuhmacher läuft offenbar nur auf seiner
> speziellen Hardware.

Nicht ganz, die abgebildete Hardware ist eigentlich der Analog-Ersatz 
für die DACs, von denen das erste PLD-System ja keine hatte. Die sind im 
FPGA natürlich emuliert, bzw. werden nicht gebraucht, um nur die 
Wellen/Kanäle mischen zu können. Das gilt auch für die Verzerrungen der 
urtümlichen Analogtechnik.

Der SID-FPGA entstand eigentlich dadurch, dass ich die 
"Orgelarchitektur" entsprechend auf 8 Bit/16 Bit erweitert habe. Meiner 
kann daher auch eine Wellenform mehr - einfach deshalb weil sie da war. 
Umgekehrt verwende ich auch nicht die Adressen, die der SID kennt. 
Deshalb hilft dir der FPGA so direkt nicht weiter. Man braucht auch die 
Ansteuerung davor.

Ich habe das später nicht mehr weiter ausgebaut, SID-Sound mache ich 
heute umgekehrt durch Degradation der Phasenvektoren und 
Amplitudenvektoren vor und nach den Synthesemodulen sowie durch 
Einstellen der Filter und Verzerrer. Der entspricht natürlich nicht dem, 
was weiter oben gelinkt wurde. Ist aber gebrauchsfähiger, weil die 
degradierten Sounds sehr dominant sind und man nicht alle Stimme zu hart 
braten darf ... jedenfalls nicht beim Trance.

Was ich gerne benutze ist das multiplexing/cattering, mit dem die 
Tonvervielfachung gemacht wurde, um Akkorde zu erzeugen. Das klingt 
gleich irgendwie nach C64 :-)

Als Beispiel das Hauptmotiv aus "Thunderstorm" mit SID-Emu-Stimmen aus 
der Pyra2 auf einem Cyclone III-System von 2008:
http://www.96khz.org/htm/polyphonicsynthesizercyclone3platform.htm

Das Ding war zum damaligen Zeitpunkt auch schon 10 Jahre alt und im 
Original mit einer AWE64 / EMU Audity gespielt, mit echtem Donnerhall 
aus Samples - konnte man ja als SoundFont laden.

SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging 
die Post damals mit den EMU-Chips und Wavetables ab.

von Thomas Kindler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Thomas Kindler schrieb:
>> Die FPGA-Variante sollte praktisch identisch mit TinySID sein. D.h.
>> knackiger, aber nicht unbedingt Originalgetreuer Sound.
>
> Ich hätte gerne mal ein Beispiel gehört, vor allem wegen des Filters.

http://freshmeat.sourceforge.net/projects/tinysid

von 6502 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SID-Pinkompatibel auf ARM Basis:

http://dzi.n.cz/8bit/armsid/index_en.php

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas Kindler schrieb:
> http://freshmeat.sourceforge.net/projects/tinysid
HM, also ich finde da leider keine Sounds. Die Links auf den Code und 
der Webseite gehen auch irgendwie ins Leere (?)
Ist aber nicht so wichtig.

von Mar.co (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging
> die Post damals mit den EMU-Chips und Wavetables ab.
Alles richtig aber ein Vergleich mit Produkten, die 20 Jahre auseinander 
liegen :-) und uhne einen SID hätte es vielleicht andere Synthesizer gar 
nicht gegeben.

Thomas Kindler schrieb:
> Das sind alles gelöste Probleme: Digitalteil ist durch Chipfotos bis auf
> Gatterebene bekannt, und der Filter wird von resid_fp exzellent
> nachgebildet.
Na ob man aus einem Chipfoto das Verhalten der Bauelemente 
rekonstruieren kann, wage ich doch zu bezweiffeln. Kann ich nicht 
einschätzen.

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
Mar.co schrieb:
> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
> rekonstruieren kann, wage ich doch zu bezweiffeln.

Ist möglich. So wurden u.a. die Mifare Classic-Karten analysiert.
Die ganze Rechentechnik des Ostblocks basierte darauf...

Im Übrigen gibt es einen Unterschied zwischen "Chipfotos" und "einem 
Chipfoto". Nämlich zumindest deren Anzahl. :-)

: Bearbeitet durch User
von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
>> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
>> rekonstruieren kann, wage ich doch zu bezweiffeln.
> Die ganze Rechentechnik des Ostblocks basierte darauf...
Abschleifen und die Foto-Masken rekonstruieren führt aber 
erfahrungsgemäß nicht zu völlig identischen Verhalten, da es einige 
Unterschiede zwischen U880 und Z80 gibt.
http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=11288

Kann natürlich sein, das der Tester am Schluss den Unterschied macht, 
wenn man dessen Programm nicht raubkopiert, selektiert man u.U. die 
falschen als einwandfrei ...

Oder nicht alle Verfahrensschritte lassen sich durch Rekonstruktion der 
Photo-Masken nachäffen wie Epataxie und selektive Ionen-Implantierung.

Und irgendwann werden die Strukturen zu klein als dass man sie noch mit 
einem Lichtmikroskop abfotografieren kann sondern nur noch mit dem 
Rasterkraftmikroskop abrastern.

Wenn ich mich recht erinnere, hat sich die DDR wohl noch an einem i386 
Nachbau nach dieser Methode versucht und ist ziemlich vollständig daran 
gescheitert, da es nicht gelang die Fehler die beim "Abfotografieren" 
entstanden Schritt um Schritt zu eliminieren, weil man daran scheiterte 
vom beobachteten Fehlverhalten an den CPU- Pins auf die Fehlkopierte 
Stelle in den Masken zu schliessen ... Oder vereinzelte  Hot spots 
sorgten für verkürzte Lebensdauer ...
Schliesslich lag der Transistorcount beim i386 bei 275 000, beim Z-80 
dagegen bei 8500 -> viel weniger Möglichkeiten, was "falsch" 
abzukopieren. Beim SID werden 2500 Transistoren geschätzt, also knapp 
halbsoviel wie die zugehörige CPU, wobei m.E. diese Schätzung für den 
SID zu hoch ist.

von Thomas Kindler (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Mar.co schrieb:
> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
> rekonstruieren kann, wage ich doch zu bezweiffeln. Kann ich nicht
> einschätzen.

Siehe auch:

  http://www.visual6502.org/
  http://www.visual6502.org/JSSim/index.html

Simulation auf Gatterebene, aus Chip-Fotos erstellt. Läuft direkt im 
Browser, mit x/z rein/rauszoombar.

Weitere Beispiele:

  http://www.righto.com/search/label/reverse-engineering

Man kann auch Firmen dafür anheuern, z.B.:

  https://zeptobars.com

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
>>> Na ob man aus einem Chipfoto das Verhalten der Bauelemente
>>> rekonstruieren kann, wage ich doch zu bezweiffeln.
>> Die ganze Rechentechnik des Ostblocks basierte darauf...
> Abschleifen und die Foto-Masken rekonstruieren führt aber
> erfahrungsgemäß nicht zu völlig identischen Verhalten, da es einige
> Unterschiede zwischen U880 und Z80 gibt.

Die DDR hatte andere Fertigungstechniken und -maschinen, deswegen 
handelt es sich nur sehr selten um exakte Kopien. Außerdem wurden auch 
andere Quellen für die Entwicklung benutzt - im Fall des Z80 zum 
Beispiel dessen Datenblatt. :-)

Ich dachte allerdings mehr an die russischen i8080-Klone und sonstige 
Chips.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich dachte allerdings mehr an die russischen i8080-Klone und sonstige
> Chips.

Hm, ich bin mir nicht sicher, ob die Ostblock-Rechentechnik mehr von den 
Clones aus der Sowjetunion oder von denen aus der DDR bestimmt wurde.

Die paranoiden sowjetischen Bürokraten behielten ihre (Top-)Chips lieber 
fürs eigene Militär geheim resp. exklusiv.
Daher nehme ich an, das der Ostblock eher auf  Z80 -Clones U880 (der 
aber selber ein i8080 Clone sein soll ?!) lief, als mit den russischen. 
Aber das ist nur ne persönliche Vermutung.

Dort kann man einiges zum Verhältniss DDR und SU Chipentwicklung finden: 
http://www.hait.tu-dresden.de/dok/bst/Heft_29_Barkleit.pdf

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Hmm. Der U880 ist der einzige Z80-Klon aus dem Ostblock (und ein echter 
Z80, mit weniger Bugs als das Original), sonst gab es nur den älteren 
KR580VM80A. Beide wurden jedenfalls in (Hobby-)Computern verwendet.

Danke für den Link!

: Bearbeitet durch User
von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas Kindler schrieb:
> Simulation auf Gatterebene, aus Chip-Fotos erstellt. Läuft direkt im
> Browser, mit x/z rein/rauszoombar.
Das ist ja nett! Cool!

Allerdings gibt es in Sachen Technologie ja einiges an Randbedingungen, 
die bei gleicher Geometrie zu völlig anderen Daten führen. An das Uni 
haben wir das mit Gauss simuliert und 3D-Modelle aus den Strukturen 
extrahiert. Da sind geringe Nuancen schon ausschlaggebend.

von Audio Freak (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Mar.co schrieb:
> Jürgen S. schrieb:
>> SID ist aus nostalgischen Gründen eine tolle Sache aber so richtig ging
>> die Post damals mit den EMU-Chips und Wavetables ab.
> Alles richtig aber ein Vergleich mit Produkten, die 20 Jahre auseinander
> liegen :-) und ohne einen SID hätte es vielleicht andere Synthesizer gar
> nicht gegeben.

Soweit ich mal gehört habe, hat der Entwickler des SID später auch bei 
der Creative Soundblaster Entwicklung mitgewirkt. Die lagen auch nur gut 
10 Jahre auseinander.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.