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
SID Sourcen für die Atmega gibt es einige, auch für einen Arduino Uno. Wird es ein Open-Source Projekt?
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
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
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 ;-)
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...
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
Ahja der absolute Wahnsinn! Die libsidplay hat tatsächlich eine VIC, CIA, ... Emulation! Auszug aus dem Code:
1 | / Set the ICs environment variable to point to |
2 | // this player
|
3 | Player::Player (void) |
4 | // Set default settings for system
|
5 | :CoUnknown<ISidplay2>("SIDPlay 2"), |
6 | CoAggregate<ISidTimer>(*iaggregate()), |
7 | c64env (&m_scheduler), |
8 | m_scheduler ("SIDPlay 2"), |
9 | cpu (&m_scheduler), |
10 | xsid (this), |
11 | cia (this), |
12 | cia2 (this), |
13 | sid6526 (this), |
14 | 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
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.
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
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
Angehängte Dateien:
-
stm.jpg
160 KB
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
>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.
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 ;)
Was sich ideal dazu eigen sind die Xmos µP es gab sogar mal ein Projekt hierzu. https://www.youtube.com/watch?v=NgI3g1nkkoI 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
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
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.
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 :-)
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
Ich schau morgen mal nach. Das waren auf jeden Fall DIL-ICs. Paula ja PLCC.
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! :)
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
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
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
>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.
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"?
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 :)
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.
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
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:
1 | // einfach irgendwie ein SID in das RAM laden (FsFAT)
|
2 | f_open(&MyFile, "MEGA.SID", FA_READ); |
3 | uint32_t size = f_size(&MyFile); |
4 | uint8_t *sidfile = (uint8_t*) malloc(size); |
5 | f_read(&MyFile, sidfile, size, (UINT*)&bytesread); |
6 | f_close(&MyFile); |
7 | |
8 | // hier gehts mit dem SID los
|
9 | sidplay2 Sidplay2; |
10 | |
11 | SidTune Tune(sidfile, size); |
12 | ReSIDBuilder ReSID(""); |
13 | Tune.selectSong(1); |
14 | |
15 | Sidplay2.load(&Tune); |
16 | sid2_config_t sid2config; |
17 | ReSID.create(1); |
18 | sid2config.frequency = 22050; |
19 | sid2config.emulateStereo = true; |
20 | sid2config.leftVolume = 255; |
21 | sid2config.rightVolume = 255; |
22 | sid2config.clockSpeed = SID2_CLOCK_PAL; |
23 | sid2config.optimisation = 1; |
24 | sid2config.sampleFormat = SID2_BIG_UNSIGNED; |
25 | sid2config.sidModel = SID2_MOS6581; |
26 | sid2config.forceDualSids = false; |
27 | sid2config.sidSamples = true; |
28 | sid2config.playback = sid2_stereo; |
29 | sid2config.environment = sid2_envPS; |
30 | sid2config.precision = 16; |
31 | sid2config.sidEmulation = &ReSID; |
32 | Sidplay2.config(sid2config); |
33 | |
34 | uint8_t *output = (uint8_t*) malloc(22050*2*2); |
35 | |
36 | // abspielen und mit dem output dann irgendwas machen
|
37 | for (int i=0;i<60;i++) { |
38 | Sidplay2.play(output, 22050*2*2); |
39 | }
|
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
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 :)
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
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!!
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
>Hoffe, ich hab deine Frage richtig verstanden.
Ähm, ich meinte eher, welchen SID-Player hast Du genommen? Hast Du
vielleicht einen Link zum Source?
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
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
>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.
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.
Angehängte Dateien:
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)
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.
>Here you are ...
Dankeschön :-)
Stecken da zwei SID-Emulatoren drinn? resid und libsidplay?
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
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?
>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?"
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: https://www.youtube.com/watch?v=po9IY5Kf0Mo Aber trotz allem sollte sich mal jemand trauen, sowas zu starten. Echter Team-Geist halt (TEAM = toll, ein anderer machts). :-)
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
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
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:
1 | "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"
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
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/
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
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
Angehängte Dateien:
-
quartus.png
42 KB
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
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
Ja, das Teil finde ich auch super. Am liebsten hätte ich eins. Hier wurde ein Thread dazu angefangen: Beitrag "6502 selfmade CPU"
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 :)
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
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
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
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
Mampf F. schrieb: > Kleiner Zwischenstand ... Music hört sich jetzt in Ordnung an, Bezieht sich das jetzt auf die Microcontroller- oder die FPGA-Version?
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^^
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^^
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
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?
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
>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.
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
Angehängte Dateien:
-
SIDs_Werksneu_sml.jpg
66 KB
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
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
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
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
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
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
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.
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.
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 ... :)
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
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.
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
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 :)
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
Hier gibt es eine Kollektion von SID-Stücken: https://www.youtube.com/watch?v=U9Racui9jJI Die meisten um 1988. Wie wohl modernere Stücke klingen würden?
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.
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... ;-(
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: https://www.youtube.com/watch?v=-3pGP1a3JRw
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.
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.
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.
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 ;-)
>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. https://www.youtube.com/watch?v=-3pGP1a3JRw 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.
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 ;-) https://youtu.be/uhIEfxRLiPI?t=37 Und Persönlich lass ich mir lieber vom Amiga, also von PAULA statt SID, die Trommelfelle freiblasen: https://youtu.be/xmEhC91k3MI?t=61 https://youtu.be/1N-iV7NHWJQ?t=37 Obwohl dieses Sample klingt, als ob da jemand vergessen hat, den 7kHz Analogfilter das A500 abzuschalten.
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.
Christian F. schrieb: > https://github.com/Feuerwerk/fpgaNES Das schaut interessant aus! Kann der auch schwarze OP-Codes?
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.
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
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?
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.
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!
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
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? https://www.youtube.com/watch?v=FpOM4Fs08kU&list=PLplgBDMGD07XTbgruf-OEaQf9Mk4KlQjL&index=72
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.
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.
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.
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
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.
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.
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
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.
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
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.
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
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
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.
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.